分层结构

自动化测试代码的结构

分层结构是指一种自动化测试代码的结构。这种结构的特点是将复杂的测试代码分成三个单向依赖的层次，采用分层结构构建的测试代码中的测试逻辑变得清晰，容易理解和维护。

分层结构是最为流行、应用最广泛的应用软件的设计方式。在应用了分层结构的系统中，各个子系统按照层次的形式组织起来，上层使用下层的各种服务，而下层对上层一无所知。每一层都对自己的上层隐藏其下层的细节。

在这个分层结构中，测试自动化代码被分成三层：（1）测试用例层，表达应用程序的测试逻辑。（2）领域层，用业务领域术语来给待测系统建模，封装HTTP请求、浏览器控制、结果解析逻辑等，给测试用例层提供一个接口。（3）待测系统层，第2层构建在这一层之上。

其实质是依据某一标准或尺度将某个社会研究客体分解分析成各种层次的科学理论规范，进而从中寻找认识主体在对研究客体进行的理性思维活动中所取得的本质经验、规律性和各种差异的认识。分层架构在一定程度解决了传统方案里，高耦合，低内聚等问题，为搭建结构清晰、易于维护的良性系统提供了理论基础。

优点

1、分层结构将应用系统正交地划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案。大的问题被分解为一系列相对独立的子问题，局部化在每一层中，这样就有效的降低了单个问题的规模和复杂度，实现了复杂系统的第一步也是最为关键的一步分解。

2、分层结构具有良好的可扩展性，为应用系统的演化增长提供了一个灵活的框架，具有良好的可扩展性。增加新的功能时，无须对现有的代码做修改，业务逻辑可以得到最大限度的重用。同时，层与层之间可以方便地插入新的层来扩展应用。

3、分层架构易于维护。在对系统进行分解后，不同的功能被封装在不同的层中，层与层之间的耦合显著降低。因此在修改某个层的代码时，只要不涉及层与层之间的接口，就不会对其他层造成严重影响。

原则

单向逐层调用

约定将 N 层架构的各层依次编号为 1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。那么，我们设计的架构应该满足以下两个原则：

1.第 K（1

2.如果 P 层依赖 Q 层，则 P 的编号一定大于 Q。

其中第一个原则，保证了依赖的逐层性，及整个架构的依赖是逐层向下的，而不能跨层依赖。第一个原则，则保证了依赖的单向性，及只能上层依赖底层，而不能底层反过来依赖上层。

针对接口编程

这里所指的接口，不是特指编程语言中的具体语言元素（如 C#中由 Interface定义的语言接口），而是只一种抽象的，在语义层面上起着接合作用语义体。它的具体实现，可能是接口，可能是抽象类，甚至可能是具体类。

从不同的视角，接口可以有以下两种定义：

1.接口是一定领域下行为的约定，它约定了接口的实现者必须遵循指定的契约，体现了自然界“如果你是……则必须能……”的理念。

2.接口是一定维度上同类事物的共性抽象，针对不同的维度，同类事物具有不同的展现形式，因此这里的共性抽象是相对的。

具体到分层架构中，针对接口编程的意义是这样的：现仍约定将 N 层架构的各层依次编号为 1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层，那么第 K 层不应该依赖具体一个 K-1 层，而应该依赖一个 K-1 层的接口，即在第K 层中不应该有 K-1 层中的某个具体类。第 K 层的编程仅仅针对 K-1 层的接口来进行编程。

依赖倒置

在软件设计原则中，有一种重要的思想叫做依赖倒置。它的核心思想是：不能让高层组件依赖底层组件，而且，不管高层组件和底层组件，两者都应依赖于抽象。

那么，这个原则和我们上面的原则是否矛盾呢？其实并不矛盾。因为这个原则定义中的“依赖”是指“具体依赖”，而上面定义中的依赖全部指“抽象依赖”。我对这两种依赖的定义如下：

具体依赖——如果 P 层中有一个或一个以上的地方实例化了 Q 层中某个具体类，则说 P 层具体依赖于 Q 层。

抽象依赖——如果 P 层没有实例化 Q 层中的具体类，而是在一个或一个以上的地方实例化了 Q 层中某个接口，则说 P 层抽象依赖于 Q 层，也叫接口依赖于 Q层。

从这两个定义可以看到，所谓的依赖倒置原则，正是上面提到针对接口编程，而不是针对实现编程，依赖于抽象而不是具体实现，两者在本质上是统一的。

综上所述，可以看出，本课题设计的分层架构，应该是这样一种架构：

1.N 层架构的各层依次编号为 1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。

2.架构中仅存在一种依赖，即第 K 层接口依赖于第 K-1 层，其中 1

封装变化

剥离系统需要不断变化的部分，独立成单元，采取具体的策略进行封装，减少变化对系统其它组成部分的影响，那里变化就封装那里，如果没有变化，就要避免过度封装。

单一职责