低成本、快速造測試數據，這個工具你指的擁有
##前言 一大早測試部的老大就召集我們開了個會——原因是我們組負責的業務除了個線上漏測，用戶的投訴跟雪花似的紛至杳來。
公司門口那個巨大的顯示器就在那輪播著用戶回饋，好幾屏都是用戶在吐槽這個bug。
沒啥可說的，該背的鍋還是要背的，那個漏測也不算冤，測試同事造不出那個異常場景，心中僥倖，覺得不至於異常會導致客戶端出現啥問題。偏偏它就出了問題！
後來組裡開會復盤了下，決定以後在測試環節里引入mock測試工具協助測試。
主要為了解決我們測試過程中遇到的以下問題：
a.程式碼存在多個介面依賴的問題，造出測試場景費時費力，且有時由於程式碼設計和業務隔離的問題無法造出來
b.涉及到外部第三方資源，無法調試外部程式碼內部情況，無法造出特定場景
c.後台開發還沒有完成，由於進度趕，需要提前測試前端問業務
mock測試是個啥
mock這個英文單詞的意思是模擬，在測試流程中指的是對不容易構造或不容易獲取的對象，用一個虛擬的對象來創建以便測試。大致可分為兩類：
客戶端 Mock：在被測服務內部工作，直接攔截被測服務的 API 請求方法，直接從方法內部返回預定義的 Mock 響應。
服務端 Mock：在被測服務外部工作，作為 HTTP 伺服器接收被測服務發送的 API 請求，並返回預定義的 Mock 響應。
到底要怎麼搞
1.直接寫程式碼
python中有個mock模組，支援用mock對象替換掉指定的python對象，達到模擬返回值的效果；
Java中也有jar包——mock server moco，它支援指定配置文件就可開啟一個http伺服器，支援動態載入。
寫程式碼的優點在於可以完全服務於你所在項目的需求，缺點也很明顯，一個迭代版本的需求往往給到的測試時間只有幾天，沒有時間給測試童鞋寫程式碼來mock。 何況程式碼也不能保證一次性跑得通，往往調試也要花去很多的時間。
我的想法是——「不要重複造輪子」。市面上其實不乏好些免費的mock工具可以用，只要能夠滿足我們的目的——可模擬多種異常測試場景，mock配置快速簡單。
2.使用mock工具
（1）mock工具的選用原則
介面管理方面： 介面測試一般會涉及數十個甚至上百個介面，這個介面後面還涉及到重構或者版本迭代的問題，因此mock工具需要具備介面管理的功能，能夠管理多個版本的介面數據，不要一堆文件胡亂堆著無法處理。
數據構造方面： 介面返回的數據類型和測試數據需要能夠做到儘可能少的配置工具和高度模擬，以達到在真實業務場景中測試的效果
場景模擬方面： 能模擬各種異常返回，以及由於介面依賴和資源隔離，業務隔離等原因在測試環境內無法構造出來的場景。
（2）場景Mock工具推薦
a.Fiddler 工具簡介：Web調試工具， 它能記錄所有客戶端和伺服器的http和https請求。允許你監視、設置斷點、甚至修改輸入輸出數據。
Fiddler在測試中主要用於攔截介面，篡改介面返回值，來對前端進行調試。
但攔截介面需要設置正則表達式，一個個介面捕捉並修改返回值，對於介面數量少，只需要用到少量介面的測試需求，這個工具還是蠻好用的。
但如果是頻繁迭代的需求，一個需求里有上百個介面，那麼用Fiddler的效率則不高。
另一個問題是介面返回的數據需要自己手工填入，簡單數據還行，複雜數據如base64編碼，哈希值等等，那麼構造起來非常費時費力。
b.Apifox
工具簡介：Apifox提供了介面設計，調試，測試，管理等功能。我們這裡只需要用到它的mock功能。
零配置mock Apifox裡面預先設置了常見數據類型的mock規則，不需要用戶自己配置，直接選擇就可以用，目前已經支援非常多常用的數據類型，包括頭像，手機號，郵箱，url，地址等，下圖是目前無須配置可直接使用的數據類型：
如何構造數據： 在介面設計tab，直接在返回參數的mock選項框里選擇與參數匹配的數據類型
自定義mock規則 如果你的項目里需要用到不怎麼常見的數據類型，可以自定義mock規則。
定義完成之後可以在介面設計>response 參數里直接調用改mock規則。
構造異常測試場景
為了提高測試覆蓋率，測試童鞋需要驗證當介面返回 異常時客戶端是否有容錯機制，會不會出現崩潰。
這可以利用mock功能來協助測試。
介面管理
一個測試需求/項目常常包含多個測試介面，在Apifox裡面可以以項目的形式，通過不同層級的文件夾來對介面進行管理。
總結 造測試數據是每個測試童鞋無法避免的一項事務，如果能藉助工具，快速地構造測試場景進行用例測試，就能夠極大地提高我們的測試效率。
