Техніки тест-дизайну: від теорії до практики. Частина 2

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, спільното! Мене звати Дмитро, я інженер із забезпечення якості (QA Engineer) у компанії GlobalLogic, і це вже друга стаття в циклі, у якому я розбираю техніки тест-дизайну та їхнє застосування на практиці. З першою частиною, де ми розібрали основи тест-дизайну, класифікацію технік та розв’язали задачі з техніками Black Box, можна ознайомитись за посиланням.

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

White Box техніки

Покриття операторів (Statement Coverage)

Statement Coverage — це одна з базових структурних (white-box) технік тест-дизайну, яка дозволяє перевірити, чи кожен оператор у програмному коді був виконаний хоча б один раз під час проходження тестів.

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

Ця техніка дозволяє:

• виявити мертвий код (який ніколи не виконується);
• забезпечити мінімальний рівень перевірки логіки;
• оцінити якість тестів з точки зору досягнення повного покриття.

Проте ця техніка не гарантує перевірку всіх можливих шляхів виконання програми або всіх умов (наприклад, умов в if чи while), лише самі оператори.

Приклад 1 — простий блок умовного оператора

def max_value(a, b):
     if a > b:
           return a
     else:
           return b

Цей код містить три оператори:

1. if a > b: — умовна перевірка;
2. return a — оператор у гілці if;
3. return b — оператор у гілці else.

Для досягнення 100% Statement Coverage потрібно хоча б один раз виконати кожен з цих трьох операторів. Це можливо, якщо ми протестуємо обидва варіанти — коли a > b і коли a <= b.

Обидва return-оператори виконані, тому досягнуто 100% Statement Coverage.

Приклад 2 — умовний блок із зайвим кодом

def check_number (n):
     if n > 0:
           print("Positive")
     print ("Done")

Оператори тут:

1. if n > 0: — умовна перевірка;
2. print("Positive") — оператор, що виконується, якщо умова істинна;
3. print("Done") — оператор, який завжди виконується.

Щоб досягти повного покриття, достатньо одного тесту, де n > 0.

Але якщо виконати лише n=-5, то print("Positive") не виконається — покриття буде лише 66%.

Приклад 3 — умовний блок з вкладеними операторами

def process_value (n):
     if x > 10:
           print("Greater than 10")
           if x % 2 ==0:
                print ("Even number")
     else
           print ("10 or less") 
     print ("End of processing")

У цьому фрагменті маємо 6 операторів:

1. if x > 10: — зовнішня умова;
2. print("Greater than 10″) — виконується при x > 10;
3. if x % 2 == 0: — вкладена умова;
4. print("Even number") — виконується, якщо x > 10 і x % 2 == 0;
5. print("10 or less") — виконується при x <= 10;
6. print("End of processing") — виконується завжди.

Щоб досягти 100% Statement Coverage, потрібно покрити всі оператори.

Лише комбінація трьох різних тестів дає повне покриття всіх операторів.

Рекомендації щодо побудови тестів

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

Переваги:

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

Обмеження:

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

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

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

• невеликих модулів із чіткою структурою;
• автоматизованих юніт-тестів;
• аналізу тестового покриття за допомогою інструментів (наприклад, coverage.py, JaCoCo, Istanbul).

Для кращого покриття логіки рекомендується поєднувати Statement Coverage з іншими структурними техніками, такими як Branch Coverage (Покриття гілок) або Condition Coverage (Покриття умов).

Покриття гілок (Branch Coverage)

Покриття гілок (Branch Coverage) — це структурна техніка тест-дизайну, яка забезпечує виконання кожної можливої гілки (true/false результатів) в умовних виразах програми хоча б один раз. Основна мета — перевірити, що кожне розгалуження (гілка) логічного виразу було протестовано.

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

Навіщо застосовується

• Виявлення логічних помилок, які можуть залишитись непоміченими при простому покритті операторів.
• Забезпечення тестування як позитивних, так і негативних сценаріїв.
• Покращення якості тестів у гіллястій логіці або умовних конструкціях (if, while, for, switch тощо).

Простий приклад

def check_discount (age):
     if age < 18:
           return "Child discount"
     else
           return "No discount"

У цьому коді є одна умовна конструкція if, яка має дві гілки:

• age < 18 → істина (True)
• age < 18 → хиба (False)

Мінімальний набір тест-кейсів для покриття гілок

Обидві гілки логіки були протестовані. Це забезпечує 100% branch coverage.

Ускладнений приклад з вкладеними умовами

def process_user (age, is_member):
     if age >= 18:
           if is_member:
                return "Adult member"
           else:
                return "Adult guest"
     else:
           return "Minor" 
 

Аналіз гілок:

• age >= 18: True / False
• is_member: True / False — виконується тільки якщо age >= 18

Мінімальний набір тест-кейсів

Завдяки цим трьом тест-кейсам досягається повне покриття всіх логічних гілок.

Складніший приклад: if-elif-else

def classify_score (score):
     if score >= 90:
           return "Excellent"
     elif score >= 75:
           return "Good"
     elif score >= 60:
           return "Satisfactory"
     else:
           return "Fail"

Мінімальний набір тест-кейсів

У цьому прикладі потрібні 4 тести, щоб досягти 100% branch coverage.

Приклад з конструкцією switch-case (match-case у Python 3.10+)

Python

def get_day_type (day):
     match day:
           case "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday":
                return "Weekday"
           case "Saturday" | "Sunday":
                return "Weekend"
           case _:
                return "Invalid"

Мінімальний набір тестів

Це забезпечує 100% покриття гілок усіх можливих шляхів у match-case.

Порівняння з Покриттям операторів (Statement Coverage)

Переваги:

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

Обмеження:

• Не гарантує покриття всіх можливих комбінацій умов у складних виразах (наприклад, if (A && B)).
• Може не виявити помилки логіки, пов’язані з певними комбінаціями змінних або граничними значеннями.
• У складних розгалуженнях кількість необхідних тестів може зростати експоненційно.

Рекомендації

• Варто застосовувати Branch Coverage для коду, що містить будь-які умовні конструкції, де поведінка залежить від логіки (наприклад, if, else, switch, while).
• Доцільно формувати мінімальний набір тест-кейсів, які перевіряють обидві гілки кожного логічного виразу (true і false), а також комбіновані розгалуження.
• Рекомендується використовувати інструменти автоматичного аналізу покриття, такі як coverage.py, JaCoCo, gcov, або відповідні засоби IDE, щоб мати точне уявлення про рівень покриття.
• Для умов зі складною логікою (кілька підумов або складені логічні вирази) варто проаналізувати можливість використання більш детальних технік: Condition Coverage або MC/DC.
• Не слід сприймати 100% branch coverage як повну гарантію відсутності дефектів — варто поєднувати його з функціональним тестуванням і техніками аналізу ризиків.

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

Покриття умов (Condition Coverage) та модифіковане покриття умов/рішень (MC/DC)

Покриття умов (Condition Coverage) — це техніка білого ящика, яка передбачає, що кожна елементарна умова в логічному виразі повинна приймати значення true та false хоча б один раз. Це дозволяє виявити помилки, пов’язані з окремими підумовами, навіть якщо вся складена умова не змінює свого результату.

MC/DC (Modified Condition/Decision Coverage) — це посилена форма покриття умов і рішень, яка, крім перевірки всіх можливих значень умов, вимагає, щоб кожна елементарна умова впливала на результат усього логічного виразу незалежно від інших умов. Це одна з найвимогливіших технік покриття, рекомендована, зокрема, для критичних систем (наприклад, у авіаційній галузі згідно DO-178C).

Простий приклад

Умовна логіка для надання доступу:

if (A && B)
     grantAccess();
else
     denyAccess();

Опис умов:

• A — користувач має права доступу
• B — користувач ввів правильний пароль

Таблиця істинності

Покриття умов (Condition Coverage)

Ціль: кожна умова (A, B) має бути true та false хоча б один раз.

Condition Coverage досягається з 3 тестами, але ми не знаємо, чи кожна умова справді впливає на результат рішення.

Модифіковане покриття умов/рішень (MC/DC)

Ціль: кожна умова повинна впливати на результат всього виразу.

MC/DC досягається з 3 тест-кейсами, але вибираються такі комбінації, які точно доводять незалежний вплив кожної умови.

Складніший приклад

Завдання: програма вирішує, чи надати користувачу преміум-функції:

if ((A || B) && C)
     enablePremium();
else
     denyPremium();

Опис умов:

• A — користувач є підписником
• B — користувач має промокод
• C — користувач пройшов верифікацію

Таблиця істинності (повна)

Покриття умов (Condition Coverage)

Мета — кожна умова має бути true та false хоча б один раз.

3 тести достатньо для досягнення Condition Coverage, але ми не гарантуємо, що кожна умова змінює результат логічного виразу.

Модифіковане покриття умов/рішень (MC/DC)

Мета — кожна умова має окремо впливати на результат рішення.

Побудова тест-кейсів

Для Condition Coverage:

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

Для MC/DC:

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

Переваги:

Condition Coverage:

• Простота реалізації.
• Швидке виявлення умов, які ніколи не приймають значення true/false.

MC/DC:

• Забезпечує високу якість покриття при відносно невеликій кількості тестів (у порівнянні з повним комбінаційним тестуванням).
• Доводить логічну незалежність кожної умови.
• Відповідає суворим вимогам сертифікації.

Обмеження:

Condition Coverage:

• Не гарантує, що кожна умова впливає на результат — може пропустити дефекти через приховані залежності.

MC/DC:

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

Техніки Condition Coverage і MC/DC є важливими інструментами білого ящика для тестування умовних конструкцій. Якщо перша дозволяє мінімальним зусиллям перевірити змінність кожної умови, то друга — гарантує її значущий вплив на логіку рішення. Вибір техніки залежить від контексту: прості системи можуть обмежитися Condition Coverage, тоді як системи з високими вимогами до безпеки та надійності потребують MC/DC.

Граф причинно-наслідкових зв’язків (Cause-Effect Graphing)

Техніка Cause-Effect Graphing базується на виявленні залежностей між вхідними умовами (причинами, causes) та вихідними діями (effects). Причини й наслідки представляються у вигляді графа з логічними зв’язками (AND, OR, NOT), який потім перетворюється на таблицю рішень, на основі якої створюються тест-кейси.

Ця техніка застосовується тоді, коли:

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

Простий приклад

Умова: користувач отримує доступ до системи, якщо:

• Введено правильне ім’я користувача (C1)
• Введено правильний пароль (C2)
• Акаунт не заблоковано (C3)

Ефект: доступ надається (E1)

Логіка: E1 = C1 AND C2 AND C3

Складніший приклад

Умова: автоматична система бронювання квитків дозволяє підтвердити замовлення лише за наступних умов.

Причини:

• C1: Обрано рейс
• C2: Заповнено дані пасажира
• C3: Вибрано метод оплати
• C4: Банківська картка дійсна
• C5: Користувач прийняв умови договору

Ефекти:

• E1: Оплата проходить
• E2: Бронювання підтверджено

Логіка:

• E1 = C3 AND C4
• E2 = C1 AND C2 AND E1 AND C5

Техніка рекомендована для складної логіки або коли присутні вкладені залежності. Вона добре поєднується з Decision Table Testing, особливо на етапі побудови тест-кейсів. Формалізує складну логіку умов, дозволяє зменшити кількість тестів без втрати покриття та виявити неочевидні комбінації.

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

Типи систем: ERP, фінансові системи, банківське ПЗ, страхові сервіси, системи з великою кількістю логічних правил.

Графове тестування (Graph-based Testing)

Графове тестування базується на моделюванні поведінки системи у вигляді графа, де:

• Вершини (nodes) — стани або дії
• Дуги (edges) — переходи або події

Техніка дозволяє використовувати критерії покриття (вершин, дуг, шляхів), і застосовується в UI, workflow, процесах з послідовною логікою.

Приклад задачі

Користувач взаємодіє з вебмагазином, проходячи такі етапи:

• A: Головна сторінка
• B: Каталог
• C: Перегляд товару
• D: Кошик
• E: Оформлення
• F: Завершення

Побудова графа

Покриття та тест-кейси

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

Область застосування: інтерфейси, процеси з переходами, сценарії взаємодії.

Типи систем: вебзастосунки, мобільні застосунки, UI-орієнтовані продукти, системи з workflow.

Вибір техніки тест-дизайну

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

• Техніки, що ґрунтуються на специфікаціях (Black-box testing).
• Техніки, що ґрунтуються на структурі (White-box testing).
• Техніки, що ґрунтуються на досвіді (Experience-based testing).

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

Залежно від рівня тестування

• Unit testing — найбільш ефективні White-box техніки, такі як покриття операторів (Statement Coverage), покриття гілок (Branch Coverage).
• Integration testing — можуть застосовуватись Black-box техніки, такі як попарне тестування (Pairwise Testing) або техніка аналізу причинно-наслідкових зв’язків (Cause-Effect Graphing).
• System testing — підходять Black-box техніки: еквівалентне розбиття (Equivalence Partitioning), аналіз граничних значень (Boundary Value Analysis), тестування переходів станів (State Transition Testing).
• Acceptance testing — зазвичай застосовується тестування на основі чек-листів (Checklist-based Testing) або тестування на основі сценаріїв (Scenario-based Testing).

Залежно від типу системи

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

Залежно від доступної документації

• Якщо вимоги добре задокументовані — Black-box техніки, такі як еквівалентне розбиття та аналіз граничних значень.
• Якщо вимоги нечіткі або відсутні — дослідницьке тестування, тестування на основі чек-листів.

Залежно від доступного часу

• Якщо тестування обмежене у часі — застосовують попарне тестування (Pairwise Testing), яке дозволяє скоротити кількість тестових випадків, зберігаючи ефективне покриття.
• Якщо час не обмежений — можливе використання комбінації Black-box, White-box і дослідницьких технік.

Комбінація різних підходів для отримання оптимальних результатів

Комбінування технік дозволяє отримати більш надійні результати та підвищити ефективність тестування. Ось кілька рекомендованих комбінацій:

Еквівалентне розбиття + Аналіз граничних значень

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

Попарне тестування (Pairwise Testing) + Аналіз таблиць рішень

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

Тестування переходів станів + Граф причинно-наслідкових зв’язків

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

Дослідницьке тестування + Чек-лісти

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

Автоматизоване тестування + Ручне тестування

• Автоматизація ефективна для регресійного тестування та великих обсягів даних.
• Ручне тестування корисне для перевірки UX/UI, складних сценаріїв та несподіваних дефектів.

ISTQB рекомендує застосовувати комбінований підхід, що включає використання різних технік тест-дизайну для покращення ефективності тестування. Основні рекомендації ISTQB:

• Використовувати різні підходи залежно від рівня тестування (Unit, Integration, System, Acceptance).
• Не покладатися на одну техніку — комбінування Black-box, White-box та досвідних технік забезпечує кращу якість тестування.
• Застосовувати ризикоорієнтоване тестування — якщо система критична, застосовуються більш строгі техніки (наприклад, аналіз таблиць рішень, тестування станів).
• Автоматизація має доповнювати, а не замінювати ручне тестування — автоматизовані тести корисні для повторюваних завдань, але деякі аспекти (наприклад, UX) потребують ручного втручання.
• Документування тестового процесу — використання чек-листів, тестових сценаріїв і тестової стратегії допомагає покращити прозорість тестування.

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

Підсумки

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

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

Практика показує, що ефективне поєднання цих технік дозволяє не тільки зменшити кількість зайвих тестів, а й досягти високого покриття критичних сценаріїв, не залишаючи сліпих зон у перевірці. Наприклад, комбінація технік Boundary Value Analysis і Equivalence Partitioning забезпечує як функціональне, так і граничне тестування, а Pairwise Testing дозволяє скоротити кількість перевірок, не втрачаючи ефективності. Своєю чергою, Use Case Testing і Scenario Testing надають змогу побачити поведінку системи очима користувача, що особливо важливо під час приймального тестування. Техніки білого ящика дозволяють контролювати покриття на рівні коду — від окремих операторів до всіх можливих гілок логіки.

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

Корисні джерела

ISTQB Glossary of Terms
ISTQB Foundation Level Syllabus 4.0
ISTQB Foundation Level Sample Exam
ISTQB Advanced Level Syllabi

Testing Computer Software — Cem Kaner
The Art of Software Testing — Glenford J. Myers
A Practitioner’s Guide to Software Test Design — Lee Copeland
Foundations of Software Testing — Dorothy Graham

NIST SP 800-142: Introduction to Combinatorial Testing
Microsoft PICT Tool (Pairwise Testing)
AllPairs Tool
Pairwise Test Generator (online)

Test Automation University — Test Design Courses
Ministry of Testing — TestSphere, Heuristics
Software Testing Help — Test Design Techniques