White Box Test Techniques (техніки тестування білої скриньки) — це підхід до тестування програмного забезпечення, при якому тестувальник має доступ до внутрішньої структури коду (наприклад, логіки, умов, циклів, змінних тощо) і використовує цю інформацію для розробки тестів.
Основна ідея:
Тестування здійснюється на основі знання коду — аналізуються всі гілки, логіка, шляхи виконання, що дозволяє виявити логічні помилки, прогалини в покритті або «мертвий код».
Основні техніки White Box Testing:
Coverage-based Testing (тестування на покриття):
Statement Coverage (покриття операторів) — перевіряє, що кожен оператор (рядок коду) виконується хоча б один раз.
Branch Coverage (покриття гілок) — перевіряє, що всі можливі гілки умов (if/else) були пройдені.
Condition Coverage— перевіряє, що кожна умова в логічному виразі приймала і true, і false.
Path Coverage (покриття шляхів) — перевіряє всі можливі шляхи виконання через програму.
Loop Testing — тестування циклів (наприклад, перевірити цикл при 0, 1 та багатьох ітераціях).
Control Flow Testing — аналіз керуючого потоку програми: як виконання переходить від одного блоку до іншого.
Data Flow Testing — аналіз, як дані передаються і змінюються в програмі (від моменту ініціалізації до використання).
Переваги:
Високий рівень покриття коду.
Виявлення «мертвого» або невикористаного коду.
Допомагає знайти логічні помилки.
Недоліки:
Не підходить для тестування без доступу до коду (наприклад, сторонніх сервісів).
Вимагає знань програмування.
Не покриває питання зручності інтерфейсу чи бізнес-логіки — тільки реалізацію.
Use Case Testing (Тестування на основі сценаріїв використання) — це метод тестування програмного забезпечення, при якому тестові сценарії створюються на основі use cases — описів того, як користувачі взаємодіють із системою для досягнення певної цілі.
Іншими словами, ми перевіряємо, чи працює система так, як її очікує бачити користувач у реальному житті.
Основи Use Case (варіанту використання)
Use Case — це сценарій взаємодії користувача з системою. Він включає актора, мету, передумови, основний потік, альтернативи, виключення.
Компонент
Опис
Актор
Хто використовує систему (користувач, адміністратор, інша система)
Мета (ціль)
Що актор хоче зробити
Передумови
Що має бути виконано до початку
Основний потік
Кроки, які ведуть до успішного завершення
Альтернативи
Інші варіанти виконання
Виключення
Що відбувається при помилці
Як проводиться Use Case Testing?
Крок 1: Збір use cases
Це може бути:
UML діаграми
Опис у вигляді тексту
Специфікація вимог
Наприклад, бізнес-аналітик створює документ із сценаріями, які повинен підтримувати продукт.
Крок 2: Аналіз варіантів використання
Визначаємо:
основні сценарії (успішне завершення)
альтернативні шляхи
виняткові ситуації (некоректні дії користувача, помилки системи)
Крок 3: Створення тест-кейсів
Для кожного сценарію створюються тест-кейси, які перевіряють:
правильність логіки
реакцію системи на помилки
обробку неочікуваних даних
взаємодію між різними компонентами
Приклад
Use Case: Авторизація користувача
Компонент
Деталі
Актор
Користувач
Мета
Увійти в систему
Передумова
Користувач має обліковий запис
Основний потік
1. Користувач вводить логін і пароль 2. Натискає “Увійти” 3. Система перевіряє дані 4. Система впускає користувача
Альтернативний потік
Пароль неправильний — показати помилку
Виключення
Сервер не доступний — повідомлення про помилку з’єднання
Одні й ті ж use cases використовуються BA, QA, Dev
Легше виявити інтеграційні помилки
Use cases часто охоплюють кілька модулів одночасно
Use Case Testing vs Інші типи тестування
Тип тестування
Орієнтація
Приклад
Use Case Testing
Бізнес-сценарії
Вхід користувача, замовлення товару
Unit Testing
Окрема функція
Перевірка функції login()
Functional Testing
Окрема функція/екран
Перевірка роботи форми логіну
Integration Testing
Зв’язки між модулями
Логін + перевірка прав доступу
Use Case Testing — це важливий підхід до тестування з точки зору користувача, який дозволяє протестувати реальні сценарії використання та підвищує якість програмного забезпечення, бо орієнтований на цілі.
State Transition Testing (тестування переходів станів) — це техніка тестування програмного забезпечення, яка використовується для перевірки поведінки системи, що змінюється в залежності від її поточного стану та дії користувача чи зовнішнього середовища.
Інакше кажучи: якщо система поводиться по-різному в залежності від того, в якому вона зараз стані, і що користувач робить, — тоді ця техніка застосовується для тестування логіки таких переходів.
Ключова ідея
Уявімо, що програма — це як машина, яка може перебувати в різних станах (наприклад: “не ввійшов у систему”, “авторизований”, “заблокований” тощо). Залежно від того, в якому вона стані, одна й та сама дія може мати різні наслідки.
Наприклад:
Якщо користувач вводить неправильний пароль вперше, нічого страшного.
Якщо він робить це третій раз підряд, — система може заблокувати обліковий запис.
Тобто, контекст (стан) має значення, і саме це ми тестуємо через State Transition Testing.
Основні поняття
Поняття
Пояснення
Стан (State)
Це поточне положення системи, що впливає на її поведінку. Наприклад: “увійшов”, “заблокований”, “чекає дії”.
Подія (Event/Input)
Це дія або вхідна інформація, що викликає зміну стану. Наприклад: введення пароля, натискання кнопки.
Перехід (Transition)
Це рух системи з одного стану до іншого під впливом події. Наприклад: з “неавторизований” до “авторизований”.
Дія (Action)
Це те, що система виконує у відповідь на подію: наприклад, показ повідомлення, блокування акаунта.
Коли варто застосовувати State Transition Testing?
Ця техніка доцільна, якщо:
Система має чітко визначені стани.
Поведінка системи змінюється в залежності від попередніх дій користувача.
Є умовні переходи, наприклад: лише після певної послідовності дій доступна певна функція.
Приклади систем, де це актуально:
Авторизація користувачів (введення логіну/паролю, блокування при помилках).
Автоматизовані системи (банкомати, автомати продажу квитків).
Ігри (стани гравця: живий, поранений, мертвий).
Веб-додатки з “мультисторінковим” введенням даних.
Приклад:
Сценарій: Банкомат (ATM) — тестування процесу авторизації користувача
Можливі стани:
S0: Очікування картки
S1: Введення PIN
S2: Авторизовано
S3: Заблоковано (після 3 неправильних PIN)
Можливі події / дії користувача:
Insert Card – вставити картку
Enter Correct PIN – правильний PIN
Enter Wrong PIN – неправильний PIN
Eject Card – витягнути картку
Таблиця переходів станів:
Поточний стан
Вхідна подія
Наступний стан
Коментар
S0
Insert Card
S1
Картку вставлено
S1
Enter Correct PIN
S2
Авторизація успішна
S2
Eject Card
S0
Картку витягнуто
S0
Insert Card
S1
Картку вставлено
S1
Enter Wrong PIN (1x)
S1
Перша помилка PIN
S1
Enter Correct PIN
S2
Авторизація успішна
S2
Eject Card
S0
Картку витягнуто
S0
Insert Card
S1
Картку вставлено
S1
Enter Wrong PIN (1x)
S1
Перша помилка PIN
S1
Enter Wrong PIN (2x)
S1
Друга помилка PIN
S1
Enter Correct PIN
S2
Авторизація успішна
S2
Eject Card
S0
Картку витягнуто
S0
Insert Card
S1
Картку вставлено
S1
Enter Wrong PIN (1x)
S1
Перша помилка PIN
S1
Enter Wrong PIN (2x)
S1
Друга помилка PIN
S1
Enter Wrong PIN (3x)
S3
Три помилки: блокування
Діаграма:
Типи покриття в State Transition Testing
Коли ми тестуємо переходи між станами, ми можемо будувати різні стратегії покриття, щоб перевірити всю логіку:
Тип покриття
Що означає
Покриття станів (State coverage)
Перевірити, що кожен можливий стан системи хоча б раз досягається.
Покриття переходів (Transition coverage)
Перевірити, що кожен можливий перехід між станами був виконаний.
Покриття послідовностей переходів
Перевірка кількох переходів підряд, як вони працюють у комбінації.
Негативне тестування
Перевірка, як система реагує на неприпустимі дії в певних станах.
Приклад тест-кейсів
На основі попереднього прикладу з банкоматом:
Позитивний сценарій
Передумова: Картка ще не вставлена.
Кроки:
Вставити картку.
Ввести правильний PIN.
Обрати операцію.
Завершити сесію.
Очікування: Транзакція проходить успішно, картка витягується.
State Transition Testing — це важливий метод тестування, який дозволяє перевірити поведінку системи в різних станах, враховуючи попередні дії користувача. Ця техніка вимагає чіткого розуміння логіки додатку і дозволяє знайти помилки, які складно помітити при звичайному функціональному тестуванні.
Decision Table Testing (Тестування таблиць прийняття рішень) — це техніка тест-дизайну, яка допомагає моделювати складні логічні умови системи. Вона базується на таблиці рішень, яка показує:
Умови (Conditions) — вхідні дані або ситуації
Дії (Actions) — очікувана поведінка системи
Правила (Rules) — комбінації умов, при яких відбуваються дії
Це дозволяє створювати тест-кейси, які покривають усі (або найважливіші) комбінації вхідних умов.
Розглянемо простий приклад.
Приклад:
Умова: користувач може увійти в систему, якщо:
Ввів правильний логін
Ввів правильний пароль
Умови
Тест 1
Тест 2
Тест 3
Тест 4
Логін правильний
T (True)
T (True)
F
F
Пароль правильний
T (True)
F (False)
T
F
Дозволити вхід
T (True)
F (False)
F
F
Етапи побудови таблиці рішень:
1. Визначення умов
Це всі вхідні змінні або умови, що впливають на результат.
Наприклад: чи користувач увійшов у систему, чи ввів правильний пароль тощо.
2. Визначення можливих значень умов
Зазвичай це True/False чи 0/1, але можуть бути й інші варіанти.
3. Визначення дій
Що має зробити система залежно від комбінації умов? Це можуть бути:
Виконати якусь операцію
Показати повідомлення
Заборонити доступ і т.д.
4. Формування правил
Кожна комбінація умов — це окреме правило (Rule), що призводить до певної дії або дій.
5. Скорочення таблиці (оптимізація)
Іноді деякі комбінації дублюють результати або не мають сенсу — їх можна об’єднати або видалити.
Boundary Value Analysis (BVA – аналіз граничних значень) — це техніка тестування, яка орієнтується на перевірку граничних значень для вхідних даних системи. Багато помилок у програмному забезпеченні часто виникають саме при роботі з даними на межах, тому тестування саме цих значень допомагає виявити критичні баги.
Чому саме граничні значення?
У програмному забезпеченні та алгоритмах часто зустрічаються випадки, коли значення змінної перевіряються на відповідність певному діапазону. Наприклад, перевірка на те, чи належить число до певного діапазону від 1 до 100.
Програмі або системі особливо важливо коректно обробляти значення, які знаходяться саме на межі цього діапазону (наприклад, 1 або 100), а також значення, які знаходяться прямо поруч (наприклад, 0 чи 101). Іноді проблеми виникають через те, що система неправильно обробляє такі значення або через помилки в межах умовних операторів.
Тому принцип BVA ґрунтується на тестуванні саме граничних значень і значень, що знаходяться поруч з ними, а не на випадкових значеннях із середини діапазону. Багато помилок стаються саме через неправильне трактування цих граничних значень.
Як працює Boundary Value Analysis?
Існує підхід із застосуванням для тестування 2 граничних значень. Також є підхід із застосуванням 3 граничних значень. Потрібно зрозуміти, які значення входять у допустимий діапазон для тестування.
Застосування 2 граничних значень:
Якщо є система, яка приймає вхідне число в діапазоні від 1 до 100, то тестувати слід:
1 (мінімальне значення)
0 (менше мінімуму — вихід за межі)
100 (максимальне значення)
101 (більше максимуму — вихід за межі)
Застосування 3 граничних значень:
Тестування на граничних значеннях: Тестуються не тільки самі межі (наприклад, 1 і 100), а й значення, що знаходяться безпосередньо біля меж:
1 (мінімальна межа)
100 (максимальна межа)
0 (одне значення нижче мінімуму)
101 (одне значення вище максимуму)
2 (мінімальна межа + 1)
99 (максимальна межа – 1)
Порівняння результатів: Різні варіанти тестів дозволяють виявити, чи система правильно працює в межах допустимого діапазону, а також чи правильно реагує на значення, що виходять за межі цього діапазону.
Тестування для діапазону дійсних чисел:
Діапазон: від 0.0 до 10.0 (включно)
Тестові значення:
0.0 (мінімум)
10.0 (максимум)
-0.1 (менше мінімуму)
10.1 (більше максимуму)
0.1 (мінімум + 0.1)
9.9 (максимум – 0.1)
Типи помилок, які можуть бути виявлені
Неправильна обробка граничних значень: Наприклад, програма може неправильно працювати, якщо мінімальне або максимальне значення не обробляється належним чином (наприклад, програма приймає 0, хоча повинна відкидати ці значення).
Помилки округлення: У випадках з дійсними числами можуть бути проблеми з точністю значень на межах, що також виявляється під час тестування крайніх значень.
Пропущена перевірка значень за межами діапазону: Іноді система не має механізму для обробки значень, що виходять за межі допустимого діапазону (наприклад, якщо програма не перевіряє, чи число не більше за 100 або не менше за 1).
Переваги BVA:
Зниження ймовірності помилок: Тестування на граничних значеннях допомагає виявити баги, які часто залишаються непоміченими при тестуванні випадкових значень.
Ефективність: Це досить ефективний спосіб тестування, оскільки він охоплює основні потенційно проблемні моменти без необхідності перевіряти всі можливі значення в межах діапазону.
Простота застосування: Метод є простим у реалізації, оскільки не потребує складних тестових випадків.
Недоліки:
Обмеженість: Не завжди можна повністю охопити всі проблеми лише тестуванням граничних значень. Наприклад, BVA не допоможе виявити логічні помилки, які можуть виникати на середніх значеннях або при складних умовах.
Не замінює інші методи тестування: Для комплексних програм або складних бізнес-логік, BVA слід комбінувати з іншими методами тестування.
Підсумки
Boundary Value Analysis — це важливий метод тестування, який дозволяє виявляти проблеми на граничних значеннях, де часто виникають помилки. Використання цього методу дає змогу перевірити важливі ситуації, які можуть залишитися непоміченими при тестуванні випадкових значень.
