Масштабирование OTP-теста должно означать повышение уверенности в сценарии, а не отправку как можно большего количества сообщений. Начните с согласованной тестовой среды, бюджета трафика и синтетических учетных записей.
Отделяйте корректность от пропускной способности
Сначала проверьте, работает ли код для предполагаемой учетной записи и цели, истекает ли он в соответствии с политикой и корректно ли обрабатывает повторный или неверный ввод. Нагрузочный тест — это отдельное упражнение, которое требует авторизации, мониторинга и условия остановки.
Используйте сфокусированную матрицу корректности
- Корректный код, введенный в пределах его срока действия.
- Неверный код, введенный в рамках политики попыток приложения.
- Корректный код, введенный после истечения срока действия.
- Код, использованный повторно после успешного действия.
- Предыдущий код, введенный после повторной отправки.
- Код, предъявленный для другой синтетической учетной записи.
Соотносите каждое сообщение
Связывайте получателя и время запроса с тестовым прогоном. Не берите самое новое письмо в общем почтовом ящике, не проверив его назначение. В противном случае задержанные сообщения из более ранних прогонов могут привести к ложным результатам.
Контролируйте нагрузку
Ограничивайте количество одновременных прогонов, используйте ограниченное ожидание и следуйте рекомендациям по повторным попыткам API. Останавливайтесь при устойчивых ошибках в принимающей или отправляющей системе. Не проверяйте лимиты стороннего сервиса, многократно создавая учетные записи или запрашивая проверочные сообщения.
Не включайте в отчеты пригодные для использования коды
Храните статус «пройдено/не пройдено», обезличенные идентификаторы и тайминги этапов, а не значения OTP или исходные тела писем. Удаляйте данные синтетических учетных записей в соответствии с согласованной политикой тестирования. Результат одного почтового провайдера не отражает доставку во все рабочие почтовые ящики.