Wi-Fi認証メールを
最後までテストする

成功を3つの結果に分ける

公衆Wi-Fiポータルのメールテストは、「認証コードが届いた」だけでは終わりません。メールが受信箱に届くこと、ポータルがコードやリンクを受け付けること、元の端末でネットワークに接続できることは、それぞれ別の結果です。最初が成功しても、トークン切れやセッション喪失、ゲートウェイのポリシーによって、後の2つが失敗することがあります。

まず開発・運用チームと合格基準を決めます。メールが何分以内に確認できればよいか、どのサービスイベントで認証成功を確認するか、接続後にどの管理下のHTTPSテストページへアクセスするかを明確にしましょう。ポータルに「成功」と表示されただけで接続済みと判断しないでください。ページがキャッシュから表示されていて、ゲートウェイの認証情報がまだ更新されていない可能性があります。

アドレスとセッションをテストごとに分ける

テスト環境、または許可を得たネットワークで実施してください。個別のテストケースごとに新しいアドレスを使い、ケース番号と端末のセッションを記録します。再送や連続クリックなど、継続性を確認するケースに限り、同じアドレスを使います。実在する宿泊客のメールアドレス、部屋番号、予約情報、身分証明書の情報をテストデータに使わないでください。

まずTmpkeyの一時受信トレイを開き、デモメールではなく、実際のアドレスと残り時間が表示されていることを確認します。同じブラウザーで受信情報を保持してください。ブラウザーを変えても、元の受信箱が自動的に表示されるわけではありません。ポータルで接続が許可されず、受信ページを開けない場合は、先に利用可能なモバイルデータ通信を用意し、接続許可前に匿名受信箱を開く方法を参考に、ネットワークの遮断とメールの未着を切り分けましょう。

まずテスト項目を作り、次に組み合わせを増やす

標準的な手順を1つ決めて基準とし、変数を1つずつ変更します。端末のOSとバージョン、ブラウザーの種類、ネットワークの接続許可状況、認証方法を記録してください。一度の失敗でアドレス・端末・ブラウザーを同時に変えると、違いの原因を特定できません。

この基準テストに、対象ユーザーがよく使うiOS、Android、デスクトップOSのバージョンを追加します。プライベートブラウズ、ストレージ無効、言語切り替えは追加テスト項目にできます。実際の対応範囲は製品要件に基づいて決め、考えられる組み合わせをすべて試す必要はありません。

到着時間を3つの時点で記録する

T0：コード送信をクリックした時刻。T1：ポータルサービスがリクエストを受け付けた時刻。T2：受信トレイにメールが初めて表示された時刻。T1−T0にはフロントエンド処理とリクエスト処理が、T2−T1にはキュー待ち、転送、受信画面への表示が含まれます。どちらも単に「メールサーバーが遅い」とまとめないでください。APIの成功応答も、メールの配信完了を意味するわけではありません。

クライアントとサーバーのタイムゾーンを統一し、時計を同期します。ログの照合には、可能であればリクエストIDを使います。受信トレイのポーリングにより、初回表示が実際の受信より遅れることがあるため、T2には「画面上の観測時刻」と明記してください。権限がある場合は配信ログで受信時刻を照合し、メールのDateヘッダーを受信時刻の代わりに使わないでください。

複数回テストを繰り返し、中央値、遅延したケース、失敗率をそれぞれ記録します。しきい値はポータルのSLAと認証コードの有効期間を基準に設定し、あらゆるネットワークに同じ秒数を適用しないでください。

6桁の数字だけでなく、メール本文も確認する

件名から現在の用途がわかり、送信元アドレスのドメインが想定どおりであることを確認します。表示名が同じでも、送信元が同じとは限りません。SPF、DKIM、DMARCの判定には、メールヘッダー全体または配信ログが必要です。送信者のアイコンだけで判断しないでください。

• HTML：外部画像を無効にしても、認証コード、有効期限、安全に関する案内を読めること。狭い画面で横にはみ出さず、ライト・ダークモードのどちらでも十分なコントラストがあること。
• テキスト形式：コードとリンクが欠けず、不要なタグが残っていないこと。改行でコードが分断されず、コピー時に不可視文字が混入しないこと。
• 内容の一致：HTMLとテキスト形式で操作目的、コード、有効期限が同じであり、翻訳版に別の言語の案内が混ざっていないこと。

一時受信トレイでは表示を確認できますが、元のMIMEデータやHTML・テキストの切り替えに対応していないことがあります。両方の形式が送信されたことを確認するには、自社の送信ログ、元のメール、または管理下のテストクライアントを確認してください。画面が正常に見えるだけで、テキスト形式も含まれていると判断しないでください。

認証リンクから元のセッションまで確認する

ボタンの文言だけでなく、実際のリンク先を確認します。リンクには想定どおりのHTTPSドメインを使い、リダイレクト先が許可されていないサイトにならないこと、不要な個人情報がパラメーターに含まれないことを確認してください。合成テストアカウントでリダイレクト全体を検証し、ログには個人情報を伏せたパスとステータスだけを残します。

同じ端末と別の端末を個別に確認する

システムのログイン小窓から認証を開始し、通常のブラウザーでメールを受信すると、リンクが別のCookieセッションで開くことがあります。パソコンで開始した認証リンクをスマートフォンで開く場合は、端末の紐づけも関係します。まず、リンクが認証する対象はメールアドレス、現在のブラウザー、元のゲートウェイセッションのどれなのかを明確にしてください。別端末からの認証を拒否すること自体は正しい場合もありますが、元の端末に戻ってコードを入力する方法や再申請の方法を案内する必要があります。

リンクを繰り返し開くケースもテストします。無関係な端末が重複して認証されず、使用済みトークンに対してわかりやすい状態が表示されることを確認してください。テストを通すために端末の紐づけを解除したり、リダイレクトの検証を緩めたりしないでください。

再送テストでは順番を入れ替える

リクエストを2回続けて送り、リクエストIDでAとBを区別してから、古いコードと新しいコードをそれぞれ試します。受信一覧の順番だけで新旧を判断しないでください。キューの遅延により、AがBより後に届くことがあります。「最新のコードのみ有効」というルールなら、画面の案内、サーバー側の検証、メールの説明を一致させます。別の方針を採用する場合も、明確に示す必要があります。

管理された環境で、重複送信、頻度制限の超過、クールダウン終了後の復帰を確認します。レート制限はサーバー側で適用し、ボタンをグレーアウトするだけにしてはいけません。ネットワークがタイムアウトしても、バックエンドでリクエストがすでに受け付けられている可能性があるため、「送信されていない」と即断しないでください。実際の結果を記録し、無制限な再試行で実ネットワークの不正利用対策を作動させないようにします。

メールとポータルトークンの期限切れを別々にテストする

Tmpkeyの一時メールは標準で3時間有効です。ポータルの認証コードや認証リンクの有効期間は、ポータル側で別途決まります。メールの有効期限があと2時間残っていても、数分前に発行されたトークンはすでに期限切れの可能性があります。メールの有効期限を延長しても、ポータルトークンは更新されません。

少なくとも2つのテストケースに分けます。メールは有効だがトークンは期限切れの場合は、認証が拒否され、再申請できることを確認します。メールは期限切れだが、ポータルトークンは明示された有効期間内にある場合は、ポータル独自の処理を確認してください。アドレスが無効になれば、発行済みトークンも自動的に取り消されると決めつけないでください。トークンの期限直前・直後、再利用、サーバー時刻による検証もテストします。

TTLを短縮したテスト設定は、隔離された環境でのみ使用し、本番環境との差を記録してください。一時メールが実際に削除されるタイミングは別途確認し、サーバー上で期限切れになったように見せるために、スマートフォンの時計を変更しないでください。

更新してアドレスを維持し、変更して古い受信箱を終了する

更新するたびに3時間延長されます。1つのメールアドレスを使えるのは作成時点から最長24時間で、最終的にはサービスから返される有効期限を確認してください。テストでは、アドレスが変わらないこと、以前のメールが残っていること、残り時間が更新されることを確認します。上限に近い場合、さらに3時間まるごと延長されるとは限りません。

アドレスを変更すると、標準で3時間有効な新しいメールボックスが作成され、古いメールボックスは削除されます。変更前に現在のテストケースを終了し、必要な証跡を個人情報を伏せて保存してください。メールを待っている途中でアドレスを変え、その後に旧アドレスで受信できなかったことを配信障害と誤認しないでください。新しいアドレスにしても、ポータルに保存済みの送信先は自動で更新されません。

再現できる証跡を残し、ログインには使えない状態にする

各記録には、テストケース番号、環境とビルドのバージョン、端末とブラウザーのバージョン、ネットワークの状態、認証方法、個人情報を伏せたアドレス、リクエストID、3つの時刻、期待値と実際の結果を含めます。「受信」「認証」「接続」は個別に記録し、単に合格・不合格だけを記入しないでください。

同じアドレスを関連づける必要がある場合は、テストケース内の識別子か管理されたハッシュを使い、完全な認証情報を残さないでください。テストメールボックスを削除しても、チケットのスクリーンショット、ダウンロード済みファイル、外部システムのコピーは消えません。これらは別途削除が必要です。

一時メールだけでは配信率を測れない

1回の成功が示すのは、その時点、その経路、その受信ドメインでの結果だけです。Gmail、Outlook、企業メールにおける迷惑メール判定、レピュテーション、受信時の表示を代表するものではありません。リリース前には、利用許可を得た実際のメールアドレスでも各プロバイダーの挙動を確認し、本番環境の配信状況、バウンス、認証完了率を監視してください。

ポータルが使い捨てアドレスを明示的に拒否する場合は、アドレス受け入れポリシーとして記録し、制限を回避しないでください。本人確認、支払い通知、宿泊内容の変更、アカウント復旧、長期の連絡に、削除されるアドレスを使ってはいけません。匿名メールでネットワーク上の送信元を隠すことはできず、セキュリティ監査の代わりにもなりません。

次のテスト：まず受信し、長期利用するか判断する

短期間のテストには、専用アドレスを1つ使って最初から最後まで確認します。日をまたいだ回帰テストで安定したアドレスが必要なら、長期転送エイリアスを検討できます。受信メールは自分のメールアドレスへ転送され、設定と直近30日分のアーカイブは独立して管理されます。転送によって経路が増えるため、その遅延を一時受信トレイの結果と同じ条件として扱わないでください。

実際に利用する方向けのポータル入力手順は、ホテル・空港・カフェのWi-Fiでメールアドレスを使う方法をご覧ください。データの取り扱い範囲については、プライバシーポリシーをご確認ください。