最近在企業里面看了一些測試案例的數據準備，發現了一個共性問題：測試數據中存在大量冗余，這些冗余會給后續的測試案例及數據維護帶來大量的成本。

為了便于大家理解，先舉一個例子：

測試信用卡交易金額匯總，測試數據完全從csv中加載，每個測試案例根據csv中的數據，assert特定返回值（由于篇幅限制，這里只舉了一個簡單的例子。實際看到的情況是，csv完全沒有字段名稱信息，一行里面成百上千個數據，而且還有許許多多類似結構的csv文件作為測試數據）。

在這兩個文件里面，我注意到有大量冗余。以csv格式的測試案例為例，想象一下如果未來這個表結構發生變化（增加或減少字段），那么需要修改所有這些csv文件，會是什么樣的工作量！

在喬梁翻譯的《持續交付：發布可靠軟件的系統方法》一書，其實已經給出了解決思路，只不過由于沒有具體實例，不是很容易理解。

經何勉提醒，發現在《實例化需求》一書中，也提到了類似思路，但同樣都沒有實例，：）：

下面我們就以上面例子為基礎，說明一下兩本書中的思路如何具體應用：

應用程序引用數據(Application reference data)是測試無關數據，但它們是應用程序啟動所必需的，這些數據往往是指一些基表和基礎數據；

測試引用數據（Test reference data）是那些和測試相關，但是對測試行為沒有多大影響的數據，在下面兩個例子中，黃色就是測試引用數據

測試專屬數據（Test specific data）：真正影響測試行為的特征數據

了解了測試引用數據和測試專屬數據的區別后，我就可以介紹測試數據構造第一秘技了：

將測試引用數據和測試專屬數據的準備過程分離，分離復用測試引用數據準備，而將測試專屬數據保存在測試腳本中。

具體的做法是，第一個例子中，我們建議在每個測試案例里面，先使用一段公共程序為每個案例準備一樣的測試引用數據，然后再用UPDATE語句來將測試專屬數據導入，測試案例的偽碼如下：

測試案例1

從CSV導入測試引用數據

測試專屬數據導入

UPDATE transactions SET amount = 15.99 WHERE id = 1;
　　UPDATE transactions SET amount = 30.98 WHERE id = 2;
　　UPDATE transactions SET amount = 75.95 WHERE id = 5;
　　UPDATE transactions SET amount = 150.9 WHERE id = 10;UPDATE transactions SET amount = 750.5 WHERE id = 50;

測試執行

測試驗證 （總和是1024.32）

測試案例2

從CSV導入測試引用數據

測試專屬數據導入

UPDATE transactions SET amount = 34.56 WHERE id = 1;
　　UPDATE transactions SET amount = 56.78 WHERE id = 2;
　　UPDATE transactions SET amount = 57.97 WHERE id = 5;
　　UPDATE transactions SET amount = 44.32 WHERE id = 10;
　　UPDATE transactions SET amount = 234.65 WHERE id = 50

測試執行

測試驗證 （總和是428.28）

這樣做主要有兩點好處：

測試案例可維護性：上面這些案例中，測試引用數據由于使用了INSERT語句，它其實會受到數據庫表結構變化的影響，而測試專屬數據準備由于使用 UPDATE語句，不會受到數據庫表結構變化的影響。我們通過統一測試引用數據準備程序，將這種變化的沖擊大大降低，未來數據表結構變更，我們只需修改統一的測試引用數據準備程序而無需修改每一個案例，這其實暗合了DRY原則（Don’t repeat yourself）。

測試案例可讀性：由于我們將測試引用數據準備從獨立出來了，只要看測試案例本身，就可以明確地看到測試專屬數據，被測行為和結果驗證，讓案例可讀性大大提升。

為了便于大家理解，我們再舉另一個例子，假設有一個測試匯率轉換接口，測試輸入是xml文件：

應用測試引用數據和測試專屬數據分離原則，可以看到哪些是引用數據，哪些是專屬數據

因此，在測試案例中，我們會先準備并加載一個基底XML文件，再設置測試專屬數據，下面是利用Robot Framework編寫的兩個測試案例，可以看出，未來如果XML文件的結構有任何變更，我們都只需要修改基底XML文件即可，而不需要修改任何測試案例了

至此，我們想大家已經明白，對于測試數據準備這個步驟而言，將測試引用數據和測試專屬數據分離，會非常有效地提升測試案例可維護性和可讀性。