摘要： 異常測試，是指通過人為製造異常，檢測系統的處理是否符合邏輯。結合在a專案中的實踐，梳理一下常見異常測試的型別、關注點及常用測試工具等。
a專案是乙個典型的web前端+後台的專案，主要的業務是購買賬號及註冊賬號。從實踐來講，我覺得乙個專案的異常測試基本可以分為2大類：功能異常及服務端異常，功能異常按照先後執行順序一般可以分為3種：單介面異常、web端異常及業務操作異常。下面來介紹一下功能異常，服務端異常在異常測試實踐與梳理之服務端異常測試中介紹。
單介面異常測試主要的關注點是依賴服務呼叫異常時，業務**能否容錯及容錯邏輯是否合理。
單介面異常測試一般也可以放到服務端異常測試階段來做，但這個階段常規功能測試已經做完，再回過頭來對每個介面進行異常測試，還需要花一定時間去重新熟悉介面業務，且該階段關注的重點是後台整體的異常，需要覆蓋的異常點很多，從時間上來說一般會比較緊。所以，個人覺得單介面異常測試放在介面測試階段比較合適，並且單介面異常測試可以為服務端異常測試做鋪墊，把介面依賴分析都完成了。
單介面異常測試，主要包括輸入異常、操作異常、依賴服務異常等，具體要視介面情況而定。輸入異常及操作異常一般在介面測試時都會涉及，而依賴服務異常不一定。如果專案對可靠性要求比較高的話，且時間允許情況下，還是要爭取覆蓋一下。
在a專案的單介面異常中，依賴服務異常是重點。在執行測試之前，需要做一些準備工作。
a專案中有乙個介面呼叫了主系統的註冊介面，需要去了解，若註冊介面呼叫失敗而返回非200返回碼，**是否會進行重試，若重試依然失敗，該介面最終的返回結果是什麼？管理後台是否還有二次註冊的介面？
在單介面異常測試執行時，只需要選擇該介面對應的依賴服務進行測試就好。訪問超時和丟包一般可以使用linux的tc命令來設定，服務掛掉一般通過改ip或埠來實現的，依賴第三方介面的異常返回碼一般是用wiremock來模擬的。
這裡的web端異常測試，主要是指介面訪問超時及返回異常返回碼時的提示是否符合預期邏輯。
除了文字提示之外，一般通用的錯誤提示分為以下三種：toast(一段時間後自動消失)、錯誤頁及alert(彈框提示)。
一般前端在開發時都會跟產品及互動定好每種異常情況下的文案規則，在ui測試階段就對照這份規則來進行測試。下圖就是a專案中頁面初始化介面的文案規則：
有些異常情況只通過頁面操作是不太好模擬，例如伺服器異常、訪問超時等等。一般ui測試是在介面測試完成之後才做的，異常返回碼的模擬在介面測試階段已經覆蓋過，所以在ui測試階段，推薦使用工具來進行異常返回碼的模擬，而不需要進行複雜的後端操作來模擬，使用工具可以節省很多的時間。
1、設定斷點
通過選單欄「rules/automatic breakpoints」給請求設定斷點，可以選擇before requests或after responses。可以修改提交到伺服器的資料資訊（如：請求頭或請求體等），也可以修改從伺服器端返回的資料，還可以用來模擬請求超時。
2、請求自動重定向
這是fiddler最實用的功能，可通過自由設定規則，將符合條件的請求進行重定向，修改http資料的特性。
這部分一般是放在功能測試的後期，因為業務異常用例的設計需要對專案有一定的理解，是業務強相關的。
a專案是購買相關的，主要的業務操作異常集中在購買流程中，例如：購買時回退頁面、支付超時、多人同時購買同一商品等等。乙個人能想到的異常情況一般是有限的，所以在業務異常測試之前，測試人員可以先出乙個大致的測試方案，然後跟開發同學一起開乙個評審會，評估一下哪些異常測試用例是沒有必要的，哪些是可能遺漏的，再對測試方案進行優化，保證測試的有效性。特別是對bug比較多的業務點要重點進行一些業務異常的測試，在進行bug發散的基礎上，多分析和思考可能引起類似異常的操作。
C 梳理 異常處理
異常是在程式執行期間出現的問題。c 中的異常是對程式執行時出現的特殊情況的一種響應，比如嘗試除以零。假設乙個塊將出現異常，乙個方法使用 try 和 catch 關鍵字捕獲異常。try catch 塊內的 為受保護的 使用 try catch 語法如下所示 try catch exceptionnam...
效能測試步驟梳理
from 最近在給新員工做培訓的時候，將效能測試進行的步驟進行了一次總結和梳理，放在這裡供大家拍磚。效能測試需求收集 這一步叫萬丈高樓平地起，從無到有的過程，收集產品需求中的效能指標，我們從效能測試的目的出發，一般可以嘗試從軟體所依賴的硬體環境，軟體架構方面入手去考慮，如果遇到專業的產品人員，自然要...
回歸測試方法梳理
測試流程的重要性不言而喻，網際網路公司擁有一套嚴格的測試流程和測試規範是把關線上 質量的重中之重。乙個專案或者需求，從提出，到開發，測試，上線，線上回歸，每乙個環節都是必不可少的。很多經驗不夠豐富的測試同學會認為在測試環境測試用例都執行通過了，那麼相同的 上線之後就肯定沒有問題，這種想法是完全不正確...