Що таке тестування на основі моделі?

Що таке тестування на основі моделі?

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

Існує безліч моделей, і кожна з них описує різний аспект поведінки системи. Типовими прикладами є:

• Потік даних
• Контрольний потік
• Графіки залежностей
• Таблиці рішень
• Машини переходу стану

Модельно-орієнтоване тестування описує, як система поводиться у відповідь на дію, визначену моделлю. Вкажіть дію, а потім перевірте, чи реагує система так, як передбачає модель. Будь-яка розбіжність між цими двома показниками є або дефектом програмного забезпечення, або помилкою в моделі, і обидва варіанти варто знайти.

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

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

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

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

Види МБТ

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

• Офлайн / апріорі: Генерація наборів тестів перед їх виконанням. Набір тестів – це колекція тестових випадків, і в цьому режимі набір зберігається, переглядається та повторно запускається, як і будь-який інший. тестування автоматизації актив.
• Онлайн / на льоту: Генерація наборів тестів під час виконання тесту, де наступний крок вибирається на основі того, як система фактично відреагувала на попередній.

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

Як працює тестування на основі моделей

Незалежно від того, який фреймворк використовується, метод проходить ті самі п'ять етапів. Кожен етап створює артефакт, який споживає наступний, тому саме модель, а не тестовий скрипт, стає тим, що команда підтримує.

• Крок 1: Побудуйте модель. Перекладіть вимоги або специфікацію в ABStract-модель очікуваної поведінки, що визначає стани, переходи між ними та вхідні дані, що запускають кожен перехід.
• Крок 2: Виберіть критерії відбору тестів. Критерії вказують генератору, коли зупинитися. Найпоширенішими є покриття всіх станів, яке відвідує кожен стан принаймні один раз; покриття всіх переходів, яке використовує кожну стрілку принаймні один раз; та покриття шляху або потоку даних для глибшого дослідження.
• Крок 3: Зробіть пресtract-тестових випадків. Інструмент обходить модель та генерує послідовності абсtract кроків, що відповідають обраним критеріям, разом з очікуваним результатом на кожному кроці.
• Крок 4: Конкретизуйте пресtract-тести. Адаптерний шар відображає кожен абсцесtracт перейти до реальної дії проти системи, такої як взаємодія з інтерфейсом користувача, API виклик або протокольне повідомлення. Ця картаping записується один раз і використовується повторно кожним згенерованим тестом.
• Крок 5: Виконайте та винесіть вердикти. Конкретні тести проводяться для тестованої системи, кожна спостережувана реакція порівнюється з прогнозом моделі, і реєструється вердикт «зараховано» або «не зараховано». tracповертається до елемента моделі, який його створив.

Команда tracПрактичним результатом є спрощеність, створена на кроці 5. Коли вимога змінюється, змінюється модель, і відповідні тести переробляються, а не переписуються, тому команди, які часто виконують регресійне тестування на тлі стабільної специфікації найкраще.

Різні моделі в тестуванні

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

Кінцеві державні машини

Ця модель допомагає тестувальникам оцінити результат залежно від вибраних вхідних даних. Різні комбінації вхідних даних можуть призвести до відповідного стану системи.

Система матиме певний стан та поточний стан, який визначається набором вхідних даних, наданих тестерами.

Розглянемо наведений нижче приклад. Система дозволяє співробітникам входити в програму. Поточний стан співробітника – «Вихідний», і він стає «Вхідним», як тільки співробітник входить у систему. У стані «Вхідний» співробітник може переглядати, друкувати та сканувати документи в системі.

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

Державні діаграми

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

Наприклад, дефекти виникають в інструменті керування дефектами зі статусом «Новий». Після того, як розробники виправили дефект, статус має бути змінений на «Виправлено». Якщо дефект не виправлено, статус змінюється на «Відкрито повторно». Діаграми станів слід розробляти таким чином, щоб для кожного стану викликалася подія.

Цей життєвий цикл дефекту зображено нижче, де кожен статус показано як стан, а кожна дія робочого процесу – як подія, яка переміщує дефект між ними.

Уніфікована мова моделювання (UML)

Уніфікована мова моделювання (UML) — це стандартизована мова моделювання загального призначення. UML включає набір методів графічної нотації, що використовуються для створення візуальних моделей, які можуть описувати дуже складну поведінку системи.

UML має такі позначення, як:

• Діяльності
• Актори
• Бізнес-процес
• компоненти
• Мова програмування

Діаграми активності та станів машини – це ті, які генератори тестів зчитують найчастіше, як показано на прикладі моделі UML нижче.

Інструменти тестування на основі моделей

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

• GraphWalker — інструмент з відкритим кодом, який зчитує моделі у формі орієнтованих графів та генерує з них тестові шляхи з можливістю вибору генераторів та умов зупинки.
• фМБТ — набір інструментів для тестування на основі моделей з відкритим кодом від Intel, який підтримує генерацію та виконання тестів на основі моделей станів.
• Конформік — комерційний автоматизований продукт для розробки тестів, який створює тестові випадки та сценарії з графічних моделей поведінки.
• MaTeLo та MBTsuite — комерційні платформи, спрямовані на статистичні моделі використання та генерацію тестів для існуючих систем автоматизації.
• Оглядач специфікацій - Microsoftрозширення тестування на основі моделей для Visual Studio, яке широко цитується в літературі з тестування протоколів.

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

Модельно-орієнтоване тестування проти традиційного дизайну тестів

Варто зазначити контраст із розробкою тестів, написаних від руки, оскільки ці два підходи не спрацьовують у різних місцях, а не просто один є кращим.

Аспект	Модельне тестування	Традиційний дизайн тесту
Джерело тестових випадків	Згенеровано автоматично з поведінкової моделі	Написано індивідуально тестувальником на основі вимог
Вплив зміни вимоги	Оновіть модель, перегенеруйте уражені тести	Знайдіть та відредагуйте кожен тестовий випадок, що зазнав впливу, вручну
Покриття	Вимірюється за такими критеріями моделі, як усі стани або всі переходи	Вимірюється відповідно до вимог та залежить від оцінки тестувальника
Попередня вартість	Високий: навички моделювання, налаштування інструментів та адаптивний шар	Низький: тестер може одразу почати писати
Найкраще підходить	Системи зі стабільною специфікацією, що зберігають стан, з тривалим терміном служби	Короткі проекти, разові матеріали та дослідницька робота
Основний режим відмови	Неправильна або застаріла модель непомітно генерує неправильні тести	Прогалини та дублікати накопичуються у великому наборі

Наведена нижче еволюція розглядає цю техніку в контексті: ручне виконання тестів поступилося місцем автоматизованому виконанню, а підходи на основі моделей переносять автоматизацію на один рівень вище, у сам дизайн тестів.

Проблеми тестування на основі моделі

Впровадження MBT в організації вимагає значних інвестицій коштів та зусиль. Нижче наведено недоліки MBT у розробка програмного забезпечення:

• Тестерам потрібні навички моделювання, яких не вимагає традиційний дизайн тестів.
• Крива навчання довга, і перший проєкт зазвичай коштує більше, ніж заощаджує.
• Саму модель може бути важко зрозуміти та переглянути, особливо після її розвитку.
• Модель, яка не відповідає специфікації, генерує впевнені, але неправильні тести.
• Адаптерний шар, який перетворює пресtracКроки, що переходять у реальні дії, мають бути записані та підтримуватися окремо.
• Розмір моделі швидко зростає, тому модель необмежених станів може створити більше шляхів, ніж будь-яка команда може виконати.

Жодне з цих рішень не є причиною уникати цієї методики, але разом вони пояснюють, чому MBT зазвичай впроваджується спочатку в одній стабільній підсистемі, а не в усій. життєвий цикл тестування ПЗ якось.

Переваги тестування на основі моделей

У порівнянні з цими витратами, переваги MBT полягають у наступному:

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

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

Поширені запитання