Тема.  Процес тестування, документування та аналіз

результатів

План

1. Управління процесом тестування.

2. Структура процесу тестування.

3. Створення групи з тестування.

4. Розподіл обов’язків щодо виконання процесу тестування.

 

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

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

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

Роботи з тестування можуть керуватися різними міркуваннями і критеріями — від управління ризиками до специфікованих сценаріїв роботи програмних систем. У будь-якому випадку, бажано, виходячи з ресурсів, кількісних оцінок та інших характеристик, забезпечити використання різних технік тестування для багатосторонньої оцінки та поліпшення якості одержуваного продукту.

 

1.   Управління процесом тестування

(Test process management)

Роботи з тестування, що ведуться на різних рівнях, повинні бути організовані в єдиний процес, на основі врахування 4 елементів і пов’язаних з ними факторів:

ü  людей (в тому числі, в контексті організаційної структури і культури);

ü  інструментів;

ü  регламентів;

ü  кількісних оцінок (вимірів).

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

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

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

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

1.   Розрахунок тривалості виконання функцій шляхом збору середніх показників швидкості виконання операторів без виконання програми на машині. Виявляються компоненти, які вимагають великого часу на виконання в реальному середовищі.

2.   Управління виконанням тестування шляхом підбору тестів перевірки, їх виконання, селекції результатів тестування та проведення зіставлення з еталонними значеннями. Результати даного процесу відображаються на дисплеї, наприклад, у графічній формі (шляхи проходження по графу програми), у вигляді діаграм ИМЬ, даних про відмови і помилки або конкретних значень вихідних параметрів програми. Ці дані аналізуються розробниками для формулювання висновків про напрямки подальшої перевірки правильності програми або їх завершення.

3.  Планування тестування призначене для розподілу термінів робіт з тестування, розподілу тестувальників з окремих видів робіт та складання ними тестів перевірки системи. Визначаються стратегія та шляхи тестування. У діалоговому вікні ввести дані про реальні значеннях процесу виконання системи, структуру розгалуження вершин графа і параметри циклів. Перевірені цикли, як правило, вилучаються з шляхів виконання програми. Під час планування шляхів виконання створюються відповідні тести, критерії та вхідні значення.

 

2.   Структура процесу тестування

Під інфраструктурою процесу тестування розуміється:

Ø  виділення об’єктів тестування;

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

Ø  підготовка тестів, їх виконання та пошук різного роду помилок і відмов у компонентах і в системі в цілому;

Ø  служба проведення і керування процесом тестування;

Ø  аналіз результатів тестування.

Об’єкти тестування:

ü  компоненти;

ü  групи компонентів;

ü  підсистеми;

ü  система.

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

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

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

Тому кращим є метод «білого ящику», при якому можна використовувати структуру об’єкта для організації тестування з різних гілок. Наприклад, можна виконати тестові набори, які проходять через усі оператори чи всі контрольні точки компонента для того, щоб переконатися в правильності їх роботи.

 

3.   Створення групи з тестування

Внутрішні та незалежні команди (Internal vs. Independent test team)

Формалізація процесу тестування може включати й організаційну формалізацію команд тестування. У неї можуть входити як члени проектної команди, зокрема, які  розробляють код, так і зовнішні особи та групи. В ідеалі — бажано мати як внутрішню команду тестування, так і зовнішню групу тестування (забезпечення якості).

Відповідні організаційні рішення приймаються на основі вартісних характеристик проекту, доступних ресурсів, аналізу вартості тестування, як такого, організаційної культури і т.п.

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

 

4.    Розподіл обов’язків по виконанню процесу тестування

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

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

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

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

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

Тестові інженери створюють безліч тестових сценаріїв (Test Cases), кожен з яких перевіряє результат взаємодії між даними і системою. Сценарії, в основному відносяться до тестування по типу «білого ящика» і орієнтовані на перевірку структури і операцій інтеграції компонентів системи.

Для проведення тестування тестові інженери пропонують процедури тестування (Test Procédures), що включають валідацію об’єктів і верифікацію тестових сценаріїв відповідно до плану графіка. Оцінка тестів (Test Evaluation) полягає в оцінці результатів тестування, ступеня покриття програм сценаріями і статусу отриманих помилок.

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

 

Питання для самоконтролю:

1. Що потрібно для оцінки якості продукту.

2. Назвіть фактори для управління процесом.

3. Як Ви розумієте структуру процесу тестування.

4. Як створити групи з тестування.

5. Розподіл обов’язків щодо виконання тестування.