Аналіз процесу ручного створення функціональних тестів

 

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

В найзагальнішому наближені процес створення тестового набору відбувається за наступним алгоритмом:

1. Визначення області перевірки

2. Аналіз функціональних вимог до цільової системи

3. Визначення вимог до повноти тестового покриття

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

5. Формування тестових наборів

 

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

Визначення масштабу тестування є необхідним, щоб визначити, що буде перевірятися, а що – ні.

 

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

У сучасній програмній інженерії функціональні вимоги до програмного забезпечення існують у різних формах в залежності від моделі розробки продукту, зрілості процесу в компанії і ризиків, що несе продукт. Їх форма може набувати як форми документу, строго відповідного стандартизованому шаблону - IEEE 830 [2], так і форми користувацьких історії, занотованих на картках формату 3 на 4, що практикується у гнучких моделях розробки, або просто не задокументованих знань учасників проектної команди – експертів, аналітиків та проектувальників.

У більшості випадків вимоги представлені у неформальному вигляді – на природній мові, тобто такому який не може бути повністю оброблений автоматично.

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

 

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

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

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

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

Таким чином уточнюється друга підзадача дослідження – визначення повноти тестового покриття набором, побудованим автоматично.

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

 

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

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

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

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

Тестовий набор, побудований на основі технік тест дизайну, досягає покриття 60-75% операторів коду і 40-60% операторів вибору (операторів циклу, умовних операторів тощо), у той самий час як тестовий набір, побудований без залучення певних технік досягає покриття 30% операторів коду і лише 20% умовних операторів[4]

 

Аналіз граничних значень

Мета техніки аналізу граничних значення зосередити зусилля на потенційних помилках, що допущені на границях умов (наприклад, розробник міг вказати >, коли необхідна вимога > або =).

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

 

 

Рис. 1.5 Техніка аналізу граничних значень

 

Тестовий набір, побудований за даною технікою, для діапазонів зображених на рис. 1.5, повинен включати тести на перевірку значень 0,1,99,100.

Розбиття на еквівалентні класи

За цим методом уся область вхідних (вихідних) даних розділяється на класи даних, з припущенням, що всі представники одного класу оброблюються додатком однаково. Цей метод використовується для досягнення двох цілей:

· зменшення тестових випадків у наборі

· для вибору правильних тестів, що покривають усі можливі сценарії

 

Один тест значення взяв з кожного класу під час тестування.

 

 

Рис. 1.6 Техніка розбиття на еквівалентні класи

 

Тестовий набір для вимог на рис. 1.6, побудований за цією технікою повинен містити тести на перевірку значень -1 (лівий діапазон некоректних даних); 25 (діапазон коректних даних); 105 (правий діапазон некоректних даних).

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

 

Діаграма станів і переходів

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

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

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

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

Третя підзадача для роботи – побудова тестів на основі формальної моделі.

 

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

Остання під задача – формування тестового набору.

 

Таким чином загальна задача дослідження – автоматична генерація функціональних тестів для додатків з графічним інтерфейсом для ручного виконання може бути декомпозована на наступні під задачі:

 

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

 

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

Побудова тестів на основі моделі. Вибір техніки для побудови тестів на основі формальної моделі.

 

Формування тестового набору. Розробка алгоритму формування тестового набору.

ВИСНОВКИ

 

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

 

 

СПИСОК ЛІТЕРАТУРИ

1. Cost Benefits Analysis of Test Automation, Douglas Hoffman, Software Quality Methods, LLC; Douglas Hoffman, 1999. – 14 с.

2. IEEE 830.1998 IEEE Recommended Practice for Software Requirements Specifications. Approved 25 June 1998. IEEE-SA Standards Board.

3. ISO/IEC 9126 Software engineering

4. FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION. Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black.

5. Certified Tester Foundation Level Syllabus. Version 2010. P.: International Software Testing Qualification Board