随着软件行业的迅猛发展,软件测试也逐渐受到越来越多的软件公司所重视,然而开发出来的软件直接就可以拿出来做测试吗?根据近几年来的实践证明,在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行,直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持,即要求软件具有可测试性。基于可测试性的目标考虑,良好的架构设计,完备的接口,使得软件测试更加高效和可行,同时产品维护也更加便利。
本文描述的范围:可测试性定义、可测试性特征、可测试性设计。
读者对象:系统分析和设计人员、开发人员、测试人员。
参考文献:
1.《软件可测试性需求设计》 Vince
3.《软件工程思想》 林锐
2.1 可测试性定义
软件的可测试性是指在一定的时间和成本前提下,进行测试设计、测试执行以此来发现软件的问题,以及发现故障并隔离、定位其故障的能力特性。简单的说,软件的可测试性就是一个计算机程序能够被测试的容易程度。
一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件,而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。
2.2 可测试性特征
1.可操作性:“运行得越好,被测试的效率越高。”
1)系统的错误很少;
2)没有阻碍测试执行的错误;
3)产品在功能阶段的演化(允许同时的开发和测试)。
2.可观察性:“你所看见的就是你所测试的。”
1)每个输入有唯一的输出;
2)系统状态和变量可见,或在运行中可查询;
3)过去的系统状态和变量可见,或在运行中可查询(例如:事务日志);
4)所有影响输出的因素都可见;
5)容易识别错误输出;
6)通过自测机制自动侦测内部错误;
7)自动报告内部错误;
8)可获取源代码。
3.可控制性:“对软件的控制越好,测试越能够被自动执行与优化。”
1)所有可能的输出都产生于某种输入组合;
2)通过某种输入组合,所有的代码都可能被执行;
3)测试工程师可直接控制软件和硬件的状态及变量;
4)输入和输出格式保持一致且有结构;
5)能够便利地对测试进行说明、自动化和再生;
6)接口和模块易控制;
7)业务流程和场景易控制。
4.可分解性:“通过控制测试范围,能够更快地分解问题,执行更灵巧的再测试。”
1)软件系统由独立模块构成;
2)能够独立测试各软件模块;
3)业务流程和场景易分解。
5.简单性:“需要测试的内容越少,测试的速度越快。”
1)功能简单性(例如:特性集是满足需求所需的最小集合);
2)结构简单性(例如:将体系结构模块化以限制错误的繁殖);
3)代码简单性(例如:采用代码标准为检查和维护提供方便)。
6.稳定性:“改变越少,对测试的破坏越小。”
1)软件的变化是不经常的;
2)软件的变化是可控制的;
3)软件的变化不影响已有的测试;
4)软件失效后能得到良好恢复和隔离。
7.易理解性:“得到的信息越多,进行的测试越灵巧。”
1)设计能够被很好地理解并遵循行业规范;
2)内部、外部和共享构件之间的依赖性能够被很好地理解;
3)设计的改变被通知;
4)可随时获取技术文档;
5)技术文档组织合理;
6)技术文档明确详细;
7)技术文档精确性稳定;
8)相关环境配置说明与操作指导。
3.1可测试性设计
软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响,不能产生附加的活动或者附加的测试,采取合适的设计模式对软件进行设计。
1.坚持测试驱动设计(测试先行)的方法。
优先编写测试代码,这是标准的XP方法。不是说应该一次性编写全部测试代码后,再一次性全部实现。先写验收测试,再写单元测试,编写一些测试代码,实现它们,再编写一些测试代码,再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它,以这种方式编写测试也更少会使人畏缩。
原文转自:http://www.uml.org.cn/zjjs/201004222.asp