Что такое тестирование на основе моделей?

Тестирование на основе моделей (MBT) — подход, при котором вы создаёте формальную модель ожидаемого поведения системы, а затем используете инструменты для автоматической генерации тест-кейсов из этой модели. Вместо ручного написания сотен тестов вы строите одну модель и позволяете алгоритмам выводить тесты.

Рабочий процесс MBT:

  1. Анализ требований — понимание поведения системы
  2. Построение модели — представление поведения в формальной модели
  3. Генерация тестов — использование инструментов MBT
  4. Выполнение тестов — запуск на тестируемой системе
  5. Оценка результатов — модель служит оракулом
  6. Поддержка модели — обновление при изменении требований

Зачем MBT?

Проблемы ручного проектирования:

  • Дизайнеры тестов интерпретируют требования по-разному
  • Важные пути пропускаются
  • Поддержка тысяч ручных тест-кейсов дорога
  • Критерии покрытия трудно удовлетворить вручную

Преимущества MBT:

  • Систематическое покрытие с гарантиями
  • Автоматическая регенерация при изменении модели
  • Построение модели выявляет неоднозначности в требованиях
  • Масштабируемость

Типы моделей для MBT

Конечные автоматы (FSM)

Пример: Сессия банкомата

Состояния: Idle, CardInserted, PINEntry, Authenticated, Transaction, Dispensing, Error
Переходы:
  Idle → CardInserted [insertCard]
  CardInserted → PINEntry [cardValid]
  PINEntry → Authenticated [correctPIN]
  PINEntry → PINEntry [wrongPIN, attempts < 3]
  PINEntry → Error [wrongPIN, attempts >= 3]
  Authenticated → Transaction [selectWithdraw]
  Transaction → Dispensing [sufficientFunds]
  Dispensing → Idle [cashTaken]
  Error → Idle [ejectCard]

Расширенные конечные автоматы (EFSM)

FSM с переменными, условиями и действиями.

Диаграммы активности UML

Для бизнес-процессов и рабочих потоков.

Цепи Маркова

Вероятностные модели для статистического тестирования.

Критерии покрытия

КритерийОписаниеСтрогость
Покрытие состоянийПосетить каждое состояниеСлабый
Покрытие переходовПройти каждый переходУмеренный
Покрытие switchКаждая пара последовательных переходовСильный
All-pathsКаждый уникальный путьСильнейший

Инструменты MBT

Open Source

  • GraphWalker — Java, FSM и EFSM, REST API
  • ModelJUnit — расширение JUnit для FSM
  • NModel — .NET фреймворк
  • Spec Explorer — Microsoft, тестирование протоколов

Коммерческие

  • Conformiq — Enterprise MBT
  • Smartesting — генерация с UML
  • MaTeLo — MBT на цепях Маркова

Когда MBT работает лучше всего

Хорошие кандидаты:

  • Реализации протоколов (API, сетевые протоколы)
  • Встраиваемые системы с определённым поведением состояний
  • Рабочие процессы бизнеса
  • Системы с множеством путей и сложной логикой состояний
  • Долгоживущие продукты

Плохие кандидаты:

  • Простые CRUD-приложения
  • Приложения с тяжёлым UI
  • Системы с быстро меняющимися требованиями
  • Одноразовые проекты

Упражнение: Построение модели MBT

Задача 1

Постройте модель конечного автомата для корзины интернет-магазина:

  • Корзина начинается пустой (Empty)
  • Добавление товаров (Empty → HasItems, HasItems → HasItems)
  • Удаление товаров (HasItems → HasItems или HasItems → Empty)
  • Переход к оплате (HasItems → Checkout)
  • Применение купона (Checkout → Checkout)
  • Оформление заказа (Checkout → OrderPlaced)
  • Ошибка оплаты (Checkout → PaymentFailed)
  • Повтор оплаты (PaymentFailed → Checkout)
  • Возврат в корзину (Checkout → HasItems)
Решение

Состояния: Empty, HasItems, Checkout, PaymentFailed, OrderPlaced

Переходы:

  1. Empty → HasItems [addItem]
  2. HasItems → HasItems [addItem]
  3. HasItems → HasItems [removeItem, items > 1]
  4. HasItems → Empty [removeItem, items == 1]
  5. HasItems → Checkout [proceedToCheckout]
  6. Checkout → Checkout [applyCoupon]
  7. Checkout → OrderPlaced [submitOrder, success]
  8. Checkout → PaymentFailed [submitOrder, fail]
  9. PaymentFailed → Checkout [retryPayment]
  10. Checkout → HasItems [backToCart]

Тесты для покрытия переходов:

Тест 1 (покрывает 1, 2, 5, 6, 7): addItem → addItem → proceedToCheckout → applyCoupon → submitOrder(success)

Тест 2 (покрывает 3, 4): addItem → addItem → removeItem → removeItem

Тест 3 (покрывает 8, 9, 10): addItem → proceedToCheckout → submitOrder(fail) → retryPayment → backToCart

3 теста покрывают все 10 переходов.

Задача 2

Оцените, подходит ли MBT для этих проектов:

  1. Банковское API с 50 эндпоинтами и сложным управлением состояниями
  2. Маркетинговый лендинг с формой обратной связи
  3. Прошивка IoT-устройства с управлением датчиками, оповещениями и протоколами
Решение
  1. Банковское API — Да. Сложное состояние, определённый протокол, много путей, регуляторные требования.
  2. Лендинг — Нет. Простое поведение, трудозатраты на моделирование превышают пользу.
  3. Прошивка IoT — Да. Определённые состояния, предсказуемое поведение, тестирование соответствия протоколам.

Проблемы и ограничения

  • Поддержка модели: Должна быть синхронизирована с системой
  • Сложность модели: Если модель столь же сложна, как система — пользы нет
  • Кривая обучения: Командам нужно обучение
  • Проблема оракула: Что если сама модель ошибочна?
  • Нефункциональные свойства: MBT не адресует производительность и безопасность напрямую

Ключевые выводы

  • MBT автоматически генерирует тесты из поведенческих моделей системы
  • Конечные автоматы — наиболее распространённый тип модели
  • Инструменты гарантируют критерии покрытия (состояния, переходы, switch)
  • Построение модели выявляет неоднозначности в требованиях
  • Лучшие кандидаты: протоколы, встраиваемые системы, сложные бизнес-процессы
  • Модель служит и генератором тестов, и оракулом
  • Поддержка модели — наибольшая постоянная стоимость