public string AccountNumber { get; set; }
public string FirstName { get; set; }
public string Surname { get; set; }
public string TelephoneNumber { get; set; }
...
}
有了這些領域模型，測試就能直接構建在這些對象上了。例如，可以如此驗證所返回的用戶名為'Bei'：
Assert.AreEqual("Bei", subscriber.FirstName);
或者電話號碼以'010'開始：
Assert.IsTrue(subscriber.TelephoneNumber.StartsWith("010"));
點擊這里可以下載到樣例代碼。代碼中演示了如何用分層架構組織測試自動化代碼。 你可以在Visual Studio 2008中打開項目，也可以在命令行運行執行'go.bat’來運行所有測試。 'go.bat’運行完后會將測試結果保存在'artifacts’文件夾。源代碼中包含三個項目。 名稱以with ‘Client’的項目包含領域層。以'Client.Spec’結尾的項目為領域層對應的單元測試(TDD)。'Stories’項目包含測試用例層。這份源代碼由真實項目中來，并作了相應修改。某些類返回了硬編碼的值，是為了不訪問真實的web服務。
這如何能解決問題?
1. 問題：'測試邏輯難以理解和修改'�，F在我們有了一個單獨的層表示測試邏輯。這層構建在領域層之上，因此測試可以 很用簡潔、緊湊的自然語言形式表述，因此閱讀、理解、推理和修改測試用例的難度，更取決于編碼人員的語言能力，而非編碼水平。
2. 問題：'測試很脆弱'。因為我們有一個單獨的層把測試用例和待測系統隔離開，若待測系統有任何變化，只有此層 會受到影響。只要在此層做相應修改，構建于此層之上的測試用例仍然可以執行。
3. 問題: '維護開銷大'。因為有了領域層的封裝，各個測試用例中不會再有重復代碼。要做修改，也只需修改一處。此外， 因為領域模型直接針對待測系統建模，代碼也跟容易理解和修改。
常見問題解答
問題：這個方法看起來有些復雜，必須要這么做嗎?
回答：這主要取決于待測系統的規模和復雜程度。如果系統規模較小、業務邏輯相對簡單，這個方法就過于笨重了。在這種情況下，甚至連測試自動化都可能是浪費時間。如果只花幾分鐘時間就能手動測試整個系統，那還自動化干什么呢?若系統較為復雜，把測試邏輯和支持代碼混合在一起問題應該不大。而對業務邏輯復雜、規模龐大的系統(也就是說，大部分企業級應用) 我偏好這種方式。
問題：若采用這種結構，那么在開始‘真正’的測試前，需要投入一定時間搭建整個結構，會不會很浪費時間?
回答：這只是另外一種組織代碼的方式。即使代碼不按照這種方式組織，還是要寫代碼拼裝URL、解析XML / HTML、驗證測試結果。采用這種結構，只需要把代碼拆分到不同的類及方法中。此外，沒有必要一次完成整個結構�？梢愿鶕斍暗臏y試需要，逐步完成整個結構。
問題：完成這個結構需要相當的面向對象知識，并不是所有QA都可以做。
回答：實際上測試自動化并不只是QA的職責。項目中其他成員，包括開發人員，也可以參與。
開發人員有很強的編程功底，編寫出的代碼質量也相對較高，因此可以負責領域層。而QA擅長設計測試用例、找出各種邊界測試條件，因此可以負責測試用例層。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
