難しいのは「今どのコードが有効か」
メールOTPで間違ったコードを受け入れないためのテスト方法
OTPのrequest、最新性、resend、期限切れ、replay、最終状態を明示的に検証し、受信箱の数字だけに依存しません。
同じ受信箱に複数のOTPが残ると、テストは簡単に曖昧になります。システムには、どのrequestがcodeを作ったか、いつexpireするか、resendが古いcodeを無効にするか、成功後に再利用できるかというルールがあります。これらを個別のassertionにします。
OTP stateを明示する
| Event | Question | Assertion |
|---|---|---|
| 最初のrequest | どのcodeが有効か | 現在のcodeが仕様どおり |
| resend | 古いcodeは有効か | 実際のpolicyを確認 |
| expiration | いつ無効か | 期限切れで安全に失敗 |
| success | replay可能か | one-time policyを確認 |
deterministicな順序
- 1
request境界を作る
新しい宛先か明確な時間窓を使います。
- 2
対応するメールを待つ
sender、subject、recipient、timeを一致させます。
- 3
現在のcodeを送る
responseとsession/account stateを確認します。
- 4
resendを別caseにする
happy pathと混ぜません。
- 5
expirationとreplayを分ける
独立したsecurity propertyです。
retryが新しいOTPを作ることがある
PlaywrightやCypressで失敗をretryすると、setupが再実行され新しいOTPが発行される場合があります。受信箱が残ると、retry自体がstateを変えます。
attemptごとのidentityか相関情報でrequestを分離します。
メールOTPは自動的にphishing-resistantではない
NISTはemailをdevice-boundなout-of-band authenticatorとして扱っていません。one-timeであることとphishing resistanceは別の性質です。
信頼できるOTPテストはstate controlです。requestとcurrent codeを特定し、resend、expiration、replay、retryをそれぞれ明示的に検証します。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。