軟體測驗回顧(9)

準備測驗資料

35章：如何準備測驗資料？

測驗資料準備方法主要可以分為四類：

基于GUI操作生成測驗資料；
通過API呼叫生成測驗資料；
通過資料庫操作生成測驗資料；
綜合運用API和資料庫的方式生成測驗資料，

1.基于GUI操作生成測驗資料

優點：

在技術上沒有任何復雜性，而且所創建的資料完全來自于真實的業務流程，
可以最大程度保證資料的正確性，

缺點：

創建測驗資料的效率非常低，
基于GUI的測驗資料創建方法不適合封裝成測驗資料工具，
測驗資料成功創建的概率不會太高，
會引入不必要的測驗依賴，如：要測驗登錄功能，首先就要保證注冊功能沒問題的，

在實際的測驗程序中，我們很少直接使用基于GUI的操作生成測驗資料，基于GUI操作生成測驗資料的方法一般只用于手工測驗

2.基于API呼叫生成測驗資料

通過API呼叫生成測驗資料，是目前主流的測驗資料生成方法，

為了規避在創建測驗資料時過于在乎實作細節的問題，在實際工程實踐中，我們往往會把呼叫API生成測驗資料的程序封裝成測驗資料準備函式，

怎么才能知道到底呼叫了哪些后端API呢？這里，我推薦三種方式：

直接詢問開發人員，這是最直接的方法；
如果你有一定的代碼基礎，可以直接閱讀源代碼，這個方法也可以作為直接詢問方法的補充；
在一個你可以獨占的環境上執行GUI操作創建測驗資料，與此同時監控服務器端的呼叫日志，分析這個程序到底呼叫了哪些API，

優點：

保證創建的測驗資料的準確性
執行效率更高
創建測驗資料的API呼叫程序，封裝成測驗資料函式更方便，因為這個呼叫程序的代碼邏輯非常清晰；
依賴于API呼叫，當創建測驗資料的內部邏輯有變更時，由于此時API內部的實作邏輯也會由開發人員同步更新

缺點：

并不是所有的測驗資料創建都有對應的API支持，
創建一條業務線上的測驗資料，往往需要按一定的順序依次呼叫多個API，并且會在多個API呼叫之間傳遞資料，這也無形中增加了測驗資料準備函式的復雜性，
執行速度上已經得到了大幅提升，并且還可以很方便地實作并發執行，但是對于需要批量創建海量資料的場景，還是會力不從心，

3.通過資料庫操作生成測驗資料

通過資料庫操作生成測驗資料，也是目前主流的測驗資料生成方法，

常見的做法是，將創建資料需要用到的SQL陳述句封裝成一個個的測驗資料準備函式，當我們需要創建資料時，直接呼叫這些封裝好的函式即可，

這樣做的前提是，你需要知道前端用戶通過GUI操作注冊新用戶時，到底修改了哪些資料庫的業務表，這里，我也推薦三種方式：

直接向開發人員索要使用到的SQL陳述句；
直接閱讀產品源代碼；
在一個你可以獨占的環境上執行GUI操作產生測驗資料，與此同時，監控獨占環境的資料庫端業務表的變化，找到哪些業務表發生了變化，

缺點：

一個前端操作引發的資料創建，往往會修改很多張表，因此封裝的資料準備函式的維護成本要高得多
容易出現資料不完整的情況，這種錯誤一般都會比較隱蔽，往往只在一些特定的操作下才會發生例外；
當業務邏輯發生變化時，即SQL陳述句有變化時，需要維護和更新已經封裝的資料準備函式

4.綜合運用API和資料庫的方式生成測驗資料

最典型的應用場景是，先通過API呼叫生成基礎的測驗資料，然后使用資料庫的CRUD操作生成符合特殊測驗需求的資料，

36章：測驗資料創建的時機

要分為On-the-fly（實時創建）和Out-of-box（事先創建測驗資料）兩類方法，

1.On-the-fly(實時創建)

在測驗用例的代碼中實時創建要使用到的測驗資料，

采用On-the-fly方式創建的資料，都是由測驗用例自己維護的，不會依賴于測驗用例外的任何資料，從而保證了資料的準確性和可控性，最大程度地避免了出現“臟”資料的可能

缺點：

實時創建測驗資料比較耗時，
測驗資料本身存在復雜的關聯性，
微服務架構的調整
- 很多時候測驗環境并不是100%處于全部可用的狀態，也就是說，并不是所有的服務都是可用的，這就給測驗資料準備帶來了新的挑戰，

2.Out-of-box(事先創建)

為了解決上述三個問題，Out-of-box（即事先創建測驗資料）的方式就應運而生

Out-of-box方法，又稱開箱即用方法，指的是在準備測驗環境時就預先將測驗需要用到的資料全部準備好，而不是在測驗用例中實時創建，

缺點：

Out-of-box最致命的問題是“臟”資料，

那到底什么是“臟”資料呢？這里的“臟”資料是指，資料在被實際使用前，已經被進行了非預期的修改，

這些事先創建好的測驗資料，在測驗用例執行的那個時刻，是否依然可用其實是不一定的，因為這些資料很有可能在被使用前已經發生了非預期的修改，

這些非預期的修改主要來自于以下三個方面：

其他測驗用例使用了這些事先創建好的測驗資料，并修改了這些資料的狀態；
執行手工測驗時，因為直接使用了事先創建好的資料，很有可能就會修改了某些測驗資料；
自動化測驗用例的除錯程序，修改了事先創建的測驗資料；

為了解決這些“臟”資料，我們只能通過優化流程去控制資料的使用，業內有些公司會將所有事先創建好的測驗資料列在一個Wiki頁面，然后按照不同的測驗資料區段來分配使用物件，

更糟糕的是，如果自動化測驗用例直接采用硬編碼的方式，去呼叫那些只能被一次性使用的測驗資料（比如訂單資料、優惠券等）的話，你會發現測驗用例只能在第一次執行時通過，后面再執行都會因為測驗資料的問題而失敗，

Out-of-box方法不適用于只能一次性使用的測驗資料場景，

3.綜合運用On-the-fly和Out-of-box

實際的工程實踐中，往往是采用綜合運用On-the-fly和Out-of-box的方式來實作測驗資料的準備的，

在實際的測驗專案中，我們可以根據測驗資料的特性，把它們分為兩大類，用業內的行話來講就是“死水資料”和“活水資料”，

“死水資料”是指那些相對穩定，不會在使用程序中改變狀態，并且可以被多次使用的資料，比如，商品分類、商品品牌、場館資訊等，這類資料就非常適合采用Out-of-box方式來創建，

這里需要特別說明的是，哪些資料屬于“死水資料”并不是絕對的，由測驗目的決定，

比如，用戶資料在大多數的非用戶相關的測驗用例中基本屬于“死水資料”,

但是，對于那些專門測驗用戶賬號的測驗用例來講，往往會涉及到用戶撤銷、激活、修改密碼等操作，那么此時的用戶資料就不再是“死水資料”了，而應該按照“活水資料”處理，

“活水資料”是指那些只能被一次性使用，或者經常會被修改的測驗資料，最典型的資料是優惠券、商品本身、訂單等類似的資料，這類資料通常在被一次性使用后狀態就發生了變化，不能反復使用，那么這類測驗資料，就更適合采用On-the-fly方式來創建，

個人覺得一定要大家使用一套產生測驗資料的腳本，無論是api還是資料庫，做到一鍵配置、恢復測驗資料，還有就是死水資料的準備大家最好有統一的平臺進行發放，而不是隨便寫，隨便測

37+38章：統一測驗資料平臺

1.測驗資料準備1.0時代

這個階段最典型的方法就是，將測驗資料準備的相關操作封裝成資料準備函式，

利用這種資料準備函式創建測驗資料方法的最大短板，在于其引數非常多、也非常復雜，

其實，絕大多數的測驗資料準備場景是，你僅僅需要一個所有引數都使用了預設值的測驗資料，或者只對個別幾個引數有明確的要求，而其他引數都可以是預設值的測驗資料，

為了解決這個問題，在工程實踐中，就引入了如圖1所示的封裝資料準備函式的形式，

當測驗用例中僅僅需要一個沒有特定要求的默認用戶時，你就可以直接呼叫這個createDefaultUser函式，

對于那些測驗用例只對個別引數有要求的場景，比如只對引數A有要求的場景，我們就可以為此封裝一個createXXXUser(A)函式，用默認值初始化引數B、C、D、E，然后對外暴露引數A，

如果是對多個引數有特定要求的場景，我們就可以封裝出createYYYUser這樣暴露多個引數的函式，

通過這樣的封裝，對于一些常用的測驗資料組合，我們通過一次函式呼叫就可以生成需要的測驗資料；而對于那些比較偏門或者不常用的測驗資料，我們依然可以通過直接呼叫最底層的createUserImpl函式完成資料創建作業，可見，這個方法相比之前已經有了很大的進步，

缺點：

對于引數比較多的情況，會面臨需要封裝的函式數量很多的尷尬，
當底層Impl函式的引數發生變化時，需要修改所有的封裝函式，
資料準備函式的JAR包版本升級比較頻繁，
- 一旦封裝的資料準備函式發生了變化，我們就要升級對應JAR包的版本號，

為了可以進一步解決這三個問題，最大程度地簡化測驗資料準備作業，將測驗資料準備推向了2.0時代，

2.測驗資料準備2.0時代

資料準備函式不再以暴露引數的方式進行封裝了，而是引入了一種叫作Builder Pattern（生成器模式）的封裝方式，這個方式能夠在保證最大限度的資料靈活性的同時，提供使用上的最大便利性，并且維護成本還非常低，

就是之前是代碼直接呼叫生成函式，而現在是生成函式類似使用了生成器設計模式而已

你需要準備一個用戶資料，而且對具體的引數沒有任何要求，

UserBuilder.build();

你現在還需要一個用戶，但是這次需要的是一個美國的用戶，

UserBuilder.withCountry("US").build();

你又需要這樣一個用戶資料：英國用戶，支付方式是Paypal，其他引數都是默認值，

UserBuilder.withCountry("US").withPaymentMethod("Paypal").build();

在實際工程專案中，隨著Builder Pattern的大量使用，又逐漸出現了更多的新需求，為此我歸納總結了以下4點：

有時候，出于執行效率的考慮，我們不希望每次都重新創建測驗資料，而是希望可以從被測系統的已有資料中搜索符合條件的資料；
但是，還有些時候，我們希望測驗資料必須是全新創建的，比如需要驗證新建用戶首次登錄時，系統提示修改密碼的測驗場景，就需要這個用戶一定是被新創建的；
更多的時候，我們并不關心這些測驗資料是新創建的，還是通過搜索得到的，我們只希望以盡可能短的時間得到需要的測驗資料；
甚至，還有些場景，我們希望得到的測驗資料一定是來自于Out-of-box的資料，

為了能夠滿足上述的測驗資料需求，我們就需要在Builder Pattern的基礎上，進一步引入Build Strategy的概念，顧名思義，Build Strategy指的是資料構建的策略，

就是在簡單的生成器模式下合入了策略模式,，通過策略進行生成

我們引入了Search Only、Create Only、Smart和Out-of-box這四種資料構建的策略，這四類構建策略在Builder Pattern中的使用很簡單，只要按照以下的代碼示例指定構建策略就可以了：

UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.SEARCH_ONLY.build();
UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.CREATE_ONLY).build();
UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.SMART).build();
UserBuilder.withCountry(“US”).withBuildStrategy(BuildStrategy.OUT_OF_BOX).build();

這里的Builder Pattern是基于Java代碼實作的，如果你的測驗用例不是基于Java代碼實作的，那要怎么使用這些Builder Pattern呢？我們不希望、也不可能為每套基于不同開發語言的測驗框架都封裝一套Builder Pattern，所以，我們就希望一套Builder Pattern可以適用于所有的測驗框架，這也就是我在前面提到的測驗準備函式的“跨平臺的能力”了，

為了解決這個問題，測驗資料準備走向了3.0時代，

3.測驗資料準備的3.0時代

為了解決2.0時代跨平臺使用資料準備函式的問題，我們將基于Java開發的資料準備函式用Spring Boot包裝成了Restful API，并且結合Swagger給這些Restful API提供了GUI界面和檔案，

就是將測驗準備函式變成了web工具，通過restful api進行統一呼叫，來實作跨平臺

我們就可以通過Restful API呼叫資料準備函式了，而且由于Restful API是通用介面，所以只要測驗框架能夠發起http呼叫，就能使用這些Restful API，于是，幾乎所有的測驗框架都可以直接使用這些Restful API準備測驗資料，

最初，統一測驗資料平臺就是服務化了資料準備函式的功能，并且提供了GUI界面以方便用戶使用，除此以外，并沒有提供其他額外功能，如圖1所示就是統一測驗資料平臺的UI界面，

后來，隨著統一測驗資料平臺的廣泛使用，我們逐漸加入了更多的創新設計，統一測驗資料平臺的架構也逐漸演變成了如圖2所示的樣子，

接下來，我和你分享一下統一測驗資料平臺的架構設計中最重要的兩個部分：

引入了Core Service和一個內部資料庫，其中，內部資料庫用于存放創建的測驗資料的元資料；Core Service在內部資料庫的支持下，提供資料質量和數量的管理機制，
當一個測驗資料被創建成功后，為了使得下次再要創建同型別的測驗資料時可以更高效，Core Service會自動在后臺創建一個Jenkins Job，這個Jenkins Job會再自動創建100條同型別的資料，并將創建成功的資料的ID保存到內部資料庫，當下次再請求創建同型別資料時，這個統一測驗資料平臺就可以直接從內部資料庫回傳已經事先創建的資料，
在一定程度上，這就相當于將原本的On-the-fly轉變成了Out-of-box，縮短整個測驗用例的執行時間，當這個內部資料庫中存放的100條資料被逐漸被使用，導致總量低于20條時，對應的Jenkins Job會自動把該型別的資料補足到100條，而這些操作對外都是透明的，完全不需要我們進行額外的操作，

我看老師的留言下面有個人說怎么一直在科普概念，我認為老師的這段回復很好

很多時候概念本身比會使用工具來得重要的多，對于測驗資料準備的文章中介紹的很多方法和理念都是外面找不到的，都是來自于大專案中的工程實踐，如果大家對工具本身的使用更感興趣，我還是建議通過官方檔案進行學習，但是怎么找到適合你的工具，以及學習這些工具設計的思路，還是要能夠掌握原理，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247100.html

標籤：其他

上一篇：第十二屆藍橋杯模擬賽第二期

下一篇：軟體測驗回顧(11)-常見的網站架構設計

軟體測驗回顧(9)-準備測驗資料