? ? ? ?從一個例子說起，我們線上系統最近出現一個BUG，客戶的物品信息中包含了特殊字符，在做支付相關功能的提交時發生了異常。這個問題初始的時候被歸類為異常流沒有考慮到，出現遺漏。
? ? ? ?我思考這個問題的時候想了很多，我發現這個特殊符號在化工行業客戶的物品中是很常見很常用到的。那么問題來了，這種數據還能歸結到異常流嗎？如果我們的測試換成了來自各個行業的普通采購員，是不是這個數據就像一個正常流了？
? ? ? ?我的感觸是，測試工程師的成長中又多了一項衡量自己的方法。伴隨著你的成長，正常流會越來越廣，而相應的異常流會越來越窄。
? ? ? ?測試工程師的工作范圍更有三個階段，作為一名普通的功能測試工程師，需求文檔以外的也許都是異常流吧。也許你不會覺得1000個人同時訪問是一件正常的事情，也不會想到化工行業的很多帶特殊符號的數據是正常的物品。當功能測試開始轉向業務測試的時候，我們開始關心目標用戶的實際使用場景，行業的相關規則，會覺得這種帶符號的數據通通都是正常用戶數據，是正常流了。當業務測試再加入考慮用戶體驗測試的時候，你會相信并發，安全的檢查，特定的操作習慣等等通通都是正常流，全部都應該考慮到，而不是作為異常流去考慮。
? ? ? ? 我們通常遺漏的問題不能簡單歸到異常流的遺漏，因為作為異常流我們仍然會繼續遺漏。很多情況下，是我們根本沒意識到它其實就是我們正常流該考慮的東西，而要做到這些，就是我們學習和成長的方向。
