本節書摘來自華章計算機《web測試囧事》一書中的第2章，第2.5節，作者 黃勇 雷輝 徐潇 楊雪敏，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
很多測試人員在面試時會被問到如何針對特定産品測試，需要考慮哪些方面時，思路都會從兩方面發散：正常場景、非正常/異常場景開始回答。從思維模式來說，測試人員就不同于開發人員比較習慣的正向思維，而是更多地從異常場景、使用者場景等出發，全面地考慮使用産品時會出現的各種可能性，并通過給這些場景配置設定優先級來指導測試的執行。
但是測試人員并不是無所不能的，有很多異常場景光了解功能性需求是不夠的，還需要了解一些架構與部署等非功能性需求。是以在設計測試場景，尤其是異常的測試場景時，很容易遺漏非功能性異常場景。小蔡最近就遺漏了一個關乎使用者體驗的異常測試場景。
産品在使用者賬戶設定頁面提供了收貨位址管理的功能，使用者可以增删改查自己的收貨資訊（見圖2-7）。不過最近使用者經常反映會有自己儲存資訊之後，下次打開資訊丢失的情況。
小蔡在測試環境重制這個問題時，發現無論如何都重制不了。是以她經過申請，拿到了生産環境上的測試賬号，嘗試在真實環境中重制這個問題。
然而即便使用了生産環境，小蔡依然不能百分之百地重制這個問題，對收貨位址的增删改查，隻是有時能重制這個問題。
開發人員根據運維人員提供的資訊，在日志中檢視到确實如此，使用者在儲存資訊時，雖然在前台看到資訊已經被儲存并且重新整理了，但是由于發送的請求逾時，背景伺服器已經報錯并記錄在日志中了，不過背景并沒有重新送出的機制，是以導緻這一部分的資訊丢失了。
這個問題時不時會出現，确實是由于負載均衡的伺服器轉發請求導緻的，從日志裡也能印證這一點。
一切正常的情況下，也是大多數情況下産品代碼對使用者收貨位址的增删改查都不會出現問題，但是在網絡環境不好等異常情況出現時，代碼的處理就導緻了功能缺陷的産生。
小蔡和開發及運維人員讨論到，雖然不希望産品代碼是通過過度的防禦式程式設計的模式編寫出來的，但是對于異常場景的處理，尤其是前背景伺服器之間的資訊傳遞，需要更全面的覆寫。
就拿現在這個特定的問題來說，解決方案是首先解決負載均衡伺服器轉發逾時的問題，此外還需要在産品代碼相應的處理邏輯中添加請求逾時重新送出的功能。