Приложение блокирует учётную запись после трёх неудачных входов. Объясните, почему проверки отдельных состояний недостаточно без проверки переходов между ними.
Проверка отдельных состояний не выявляет ошибки в условиях и порядке переходов между ними. Для такого сценария нужно тестировать переходы состояний: какие действия, из какого состояния и при каких условиях переводят учётную запись в новое состояние.
Например, система может корректно отображать состояния «активна» и «заблокирована», но ошибочно блокировать пользователя после второй попытки, не сбрасывать счётчик после успешного входа или разрешать вход уже после блокировки.
Техника тестирования переходов состояний появилась как способ проверять системы, поведение которых зависит не только от текущего входного значения, но и от истории предыдущих событий. Обычные проверки отдельных функций плохо обнаруживают ошибки, возникающие именно из-за последовательности действий.
Подход особенно полезен для авторизации, заказов, платежей, workflow, сетевых протоколов и других систем с конечным набором состояний и переходов между ними.
Учётная запись может находиться, например, в состояниях «активна», «ожидает подтверждения» и «заблокирована». Одно и то же действие, такое как попытка входа, должно давать разный результат в зависимости от текущего состояния и количества предыдущих неудачных попыток.
Если тестировать только каждое состояние отдельно, можно подтвердить правильность отображения и некоторых операций, но пропустить ошибки переходов. Последствиями станут преждевременная или несвоевременная блокировка, обход ограничения числа попыток, невозможность разблокировки либо сохранение неправильного счётчика после успешного входа.
Сначала описывают модель состояний, событий, условий и ожидаемых переходов. Для каждого перехода фиксируют исходное состояние, событие, дополнительные условия, новое состояние и побочный результат, например увеличение или сброс счётчика неудачных попыток.
Затем проверяют как допустимые, так и недопустимые переходы. В рассматриваемом сценарии важны последовательности из одной, двух и трёх неудачных попыток, успешный вход после неудачных попыток, попытка входа после блокировки и процедура разблокировки.
Ключевая граница находится не только в количестве попыток, но и в переходе через неё: после второй неудачи учётная запись ещё активна, после третьей — заблокирована. Нужно также проверить, что повторная попытка после блокировки не возвращает систему в активное состояние и что разрешённое действие разблокировки действительно переводит её в предусмотренное состояние.
Техника не требует проверять все возможные истории пользователя. Обычно выбирают критичные и наиболее рискованные переходы, а для сложных моделей применяют покрытие переходов или выбранных последовательностей. Полное покрытие всех последовательностей может быть слишком дорогим или невозможным, если число состояний и событий велико.
Важно отличать ошибку состояния от ошибки перехода. Некорректная надпись «активна» — проблема состояния или представления, а возможность войти после третьей неудачи — проблема перехода и связанного с ним правила.
В интернет-магазине после трёх неудачных попыток оплаты заказ должен перейти из состояния «ожидает оплаты» в состояние «требует ручной проверки». Команда проверила отображение обоих состояний и отдельно убедилась, что ручная проверка работает.
Рассматривались два варианта. Проверка только конечных состояний была бы быстрой, но не обнаружила бы ошибку в переходе после третьей попытки. Полный перебор всех последовательностей давал бы высокую уверенность, но потребовал бы чрезмерного времени из-за повторных оплат, отмен и возвратов.
Выбрали набор критичных переходов: одна и две неудачи, третья неудача, успешная оплата после неудач, повторная попытка после ручной проверки и отмена заказа в каждом существенном состоянии. Такой набор обнаружил дефект: после успешной оплаты счётчик неудач не сбрасывался, поэтому следующая неудачная попытка преждевременно отправляла новый заказ на ручную проверку.
1. Достаточно ли проверить каждый переход по одному разу?
Нет, если результат зависит от счётчика, роли пользователя, времени или других условий. Один и тот же переход может вести себя по-разному после разных последовательностей, поэтому нужно проверить значимые комбинации контекста и переходов, особенно границы и восстановление после ошибок.
2. Чем тестирование переходов отличается от тестирования состояний?
Тестирование состояний проверяет свойства системы в конкретном состоянии: например, заблокированный пользователь не может войти. Тестирование переходов проверяет изменение состояния в ответ на событие: например, что именно третья неудачная попытка блокирует учётную запись, а успешный вход сбрасывает счётчик. Ошибка может быть незаметна при корректных отдельных состояниях, но проявиться при неверном переходе между ними.
3. Нужно ли проверять недопустимые переходы?
Да. Запрет перехода — это тоже функциональное правило. Например, после блокировки нельзя разрешать вход только из-за повторной попытки, а разблокировка должна быть доступна лишь при предусмотренном условии. Игнорирование недопустимых переходов часто приводит к обходу ограничений безопасности или к неконсистентным данным.