摘要
在测试自动化中，测试代码中不仅仅包含测试逻辑，还包含许多其他代码，比如URL拼接、html/xml解析、访问UI控件，等等。若把测试逻辑与这些无关代码混在一起，测试逻辑将会很难理解，也不容易维护。本文会介绍如何用分层结构来解决测试自动化中遇到的这些问题。在这个分层结构中，测试自动化代码会被分成三层：（1）测试用例层，表达应用程序的测试逻辑。（2）领域层，用业务领域术语来给待测系统建模，封装HTTP请求、浏览器控制、结果解析逻辑等，给测试用例层提供一个接口。（3）待测系统层，第2层构建在这一层之上。
问题
QA的工作包括设计测试用例、探索性测试（exploratory testing）及回归测试，等等。这些工作有的依靠QA的聪明才智， 而有的却只是重复劳动（例如回归测试）。随着系统中不断地加入新功能，回归测试这类工作耗费的时间也越来越多。
测试自动化可以解决这个问题。测试自动化后，重复性的劳动会由计算机来做，而测试用例都用计算机程序来表述， 因此QA可以从重复劳动中解脱出来，有更多的时间用在创造性的工作上来。
在测试自动化中，测试代码并不仅仅包含测试逻辑，也包含许多其他的支撑代码，例如URL拼接、HTML/XML解析、UI控件访问等。 例如要测试一个能接受不同搜索参数，并返回包含特定信息的XML（例如用户数据）的web服务，测试代码需要：
1. 根据待测操作拼接URL
2. 使用HTTP库发起HTTP请求
3. 读取web服务器返回的信息，并解析数据
4. 对比返回的数据与期望数据
解决方法
软件开发领域曾遇到过同样的问题，并找到了解决方法，即‘层次结构’(Layered Architecture)。引用《领域驱动设计--软件核心复杂性应对之道》（'Domain-driven design: tackling complexity in the heart of software'）一书：
| “分层结构的价值在于每一层只关注于程序的特定方面。这使得每个方面的设计都很紧凑，也更容易理解。当然，使用层次结构的最重要原因是把各个重要的方面都分隔开。“ |
虽然测试自动化领域关注的是测试领域，但是所遇到的问题的本质却是一样的，因此可以应用相似的解决方案：
| 测试用例层 | 这一层包含所有（并只有）测试逻辑。有了下一层即领域层帮忙，测试逻辑可以很清晰、简洁地表达出来。不同用户故事、场景及边界条件 都构建领域层之上，区别只在于测试数据。 |
|---|---|
| 领域层 | 这 一层封装了对待测系统的所有操作，例如URL拼接、XML或HTML解析，富客户端或浏览器的控制，等等。通过这一层包装， 待测系统可以以业务领域语言的形式供调用者使用，而非以xpath、sql或者html等技术“语言”形式。这层的目的在于提高抽象层次。 测试的目的是验证业务逻辑是否实现地正确。若测试能用业务领域的语言编写，那么测试目的就一目了然了。 |
| 待测系统层 | 即要测试的系统 |
测试用例层包含许多测试用例。这些测试用例都是基于领域层的。领域层用领域语言封装了待测系统。
领域层直接访问待测系统。
