測試數據構造秘技

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

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

　　測試信用卡交易金額匯總，測試數據完全從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文件：

原文轉自：http://www.uml.org.cn/Test/201406185.asp