Границы тестирования

Начнём с того, что любой тестовый сценарий можно разделить на три основных этапа:

1. Подготовка входных данных: инициализация аргументов для тестируемой программы.
2. Выполнение функций: взаимодействие с программой для получения результатов её работы.
3. Верификация: проверка полученных результатов на соответствие установленным условиям.

С помощью этих этапов можно выделить так называемые границы тестирования.

Определение границ

Любое приложение можно смоделировать в следующем виде:

примечание

Стрелки на диаграмме указывают направление потока информации.

Аргументы

Входящие в приложение данные. Состоят из двух компонентов:

• Пользователь: пользовательские события (например, клики мыши, нажатия клавиш).
• Запросы: неявные входящие данные (например, веб-сервисы, локальные хранилища).

Результат

Результат работы приложения. Включают:

• Монитор: отображаемый пользовательский интерфейс.
• Команды: неявные исходящие данные (например, обновления БД, включение фонарика на телефоне).

Функция

Компонент, преобразующий аргументы в результат. Представлен блоком AUT (сокр. application under test) и является основным объектом тестирования.

Для повышения защиты от регресса рекомендуется включать как можно больше функциональности в тестируемый блок AUT. Это достигается за счёт упрощения и минимизации оставшихся секций, а именно аргументов и результата.

Нулевая сумма

Секции связаны между собой, так как формируют единую программу, таким образом, увеличение объёма одной секции, приведёт к уменьшению размеров остальных частей.

Верификация

Модель верификации поведения выглядит следующим образом:

Где:

• Слепок — это артефакт поведения AUT, представленный в виде значения.
• Эталон — это хранилище, содержащее слепок ожидаемого поведения приложения.

Данная модель использует популярный метод тестирования golden master.

примечание

Стоит заметить, что данная модель не доказывает корректность работы программы в привычном понимании. Она лишь помогает отследить девиации в поведении AUT.

Однако, регресс — это частный случай девиации, поэтому этого вполне достаточно.

Преимущество данного метода заключается в его простоте: управление эталоном и верификация легко автоматизируются.

Но данная техника имеет высокую цену:

• Выделяемые аргументы — аргументы должны чётко закрепляться за конкретным сценарием тестирования.
• Детерминированность как самого приложения, так и окружения в котором оно выполняется.
• First class результат — результат AUT должен быть чем-то что можно записать в эталон и сравнить.

Начало работы положено — границы тестирования уже чётко выделяют аргументы, результат и само приложение.

Осталось дело техники: пройтись по слоям и установить необходимые свойства для каждого из компонентов в отдельности.

Реализация границ в storyshots

storyshots объединяет управление слоями в единую сущность — историю, где:

• Аргументы описываются в функциях act и arrange.
• AUT выполняется в функции render.
• Результат — это снимки UI и журнал сайд-эффектов программы.