如何對軟件測試中用到的測試數據建模

　　現在很多軟件應用，都設計成2部分：應用程序Application + 數據庫DB。要對這種類型的應用軟件進行測試，“測試數據”這個概念就非常的關鍵。測試用例中的“前置條件”，基本就是圍繞測試數據來設計的。以淘寶網的測試為例，驗證每個功能點時，最重要的就是準備好各種類型的數據對象，比如：不通信用級別的賣家，不同類目屬性的商品等等。

　　熟練的測試工程師手里都會保存一批測試數據(比如賬號、商品)，并且分類管理，不同場景的測試用例，都會有專門的測試數據來支持。在ta的心里，存在著一套完整的測試設計方案，在工作中也會顯得游刃有余。要達到這種狀態，需要經過一段時間的積累，需要“磨合”。對測試數據的控制力，也是測試工程師的重要能力之一，可惜這種能力很難被識別，被比較。

　　最近2年，軟件測試工作在逐漸向開發團隊轉移，由以前的測試團隊“全包”，變成了現在的“半包”。很多觀點也認為，開發團隊來做測試工作，有著得天獨厚的優勢，因為開發對應用程序的結構最熟悉，哪里容易出現問題也最清楚。當然也有很多開發表示反對，原因大概有下面幾個：

　　沒時間，能把代碼寫完就不錯了

　　開發工程師沒有測試工程師的那種思維方式

　　測試數據準備起來比較困難

　　這里的“測試數據問題”是客觀存在的，但不僅僅是這么簡單的一句話可以概括，需要深入分析。我們觀察開發工程師在做測試工作的時候，在測試數據方面會遇到下面幾個問題：

　　對于一些比較復雜的測試場景，搞不清應該構造哪些測試數據對象，最后只好隨便抓一個來測試，只要沒拋異常，就算pass;

　　就算搞清了測試數據的需求，去哪找這些數據，仍然是一個大問題，最后還是隨便抓一個來測試;

　　就算把所有的測試數據都做好，如何根據測試場景隨機應變的使用，如何維護這些數據始終有效，也非常不容易;

　　分析到這里我們發現，測試工程師對測試數據的控制能力，真的不簡單，開發工程師在工作中一般沒有接受過類似的訓練，所以很容易陷入“測試數據”的泥潭。而且，這個問題跟人的能力有關，不是單純依靠工具能解決的。關于“測試數據建模”，主要是解決上面的第一個問題：當我們要測試一個功能點，或者一系列場景的時候，需要設計出怎樣的測試數據組合。

　　我們先假設一個最簡單的場景，這個場景只需要用到1個數據對象：USER，那么這里的測試數據，就是USER的每個屬性的枚舉值：性別、年齡、狀態、等級，我們用一句話就可以概括一個數據對象，比如：女性user、20歲的user、狀態是已認證的user。測試用例可以這樣寫，但是實際測試時，熟練的測試工程師并不會分別測試，而是把多種情況組合在一起，比如：20歲的已經認證的女性user。每個人的組合方式都不一樣。有一種算法叫做“Pairwise Testing”，可以比較科學的組合多個屬性的枚舉值。但是有經驗的測試工程師發現，年齡和性別的邏輯關系很密切，這里的組合需要特別的設計，依靠Pairwise的基礎設計還遠遠不夠，需要引入業務邏輯的分析。

　　所以同樣的測試用例，不同的工程師在測試時，花費的時間，得出的結果，會有很大的不同。僅僅一個數據對象，就會產生這么復雜的情況，那么請設想一下，如果一個場景需要用到5個數據對象，并且它們之間存在復雜的邏輯關系時，測試工程師需要面臨怎樣的困難局面，我們已經無法用一句話來概括測試數據的具體值。這里“測試數據建模”的概念就自然的引出了，建模的目的，就是我們可以很容易的描述清楚，復雜場景下的測試數據是怎樣的。

　　很多工程師習慣用思維導圖來進行測試數據的設計，比如上文那個例子，大家會看到這樣的設計圖：

　　但是在真實的測試場景中，我們使用的是matrix來組織測試數據，如下：

　　灰色的cell代表在這個場景下，該屬性隨便取什么值。在這個案例里，我們發現性別和年齡關系密切，而狀態和等級關系密切，所以測試數據需要分開設計，我們建立A、B兩個模型：

　　A模型是：

　　user.性別 : {"男" , "女" , "不知道"}

　　user.年齡 : {"10" , "20" , "30" , "40"}

　　B模型是：

　　user.狀態 : {"未認證" , "認證" , "刪除" }

　　user.等級 : {"新人" , "熟練手" , "磚家" }

　　每個模型都必須有一個唯一的名稱，目的是為了方便測試設計和交流。比如這個Test Suite(一組Test Case的集合)需要使用A模型，那個Test Suite需要B模型。這里的A、B只是一個代號，真實工作中可以根據產品特點重新定義命名規則。

　　測試數據模型的真正內涵是：把業務邏輯關聯最強的數據對象屬性聚在一起建立group，并列舉出需要的屬性值，方便測試用例的設計，更為重要的是，模型讓開發和測試在圍繞“測試數據問題”進行討論的時候，有一個標準。由于模型里面已經封裝了很多信息，只要指明模型的名稱，交流就變得更加簡單了。

　　當然文章里這個案例的邏輯非常簡單，實際工作中并不需要測試數據建模，不過當數據對象比較多時，價值就能體現出來了。比如淘寶的下單，可能就會出現這樣的數據模型：

　　商品.價格 : {"",""}

　　賣家.狀態 : {"",""}

　　買家.所在地 : {"",""}

　　類目.XXX : {"",""}

　　復雜的數據模型，可能會有10個以上的數據對象屬性。不過我們不能把所有對象屬性，都堆在一個模型里，那樣沒有任何意義，我們需要根據業務邏輯對屬性進行分類，建立不同的模型，比如優惠、運費計算是不同的業務邏輯，因此需要建不同的模型。而圍繞優惠這個概念，還會根據不同屬性組合關系，建立多個模型。

原文轉自：http://www.kjueaiud.com