Взгляд со стороны поддержки на типовые проблемы приложений

Андрей Зоткин. EPAM Systems

Автор:

Andrey ZotkinSenior Software Testing EngineerEPAM Systems, Inc.Ryazan, RussiaEmail: Andrey_Zotkin@epam.comhttp://www.epam.com

Доклад подготовлен на основе реальных событий,

исходя из опыта нескольких лет тестирования и последующей поддержки

приложений,

опыт тестирования был целиком переосмыслен благодаря возможности

увидеть приложения в их реальной среде обитания в руках

пользователей.

Введение

• В ходе тестирования мы всегда стараемся представить как наше

приложение будет работать в реальных условиях и насколько полно

оно будет соответствовать тем целям, для которых его создавали.

• Всем нам хотелось бы, чтобы в руках пользователей оказалось

качественное приложение, удобное и эффективное.

• К сожалению, в реальных условиях это не всегда получается.

Так или иначе часто бывают упущены серьѐзные недоработки

требующие поддержки и исправления.

• Мы бы хотели поделиться опытом решения подобных проблем и

способами предотвращения типичных ошибок.

Цели и реальное положение дел

Цель – безошибочная стабильная работа

Реальное положение дел – далеко от идеала

Проблемы с

выводом в

промышленную

эксплуатацию

Множество

типовых

проблем

Дорогостоящая

поддержка и

снижение

выгоды от

внедрения

Неудобство

использования

Частые однотипные проблемы

• неудовлетворительная производительность

• непригодные/неудобные настройки UI – фильтрация,

сортировка, пользовательские параметры, подсказки и

справка

• обработка изначально некорректных входных данных –

отсутствие адекватной защиты от невалидных данных

• неполнота/некорректность логирования и трассировки

ошибок

• хардкод параметров/путей/настроек – чего могут стоить

изменения всего лишь пары сетевых путей

Неудовлетворительная производительность

неоправданно длительное время

запуска приложения

“висящие” гриды с большими

объѐмами данных

•

• затруднѐнный импорт/экспорт

• больших массивов информации

Неудовлетворительная производительность

Неудовлетворительная производительность

многочасовое построение

отчетов

медленная фильтрация по

всем параметрамили их сочетаниям

Неудовлетворительная производительность

Непригодные/неудобные настройки UIнеудобное отображение гридов

• по-умолчанию

сброс пользовательских настроек

интерфейса (рестарт, новый билд ..)

недоступность/неудобное расположение

элементов управления

(кнопок, тулбаров и т.д.)

отсутствие фильтров либо некорректная

фильтрация

отсутствие подсказок, контекстной

помощи, полноценной справки

Обработка некорректных входных данных

недостаточная защита от

ввода некорректных данных

вручную

непродуманный алгоритм

загрузки данных из файлов

система

Входные

данные

Неполнота/некорректность логирования и трассировки

ошибок

лог или трейс отсутствуют либо не

отображают необходимого

логируется всѐ, но в непригодной

форме

лог/ трейс за большой период не

может нормально отобразиться

требуется архивация, очистка данных

за период)

Хардкод параметров/путей/настроек

нет UI для важных

непрозрачность словарей в

БД

хардкод констант,

каталогов, имѐн linked servers

в хранимых процедурах

Система

Хардкод таймаутов/настроек

настройки

администрирования,

просмотр/обновление

словарей

параметры,

логины/пароли,

каталоги,

маски имѐн

Клиентское

приложение

(UI)

БД

Сервис

Как мы могли бы избежать этих проблем

• Выявление проблем и особенностей на стадии анализа,

тестирование функциональных и нефункциональных требований

• code review

• обязательное тестирование под нагрузкой

• preUAT , UAT, PAT

• тестовые данные максимально приближенные к настоящим

Выявление архитектурных проблем на ранних стадиях

Система

Прирост??………..

Узкие места по

производительности??

Тестирование требований на

этапах их подготовки

через N летДАННЫЕ

(в начале)

Функциональные

требования

Нефункциональные

требования

Гриды,

фильтры

Логирование

Отчеты

Code review

обязательное полноценное

периодическое code review

CODE REVIEW ревью хранимых процедур

тестировщиками

Код

клиентской

части

Код

сервисов

Хранимые

процедуры

и функции

Обязательное тестирование под нагрузкой

тестирование

производительности и

нагрузочное тестирование

обязательно в плане работ

объѐмы данных заранее

утверждены и согласованы с

заказчиком

чѐтко определѐнные показатели

системы по итогам тестирования

производительности

(что система может и что от неѐ

ждать не стоит)

PreUAT , UAT, PAT

preUAT – тестирование основных

кейсов поставки в среде UAT силами

тестировщиков

UAT (User Acceptance Testing) –

приѐмочное тестирование

системы пользователями

в среде заказчика

PAT - тот же Acceptance Testing –

но в среде Production

(опытная эксплуатация в «боевой»

среде на реальных данных)

Система

(PAT)

Система

(preUAT,

UAT)

тестировщики

пользователи

Тестовые данные максимально близкие к реальным

реальные данные со стороны

заказчика или утверждѐнный

способ их подготовки

полнота кейсов и

адекватный объѐм тестовых

данных

конфиденциальные данные

должны быть корректно

замаскированы, настройки и

словари - без маскировки

Реальные данные и

настройки из

промышленной

эксплуатации

Идентичные

настройки и данные

словарей

Тестовые данные

(замаскированные)

Как можно облегчить жизнь заказчику и упростить

поддержку

• инструкции по установке

(наличие, поддержание актуальности)

• вся новая функциональность должна быть

задокументирована (FD, UserGuide)

• контроль версионности поставок и функционала

(особенно для исправлений на PROD)

Инструкции по установке

каждая поставка с билдом должна

иметь актуальную инструкцию по

установке

все шаги должны быть чѐтко

описаны, обязательность шага

должна быть выделена особо

новая система/версия может

потребовать максимально

полной инструкции

Своевременное документирование новой

функциональности

- документация должна быть

поставлена одновременно с новой

версией а не «задним числом»

- кроме FD/спецификации

желательно наличие

UserGuide , при этом – наличие

одного документа никак не может

исключать необходимость другого

Контроль версионности поставок и функционала

контроль функциональности по

версиям – что какая версия должна

??? точно содержать

контроль версий с исправлениями,

упорядочивание фиксов/ патчей,

??? отслеживание версионности в БД

Ver.1.0 Ver.1.01..

Ver.2.0Fix 1.0089

Заключение

Мы надеемся, что все рассмотренные примеры помогут

вам взглянуть на свои приложения с новой стороны

и расширить границы понимания того, какие детали стоит

лучше продумать для счастливой жизни вашей системы в

руках её пользователей.

Возникли вопросы?

P.S. «Тестировщику полезно услышать крики пользователей»

(один из топ-менеджеров EPAM Systems)

Спасибо за внимание!