测试策略

自动化测试金字塔

如图:

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

 单元测试应该做到接近100%的覆盖率,通常来说这个数字应该保持在90%以上.

2.组件测试,通常它们是针对系统的各个组件而编写.系统的组件封装了业务规则,因此对这些组件的测试便是对其中业务规则的验收测试.组件测试由QA和业务人员编写,开发人员提供辅助.它们需要在FitNesse,JBehave或Cucymber等组件测试环境下编写(GUI图形化界面组件可以使用Selenium或Watir之类的GUI测试环境).让不具备编写测试能力的业务人员也能理解这些测试.

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

3.集成测试,这些测试只对组件很多的较大型的系统才有意义.这些测试将组件装配成组,测试他们彼此之间是否能正常通信.照例要使用的模拟对象和测试辅助,与系统的其他组件解耦.集成测试时编排性测试.它们并不会测试业务规则,而是主要测试组件装配在一起是否协调.它们是装配测试,用以确认这些组件之间已经正确连接,彼此间通信正常.

 集成测试一般由系统架构师或主设计师编写,用以确认系统架构层面的结构是否正确无误.在这个层次上,已经可以进行性能测试和吞吐量测试.集成测试多使用与组件测试同样的语言和环境来编写,一般不会作为持续集成的一部分,因为集成测试的运行时间通常都比较长

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

 系统测试曰占测试的10%.其目的不是要确保正确的系统行为,而是要确保正确的系统构造.底层代码和组件的正确性已经有金字塔中较底层的测试要验证保障了. 系统测试由系统架构师和技术负责人编写,一般使用UI基层测试同样的言语和环境.测试周期视测试运行时间长短而定,相对而言不会过于频繁,但越频繁越好.

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

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