如何更好对系统进行测试

TDD（测试驱动开发）的三项法则：

1. 在编好失败单元测试之前，不要编写任何产品代码。

2. 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。

3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，你必须找出将这个函数和其他函数解耦的办法。换言之，测试先行的需要，会迫使你去考虑什么是好的设计。如果不先写测试，就有可能会出现各个函数耦合在一起最终变成无法测试的一大团的问题。如果后面再写测试，你也许能够测试整个大块的输入和输出，但是很难测试单个函数。

自动化测试金字塔

专业开发人员遵循测试驱动开发的要求来创建单元测试。专业开发团队使用验收测试定义系统需求，使用持续集成保证质量稳步提升；同时，这些测试又属于全局测试体系。拥有一套单元测试和验收测试的同时，还需要有更高层次的测试，这样QA才找不出任何错误。下图显示的是自动化测试金字塔，以图形化方式展现了专业开发组织中所需要的测试种类。

 

1.单元测试。

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

       单元测试是可行，而且可以做到接近100%的覆盖率。通常而言，这个数字应该保持在90%以上。这里说的是真实的覆盖率，而不是那种虽然能通过但并不关心运行结果的错误的单元测试。

2.组件测试

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

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

       组件测试由QA和业务人员编写，开发人员提供辅助。它们需要在FitNess、JBehave或Cusumber等组件测试环境下编写。其目的是让不具备编写测试能力的业务人员也能理解这些测试。

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

3.集成测试

       这些测试只对那些组件很多的较大型系统才有意义。这些测试将组件装配成组，测试它们之间是否能正常通信。照例要使用合适的模拟对象和测试辅助，与系统的其他组件解耦。

       集成测试是编排性测试。它们并不会测试业务规则，而是主要测试组件装配在一起时是否协调。它们是装配测试，用以确认这些组件之间已经正确连接，彼此间通信畅通。

       集成测试一般由系统架构师或主设计师来编写，用以确认系统架构层面的结构是否正确无误。在这个层次上，也许已经可以进行性能测试和吞吐率测试了。

       集成测试的编写人员认为有必要，可以周期性（如每天一次或每周一次）运行。

4.系统测试

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

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

5.人工探索式测试

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