《軟件測試52講》
測試數據准備篇
35——如何准備測試數據？
從創建測試數據的維度來看，測試數據准備方法主要可以分為四類：
基於 GUI 操作生成測試數據；
通過 API 調用生成測試數據；
通過數據庫操作生成測試數據；
綜合運用 API 和數據庫的方式生成測試數據。
36——淺談測試數據的痛點
測試數據的痛點
1、在測試用例執行過程中，創建所需的數據往往會耗時較長，從而使得測試用例執行的時間變長；
2、在測試執行之前，先批量生成所有需要用到的測試數據，就有可能出現在測試用例執行時，這些事先創建好的數據已經被修改而無法正常使用了的情況；
3、在微服務架構下，測試環境本身的不穩定，也會阻礙測試數據的順利創建。
從測試數據創建的時機來看，主要分為 On-the-fly（實時創建）和 Out-of-box（事先創建測試數據）兩類方法
On-the-fly 方法又稱為實時創建方法，指的是在測試用例的代碼中實時創建測試用例所要使用到的測試數據，具有數據可靠性高的優點，但是會比較耗時。
Out-of-box 方法又稱為開箱即用方法，指的是在准備測試環境時就事先准備好測試需要用到的全部數據。這樣可以有效縮短測試用例的執行時間，但是存在“臟”數據的問題。
根據測試數據的特性，把它們分為兩大類
“死水數據”是指那些相對穩定，不會在使用過程中改變狀態，並且可以被多次使用的數據。
“活水數據”是指那些只能被一次性使用，或者經常會被修改的測試數據。
“死水數據”適合用 Out-of-box 的方式，而“活水數據”適合采用 On-the-fly 的方式。
37——測試數據的“銀彈”-統一測試數據平台（上）
在測試數據准備1.0 時代，准備測試數據最典型的方法就是，將測試數據准備的相關操作封裝成數據准備函數。
歸納起來，這個時代的數據准備函數，主要有兩種封裝形式：
第一種是，直接使用暴露全部參數的數據准備函數，雖說靈活性最好，但是每次調用前都需要准備大量的參數，從使用者的角度來看便利性比較差；
第二種是，為了解決便利性差的問題，我們引入了更多的專用封裝函數，在靈活性上有了很大的進步，但是也帶來了可維護差的問題。
38——測試數據的“銀彈”-統一測試數據平台（下）
測試數據准備的 3.0 時代
為了解決 2.0 時代跨平台使用數據准備函數的問題，我們將基於 Java 開發的數據准備函數用
Spring Boot 包裝成了 Restful API，並且結合 Swagger 給這些 Restful API 提供了 GUI 界面和文檔。
這樣一來，我們就可以通過 Restful API 調用數據准備函數了，而且由於 Restful API 是通用接口，
所以只要測試框架能夠發起 http 調用，就能使用這些 Restful API。於是，幾乎所有的測試框架都
可以直接使用這些 Restful API 准備測試數據。
由此，測試數據准備工作自然而然地就發展到了平台化階段。我們把這種統一提供各類測試數據的
Restful API 服務，稱為“統一測試數據平台”。
1. 引入了 Core Service 和一個內部數據庫。其中，內部數據庫用於存放創建的測試數據的元數據；Core Service 在內部數據庫的支持下，提供數據質量和數量的管理機制。
2. 當一個測試數據被創建成功后，為了使得下次再要創建同類型的測試數據時可以更高效，CoreService 會自動在后台創建一個 Jenkins Job。這個 Jenkins Job 會再自動創建 100 條同類型的數據，
並將創建成功的數據的 ID 保存到內部數據庫，當下次再請求創建同類型數據時，這個統一測試數據平台就可以直接從內部數據庫返回已經事先創建的數據。在一定程度上，這就相當於將原本的 On-the-fly 轉變成了 Out-of-box，
縮短整個測試用例的執行時間。當這個內部數據庫中存放的 100 條數據被逐被使用，導致總量低於 20 條時，對應的 Jenkins Job 會自動把該類型的數據補足到 100 條。而這些操作對外都是透明的，完全不需要我們進行額外的操作。