灰色的cell代表在這個場景下，該屬性隨便取什么值。在這個案例里，我們發(fā)現(xiàn)性別和年齡關(guān)系密切，而狀態(tài)和等級關(guān)系密切，所以測試數(shù)據(jù)需要分開設(shè)計，我們建立A、B兩個模型：
A模型是：
● user.性別 : {"男" , "女" , "不知道"}
● user.年齡 : {"10" , "20" , "30" , "40"}
B模型是：
● user.狀態(tài) : {"未認證" , "認證" , "刪除" }
● user.等級 : {"新人" , "熟練手" , "磚家" }
每個模型都必須有一個唯一的名稱，目的是為了方便測試設(shè)計和交流。比如這個Test Suite（一組Test Case的集合）需要使用A模型，那個Test Suite需要B模型。這里的A、B只是一個代號，真實工作中可以根據(jù)產(chǎn)品特點重新定義命名規(guī)則。
測試數(shù)據(jù)模型的真正內(nèi)涵是：把業(yè)務邏輯關(guān)聯(lián)最強的數(shù)據(jù)對象屬性聚在一起建立group，并列舉出需要的屬性值，方便測試用例的設(shè)計，更為重要的 是，模型讓開發(fā)和測試在圍繞“測試數(shù)據(jù)問題”進行討論的時候，有一個標準。由于模型里面已經(jīng)封裝了很多信息，只要指明模型的名稱，交流就變得更加簡單了。
當然文章里這個案例的邏輯非常簡單，實際工作中并不需要測試數(shù)據(jù)建模，不過當數(shù)據(jù)對象比較多時，價值就能體現(xiàn)出來了。比如淘寶的下單，可能就會出現(xiàn)這樣的數(shù)據(jù)模型：
● 商品.價格 : {"",""}
● 賣家.狀態(tài) : {"",""}
● 買家.所在地 : {"",""}
● 類目.XXX : {"",""}
復雜的數(shù)據(jù)模型，可能會有10個以上的數(shù)據(jù)對象屬性。不過我們不能把所有對象屬性，都堆在一個模型里，那樣沒有任何意義，我們需要根據(jù)業(yè)務邏輯 對屬性進行分類，建立不同的模型，比如優(yōu)惠、運費計算是不同的業(yè)務邏輯，因此需要建不同的模型。而圍繞優(yōu)惠這個概念，還會根據(jù)不同屬性組合關(guān)系，建立多個 模型。
我想每個測試場景，需要建立的數(shù)據(jù)模型并不會很多，2、3個左右。數(shù)據(jù)模型必須是常用的，這樣才有實際意義。時間久了，研發(fā)團隊每個成員的腦海 里，對于測試數(shù)據(jù)模型的概念，會越來越深刻，甚至對于模型里的某個Test Case，如果被執(zhí)行的次數(shù)夠多的話，也會被大家記住。到時候Test Case也會需要名稱，為了方便大家記憶交流。
在實際工作中，開發(fā)工程師經(jīng)常反映，要執(zhí)行某個Test Case，只修改某個數(shù)據(jù)對象（比如user）的屬性，根本不夠，必須要把多個數(shù)據(jù)對象（比如user、order、item）同時修改，才能完成。這其 實就是一個典型的需求：這個Case需要一個復雜的測試數(shù)據(jù)模型。
當測試數(shù)據(jù)模型被大家接受以后，我們就可以圍繞模型做一些工具開發(fā)，來簡化準備測試數(shù)據(jù)的工作。如果工具只能分別修改某個對象的屬性，那么可用 性就不會太好，需要人為進行組合操作。如果工具能以測試數(shù)據(jù)模型為單元，就可以很快生成數(shù)據(jù)模型里的某個Test Case，這樣會大大簡化測試準備工作。
需要說明的是，本文是基于工作現(xiàn)狀的推理，這種建模方式僅僅是“原型”，還缺少一些最佳實踐。如果本文的論述能引起你的共鳴，歡迎你在自己的產(chǎn)品測試中試一試。