Тестування на основі діаграм станів сутності

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

Вимоги до станів сутності

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

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

Приклад: складання діаграми станів за вимогами

Вимогу 1: одразу після отримання повідомлень з поштового сервера вони помічені як непрочитані.
Вимога 2: коли користувач клікає на повідомлення, щоб відкрилося його зміст, повідомлення стає прочитаним.
Вимогу 3: користувач може помітити раніше прочитані повідомлення як непрочитане.
Вимога 4: користувач може видалити повідомлення (як прочитані, так і непрочитані), повернути повідомлення після видалення не можна.

З цим вимогам можна отримати таку діаграму повідомлень:
image

Як проектувати тести по діаграмах станів

Прості позитивні тести по діаграмах станів являють собою перевірку валідних переходів між станами, тобто можливість виконати дії, позначені стрілками. Негативні тести – перевірка неможливості виконання жодних інших дій. Таким чином, легко порахувати кількість необхідних позитивних тестів – кількість стрілок на діаграмі. Кількість негативних тестів теж нескладно підрахувати:
T- = N2-T+,
де T- – кількість негативних тестів, N – кількість станів, T+ – кількість позитивних тестів.

Формулу вище легко отримати з матричного представлення діаграми станів. Таке уявлення будується наступним чином:
  • матриця квадратна, кількість рядків і стовпців дорівнює кількості станів на діаграмі;
  • рядка будуть позначати вихідні стрілки, стовпці – вхідні;
  • якщо стрілка виходить із стану 1 і входить в стан 2, на перетині рядка 1 і стовпця 2 слід поставити +.
Таким чином, кількість плюсів у матриці відповідає позитивним тестів, а порожніх ячекк – негативним. Їх кількість розраховується за формулою вище.

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

За таким поданням даних легко дати оцінку на тестування, особливо якщо зібрані метрики часу: середній час на написання тесту і середній час проходження – досить помножити кожен показник на N2 і скласти їх.

Приклад: тести для діаграми станів повідомлення

Спроектуємо матричне подання для наступної діаграми станів:
image
image

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

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

— Видалено – Видалено:
  1. Відкрити список повідомлень на двох вкладках браузера.
  2. Знайти довільне повідомлення і видалити його на першій вкладці.
  3. Не оновлюючи другу вкладку видалити повідомлення, вибране у Кроці 2.
Очікуваний результат: повідомлення на обох вкладках видалено (зникла зі списку повідомлень), на Кроці 3 не виникає повідомлення про помилку.

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

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

Складні тести з діаграмі станів

Прості позитивні тести являють собою, як описано вище, перевірку одного коректного переходу між двома станами. Таким чином, можна сформулювати найпростіший критерій покриття діаграми тестами: протестовані всі існуючі переходи між станами, і об'єкт побував у кожному стані хоча б один раз. Але можна проектувати і більш складні сценарні тести, що складаються з більш ніж одного переходу. Такі тести можуть бути в подальшому використані і для навантажувального тестування. Аналогічно, можна задати більш сильні критерії покриття тестами: перевірені всі можливі пари переходів між станами, трійки і т.д. (до N-1, де N – кількість станів об'єкта). Таке покриття називається покриттям переходом Чау або покриттям N-1 переходів. Відповідно, саме слабке покриття буде покриттям 0 переходів.

Інші застосування діаграм станів

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

Проектування тестів може бути автоматизовано, якщо діаграма станів задана за допомогою одного з формальних мов специфікацій (VDM, Z, B та ін). Існують універсальні рішення для формального підходу до складання специфікацій і відповідно тестування на основі такого роду моделей (uniTESK). Але навіть якщо такі інструменти не застосовуються, необхідне проектування тестів цілком можна зробити вручну, якщо діаграма станів не надто велика.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.