《一》前言

健壯性是指系統對於規範要求以外的各種輸入進行處理的能力。是系統穩定性的重要指標之一。

在“雲+瘦客戶端”時代，app一般使用介面的方式，與雲端進行資源交換。app的健壯性最直觀的一部分就體現在與雲端資源交換過程中的健壯性，比如：

1. 對雲端返回的各種非規範要求資料返回值，app能否作出正常的反應。
2. 弱網條件下與雲端互動，app能否作出正常的反應。

等等。這些是引發app crash的主要凶手之一，也應成為app功能測試中的重點。

《二》專案背景

在我負責的專案app測試過程中，所有的服務都是採用api進行互動的，目前app已接入了數十個第三方系統api，未來還有擴充套件的趨勢。如此健壯性測試就遇到以下難點：

1. 很多第三方系統，直接接線上環境。在測試環境要怎麼測？
2. 就算在線上版本使用了線上環境，由於許可權等限制，沒有辦法在線上第三方系統模擬各種非常規資料，怎麼破?
3. 一般測試時間很緊張，採用搭建mock伺服器的方式進行模擬，時間上完全來不及,該如何應對？
4. 模擬弱網條件，測試app的網路健壯性，怎樣才能快速模擬？

......

因此，隨著專案實踐的深入，我一直在探索一種實用解決方案，不僅要能解決問題，還要能快速的解決問題。

《三》解決方案

主要思路就是：Fiddler抓包+AutoResponder攔截並且Mock資料+Fdiddler Sricpt網路限速

第一部分：Fiddler抓包

原理：通過設定手機無線網手動代理(設定ip和port)，將app請求傳送至Fiddler。由此Fiddler就可以抓取app發出的網路請求資料。

具體步驟不在此詳述。重點要注意，如果抓取https包並且需要對內容進行解密，需要進行如下設定。

第二部分：AutoResponder攔截和Mock資料

（1）AutoResponder支援多種攔截方式，如下圖：

比如最常用的： 無字首:表示基本搜尋，表示搜尋到字串就匹配

字首為Match:代表全匹配，大小寫敏感。就是url必須完全一致的才能被Fiddler攔截

字首為regex:代表匹配符合正則表示式規則的請求，並進行攔截

等等

小技巧：如果覺得url較長導致設定攔截url比較繁瑣，可以直接把左側抓取的介面，拖動到右邊，然後適當的修改，這樣效率很高。

（2）返回Mock資料

首先快速獲取基礎資料。如下圖所示：

從抓取的待測試介面，儲存正常情況下返回的資料，作為基礎資料，進行儲存，假設命名為：testdata.txt

然後開啟testdata.txt，並對裡面返回的資料內容根據測試用例進行修改，改成任意你想要測試資料，作為mock資料

(3)模擬伺服器返回資料

將上述mock資料，作為待測試被攔截介面的返回值，返回給app。如下所示：

如上，在攔截介面的返回值裡，選擇find a file，然後選擇testdata.txt作為返回資料。

至此，就可以對app的介面，給他模擬任何的非規範資料，測試app的處理健壯性了。

第三部分：快速模擬弱網

Fiddler支援，通過script來快速控制網速，如下所示：

request-tricky-delay: 代表每上傳1KB資料，延遲多少毫秒

response-tricky-delay：代表每下載1KB資料，延遲多少毫秒

修改之後，儲存，可以模擬出網路的狀態。並且是熱切換的。儲存生效，不需要重啟Fiddler之類的。

《四》應對的測試場景

在日常測試中，採用上述的方法，能快速靈活的應對哪些測試場景呢？

(1) 介面的各種異常返回碼測試

只需要修改基準測試資料中的返回code即可

(2) 介面的各種異常返回欄位值（比如，名字太長這樣的值，在app端是否會自適應展示；各種邊界值處理是否符合互動視覺定義等）

只需要修改，data中具體返回值內容即可

(3) 介面返回欄位動態新增、缺失，app能不能正常處理，會不會crash之類的

只需要修改返回欄位數即可

(4) 某些頁面的資料，在24小時內，根據時間變化，app進行不同的展示和處理。但是給你的測試時間也許只有12小時

此時，就可以模擬24小時不同的資料返回，就可以測試app的處理邏輯是否正確

(5) 介面弱網下資料的返回，以及app是否能正常處理

採用script限制各種網速，然後觀察app的反應即可

(6) 升級測試，在正式釋出前，需要看看升級文案和升級邏輯是否正常。

就可以模擬高版本的返回值和升級文案，然後測試app的升級邏輯。

等等，都是可以根據具體的業務邏輯進行模擬測試。

《五》 總結

如果你問我這是一種萬能的測試方式嗎？

答：與專案的具體業務相關。對於我所在的專案，接入的第三方系統介面提供的資料，資料本身的正確性，第三方系統已經測試過並且上線了。我需要關注的是我專案的待測app對這些資料的處理方式是否正確，app才是我測試的重點，測試目標要明確。

如果你問有這種測試方法就夠了嗎？

答：這只是一種異常的輔助測試手段。他是對正向測試的補充和完善。在測試中，要優先保證app與真正的服務端互動正常，然後在利用這個輔助測試手段，進行異常和健壯性測試，主次要把握好。

如果你問這種解決方案最大的優點是什麼？

答：快速且符合業務的需要。我知道有很些專業的弱網測試方案、Mock測試方案等，但是在日常快速迭代的產品中，介入的時間較長，一般會作為專項測試而存在。而本文描述的方法，可以滲透到日常測試，快速介入，儘可能早的發現缺陷。

總之，這只是在當前階段的一些嘗試，後續會繼續深入探索。伴隨著產品的成熟，而引入不同的測試手段和方法，持續探索！