测试策略

自动化测试金字塔

单元测试

在金宇塔底部是单元测试，这些测试由程序员使用与系统开发相同的语言来编写，供程序员自己使用。编写这些测试的目的是在最低层次上来定义系统。开发人员是这样定义待写代码规约的：先编写测试，再编写产品代码。这些单元测试将作为持续集成的一部分来运行，用以确保程序员的代码意图没有遭到破坏。

组件测试

组件测试是验收测试的一种。通常，它们是针对系统的各个组件而编写的。系统的组件封装了业务规则，因此，对这些组件的测试便是对其中业务规则的验收测试。

它向组件中传入数据，然后收集输出数据。它会测试实际输出是否符合预期的输出。在组件测试中，需要使用合适的模拟（mocking )或测试辅助（ test-doubling ) 技术解开与系统的其他组件的耦合。

组件测试差不多可以覆盖系统的一半。它们更主要测试的是成功路径的情况，以及一些明显的极端情况、边界状态和可选路径。大多数的异常路径是由单元测试来覆盖测试的。在组件测试层次，对异常路径进行测试并无意义。

集成测试

这些测试只对那些组件很多的较大型系统才有意义。如图所示，这些测试将组件装配成组，测试它们彼此之间是否能正常通信。照例要使用合适的模拟对象和测试辅助，与系统的其他组件解耦。 集成测试是编排性测试。它们并不会测试业务规则，而是主要测试组件装配在一起时是否协调。它们是装配测试，用以确认这些组件之间已经正确连接，彼此间通信畅通。集成测试一般由系统架构师或主设计师来编写，用以确认系统架构层面的结构是否正确无误。在这个层次上，也许已经可以进行性能测试和吞吐率测试了。

系统测试

这些测试是针对整个集成完毕的系统来运行的自动化测试，是最终的集成测试。它们不会直接测试业务规则，而是测试系统是否已正确组装完毕，以及系统各个组成部件之间是否能正确交互在这个层次的测试集中，应该包含吞吐率测试和性能测试。

系统测试由系统架构师和技术负责人来编写，一般使用和集成测试同样的语言和环境。测试周期视测试运行时间长短而定，相对而言不会过于频繁，但越频繁越好。

系统测试约占测试的 10%，其目的不是要确保正确的系统行为，而是要确保正确的系统构造。底层代码和组件的正确性已经有金字塔中较低层的测试来验证保障。

人工探索式测试

这是需要人工介人、敲击键盘、盯牢屏幕的测试。它们既非自动化的测试，亦非脚表化的測试。这些测试的意图，是要在验证预期行为的时候，探索系统预期之外的行为。为了达到这个目的，需要人类智慧的介人，需要使用人类的创新能力，对系统进行深人研究和探索。预先编写测试计划反而会削弱这类测试的效果。

覆盖率并非此类测试的目标。探索式测试不是要证明每条业务规则、每条运行路径都正确，而是要确保系统在人工操作下表现良好，同时富有创造性地找出尽可能多的“古怪之处”。