測試基礎：你如何準備測試資料
準備測試資料是我們測試過程中非常重要的一環，不管你是哪種型別的測試，都避不開。通常，我們有 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 建立資料，然後去資料庫修改這個資料，增加國籍這個欄位的值就好了。
隨著現在系統服務引入的其他中介軟體也越來越多，可能還需要涉及到快取、訊息佇列的資料建立，屆時再進行分享。
作者： 千里和他的軟體測試
軟體測試學習交流： 軟體測試交流群 172489141
銀行金融業務交流： 新網銀測試群 52304542
介面自動化效能交流： 一個正經的測試群 188427938