設計用例最開始遇到的異常情況，就是前置條件引起的異常流。例如，不具備訂購條件的用戶，不能訂購該服務，這種條件排列組合就會產生很多種異常場景。
接下來遇到的異常場景就是，在操作進行中遇到的。
- 1）比如說操作進行時，斷電、斷網、死機等原因導致的信息丟失的異常；
- 2）訂購過程中，用戶或產品的狀態變化引起的異常。例如商品下架或價格調整的處理；或是用戶在下單后付款前，被監管等。
- 3）操作中應該選擇的選項沒有選擇時的場景，例如購買產品服務時，未選擇同意服務協議的場景，此時付款按鈕應該灰顯，無法進行付款操作。
- 4）通過構造URL產生的異常場景。例如用戶存在某產品失效的訂單，通過URL進入訂單支付的頁面的異常情況，此時應該提示此訂單已經失效，支付不成功。
- 5）打開兩個頁面做相同操作時的異常流。例如，用戶滿足訂購該產品的條件，用戶打開兩個購買服務頁面A和B，當在A頁面訂購成功后，點擊B頁面的訂購可能有三種可能：一是若訂購的產品是周期型的，則進入續費的流程；二是，若訂購的產品是永久型的，則會提示不可重復訂購；三是，若訂購的產品是計量型的，則可繼續正常訂購。
- 6）用戶賬戶余額不足，充值失敗的異常場景。
最后還有一些不怎么被關注的異常。因為這些異常發生的概率極低，而且通過正常的驗證方式非常麻煩。例如，訂購服務打標志位的問題。我們通常的測試方法，是去驗證用戶做了某個操作之后，有沒有成功地打上應有的標志位；但是我們會忽略掉，如果用戶做了某個操作后，除了打上應有的標志位以外，還打上了非期望的標志位的異常場景。這時，我們是否要驗證每一個標准位是否有被誤打上。這樣工作量就太大了，因為也許有非常多的標准位。面對這種情況，我認為可以通過兩個步驟來保證質量。第一，將標志位分類，以期望的標志位為標准，篩選出與它關系及其密切的標志位，例如有依賴關系和對立關系的標志位，這些標志位是重點校驗的對象。第二，從源頭檢查。找出這些標志位的值是從何而來，可以通過檢查配置或代碼走讀來檢驗。
由於實際上，普通人類的思維不可能縝密的無懈可擊，不可能把大量復雜的邏輯整理得完美無瑕。這就像是小說里的“密室殺人案”，看上去是多么的不可思議，然而真相大白時的結果卻是完全符合邏輯的。因此，作為測試設計人員，我們必須有良好的預見性，去摸索，並組合一些“必然”的錯誤。當然每一種產品都有他的特殊性，於是就存在其獨特的異常場景。以上是我的一些想法，歡迎拍磚和補充，謝謝！
版權聲明：本文出自fnngj的51Testing軟件測試博客：http://www.51testing.com/?363937
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。