Category: Конспект тестувальника

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)	Перевірити, що кожен можливий перехід між станами був виконаний.
Покриття послідовностей переходів	Перевірка кількох переходів підряд, як вони працюють у комбінації.
Негативне тестування	Перевірка, як система реагує на неприпустимі дії в певних станах.

Приклад тест-кейсів

На основі попереднього прикладу з банкоматом:

Позитивний сценарій

• Передумова: Картка ще не вставлена.
• Кроки:
  1. Вставити картку.
  2. Ввести правильний PIN.
  3. Обрати операцію.
  4. Завершити сесію.
• Очікування: Транзакція проходить успішно, картка витягується.

Негативний сценарій

• Передумова: Картка вставлена.
• Кроки:
  1. Ввести 3 рази неправильний PIN.
• Очікування: Акаунт блокується, транзакції недоступні.

Переваги State Transition Testing

Допомагає знайти:

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

Добре підходить для:

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

State Transition Testing — це важливий метод тестування, який дозволяє перевірити поведінку системи в різних станах, враховуючи попередні дії користувача. Ця техніка вимагає чіткого розуміння логіки додатку і дозволяє знайти помилки, які складно помітити при звичайному функціональному тестуванні.

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

• Умови (Conditions) — вхідні дані або ситуації
• Дії (Actions) — очікувана поведінка системи
• Правила (Rules) — комбінації умов, при яких відбуваються дії

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

Розглянемо простий приклад.

Приклад:

Умова: користувач може увійти в систему, якщо:

1. Ввів правильний логін
2. Ввів правильний пароль

Умови	Тест 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. Скорочення таблиці (оптимізація)

Іноді деякі комбінації дублюють результати або не мають сенсу — їх можна об’єднати або видалити.

Приклад: Надання знижки постійному клієнту

Умови:

№	Умова
C1	Клієнт є постійним клієнтом
C2	Сума замовлення перевищує 1000 грн

Дії:

№	Дія
A1	Надати знижку 10%
A2	Надати знижку 5%
A3	Не надавати знижку

Логіка дій:

Комбінація	Умови виконані	Знижка
Тест 1	Постійний клієнт + сума > 1000	10%
Тест 2	Постійний клієнт + сума ≤ 1000	5%
Тест 3	Непостійний клієнт + сума > 1000	5%
Тест 4	Новий клієнт, невелике замовлення	0%

Таблиця рішень

Умова	Тест 1	Тест 2	Тест 3	Тест 4
C1: Постійний клієнт	T	T	F	F
C2: Сума > 1000 грн	T	F	T	F
Очікувана дія	A1 (10%)	A2 (5%)	A2 (5%)	A3 (0%)

Переваги Decision Table Testing:

Перевага	Пояснення
Чіткість	Всі логічні умови систематизовані
Повне покриття	Кожна важлива комбінація умов врахована
Автоматизація	Таблицю легко перевести в автоматичні тести
Виявлення прогалин	Допомагає побачити, які варіанти не опрацьовані

Коли використовувати?

Ситуація	Decision Table Testing — підходить?
Багато вхідних умов	Так
Складні правила прийняття рішень	Так
Просте позитивне/негативне тестування	Краще Boundary Value чи Equivalence Partitioning
Бізнес-логіка (знижки, ролі, правила доступу)	Ідеально

Інструменти для створення таблиць:

• Excel або Google Sheets
• TestRail (та інші TMS)
• Draw.io або інші діаграмні редактори
• Mind maps (для візуалізації)

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. Тестування на граничних значеннях: Тестуються не тільки самі межі (наприклад, 1 і 100), а й значення, що знаходяться безпосередньо біля меж:
   • 1 (мінімальна межа)
   • 100 (максимальна межа)
   • 0 (одне значення нижче мінімуму)
   • 101 (одне значення вище максимуму)
   • 2 (мінімальна межа + 1)
   • 99 (максимальна межа – 1)
2. Порівняння результатів: Різні варіанти тестів дозволяють виявити, чи система правильно працює в межах допустимого діапазону, а також чи правильно реагує на значення, що виходять за межі цього діапазону.

Тестування для діапазону дійсних чисел:

• Діапазон: від 0.0 до 10.0 (включно)
  • Тестові значення:
    • 0.0 (мінімум)
    • 10.0 (максимум)
    • -0.1 (менше мінімуму)
    • 10.1 (більше максимуму)
    • 0.1 (мінімум + 0.1)
    • 9.9 (максимум – 0.1)

Типи помилок, які можуть бути виявлені

1. Неправильна обробка граничних значень: Наприклад, програма може неправильно працювати, якщо мінімальне або максимальне значення не обробляється належним чином (наприклад, програма приймає 0, хоча повинна відкидати ці значення).
2. Помилки округлення: У випадках з дійсними числами можуть бути проблеми з точністю значень на межах, що також виявляється під час тестування крайніх значень.
3. Пропущена перевірка значень за межами діапазону: Іноді система не має механізму для обробки значень, що виходять за межі допустимого діапазону (наприклад, якщо програма не перевіряє, чи число не більше за 100 або не менше за 1).

Переваги BVA:

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

Недоліки:

• Обмеженість: Не завжди можна повністю охопити всі проблеми лише тестуванням граничних значень. Наприклад, BVA не допоможе виявити логічні помилки, які можуть виникати на середніх значеннях або при складних умовах.
• Не замінює інші методи тестування: Для комплексних програм або складних бізнес-логік, BVA слід комбінувати з іншими методами тестування.

Підсумки

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

Equivalence Class Partitioning (ECP) (розбиття на еквівалентні класи) — це метод тест-дизайну в тестуванні програмного забезпечення, який дозволяє зменшити кількість тестів, зберігаючи при цьому хороше покриття.

Суть методу:

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

Приклад:

Уявімо, що ми тестуємо форму, яка приймає вік користувача (від 18 до 60 років).

Можливі класи еквівалентності:

Тип класу	Діапазон	Опис
Допустимий	18–60	Валідні значення віку
Недопустимий	< 18	Занадто малий вік
Недопустимий	> 60	Занадто великий вік

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

• 25 (допустимий клас)
• 17 (менше мінімуму)
• 61 (більше максимуму)

Навіщо використовувати ECP?

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

Застосування:

ECP часто використовується разом з іншими техніками, наприклад:

• Boundary Value Analysis (BVA) — аналіз граничних значень
• Decision Table Testing — тестування за таблицею рішень

Техніки тестування “чорної скриньки” (Black box testing techniques) — це підхід до тестування програмного забезпечення, при якому тестувальник не має доступу до внутрішнього коду або структури програми. Вся увага зосереджена на перевірці функціональності та взаємодії між користувачем і системою, без знань про те, як саме реалізовані ці функції.

Основні техніки тестування чорної скриньки:

1. Тестування еквівалентних класів (Equivalence Class Partitioning): програму тестують шляхом поділу вхідних даних на класи еквівалентності. Кожен клас містить такі ж або подібні значення. Якщо програма коректно обробляє одне значення з класу, можна вважати, що вона коректно обробляє всі інші значення цього класу.
2. Тестування граничних значень (Boundary Value Analysis): це техніка тестування, де перевіряються крайні значення вхідних даних. Зазвичай помилки найчастіше виникають саме на межах допустимих значень. Наприклад, якщо програма приймає числа від 1 до 10, то тестувальник може перевірити значення 1, 10, а також значення, які знаходяться поруч: 0, 11.
3. Тестування таблиць прийняття рішень (Decision Table Testing): використовується для систем, де вхідні дані можуть мати кілька можливих комбінацій, що призводять до різних результатів. Тестувальник створює таблицю, в якій зазначені всі можливі комбінації вхідних значень і відповідні результати для кожної з них.
4. Тестування переходів станів (State Transition Testing): у випадку програм, які мають різні стани (наприклад, система, яка переходить від одного стану до іншого в залежності від подій), тестувальник перевіряє, чи система коректно реагує на події, що викликають зміну стану.
5. Тестування на основі сценаріїв використання (Use Case Testing): тестування фокусується на перевірці, чи система виконує необхідні операції для користувача в рамках певних сценаріїв. Це допомагає перевірити, чи система відповідає вимогам і чи забезпечує належний досвід користувача.

Переваги тестування чорної скриньки:

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

Недоліки:

• Не дозволяє виявити помилки в коді — оскільки тестувальник не має доступу до коду, він не може виявити проблеми, які пов’язані з внутрішньою логікою або архітектурою програми.
• Обмеженість тестових випадків — неможливо протестувати всі можливі варіанти роботи системи, тому тестування часто є неповним.

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