Меню

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

how write complex business logic test scenarios using decision table technique

Спробуйте Наш Інструмент Для Усунення Проблем

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

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

Ось ілюстрація:

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

Написання сценарію тесту з використанням техніки таблиці рішень

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

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

Приклад: Написання тестових кейсів для екрана входу за допомогою методики таблиці рішень:

Візьмемо Приклад таблиці рішень нижченаведених бізнес-вимог для екрана входу.

Тестування таблиці рішень

Рис.: 1.0 Зразок бізнес-схеми

Перший крок, який ми робимо, - це назвати всі гілки та залишити цифрами або алфавітами, як показано нижче.

1, 2, 3 - листя, а, b & c - гілки.

найкраще безкоштовне програмне забезпечення для резервного копіювання зображень 2017

Потім ми повинні створити таблицю рішень, як показано нижче: (Клацніть, щоб збільшити зображення)

Тестування таблиці рішень 1

Рис. 1.1 Таблиця прийняття рішень щодо потоку бізнесу Рис. 1.0

Що ви дізнаєтесь:

Окуляри, які слід пам’ятати

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

Переваги використання техніки прийняття таблиць рішень

# 1) Будь-який складний бізнес-потік, представлений у вигляді діаграми, може бути легко охоплений цією технікою.
# два) Це забезпечує швидку впевненість у тестових випадках. Не потрібно переглядати власні тестові кейси кілька разів, щоб отримати впевненість.
# 3) Легко зрозуміти. Будь-хто може зробити тестові кейси за цим шаблоном таблиці рішень.
# 4) Можна повністю уникнути переробки тестових кейсів та сценаріїв тестів, оскільки це забезпечує повне охоплення при першому пострілі.

Обмеження використання техніки таблиць рішень

# 1) Деякі методи підготовки тестових кейсів, такі як аналіз граничних значень, розділення еквівалентності, не можуть бути безпосередньо розміщені в цьому шаблоні. Але це можна записати у стовпці комбінацій та використовувати їх під час написання тестових кейсів.

Перш ніж пояснювати, чому інші методи написання тестових кейсів не можуть забезпечити стільки точності, як таблиці рішень, я хотів би швидко нагадати іншим Чорна скринька і Біла коробка техніки написання тестових кейсів.

Інші методики проектування тестових кейсів

# 1) Аналіз граничних значень - це техніка тестування програмного забезпечення, в якій тестові кейси призначені для включення представників граничні значення в межах і поза заданим діапазоном.

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

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

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

# 5) Використовуйте тестування кейсів У цій техніці для написання тестових кейсів використовуються сценарії використання / сценарії. Взаємодія користувачів та систем описана у випадку використання.

Ще кілька прийомів проектування тестів:

# 6) Покриття заяви
# 7) Покриття стану
# 8) Пошукові випробування

Чому інші прийоми розробки тестових кейсів для ділової логіки не можуть бути корисними як таблиці рішень?

# 1) Аналіз граничного значення та розділення класу еквівалентності призначено для числових діапазонів та довжини. Обидва ці прийоми самі по собі не можуть забезпечити 100% випробовування покриття ділових правил.

# два) Відгадування помилок - це більше про досвід. Хоча досвід необхідний, він не може виявитись усім.

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

Висновок

Для написання тестових кейсів для ділової логіки доцільно дотримуватися наведеного нижче кроки з підготовки тестових кейсів з метою забезпечення максимального охоплення тестуванням:

як відкрити файл jar з

Крок 1) Використовуйте техніка проектування тестового кейсу таблиці рішень для досягнення 100% логічного покриття.
Крок No2) Аналіз граничних значень та розподіл еквівалентності для охоплення різних діапазонів вхідних даних.
Крок No3) Комбінації та перестановки для перевірки рівня поля (хоча не всі перестановки потрібні).
Крок No4) Відгадування помилок (крім помилок, які можна визначити з вищезазначених трьох кроків) із досвідом як останній штрих

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

Про автора: Харі Нараян - професіонал з тестування програмного забезпечення, який має більше 3 років досвіду роботи у написанні сценаріїв тестування для складної бізнес-логіки. В даний час він працює з Plintron Global Technologies.

Повідомте нас, яку техніку розробки тестових кейсів ви найчастіше використовуєте у своєму проекті? А який найкращий метод на ваш досвід?

Не соромтеся ділитися вашими цінними коментарями / пропозиціями щодо цієї статті.

Рекомендована література

^