准備測試數據是我們測試過程中非常重要的一環，不管你是哪種類型的測試，都避不開。通常，我們有 4 種方法。
一、基於 GUI 操作生成
GUI 就是圖形用戶界面。基於 GUI 操作生成測試數據，是最原始的創建測試數據的方法。
比如，想要測試用戶登錄功能，那么首先就要准備一個已經注冊的用戶。那么就可以直接通過 GUI 界面來注冊一個新用戶，然后用這個新用戶完成用戶登錄功能的測試。
優點
· 簡單直接。
· 所建數據完全來自真實業務流程，最大限度保證數據准確性。
缺點
· 創建效率低：每次執行 GUI 業務操作都只能創建一條數據，而執行過程費時。
· 不適合封裝復用：如果想封裝GUI的創建數據操作進行復用，就相當於在開發 GUI 自動化測試用例了。無論是從開發工作量，還是從執行效率來講，這都不是一個好的選擇。
· 引入不必要依賴：比如，你的被測對象是用戶登錄功能，但是通過 GUI 頁面操作准備這個已經注冊的用戶，就首先要保證用戶注冊功能沒有問題，而這顯然是不合理的。
通常來看，這種方法只用在手工測試環節。在 GUI 自動化里實現代價太大，還不夠穩定。
但是，這種方式的必要性還是存在的。它可以幫助我們找到在創建數據的過程中，后端調用了哪些 API，為后續的 API 相關的工作打下基礎。
二、調用 API 生成
通過 API 調用生成測試數據，是目前主流的測試數據生成方法了。
其實在我們用 GUI 操作生成數據時，背后就是各種 API 在工作，所以我們繞開繁重的 GUI 直接操作 API 豈不美哉？
而且，直接調用 API 也更容易封裝成測試數據准備函數，方便復用。
獲取 API
要調用 API 之前，得先知道有哪些 API：
· 直接詢問開發人員，最直接。
· 如果你有一定的代碼基礎，可以直接閱讀源代碼，這個方法也可以作為直接詢問方法的補充。
· GUI 操作一遍，同時觀察 API 調用日志（比如，F12、日志系統）。
優點
· 可以保證創建的測試數據的准確性，因為本質與 GUI 背后調用 API 一樣。
· 測試數據准備的執行效率更高，因為繞開了 GUI 操作。
· 封裝成測試數據函數更方便，因為這個調用過程的代碼邏輯非常清晰。
· 測試數據的創建可以完全依賴於 API 調用，就算后續邏輯有變更，你調用 API 得到的就是變更處理后的數據。
缺點
· 並不是所有的測試數據創建都有對應的 API 支持。
· 有時需要多個 API 順序調用，增加了測試數據准備函數的復雜性。
· 雖然 API 創建效率比起 GUI 已經大幅提示，但是對於需要批量創建海量數據的場景，還是會力不從心。
因此，我們還需要通過數據庫的 CRUD 操作生成測試數據。
三、通過數據庫操作生成
通過數據庫操作生成測試數據，也是目前主流的測試數據生成方法，彌補了上述 API 方式的一些不足。
通常我們會：
· 直接通過數據庫連接工具，直接向表里添加數據，比如Navicat。
· 編寫 sql 執行。
· 把 sql 編寫到函數里，方便調用。
獲取 相關業務表
要操作數據表，還是得先知道，要操作哪些表：
· 直接向開發人員索要使用到的 SQL 語句。
· 直接閱讀產品源代碼，從里面自取。
· 同樣可以借助系統日志，里面通常會記錄一些sql的執行記錄。
優點
· 生成效率非常高。
· 適合大批量數據創建場景，比如需要百萬級的測試數據。
缺點
· 很多時候，一個前端操作引發的數據創建，往往會修改很多張表，因此封裝的數據准備函數的維護成本要高得多。
· 容易出現數據不完整的情況，當對於表的操作理解不全，就可能出現漏插入表數據的情況。
· 當業務邏輯發生變化時，即 SQL 語句有變化時，需要維護和更新已經封裝的數據准備函數。
現在看起來，沒有一個是十全十美的方法。
四、綜合運用 API 和數據庫的方式生成
的確，到現在沒有一個是完美的方法，但是我們可以組合起來使用啊。
最典型的應用場景是，先通過 API 調用生成基礎的測試數據，然后使用數據庫的 CRUD 操作生成符合特殊測試需求的數據。
比如，我要創建一個用戶，這個用戶得有一個國籍屬性。但是，創建用戶的 API 生成的用戶數據，是不帶有國籍的。那我就先用 API 創建數據，然后去數據庫修改這個數據，增加國籍這個字段的值就好了。
隨着現在系統服務引入的其他中間件也越來越多，可能還需要涉及到緩存、消息隊列的數據創建，屆時再進行分享。