在平時測試過程中，總會遇到一些比較難構造的場景。比如不同平台間的同步，異常場景的構造。遇到難構造的場景時，就可以引用Mock來進行單元測試。簡言之：mock測試就是在測試過程中，對於某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。
Mock場景
1.對象信息難構建
mock對象就是真實對象在調試期間的代替品。在測試時使用Mock，可以自由方便的構建配置接口對象的信息參數；在測試過程中，需要第三方接口返回特定的數據以符合特定的測試場景，這種情況往往需要跨條線的溝通協調測試數據，成本高，效率低；利用Mock可以自定義返回測試結果，支持手動構造依賴接口的返回值。
2.依賴的接口尚未開發完成
在系統交互雙方定義好接口之后，我們可以提前進行開發和測試，並不依賴上游系統的開發。
3.異常場景（連接異常、超時異常等）
大體量級別的公司，系統錯綜復雜，依賴性極強。使用Mock技術，相當於在開發、測試過程中降級了對外部服務接口的依賴，可以不受限制的提前進行我們的工作。
4.自動化測試
在自動化測試概念和發展要求下，自動化測試的規模也逐漸增大到一定程度；
大型業務系統下測試接口多，測試用例也日益增多，依賴環境的穩定就成為了自動化測試執行的關鍵所在；
自動化測試過程中，經常會因為依賴的第三方環境不穩定，導致測試執行失敗，長期以往的出現問題，導致測試人員對自動化的穩定運行失去維護的信心；
利用Mock技術，在測試過程中，只關注被測業務邏輯，mock掉依賴不相關的系統，這種情況下自動化測試運行失敗，就一定是被測系統本身的業務邏輯問題，而不是第三方系統、數據的問題。
Mock步驟
近期在測試同步場景時，涉及到兩個平台間的數據同步。為了測試不同場景，總不能讓上游把接口給弄壞吧？所以就想到了，使用Fiddler來進行接口返回狀態的Mock。
使用Fiddler來進行Mock，就是將請求的接口攔截，然后修改接口的返回值，使得接口返回對應異常場景下的報錯，前端依據后端數據來展示對應提示信息。
Fiddler攔截
在Mock之前，需要先學習下Fiddler攔截操作，詳細可參見博文：利用Fiddler攔截接口請求並篡改數據，使用起來很簡單。
在Fiddler中，配置成接口請求前攔截，我們來看效果，如下所示：
選擇Response
數據被攔截后，可以選擇Response，如圖上所示，這些狀態碼，是Fiddler工具自帶的，不防試試看？
選擇Response為401，並點擊Run to Completion后，查看數據。
接口狀態碼為401，如下：
我們再來看頁面數據，彈出了登錄驗證框，如下：
上述這些狀態碼是自帶的，那我們如何模擬自己想要的數據呢？很簡單，我們找到這些狀態碼的存放路徑，比如：C:\Users\XX\AppData\Local\Programs\Fiddler\ResponseTemplates，復制一份數據，並修改成自己需要的返回值，即可。
Mock實踐
我們熟悉了基本的操作步驟，那么就來實踐一番，畢竟是實踐出真知嘛，講太多的理論都是紙上談兵。
模擬響應碼500
先將攔截方式設置為請求前攔截，在之后的例子中就不重復了，默認為請求前。
再將模擬的狀態碼及Response數據修改如下所示：
HTTP/1.1 500 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Server: fiddler Content-Type: application/json;charset=UTF-8 Vary: Accept-Encoding Date: Fri, 27 Mar 2020 14:36:51 GMT Content-Length: 112 {"message":"請求接口過快","errorCode":"9960","exceptionCategory":"BIZ_ERR","exceptionType":"BizException"}
在對應頁面中操作接口請求，此時，Fiddler中已經攔截了請求，我們選擇已修改后的狀態碼文件，並“放行”接口，如下所示：
我們從上圖可知，接口的響應碼已為500，接口返回的Json數據信息就是界面將要展示的數據，我們來看剛才操作的界面，報錯信息展示如下：
如上一個過程，就模擬了一個請求速度過快的場景。可能有人會疑問，這在界面上操作，重復調用不就可以了嘛？何必需要Mock呢？這個呢，就是前后端的都有校驗的緣故了，前端的校驗是，當后端沒有返回值時，隨便你怎么操作，不會再次請求接口。萬一哪天前端的校驗壞了呢？所以還是要Mock測試下，小心為上。
模擬響應碼400
從模擬狀態碼500的過程來看，是不是很簡單，接口繼續來看下狀態碼為400的情況，還是需要先將模擬數據修改，如下：
HTTP/1.1 400 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Server: fiddler Content-Type: application/json;charset=UTF-8 Vary: Accept-Encoding Date: Fri, 27 Mar 2020 14:36:51 GMT Content-Length: 121 {"message":"驗證接口400錯誤提示","errorCode":"9960","exceptionCategory":"BIZ_ERR","exceptionType":"BizException"}
請求接口並攔截，選擇修改后的響應數據，如下：
查看頁面中的前端提示，驗證數據，如下所示：
模擬響應碼502
我們同理，重復上述操作，模擬個系統異常，修改如下：
HTTP/1.1 502 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Server: fiddler Content-Type: application/json;charset=UTF-8 Vary: Accept-Encoding Date: Fri, 27 Mar 2020 14:36:51 GMT Content-Length: 106 {"message":"系統異常","errorCode":"9960","exceptionCategory":"BIZ_ERR","exceptionType":"BizException"}
選擇響應數據，並放行接口：
查看界面的展示信息，如下：
模擬響應碼200
接口響應為200時，接口也有可能返回錯誤信息，這次我測試的這個接口就是如此。先修改接口200下會報錯誤的信息，如下：
HTTP/1.1 200 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Server: fiddler Content-Type: application/json;charset=UTF-8 Vary: Accept-Encoding Date: Fri, 27 Mar 2020 14:36:51 GMT Content-Length: 56 {"errMsg":"接口200下的錯誤信息","errorCode":"1"}
還是如出一轍，攔截修改響應數據后放行接口，如下所示：
在界面查看報錯數據，如下：
AutoResponder自動響應
AutoResponder可以把本來服務器響應的內容，使用本地內容來響應。理解下來，就相當於，訪問百度頁面首頁，本該展示搜索框。但經過自動響應配置，就可以替換成自己本地的內容。
AutoResponder界面
界面如下所示，我們先來了解下：
我們從上圖界面，一一來了解下對應的功能配置點：
1.Enable rules（激活規則）：勾選此選項，自動響應才會激活；
2.Unmatched requests passthrough（跳過非匹配請求）：如果不勾選此選項，那么抓包的時候，會返回如下信息：
[Fiddler] The Fiddler AutoResponder is enabled, but this request did not match any of the listed rules. Because the "Unmatched requests passthrough" option on the AutoResponder tab is not enabled, this HTTP/404 response has been generated.
提示理解下來的意思是：fiddler的自動響應激活了，但是請求沒匹配到任何列表中的規則。而且因為跳過非匹配請求選項沒有激活，所以產生了http/404返回結果。
3.Enable latency（激活延遲）：勾選了這個選項，在規則里面就可以設置是立即返回響應，還是隔多少毫秒返回響應；
4.Add rule（加入規則）：點擊此按鈕則會在規則框里插入一個新的規則；
5.import（導入）：支持導入之前捕獲的saz文件；
6.規則框:
規則框有三個列，下面解釋每個列的意思：
if requests matches---這里顯示的是匹配的條件；
then response with---這里顯示的是如果匹配條件，返回的文件；
latency---這里顯示的是延遲時間（毫秒），只有勾選了Enable latecy才會展示出來。
7.rule editor（規則編輯）：第一行是設置匹配條件，點開下拉，會看到很多fidder自帶的條件；第二行是設置返回，點開下拉，會看到很多fidder自帶的返回；
8.test(測試)：這個就是用來測試匹配條件的，第一行，url pattern設置匹配公式，第二行test url設置測試的網址。點擊savechages，則會將條件替換為rule editor的第一行；
9.Match only once（只匹配一次）：勾選此選項，那么自動響應就只會響應一次；
10.Save（保存）：按鈕可以在更改了規則之后，更新規則。
規則配置
規則進行配置時，是支持正則匹配的，如上例子，就是使用的完全匹配方式，我們來詳細看下正則匹配。
1.前綴為“EXACT:” 表示完全匹配（大小寫敏感）：只有match=rules時，才匹配；
2.無前綴表示基本搜索，表示搜索到字符串就匹配：只要match中包含了rules的字符串，即可；
3.前綴為“NOT:”表示發現就不匹配：與無前綴的基本搜索同理，只是發現了就不匹配，其他默認匹配；
4.前綴為“REGEX:”表示使用正則表達式匹配：
.+ 匹配一個或多個字符，如regex:.+jpg 包含有jpg字符串且以jpg字符串結尾的，即可匹配
.* 匹配0個或多個字符，如regex:.+.jpg.*包含有.jpg字符串即可匹配
^ 匹配字符串開始位置
$ 匹配字符串結束位置，如regex:.+.(jpg|gif|bmp)$包含以jpg或gif或bmp字符串結尾的，即可匹配
如regex:(?insx).+.(jpg|gif|bmp)$ 包含以jpg或gif或bmp字符串結尾的，不區分大小寫，且是單行的，即可匹配
5.前綴為“REGEX:(?insx)”表示匹配方式其中：
i表示不區分大小寫；
n表示指定的唯一有效的捕獲是顯式命名或編號的形式；
s表示單行模式；
x表示空格說明的。
實踐操作
我們來實踐操作一番，在fiddler上啟用已配置好的規則，然后訪問百度頁面，此時，返回的不是百度的首頁了，而是規則中配置的圖片了，如下所示：
還可以替換成網頁內容，將我的博客頁面另存為html文件，修改規則內容，返回的數據設置為保存的html文件，我們再次來訪問百度頁面，展示的是如下頁面：
以上就是今天分享的Mock內容了，通過攔截請求的方式，是Mock接口的響應碼及響應內容；配置自動響應，是直接修改了響應的整個頁面內容，兩者還是有所區別。每天總結一點，不積跬步無以至千里。