低成本、快速造測試數據，這個造數數據我推薦晚了
沒有測試數據，所謂的功能測試和性能測試全都是無米之炊。但我發現一個蠻詭異的事情，就是行業內很少會有人去強調測試數據的重要性，甚至市面上都沒有人在做測試數據這門生意。
至今測試er造測試數據還是靠人工寫，電話號碼、身份證號、地址隨便敲個差不多的數據就湊合著用。
或者用Python或js腳本去跑些測試數據出來，當然這要求你得會寫腳本，還要熟悉後端業務介面。
這樣帶來兩類問題 ：
1.對於業務數據簡單、常規的項目來說，手工臨時敲幾個測試數據，用來跑完用例沒問題；
但如果你在的行業是電商，是保險類，是銀行類，項目數據往往都具有特定的數據結構以及業務約束，如果硬要手造的話——只能說你要麼特別聰明，要麼特別堅強。
2.絕大部分項目的測試執行排期都非常緊湊，往往給不出寫數據腳本的時間，何況調試數據腳本，本身也非常費時，特別是業務關聯到多個介面和多個系統、且後端介面還處於開發狀態的時候。
低成本、快速造出高可用測試數據
所以我這陣子一直在找一些可用於造數據的工具，甚至降低要求半成品也行，只要它能滿足我快速，低成本造測試數據的需求就行。
後面找到了一款叫Apifox的工具，它本身不是專門做測試數據的，它更接近於國產Postman，它自己的定位是Apifox=Postman+Swagger+Jmeter+Mock， 也就是集成了介面文檔管理，介面調試、測試、mock功能。
但我取我所需，把它的mock和介面自動化功能結合起來用，就成了為我量身定做的測試數據工廠。 接下來我結合這幾天的使用經驗，給大家分享下要怎麼用這款工具來造測試數據。
根據測試數據的類型，我們把它分為常規數據和專有數據，常規數據如姓名，年齡，手機號，郵箱，身份證號等等；
專有數據如電商項目的運單號，物流數據，訂單號等。這部分可通過Apifox的mock智慧引擎實現。
根據造數據的難易程度可以分為單個介面可直接生成的數據和需要中間變數、通過多個介面生成的測試數據。這部分可在mock的基礎上，通過介面自動化實現。
而為了使構造出來的測試數據更加符合業務要求，在這個基礎上可以對測試數據添加數據範圍約束，mock期望或者使用mock自定義腳本。
基本上是遵循三個步驟：先構建測試數據欄位，再構建介面響應數據，修改測試數據使之更符合業務數據要求。
開始造數據
造數據之前，我們還需要一份介面文檔，造數據的基本規則是通過跑介面來造數據的。
Apifox支援Swagger、Postman、yapi等20多種格式的介面文檔一鍵導入，所以無論你的團隊用的什麼介面管理工具，基本上都能無痛導入進來。
如果你跟開發要到的介面文檔是word，html格式的，那就先問問為什麼2022年了，還要用web1.0時代的東西，是因為村裡還沒通網嗎？然後再罵罵咧咧、手動一個個把介面複製進apifox。
都導入、複製完成之後，一個整潔的項目介面頁面如下，接下來就可以開始幹活兒了。
使用mock功能造數據欄位
對於測試數據中的常規數據，如姓名、電話號碼、郵箱、地址等，Apifox已經內置了一批mock規則。
如下所示，Apifox的mock規則兼容mock.js的語法，並且可以通過正則表達式，靈活構造數據規則。可在項目設置-功能設置-mock設置中查看所有內置規則、添加自定義規則。
使用的時候非常簡單，選擇測試數據對應的介面，在介面請求和響應的參數中選擇變數所對應的造數規則，保存並發起請求，則每次都會生成對應的數據。 舉例： 我們使用post介面來生成寵物數據。在請求參數mock規則框選擇符合該欄位要求的造數規則並保存、發起請求。
則介面保存並返回了對應的寵物數據：
生成專有業務數據
上面生成的常規測試數據是直接使用內置造數規則，構造出來的，我們做的操作基本就是做選擇題。這確實符合我們之前所說的低成本、高效造測試數據。
如果是一些垂直行業內專用的業務數據，像剛剛說的物流號，訂單號，保單號之類的數據。
Apifox的內置mock規則里沒有現成可用的，但它提供了自定義mock規則來滿足這類需求。
這裡不需要複雜的程式碼，通過一行正則表達式即可完成造數邏輯。至於寫出來的這行正則表達式是否能準確概括數據規則，可以通過一些在線的正則表達式檢驗器去校驗，校驗成功後才填到mock規則里。
舉例：假設項目涉及到物流行業順豐的運單號，那麼可以在項目設置-智慧mock設置里，新建一個自定義mock規則，填入一個正確的正則表達式，之後再在介面響應參數里使用該規則
構造運單號數據規則
在介面響應或數據模型中使用該規則
發起包含該欄位的介面請求，可得到符合業務要求的運單號數據：
批量造數據
如果需要生成多條測試數據，則可以在介面設計頁面-請求參數中設置動態值，動態值的設置同樣遵循mock規則，動態值使得每次提交的數據都不同，則對應的能生成不同的新測試數據。
將該用例保存，導入自動化測試中循環執行10次，則會生成10條測試數據。
使用介面自動化造場景數據
有時候一個測試數據可能需要中間數據才能生成，這需要調用到多個介面，涉及到介面間的參數調用和介面關聯的問題。 這裡我一般是用apifox的介面自動化功能。 鑒於本文不是專門介紹介面自動化的，只稍微提一下用介面自動化來造測試數據的三個關鍵問題：
參數用例自動生成 單個介面的響應數據構造在上面已經提到，只需要將配置好的用例保存為參數，接著再自動化測試-新建測試用例-導入步驟里綁定這條用例 場景用例一鍵導入 根據執行一個業務場景所需要的介面按調用順序進行拖曳排序，模擬實際操作場景
介面變數提取和介面關聯 回到單個介面用例中，將供下游介面使用的參數提取到全局變數中，在需要使用上游介面變數的介面的請求參數中調用該變數。
最後再執行整條測試用例，完成最終測試數據的獲取。
使用mock期望，自定義mock腳本完善測試數據
造出來的數據，在數據結構上是沒問題了，但某些測試場景下可能存在業務約束，需要更加精確一點的測試數據，那可以用到數據約束，自定義mock腳本。
數據約束在確定了響應數據的數據類型如string，boolean等基礎之上，還可以在請求參數-高級設置對數據範圍進行進一步約束。 如，對body里的某個參數，數據類型為integer,可以在高級設置里，縮小數據的變化範圍。
測試數據的管理
用程式碼寫的造數腳本，通常只有寫它的人才知道具體的造數邏輯，這個小夥伴離職了就會比較難維護下來。
但是用這個工具的話，造數邏輯還是比較簡單的，而且整個團隊都能看到具體、詳細的規則，不會因為團隊里有人走了，腳本就廢掉了。
項目里所有的造數規則，是全體項目成員都能看到的
然後因為是造數是通過介面請求去實現的，造數規則是附帶在介面請求和響應參數里的，所以如果版本迭代了，介面變了，那造數規則要改的話，也直接在這個介面文檔頁面改就好， 也不必去改腳本。
尤其是介面增刪改了參數，或者修改了數據類型和數據結構，基本上要改的就是一個正則表達式，接著對應參數頁面選擇新的造數規則。
這個維護難度簡單到我都覺得不能叫維護——就只是，順手一改了。
下載
介紹完用Apifox 造測試數據的幾個方法，大家如果有興趣的話可以自己下載來嘗試一下，軟體免費，也不用配置什麼，直接去 官網下載來安裝就能用了。
官網地址：//www.apifox.cn/
如果有什麼疑問，可以查看幫助文檔：//www.apifox.cn/help/app/mock/
