最近看了幾篇關(guān)于測試數(shù)據(jù)的文章，在此總結(jié)記錄一下。文章尾部為閱讀的原文，有興趣的同學(xué)可以查看一下。
1.測試數(shù)據(jù)的準(zhǔn)備主要有以下幾種方式：
1）基于 GUI 操作生成測試數(shù)據(jù)
優(yōu)點(diǎn)：
簡單直接，無任何復(fù)雜性
缺點(diǎn)：
創(chuàng)建數(shù)據(jù)效率低
基于 GUI 的測試數(shù)據(jù)創(chuàng)建方法不適合封裝成測試數(shù)據(jù)工具
測試數(shù)據(jù)成功創(chuàng)建的概率不會太高（因?yàn)榉浅Ｒ蕾嘦I頁面的穩(wěn)定性）
會引入不必要的依賴
備注：此種生成數(shù)據(jù)方法是2）和3）的基礎(chǔ)，所以確實(shí)有存在的意義
2）通過 API 調(diào)用生成測試數(shù)據(jù)
優(yōu)點(diǎn)：
可以保證創(chuàng)建的測試數(shù)據(jù)的準(zhǔn)確性。
測試數(shù)據(jù)準(zhǔn)備的執(zhí)行效率更高，因?yàn)樵摲椒ê臅r(shí)低
把創(chuàng)建測試數(shù)據(jù)的 API 調(diào)用過程進(jìn)行封裝，方便調(diào)用
缺點(diǎn)：
部分?jǐn)?shù)據(jù)依賴于數(shù)據(jù)庫的 CRUD 操作(增刪改查)
部分業(yè)務(wù)的復(fù)雜性，會增加api函數(shù)的復(fù)雜性
api生成測試數(shù)據(jù)的方式，對于需要批量創(chuàng)建海量數(shù)據(jù)的場景，會力不從心。
3）通過數(shù)據(jù)庫操作生成測試數(shù)據(jù)
4）綜合運(yùn)用 API 和數(shù)據(jù)庫的方式生成測試數(shù)據(jù)
在實(shí)際項(xiàng)目中，業(yè)界往往會綜合采用 API 和數(shù)據(jù)庫的方式生成測試數(shù)據(jù)，即通過 API 調(diào)用生成基礎(chǔ)數(shù)據(jù)，然后使用數(shù)據(jù)庫的 CRUD 操作進(jìn)一步生成符合特殊測試需求的數(shù)據(jù)。
2.測試數(shù)據(jù)創(chuàng)建時(shí)機(jī)
1）On-the-fly（實(shí)時(shí)創(chuàng)建）
采用On-the-fly方式創(chuàng)建的數(shù)據(jù)，都是由測試用例自己維護(hù)的，不會依賴于測試用例外的任何數(shù)據(jù)，從而保證了數(shù)據(jù)的準(zhǔn)確性和可控性，最大程度地避免了出現(xiàn)“臟”數(shù)據(jù)的可能。
弊端：
實(shí)時(shí)創(chuàng)建測試數(shù)據(jù)比較耗時(shí)。
測試數(shù)據(jù)本身存在復(fù)雜的關(guān)聯(lián)性。
微服務(wù)架構(gòu)的調(diào)整，由于api不可用會導(dǎo)致造數(shù)失敗
2）Out-of-box（事先創(chuàng)建測試數(shù)據(jù)）
Out-of-box方法，又稱開箱即用方法，指的是在準(zhǔn)備測試環(huán)境時(shí)就預(yù)先將測試需要用到的數(shù)據(jù)全部準(zhǔn)備好，而不是在測試用例中實(shí)時(shí)創(chuàng)建。因此，我們可以節(jié)省不少測試用例的執(zhí)行時(shí)間，同時(shí)也不會存在由于環(huán)境問題無法創(chuàng)建測試數(shù)據(jù)而阻礙測試用例執(zhí)行的情況。
弊端：最致命的問題是“臟”數(shù)據(jù)
非預(yù)期的修改主要來自于以下三個(gè)方面：
其他測試用例使用了這些事先創(chuàng)建好的測試數(shù)據(jù)，并修改了這些數(shù)據(jù)的狀態(tài)；
執(zhí)行手工測試時(shí)，因?yàn)橹苯邮褂昧耸孪葎?chuàng)建好的數(shù)據(jù)，很有可能就會修改了某些測試數(shù)據(jù)；
自動(dòng)化測試用例的調(diào)試過程，修改了事先創(chuàng)建的測試數(shù)據(jù)；
業(yè)內(nèi)有些公司會將所有事先創(chuàng)建好的測試數(shù)據(jù)列在一個(gè) Wiki 頁面，然后按照不同的測試數(shù)據(jù)區(qū)段來分配使用對象。
3）綜合運(yùn)用 On-the-fly 和 Out-of-box
為了充分利用 On-the-fly 和 Out-of-box 這兩種方式的各自優(yōu)點(diǎn)，并且規(guī)避各自的缺點(diǎn)，實(shí)際的工程實(shí)踐中，往往是采用綜合運(yùn)用 On-the-fly 和 Out-of-box 的方式來實(shí)現(xiàn)測試數(shù)據(jù)的準(zhǔn)備的。
在實(shí)際的測試項(xiàng)目中，我們可以根據(jù)測試數(shù)據(jù)的特性，把它們分為兩大類，用業(yè)內(nèi)的行話來講就是“死水?dāng)?shù)據(jù)”和“活水?dāng)?shù)據(jù)”。
“死水?dāng)?shù)據(jù)”是指那些相對穩(wěn)定，不會在使用過程中改變狀態(tài)，并且可以被多次使用的數(shù)據(jù)。比如，商品分類、商品品牌、場館信息等。這類數(shù)據(jù)就非常適合采用 Out-of-box 方式來創(chuàng)建。
這里需要特別說明的是，哪些數(shù)據(jù)屬于“死水?dāng)?shù)據(jù)”并不是絕對的，由測試目的決定。
“活水?dāng)?shù)據(jù)”是指那些只能被一次性使用，或者經(jīng)常會被修改的測試數(shù)據(jù)。最典型的數(shù)據(jù)是優(yōu)惠券、商品本身、訂單等類似的數(shù)據(jù)。這類數(shù)據(jù)通常在被一次性使用后狀態(tài)就發(fā)生了變化，不能反復(fù)使用。那么這類測試數(shù)據(jù)，就更適合采用 On-the-fly 自維護(hù)的方式。
4）總結(jié)：
On-the-fly 方法又稱為實(shí)時(shí)創(chuàng)建方法，指的是在測試用例的代碼中實(shí)時(shí)創(chuàng)建測試用例所要使用到的測試數(shù)據(jù)，具有數(shù)據(jù)可靠性高的優(yōu)點(diǎn)，但是會比較耗時(shí)。
Out-of-box 方法又稱為開箱即用方法，指的是在準(zhǔn)備測試環(huán)境時(shí)就事先準(zhǔn)備好測試需要用到的全部數(shù)據(jù)。這樣可以有效縮短測試用例的執(zhí)行時(shí)間，但是存在“臟”數(shù)據(jù)的問題。
“死水?dāng)?shù)據(jù)”和“活水?dāng)?shù)據(jù)”的角度來看，如何綜合運(yùn)用上述兩種方式創(chuàng)建測試數(shù)據(jù)：其中“死水?dāng)?shù)據(jù)”適合用 Out-of-box 的方式，而“活水?dāng)?shù)據(jù)”適合采用 On-the-fly 的方式。
3.測試數(shù)據(jù)的“銀彈”- 統(tǒng)一測試數(shù)據(jù)平臺（上）
在 1.0 時(shí)代，準(zhǔn)備測試數(shù)據(jù)最典型的方法就是，將測試數(shù)據(jù)準(zhǔn)備的相關(guān)操作封裝成數(shù)據(jù)準(zhǔn)備函數(shù)。
歸納起來，這個(gè)時(shí)代的數(shù)據(jù)準(zhǔn)備函數(shù)，主要有兩種封裝形式：
第一種是，直接使用暴露全部參數(shù)的數(shù)據(jù)準(zhǔn)備函數(shù)，雖說靈活性最好，但是每次調(diào)用前都需要準(zhǔn)備大量的參數(shù)，從使用者的角度來看便利性比較差；
第二種是，為了解決便利性差的問題，我們引入了更多的專用封裝函數(shù)，在靈活性上有了很大的進(jìn)步，但是也帶來了可維護(hù)差的問題。
所以，為了可以更高效地準(zhǔn)備測試數(shù)據(jù)，我們即將迎來測試數(shù)據(jù)準(zhǔn)備的 2.0 時(shí)代，拭目以待吧。
4.測試數(shù)據(jù)的“銀彈”- 統(tǒng)一測試數(shù)據(jù)平臺（下）
1）Builder Pattern 是一種數(shù)據(jù)準(zhǔn)備函數(shù)的封裝方式。
Builder Pattern 的便利性：
如果僅僅需要一個(gè)全部采用缺省參數(shù)的數(shù)據(jù)的話，你可以直接使用 TestDataBuilder.build() 得到；
如果你對其中的某個(gè)或某幾個(gè)參數(shù)有特定要求的話，你可以通過“.withParameter()”的方式指定，而沒有指定的參數(shù)將自動(dòng)采用默認(rèn)值。
2）Builder Pattern 對于新需求的使用方案：
在實(shí)際工程項(xiàng)目中，隨著 Builder Pattern 的大量使用，又逐漸出現(xiàn)了更多的新需求，歸納總結(jié)為以下 4 點(diǎn)：
有時(shí)候，出于執(zhí)行效率的考慮，我們不希望每次都重新創(chuàng)建測試數(shù)據(jù)，而是希望可以從被測系統(tǒng)的已有數(shù)據(jù)中搜索符合條件的數(shù)據(jù)；
但是，還有些時(shí)候，我們希望測試數(shù)據(jù)必須是全新創(chuàng)建的，比如需要驗(yàn)證新建用戶首次登錄時(shí)，系統(tǒng)提示修改密碼的測試場景，就需要這個(gè)用戶一定是被新創(chuàng)建的；
更多的時(shí)候，我們并不關(guān)心這些測試數(shù)據(jù)是新創(chuàng)建的，還是通過搜索得到的，我們只希望以盡可能短的時(shí)間得到需要的測試數(shù)據(jù)；
甚至，還有些場景，我們希望得到的測試數(shù)據(jù)一定是來自于 Out-of-box 的數(shù)據(jù)。
為了能夠滿足上述的測試數(shù)據(jù)需求，我們就需要在 Builder Pattern 的基礎(chǔ)上，進(jìn)一步引入 Build Strategy 的概念。顧名思義，Build Strategy 指的是數(shù)據(jù)構(gòu)建的策略。
為此，我們引入了 Search Only、Create Only、Smart 和 Out-of-box 這四種數(shù)據(jù)構(gòu)建的策略。這四類構(gòu)建策略在 Builder Pattern 中的使用很簡單，只要按照以下的代碼示例指定構(gòu)建策略就可以了：
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();
結(jié)合著這四類構(gòu)建策略的代碼，我再和你分享一下，它們會在創(chuàng)建測試數(shù)據(jù)時(shí)執(zhí)行什么操作，返回什么樣的結(jié)果：
當(dāng)使用 BuildStrategy.SEARCH_ONLY 策略時(shí)，Builder Pattern 會在被測系統(tǒng)中搜索符合條件的測試數(shù)據(jù)，如果找到就返回，否則就失?。ㄟ@里，失敗意味著沒能返回需要的測試數(shù)據(jù)）；
當(dāng)使用 BuildStrategy.CREATE_ONLY 策略時(shí)，Builder Pattern 會在被測系統(tǒng)中創(chuàng)建符合要求的測試數(shù)據(jù)，然后返回；
當(dāng)使用 BuildStrategy.SMART 策略時(shí)，Builder Pattern 會先在被測系統(tǒng)中搜索符合條件的測試數(shù)據(jù)，如果找到就返回，如果沒找到就創(chuàng)建符合要求的測試數(shù)據(jù)，然后返回；
當(dāng)使用 BuildStrategy.OUT_OF_BOX 策略時(shí)，Builder Pattern 會返回 Out-of-box 中符合要求的數(shù)據(jù)，如果在 Out-of-box 中沒有符合要求的數(shù)據(jù)，build 函數(shù)就會返回失??；
由此可見，引入 Build Strategy 之后，Builder Pattern 的適用范圍更廣了，幾乎可以滿足所有的測試數(shù)據(jù)準(zhǔn)備的要求。
3）測試數(shù)據(jù)準(zhǔn)備的 3.0 時(shí)代
將所有的數(shù)據(jù)準(zhǔn)備函數(shù)在SpringBoot的支持下轉(zhuǎn)變?yōu)榱薘estfulAPI，為跨平臺和跨語言的各類測試框架提供了統(tǒng)一的數(shù)據(jù)準(zhǔn)備方案。
統(tǒng)一測試數(shù)據(jù)平臺的架構(gòu)設(shè)計(jì)中最重要的兩個(gè)部分：
--引入了 Core Service 和一個(gè)內(nèi)部數(shù)據(jù)庫。其中，內(nèi)部數(shù)據(jù)庫用于存放創(chuàng)建的測試數(shù)據(jù)的元數(shù)據(jù)；Core Service 在內(nèi)部數(shù)據(jù)庫的支持下，提供數(shù)據(jù)質(zhì)量和數(shù)量的管理機(jī)制。
--當(dāng)一個(gè)測試數(shù)據(jù)被創(chuàng)建成功后，為了使得下次再要?jiǎng)?chuàng)建同類型的測試數(shù)據(jù)時(shí)可以更高效，Core Service 會自動(dòng)在后臺創(chuàng)建一個(gè) Jenkins Job。這個(gè) Jenkins Job 會再自動(dòng)創(chuàng)建 100 條同類型的數(shù)據(jù)，并將創(chuàng)建成功的數(shù)據(jù)的 ID 保存到內(nèi)部數(shù)據(jù)庫，當(dāng)下次再請求創(chuàng)建同類型數(shù)據(jù)時(shí)，這個(gè)統(tǒng)一測試數(shù)據(jù)平臺就可以直接從內(nèi)部數(shù)據(jù)庫返回已經(jīng)事先創(chuàng)建的數(shù)據(jù)。
在一定程度上，這就相當(dāng)于將原本的 On-the-fly 轉(zhuǎn)變成了 Out-of-box，縮短整個(gè)測試用例的執(zhí)行時(shí)間。當(dāng)這個(gè)內(nèi)部數(shù)據(jù)庫中存放的 100 條數(shù)據(jù)被逐漸被使用，導(dǎo)致總量低于 20 條時(shí)，對應(yīng)的 Jenkins Job 會自動(dòng)把該類型的數(shù)據(jù)補(bǔ)足到 100 條。而這些操作對外都是透明的，完全不需要我們進(jìn)行額外的操作。
這就是測試數(shù)據(jù)準(zhǔn)備的 3.0 時(shí)代的最佳實(shí)踐了。
相關(guān)文章：
https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=2&sn=d89f79447b3d344c2f304771fce7f3ba&chksm=f3f6751fc481fc09e9503ac2ff311b4202412380d9e8413150619c93fe38c00bbd4002d3eed8&mpshare=1&scene=24&srcid=04158wfglL0n5vECouoqiPnH#rd
https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=3&sn=7a82a82fd8d5bf7483b771e74789dd8f&chksm=f3f6751fc481fc0945e24ce256397d58d05852eb4bd24da117e50de782500b3a2cd7f8840042&mpshare=1&scene=24&srcid=04150t80cKjyXCbC3yQyyAyj#rd
https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=4&sn=e2d9b55a3d086e1d5eef77bb3b5ef598&chksm=f3f6751fc481fc09f5059bf8726fcb5330e374689a52126e9d052510d26b396e85580baf40ce&mpshare=1&scene=24&srcid=0415w541r3xxeTpBdo2D8TzF#rd
https://mp.weixin.qq.com/s?__biz=MzIyNTIzNzM3Ng==&mid=2650805744&idx=5&sn=27f52d70961aeb22e3d68d94e80ab2d1&chksm=f3f6751fc481fc0913c961c49d877e1cfcd1b0b4c2be37c28c4643a0f3906128ed5e5f178d0d&mpshare=1&scene=24&srcid=0415EHb3RrydihPgMZLGtiu1#rd
