领域层
CustomerService类以真实web服务的名称命名。在需求文档、日常对话、架构图以及代码中，都用这个名称来指代此web服务。 使用统一的名称，能除去二义，提高沟通效率。
{
public Subscriber SearchWithTelephoneNumber(string telephoneNumber)
{
string url =
string.Format(
"{0}/subscribers?telephoneNumber={1}",
endpoint, telephoneNumber);
//Send http request to web service, parse the xml returned,
//populate the subscriber object and etc.
return GetResponse(url);
}
...
}
Subscriber类建模了用户。比起用竖线分割的字符串，增加一层数据抽象，用对象表示返回的数据，能使 测试更容易理解(你应该不会偏好用pipedData[101]表示电话号码吧?)。
{
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. 问题：'测试逻辑难以理解和修改'。现在我们有了一个单独的层表示测试逻辑。这层构建在领域层之上，因此测试可以 很用简洁、紧凑的自然语言形式表述，因此阅读、理解、推理和修改测试用例的难度，更取决于编码人员的语言能力，而非编码水平。
2. 问题：'测试很脆弱'。因为我们有一个单独的层把测试用例和待测系统隔离开，若待测系统有任何变化，只有此层 会受到影响。只要在此层做相应修改，构建于此层之上的测试用例仍然可以执行。
3. 问题: '维护开销大'。因为有了领域层的封装，各个测试用例中不会再有重复代码。要做修改，也只需修改一处。此外， 因为领域模型直接针对待测系统建模，代码也跟容易理解和修改。
常见问题解答
问题：这个方法看起来有些复杂，必须要这么做吗?
回答：这主要取决于待测系统的规模和复杂程度。如果系统规模较小、业务逻辑相对简单，这个方法就过于笨重了。在这种情况下，甚至连测试自动化都可能是浪费时间。如果只花几分钟时间就能手动测试整个系统，那还自动化干什么呢?若系统较为复杂，把测试逻辑和支持代码混合在一起问题应该不大。而对业务逻辑复杂、规模庞大的系统(也就是说，大部分企业级应用) 我偏好这种方式。
问题：若采用这种结构，那么在开始‘真正’的测试前，需要投入一定时间搭建整个结构，会不会很浪费时间?
回答：这只是另外一种组织代码的方式。即使代码不按照这种方式组织，还是要写代码拼装URL、解析XML / HTML、验证测试结果。采用这种结构，只需要把代码拆分到不同的类及方法中。此外，没有必要一次完成整个结构。可以根据当前的测试需要，逐步完成整个结构。
问题：完成这个结构需要相当的面向对象知识，并不是所有QA都可以做。
回答：实际上测试自动化并不只是QA的职责。项目中其他成员，包括开发人员，也可以参与。
开发人员有很强的编程功底，编写出的代码质量也相对较高，因此可以负责领域层。而QA擅长设计测试用例、找出各种边界测试条件，因此可以负责测试用例层。
