3. Проектування процесу тестування модулів застосувань

Розробка тестів :

• розробка і підтримка автоматизованих тестів (automated test cases), інструментів і скриптів;

• проведення тестів з метою визначення стану проекту;

• управління билдами (manage the build process).

Звітність про тести:

• доведення до зведення проектної групи інформації про якість продукту;

• моніторинг знайдених помилок з метою забезпечення їх залагоджування до випуску продукту.

Планування тестів. Ця область компетенції (планування тестів - test planning) ролевого кластера "Тестування" формулює методологію знаходження і врегулювання проблем якості продукту.

Команда тестувальників розробляє плани і методики тестування і таким чином формує стратегію, використовувану в проекті для тестування рішення. Плани тестування включають опис типів тестів, тестованих складових і інформацію про необхідні ресурси (як людських, так і технічних).

Істотна частина роботи цієї області компетенції полягає в участі у виробленні необхідного рівня якості (quality bar) продукту. Ця діяльність включає надання проектній групі метрик контролю якості і критеріїв успішності вирішення.

Ще один рід діяльності, здійснюваний цією областю компетенції, полягає в розробці специфікацій тестів. Його суть - в детальному описі інструментарію і програмного коду, необхідних для виконання плану тестування.

Розробка тестів. Ця область компетенції (розробка тестів - test engineering) відповідальна за передбачені планом тестування заходи, спрямовані на знаходження і врегулювання усіх проблем якості створюваного продукту. У їх числі - робота із створення і підтримки тестових сценаріїв (test cases), розробка засобів, скриптів і документації процесу тестування, управління щоденними билдами (daily builds), проведення на них тестів з метою чіткого визначення рівня завершеності продукту.

Звітність про тести. Ця область компетенції (звітність про тести - test reporting) забезпечує проектну групу інформацією про поточні вади в рішенні, так само як і про досягнуті успіхи. Завдяки цьому проектна група має чітку картину поточного стану розробки.

Щоб усі знайдені проблеми були дозволені до остаточного випуску продукту, проводиться їх моніторинг (tracking). Регулярно здійснюється документування стану проблем (включаючи завдання по їх дозволу, пріоритети, методи врегулювання і можливі шляхи їх обходу), що дозволяє проектній групі постійно мати поточні дані про якість продукту і детальний аналіз тенденцій його зміни.

Таким чином, при розробці стратегії (чи загального плану тестування) проектувальник повинен спиратися на прийняті в організації стандарти розробки систем. Якщо він спирається у своїй роботі на використання моделі проектної групи MSF, то повинен формулювати пункти стратегії тестування відповідно до вищевикладених вимог по організації роботи ролевого кластера "Тестування".

На закінчення розділу розглянемо деякі практичні рекомендації проектувальникам бази даних при розробки стратегії тестування.

Стратегія тестування - це план проведення робіт по тестуванню системи або її модуля, що зважає на специфіку функціональності і взаємозалежності з іншими компонентами системи і платформи. Стратегія визначає типи тестів, яких треба виконувати для цього функціонала системи, включає опис необхідних підходів з точки зору цілей тестування і може задавати описи або вимоги до необхідних для проведення тестування інструментів і інфраструктури.

Стратегія тестування повинна відповідати на наступні питання:

• Як, яким чином тестування дасть відповідь, що цей функціонал працює?

• Що треба зробити і чим користуватися з інструментальних засобів, для досягнення цілей тестування?

• Коли певний функціонал тестуватиметься і, відповідно, коли чекати отримання результатів?

Як додаткове завдання, яке вирішується в процесі розуміння стратегії тестування, можна розглядати завдання мінімізації витрат на тестування.

Із стратегії тестування органічно виписується план тестування. Шаблони планів тестування, пропоновані різними методологіями, частенько прямо включають одним з розділів опис стратегії тестування або ж включають опис стратегії в пункти плану, що відповідають за тестування конкретних частин функціонала. Приміром, шаблон методології Rational Unified Process визначає стратегію тестування як найбільший розділ плану тестування.

Замовник частенько хоче контролювати процес тестування і бачити розуміння завдання тестування виконавцями за проектом. Для нього стратегія тестування - це менш детальний документ-бачення того, як тестуватиметься система в процесі розробки.

При розробці стратегії тестування для розподіленої системи з базою даних проектувальникові бази даних треба виділити основні області, які можуть тестуватися окремо один від одного. Для тестування складних систем також корисно виділяти не лише оперативні кроки по тестуванню (тобто що, як і де тестуватиметься), але і проводити аналіз тактичних кроків по тестуванню з урахуванням розвитку системи в часі.

Приклад. Проведемо орієнтовне розбиття функціональності на тестові області, з тим щоб зрозуміти, як спланувати тестування і мінімізувати витрати.

Нехай система має "товстого" клієнта, сервер застосування і сервер бази даних, які можуть функціонувати на різних фізичних платформах. Основна логіка введення/виводу, перевірки даних і побудови звітів зосереджена на клієнтові, сервер застосувань забезпечує необхідну сервісну логіку (автоматична архівація даних, сповіщення користувачів про позаштатні ситуації і так далі), а база даних забезпечує, окрім безпосереднього зберігання даних, певну частину обробки даних, що реалізовується, приміром, у вигляді пакетів функцій.

Для простоти припустимо, що система має фіксовану конфігурацію для сервера бази даних і сервера застосувань. Клієнтське застосування працює під двома операційними системами з жорстко фіксованою конфігурацією компонентів. Як правило, завдання тестування формулюється на мові тестових сценаріїв, тобто для оцінки трудомісткості завдання або її частини використовується кількість тестів, необхідних для перевірки працездатності функціонала.

Клієнт: 50 тестів на роботу з даними (введення форм, розрахунок даних на основі даних, що зберігаються в словниках, пошук даних, редагування словників і тому подібне), 10 тестів на роботу з друкарськими формами (формування періодів вибірок, вибір типів звітів, друк або експорт в зумовлений список форматів і так далі). Нехай для тестування роботи з системою вимагається ще 5 тестів. Для перевірки функціональності, пов'язаної з самою операційною системою, буде потрібно (5 + 10)*2 = 30 тестових прогонів. Вважатимемо, що 50 тестових прогонів буде достатні для перевірки логіки роботи з даними. Підсумок - 80 тестових прогонів для тестування клієнта системи.

Об'єднаємо у рамках даного прикладу тестування функціональності сервера застосувань і бази даних. Нехай сервер застосування реалізує 20 команд по обробці цих і призначених для користувача сесій (без урахування роботи з системними пулами з'єднань, функцій стискування передаваного по мережі трафіку і тому подібне). Сервер баз даних реалізує 10 системних операцій по архівації даних, побудові статистики використання звітів і ще декілька подібних операцій. Загальний сенс полягає в тому, що ми маємо кінцевий набір тестованих операцій, і так як конфігурації визначені заздалегідь, можемо говорити про кінцевий набір тестів, яких необхідно виконати, щоб перевірити працездатність серверного функціонала системи. Підсумок - 30 тестів на серверній стороні. Помітимо, що в цьому прикладі ми не зачіпаємо складову навантаження тестування : йдеться тільки про функціональне тестування.

При розробці стратегії тестування проектувальник бази даних повинен враховувати, що, плануючи тестування, він не починає розбиратися з системою, а займається безпосередньо плануванням, виділенням ресурсів і термінів на конкретні завдання.

Тестування інформаційних систем є прикладною наукою, що бурхливо розвивається. Практика показує доцільність застосування CASE -средств для організації і проведення тестування. У списку літератури до лекції вказані джерела, які слід використовувати для поглибленого вивчення розробки планів тестування застосувань бази даних.