Основной сценарий подтверждает, что один пользователь может зарегистрироваться. Негативные тесты проверяют, остаётся ли приложение согласованным, когда письма приходят с опозданием, действия повторяются или пользователь меняет адрес посреди регистрации.
Сначала определите ожидаемое поведение
| Сценарий | Вопрос, на который нужно ответить |
|---|---|
| Просроченная ссылка подтверждения | Остаётся ли учётная запись неизменной и предлагается ли поддерживаемый следующий шаг? |
| Повторно использованная ссылка | Позволяет ли повторение действия избежать предоставления непреднамеренного доступа? |
| Запрошено второе подтверждение | Какая ссылка остаётся действительной согласно политике продукта? |
| Адрес изменён до подтверждения | Может ли прежнее письмо всё ещё повлиять на неверный адрес? |
| Выполнен вход в другую учётную запись | Привязано ли подтверждение к той учётной записи, для которой оно предназначено? |
Используйте контролируемые учётные записи
Выполняйте эти проверки только против собственного приложения или в рамках авторизованного аудита. Создавайте синтетические учётные записи без данных клиентов. Используйте средства контроля доступа к почтовому ящику, соответствующие тестируемым ссылкам подтверждения.
Проверяйте и страницу, и сохранённое состояние
Сообщение об успехе в браузере — это ещё не всё. Проверьте состояние подтверждения учётной записи с помощью поддерживаемых вами инструментов тестирования. Аналогично, страница с ошибкой не должна оставлять частично применённое обновление, которое меняет последующее поведение.
Обеспечьте сохранность доказательств
Указывайте последовательность действий, версию сборки и обезличенные идентификаторы. Не вставляйте действующие токены в общедоступные заголовки задач или логи. По завершении теста удалите синтетические учётные записи и сделайте недействительными оставшиеся тестовые ссылки.