文章內(nèi)容來(lái)源于《軟件測(cè)試52講》

測(cè)試數(shù)據(jù)的準(zhǔn)備是軟件測(cè)試過(guò)程中非常重要的一個(gè)環(huán)節(jié)，無(wú)論是手工測(cè)試，還是自動(dòng)化測(cè)試，無(wú)論是 GUI 測(cè)試，還是 API 測(cè)試，無(wú)論是功能測(cè)試，還是性能測(cè)試，都避不開(kāi)測(cè)試數(shù)據(jù)準(zhǔn)備的工作。

從創(chuàng)建測(cè)試數(shù)據(jù)的維度來(lái)看，測(cè)試數(shù)據(jù)準(zhǔn)備方法主要可以分為四類：

一、基于 GUI 操作生成測(cè)試數(shù)據(jù)

最原始的創(chuàng)建測(cè)試數(shù)據(jù)的方法，采用 E2E（end 2 end） 的方式來(lái)執(zhí)行業(yè)務(wù)場(chǎng)景，然后生成數(shù)據(jù)的方法。

比如，想要測(cè)試用戶登錄功能，那么首先就要準(zhǔn)備一個(gè)已經(jīng)注冊(cè)的用戶

方法：直接通過(guò) GUI 界面來(lái)注冊(cè)一個(gè)新用戶，然后用這個(gè)新創(chuàng)建的用戶完成用戶登錄功能的測(cè)試。

優(yōu)點(diǎn)：簡(jiǎn)單直接，在技術(shù)上沒(méi)有任何復(fù)雜性，而且所創(chuàng)建的數(shù)據(jù)完全來(lái)自于真實(shí)的業(yè)務(wù)流程，可以最大程度保證數(shù)據(jù)的正確性。

缺點(diǎn)：
1、創(chuàng)建測(cè)試數(shù)據(jù)的效率非常低

• 每次執(zhí)行 GUI 業(yè)務(wù)操作都只能創(chuàng)建一條數(shù)據(jù)
• 基于 GUI 操作的執(zhí)行過(guò)程比較耗時(shí)

2、基于 GUI 的測(cè)試數(shù)據(jù)創(chuàng)建方法不適合封裝成測(cè)試數(shù)據(jù)工具
由于測(cè)試數(shù)據(jù)的創(chuàng)建是通過(guò) GUI 操作實(shí)現(xiàn)的，所以把這種數(shù)據(jù)創(chuàng)建方法封裝成測(cè)試數(shù)據(jù)準(zhǔn)備工具的過(guò)程，其實(shí)就是在開(kāi)發(fā) GUI 自動(dòng)化測(cè)試用例。
無(wú)論是從開(kāi)發(fā)工作量，還是從執(zhí)行效率來(lái)講，把基于 GUI 操作的測(cè)試數(shù)據(jù)創(chuàng)建方法封裝成測(cè)試數(shù)據(jù)準(zhǔn)備工具都不是最佳的選擇。

3、測(cè)試數(shù)據(jù)成功創(chuàng)建的概率不會(huì)太高
測(cè)試數(shù)據(jù)準(zhǔn)備的成功率受限于 GUI 自動(dòng)化執(zhí)行的穩(wěn)定性，而且任何界面的變更都有可能引發(fā)測(cè)試數(shù)據(jù)創(chuàng)建的失敗。

4、會(huì)引入不必要的測(cè)試依賴
比如，被測(cè)對(duì)象是用戶登錄功能，通過(guò) GUI 頁(yè)面操作準(zhǔn)備這個(gè)已經(jīng)注冊(cè)的用戶，就首先要保證用戶注冊(cè)功能沒(méi)有問(wèn)題，而這顯然是不合理的。

應(yīng)用場(chǎng)景：
幫助我們找到創(chuàng)建一個(gè)測(cè)試數(shù)據(jù)的過(guò)程中，后端調(diào)用了哪些 API，以及修改了哪些數(shù)據(jù)庫(kù)的業(yè)務(wù)表，是“通過(guò) API 調(diào)用生成測(cè)試數(shù)據(jù)”，以及“通過(guò)數(shù)據(jù)庫(kù)操作生成測(cè)試數(shù)據(jù)”這兩種方法的基礎(chǔ)。

二、通過(guò) API 調(diào)用生成測(cè)試數(shù)據(jù)

目前主流的測(cè)試數(shù)據(jù)生成方法

其實(shí)，當(dāng)我們通過(guò)操作 GUI 界面生成測(cè)試數(shù)據(jù)時(shí)，實(shí)際的業(yè)務(wù)操作往往是由后端的 API 調(diào)用完成的。所以，我們完全可以通過(guò)直接調(diào)用后端 API 生成測(cè)試數(shù)據(jù)。

還是以用戶登錄功能的測(cè)試為例，我們通過(guò) GUI 界面注冊(cè)新用戶時(shí)，實(shí)際上就是調(diào)用了 createUser 這個(gè) API。
既然知道了具體要調(diào)用哪個(gè) API，那么我們就可以跳過(guò)在 GUI 界面的操作，直接調(diào)用 createUser 生成“已經(jīng)注冊(cè)的用戶”這個(gè)測(cè)試數(shù)據(jù)了。

為了規(guī)避在創(chuàng)建測(cè)試數(shù)據(jù)時(shí)過(guò)于在乎實(shí)現(xiàn)細(xì)節(jié)的問(wèn)題，在實(shí)際工程實(shí)踐中，我們往往會(huì)把調(diào)用 API 生成測(cè)試數(shù)據(jù)的過(guò)程封裝成測(cè)試數(shù)據(jù)準(zhǔn)備函數(shù)。

那么問(wèn)題來(lái)了，怎么才能知道前端新用戶注冊(cè)這個(gè)操作到底調(diào)用了哪些后端 API 呢？推薦三種方式：

• 直接詢問(wèn)開(kāi)發(fā)人員（最直接）
• 如果有一定的代碼基礎(chǔ)，可以直接閱讀源代碼（作為直接詢問(wèn)方法的補(bǔ)充）
• 在一個(gè)你可以獨(dú)占的環(huán)境上執(zhí)行 GUI 操作創(chuàng)建測(cè)試數(shù)據(jù)，與此同時(shí)監(jiān)控服務(wù)器端的調(diào)用日志，分析這個(gè)過(guò)程到底調(diào)用了哪些 API

優(yōu)點(diǎn)：

• 可以保證創(chuàng)建的測(cè)試數(shù)據(jù)的準(zhǔn)確性（使用了和 GUI 操作同樣的 API 調(diào)用）
• 測(cè)試數(shù)據(jù)準(zhǔn)備的執(zhí)行效率更高（該方法跳過(guò)了耗時(shí)的 GUI 操作）
• 把創(chuàng)建測(cè)試數(shù)據(jù)的 API 調(diào)用過(guò)程，封裝成測(cè)試數(shù)據(jù)函數(shù)更方便（這個(gè)調(diào)用過(guò)程的代碼邏輯非常清晰）
• 測(cè)試數(shù)據(jù)的創(chuàng)建可以完全依賴于 API 調(diào)用
  當(dāng)創(chuàng)建測(cè)試數(shù)據(jù)的內(nèi)部邏輯有變更時(shí)，由于此時(shí) API 內(nèi)部的實(shí)現(xiàn)邏輯也會(huì)由開(kāi)發(fā)人員同步更新，所以我們依舊可以通過(guò)調(diào)用 API 來(lái)得到邏輯變更后的測(cè)試數(shù)據(jù)，而這個(gè)過(guò)程對(duì)使用來(lái)說(shuō)是完全透明的。

缺點(diǎn)：

• 并不是所有的測(cè)試數(shù)據(jù)創(chuàng)建都有對(duì)應(yīng)的 API 支持。
  也就是說(shuō)，并不是所有的數(shù)據(jù)都可以通過(guò) API 調(diào)用的方式創(chuàng)建，有些操作還是必須依賴于數(shù)據(jù)庫(kù)的 CRUD 操作。那么，這時(shí)，我們就不得不在測(cè)試數(shù)據(jù)準(zhǔn)備函數(shù)中加入數(shù)據(jù)庫(kù)的 CRUD 操作生成測(cè)試數(shù)據(jù)了。
• 有時(shí)，創(chuàng)建一條業(yè)務(wù)線上的測(cè)試數(shù)據(jù)，往往需要按一定的順序依次調(diào)用多個(gè) API，并且會(huì)在多個(gè) API 調(diào)用之間傳遞數(shù)據(jù)，這也無(wú)形中增加了測(cè)試數(shù)據(jù)準(zhǔn)備函數(shù)的復(fù)雜性。
• 雖然相比于 GUI 操作方式，基于 API 調(diào)用的方式在執(zhí)行速度上已經(jīng)得到了大幅提升，并且還可以很方便地實(shí)現(xiàn)并發(fā)執(zhí)行（比如，使用 JMeter 或者 Locust），但是對(duì)于需要批量創(chuàng)建海量數(shù)據(jù)的場(chǎng)景，還是會(huì)力不從心。

三、通過(guò)數(shù)據(jù)庫(kù)操作生成測(cè)試數(shù)據(jù)

目前主流的測(cè)試數(shù)據(jù)生成方法

常見(jiàn)的做法是，將創(chuàng)建數(shù)據(jù)需要用到的 SQL 語(yǔ)句封裝成一個(gè)個(gè)的測(cè)試數(shù)據(jù)準(zhǔn)備函數(shù)，當(dāng)我們需要?jiǎng)?chuàng)建數(shù)據(jù)時(shí)，直接調(diào)用這些封裝好的函數(shù)即可。

還是以用戶登錄功能測(cè)試為例，當(dāng)我們通過(guò) GUI 界面注冊(cè)新用戶時(shí)，實(shí)際上是在后端調(diào)用了 createUser 這個(gè) API，而這個(gè) API 的內(nèi)部實(shí)現(xiàn)邏輯是，將用戶的詳細(xì)信息插入到了 userTable 和 userRoleTable 這兩張業(yè)務(wù)表中。

那么此時(shí)，我們就可以直接在 userTable 和 userRoleTable 這兩張業(yè)務(wù)表中插入數(shù)據(jù)，然后完成這個(gè)新用戶的注冊(cè)工作。

這樣做的前提是：需要知道前端用戶通過(guò) GUI 操作注冊(cè)新用戶時(shí)，到底修改了哪些數(shù)據(jù)庫(kù)的業(yè)務(wù)表
推薦三種方式：

• 直接向開(kāi)發(fā)人員索要使用到的 SQL 語(yǔ)句；
• 直接閱讀產(chǎn)品源代碼；
• 在一個(gè)你可以獨(dú)占的環(huán)境上執(zhí)行 GUI 操作產(chǎn)生測(cè)試數(shù)據(jù)，與此同時(shí)，監(jiān)控獨(dú)占環(huán)境的數(shù)據(jù)庫(kù)端業(yè)務(wù)表的變化，找到哪些業(yè)務(wù)表發(fā)生了變化。

優(yōu)點(diǎn)：
測(cè)試數(shù)據(jù)的生成效率非常高，可以在較短的時(shí)間內(nèi)創(chuàng)建大批量的測(cè)試數(shù)據(jù)。

缺點(diǎn)：

• 很多時(shí)候，一個(gè)前端操作引發(fā)的數(shù)據(jù)創(chuàng)建，往往會(huì)修改很多張表，因此封裝的數(shù)據(jù)準(zhǔn)備函數(shù)的維護(hù)成本要高得多
  數(shù)據(jù)庫(kù)，大部分業(yè)務(wù)的數(shù)據(jù)庫(kù)表都是關(guān)聯(lián)的，如果改不好，可能定位問(wèn)題就需要很長(zhǎng)時(shí)間
• 容易出現(xiàn)數(shù)據(jù)不完整的情況
  比如一個(gè)業(yè)務(wù)操作，實(shí)際上在一張主表和一張附表中插入了記錄，但是基于數(shù)據(jù)庫(kù)操作的數(shù)據(jù)創(chuàng)建可能只在主表中插入了記錄，這種錯(cuò)誤一般都會(huì)比較隱蔽，往往只在一些特定的操作下才會(huì)發(fā)生異常；
• 當(dāng)業(yè)務(wù)邏輯發(fā)生變化時(shí)，即 SQL 語(yǔ)句有變化時(shí)，需要維護(hù)和更新已經(jīng)封裝的數(shù)據(jù)準(zhǔn)備函數(shù)。

四、綜合運(yùn)用 API 和數(shù)據(jù)庫(kù)的方式生成測(cè)試數(shù)據(jù)

目前，在實(shí)際的工程實(shí)踐中，很少使用單一的方法生成測(cè)試數(shù)據(jù)，基本都是采用 API 和數(shù)據(jù)庫(kù)相結(jié)合的方式。

最典型的應(yīng)用場(chǎng)景是，先通過(guò) API 調(diào)用生成基礎(chǔ)的測(cè)試數(shù)據(jù)，然后使用數(shù)據(jù)庫(kù)的 CRUD 操作生成符合特殊測(cè)試需求的數(shù)據(jù)

以創(chuàng)建用戶為例：
假設(shè)，我們需要封裝一個(gè)創(chuàng)建用戶的函數(shù)，這個(gè)函數(shù)需要對(duì)外暴露“用戶國(guó)家”和“支付方式”這兩個(gè)參數(shù)。由于實(shí)際創(chuàng)建用戶是通過(guò)后臺(tái) createUser API 完成的，但是這個(gè) API 并不支持指定“用戶國(guó)家”和“支付方式”，所以我們就需要自己封裝一個(gè)創(chuàng)建用戶的函數(shù)。

思路：
1、調(diào)用 createUser API 完成基本用戶的創(chuàng)建
2、調(diào)用 paymentMethod API 實(shí)現(xiàn)用戶對(duì)于不同支付方式的綁定
（其中 paymentMethod API 使用的 userID 就是上一步中 createUser API 產(chǎn)生的用戶 ID）
3、通過(guò)數(shù)據(jù)庫(kù)的 SQL 語(yǔ)句更新“用戶國(guó)家”。

注：在這個(gè)例子中，createUser API 和 paymentMethod API 只是為了說(shuō)明如何綜合運(yùn)用 API 的順序調(diào)用

延伸：
目前，我們需要?jiǎng)?chuàng)建的測(cè)試數(shù)據(jù)并不僅僅局限于數(shù)據(jù)庫(kù)，很多時(shí)候還需要?jiǎng)?chuàng)建消息隊(duì)列里面的數(shù)據(jù)。