Застосування методик тестування
Таблиці переходів станів
Таблиці переходів станів корисні і бізнес-аналітикам і проектувальникам систем, тому що дозволяють враховувати комбінації станів, подій і умов, які можна пропустити.
Для побудови таблиці переходів станів спочатку потрібно перерахувати всі стани з діаграми переходів станів (див. Рис. 1.) з прикладу, який розглядався в попередній статті.
Мал. 1. Діаграма переходів станів для програми електронної комерції
Далі потрібно перерахувати всі комбінації подій / умов з діаграми переходів станів. Далі створюється таблиця, в якій кожен рядок відповідає комбінації стану і кожної події / умови. Кожен рядок має чотири поля:
- Поточний стан;
- Подія / умова;
- Дія;
- Новий стан.
Для рядків, де діаграма переходів станів визначає дію і новий стан для заданих комбінацій поточного стану і події / умови, можна заповнити ці два поля (дія і новий стан) з діаграми переходів станів. Однак для інших рядків в таблиці вони не визначені.
Тепер можна йти до бізнес-аналітикам, проектувальникам системи або іншим учасникам і запитати: «Ну, що ж має статися в кожній з цих ситуацій?»
І швидше за все у відповідь ви почуєте: «А, така ситуація не станеться!». Але як тест-аналітик, ви знаєте, що це означає. І тепер ваше завдання показати, як це може статися.
На малюнку 2 зображено частину таблиці, яку можна створити для прикладу програми електронної комерції, який розглядався в четвертій статті цієї серії. Тут є 6 станів:
Також є 11 умов / подій:
- Пройти за посиланням;
- Додати в кошик;
- продовжити;
- виписати;
- Вхід [Невірний];
- Вхід [Вірний];
- Оплата [Успішно];
- Оплата [Невірно];
- Відміна;
- Продовжити покупки;
- Піти на інший сайт.
Мал. 2. Приклад таблиці переходів станів
Це означає, що повна таблиця переходів станів матиме 66 рядків - по одній для кожної можливого утворення пар окремих станів і окремих комбінацій подій / умов.
Для отримання набору тестів, який покриває таблицю переходів станів, можна слідувати наступній процедурі. Слід зауважити, що ми будуємо вже існуючий набір тестів, створений на основі діаграми переходів станів, для досягнення покриття станів / переходів або «покриття 0 переходів».
- Почнемо з набору тестів (включаючи правила початкового і кінцевого стану), отриманих з діаграми переходів станів, що дає покриття станів / переходів.
- Побудуємо таблицю переходів станів і переконаємося, що тести покривають всі «певні» рядки (визначені дію і новий стан). Якщо вони не покривають, то або невірно згенерований існуючий набір тестів, або невірно побудована таблиця переходів станів, або невірна діаграма переходів станів. Не можна продовжувати до тих пір, поки проблема не знайдена і не усунуто, включаючи створення таблиці переходів станів або набору тестів заново, якщо буде потрібно.
- Виберемо тести, що покривають стан, для якого в таблиці існує одна або більше «невизначених» рядків. Змінимо тести і спробуємо створити комбінацію подій / умов для «невизначеною» рядки. Зауважимо, що дія в цьому випадку не визначено.
- У міру зміни тестів, помічаємо рядки як покриті. Найпростіше зробити це, взявши роздруковану версію таблиці і, використовуючи олівець або маркер, позначати кожен рядок в міру покриття.
- Повторюємо кроки 3 і 4 поки все рядки не будуть покриті.
Така процедура створює логічні тестові сценарії.
Не намагайтеся покрити «невизначені» комбінації подій / умов більш ніж для одного стану в будь-якому тесті, оскільки ви напевно не знаєте, чи залишиться система придатною для тестування після цього!
У кращому випадку «невизначена» комбінація подій / умов залишиться проігнорованою або буде отримано відмову з осмисленим повідомленням про помилку, а після цього процес продовжиться в нормальному режимі.
Також можна помітити, що в кожен тест включена тільки одна «невизначена» комбінація подій / умов. Чому? Це різновид правила еквівалентного роздроблення, згідно з яким не можна створювати «некоректні» тестові сценарії, які включають більше одного «некоректного» тестового даного. У нашому випадку кожен рядок являє собою «некоректні» тестові дані. Якщо спробувати покрити два рядки одним тестом, то ми не можемо бути впевнені, що система залишиться придатною для тестування після першого «некоректного» тестового даного.
Ми позначили дію як «невизначене». Яка поведінка системи в цих умовах можна вважати ідеальним? Краще, якщо «невизначені» події / умови будуть проігноровані, або - ще краще - відхилені з осмисленим повідомленням про помилку. Після цього система повинна функціонувати нормально. За відсутності будь-якого рішення бізнес-аналітика, специфікації вимог, проектувальників системи або іншого впливового фахівця, я маю право прийняти позицію, коли будь-який інший результат вважається дефектом, включаючи незрозумілі повідомлення про помилки на зразок «Те, що тільки що сталося, - не могло статися ». Це не вигадана історія. На одному з курсів дівчина сказала, що вона бачила на власні очі саме таке повідомлення у відповідь на спробу ввести некоректні дані.
Андрій Конушін, провідний інженер-тестувальник