如何端對端測試你自己的簡訊驗證流程

你實際在測什麼

一個驗證流程有多個活動部件，每個都可能獨立出錯。好的測試同時涵蓋順利路徑與失敗路徑，因為失敗處理正是贏得或失去使用者信任之處。

• 傳送：為一個有效號碼產生並派送驗證碼。
• 接收並校驗：正確的驗證碼被接受，工作階段被提升。
• 拒絕：錯誤、過期與被重複使用的驗證碼被拒。
• 限制：限流與重送冷卻依設計生效。
• 降級：管道升級與錯誤狀態被正確算繪。

使用供應商測試憑證與魔法驗證碼

每家主要供應商都提供在不傳真實訊息的情況下演練流程的方式。Twilio 有測試憑證與魔法手機號碼，可模擬成功與特定失敗回應；Vonage、Sinch 與 MessageBird 提供沙箱模式與測試號碼。在本機與 CI 執行中使用它們，讓你的測試套件從不觸及真實電信業者。

• Twilio：測試憑證 + 強制成功／無效／失敗結果的魔法號碼。
• 其他：沙箱 API 金鑰與指定的測試號碼。
• 把測試與實傳憑證放在分開、命名清晰的環境設定中。

開通你掌控的測試號碼

對於真正會送達訊息的端對端測試，請開通你所擁有的可程式化號碼作為測試收件者，再透過供應商的訊息 API 把送達的驗證碼讀回來，餵給你的校驗步驟。因為號碼和應用程式都歸你所有，這是一次對你自己系統的乾淨閉環測試。

1. 1

   開通一個測試號碼

   在你的供應商帳號中建立一個專用於測試環境的可程式化號碼。

2. 2

   觸發你的傳送

   呼叫你自己的註冊／校驗端點，讓你的應用程式向測試號碼真實地傳一個驗證碼。

3. 3

   透過 API 讀取驗證碼

   透過供應商 API 取回傳入訊息，並以程式方式擷取驗證碼。

4. 4

   完成並斷言

   把驗證碼提交到你的校驗端點，斷言工作階段被提升；隨後釋放號碼。

在 CI 中自動化

把上述流程接入你的管線，讓每次建置都檢查驗證。用模擬／沙箱路徑做在每次提交上執行的快速單元與整合測試，把真實閉環測試（用你所擁有的號碼）留到每晚或發布前階段，以控制成本。

• 快車道：在每次提交上模擬供應商或使用測試憑證。
• 慢車道：每晚或發布前做真實的傳到自有號碼測試。
• 也要斷言失敗路徑：過期驗證碼、錯誤驗證碼與限流回應。
• 對送達延遲的退化發出警示，而不只是通過／失敗。

測試送達，而非只測邏輯

邏輯測試證明你的程式碼正確；它們並不證明訊息在現實世界中送達。請定期向你關鍵電信業者與國家的號碼傳送真實測試流量，測量實際送達率與延遲，從而在使用者之前發現路由或過濾的退化。