異常測試實踐與梳理

A專案是一個典型的web前端+後臺的專案，主要的業務是購買賬號及註冊賬號。從實踐來講，我覺得一個專案的異常測試基本可以分為2大類：功能異常及服務端異常，功能異常按照先後執行順序一般可以分為3種：單介面異常、web端異常及業務操作異常。下面來介紹一下功能異常，服務端異常在異常測試實踐與梳理之服務端異常測試中介紹。

1、單介面異常測試

單介面異常測試主要的關注點是依賴服務呼叫異常時，業務程式碼能否容錯及容錯邏輯是否合理。

單介面異常測試一般也可以放到服務端異常測試階段來做，但這個階段常規功能測試已經做完，再回過頭來對每個介面進行異常測試，還需要花一定時間去重新熟悉介面業務，且該階段關注的重點是後臺整體的異常，需要覆蓋的異常點很多，從時間上來說一般會比較緊。所以，個人覺得單介面異常測試放在介面測試階段比較合適，並且單介面異常測試可以為服務端異常測試做鋪墊，把介面依賴分析都完成了。

單介面異常測試，主要包括輸入異常、操作異常、依賴服務異常等，具體要視介面情況而定。輸入異常及操作異常一般在介面測試時都會涉及，而依賴服務異常不一定。如果專案對可靠性要求比較高的話，且時間允許情況下，還是要爭取覆蓋一下。

在A專案的單介面異常中，依賴服務異常是重點。在執行測試之前，需要做一些準備工作。

• 分析介面所有依賴的服務（需要諮詢開發，或對業務和程式碼熟悉的可以直接看程式碼來了解） A專案中所有介面的依賴服務主要包括主系統（呼叫註冊服務）、資料庫(MySQL)、快取(redis)等。
• 瞭解各依賴服務的超時設定 如訪問mysql、redis及http請求的超時時間。需要跟開發確認所有訪問第三方依賴的http請求的連線引數設定是否相同。
• 依賴第三方服務介面的異常返回碼型別，及程式碼處理邏輯

A專案中有一個介面呼叫了主系統的註冊介面，需要去了解，若註冊介面呼叫失敗而返回非200返回碼，程式碼是否會進行重試，若重試依然失敗，該介面最終的返回結果是什麼？管理後臺是否還有二次註冊的介面？

在單介面異常測試執行時，只需要選擇該介面對應的依賴服務進行測試就好。訪問超時和丟包一般可以使用linux的tc命令來設定，服務掛掉一般通過改ip或埠來實現的，依賴第三方介面的異常返回碼一般是用WireMock來模擬的。

2、web端異常測試

這裡的web端異常測試，主要是指介面訪問超時及返回異常返回碼時的提示是否符合預期邏輯。

除了文字提示之外，一般通用的錯誤提示分為以下三種：toast(一段時間後自動消失)、錯誤頁及alert(彈框提示)。

一般前端在開發時都會跟產品及互動定好每種異常情況下的文案規則，在UI測試階段就對照這份規則來進行測試。下圖就是A專案中頁面初始化介面的文案規則：

有些異常情況只通過頁面操作是不太好模擬，例如伺服器異常、訪問超時等等。一般UI測試是在介面測試完成之後才做的，異常返回碼的模擬在介面測試階段已經覆蓋過，所以在UI測試階段，推薦使用工具來進行異常返回碼的模擬，而不需要進行復雜的後端操作來模擬，使用工具可以節省很多的時間。

windows的pc端推薦使用fiddler，這是一個http協議除錯代理工具。在前端測試中，一般主要使用fiddler的2種功能，設定斷點功能及請求自動重定向功能。下面簡單介紹一下這兩種功能，具體用法自行百度啊~~

1、設定斷點
通過選單欄“Rules/Automatic Breakpoints”給請求設定斷點，可以選擇Before Requests或After Responses。可以修改提交到伺服器的資料資訊（如：請求頭或請求體等），也可以修改從伺服器端返回的資料，還可以用來模擬請求超時。

2、請求自動重定向
這是fiddler最實用的功能，可通過自由設定規則，將符合條件的請求進行重定向，修改HTTP資料的特性。

3、業務操作異常測試

這部分一般是放在功能測試的後期，因為業務異常用例的設計需要對專案有一定的理解，是業務強相關的。
A專案是購買相關的，主要的業務操作異常集中在購買流程中，例如：購買時回退頁面、支付超時、多人同時購買同一商品等等。一個人能想到的異常情況一般是有限的，所以在業務異常測試之前，測試人員可以先出一個大致的測試方案，然後跟開發同學一起開一個評審會，評估一下哪些異常測試用例是沒有必要的，哪些是可能遺漏的，再對測試方案進行優化，保證測試的有效性。特別是對bug比較多的業務點要重點進行一些業務異常的測試，在進行bug發散的基礎上，多分析和思考可能引起類似異常的操作。