灰色的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個以上的數據對象屬性。不過我們不能把所有對象屬性，都堆在一個模型里，那樣沒有任何意義，我們需要根據業務邏輯 對屬性進行分類，建立不同的模型，比如優惠、運費計算是不同的業務邏輯，因此需要建不同的模型。而圍繞優惠這個概念，還會根據不同屬性組合關系，建立多個 模型。
我想每個測試場景，需要建立的數據模型并不會很多，2、3個左右。數據模型必須是常用的，這樣才有實際意義。時間久了，研發團隊每個成員的腦海 里，對于測試數據模型的概念，會越來越深刻，甚至對于模型里的某個Test Case，如果被執行的次數夠多的話，也會被大家記住。到時候Test Case也會需要名稱，為了方便大家記憶交流。
在實際工作中，開發工程師經常反映，要執行某個Test Case，只修改某個數據對象（比如user）的屬性，根本不夠，必須要把多個數據對象（比如user、order、item）同時修改，才能完成。這其 實就是一個典型的需求：這個Case需要一個復雜的測試數據模型。
當測試數據模型被大家接受以后，我們就可以圍繞模型做一些工具開發，來簡化準備測試數據的工作。如果工具只能分別修改某個對象的屬性，那么可用 性就不會太好，需要人為進行組合操作。如果工具能以測試數據模型為單元，就可以很快生成數據模型里的某個Test Case，這樣會大大簡化測試準備工作。
需要說明的是，本文是基于工作現狀的推理，這種建模方式僅僅是“原型”，還缺少一些最佳實踐。如果本文的論述能引起你的共鳴，歡迎你在自己的產品測試中試一試。