软件可测试性设计(2)

　　1.坚持测试驱动设计(测试先行)的方法。

　　优先编写测试代码，这是标准的XP方法。不是说应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误并在下一组测试中改正它，以这种方式编写测试也更少会使人畏缩。

　　2.尽量做到每个操作对应一个函数，使函数小型化。

　　使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使你编写比在其它情况下更少的测试。

　　3. 数据的显示与控制分离

　　把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

　　4.可控制性设计

　　1)全局变量的可控制性设计

　　I.在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等;

　　II. 可以将全局类型的变量进行分类并封装到一个个接口中操作。

　　2)接口的可控制性设计

　　各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码. 对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于整个被测系统，即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。

　　3)模块的可控制性设计

　　对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。

　　4)业务流程的可控制性设计

　　在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。

　　5)场景的可测试性设计

　　将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。

　　5.可分解性设计

　　1)业务流程的可分解性设计

　　对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。

　　2)场景的可分解性设计

　　对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。

　　6.稳定性设计

　　测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。

　　7.易理解性设计

　　1)设计文档的易理解性

　　I.设计参考标准

　　II.内容描述主次要分清

　　III.依赖关系描述明确

　　2)接口的易理解性

　　I.接口功能明确

　　II.参数有意义

　　3)业务的易理解性

　　4)场景的易理解性

　　8.可观察性设计

　　1)业务执行状态和过程可观察性设计

　　2)异常情况可观察性设计

　　9.测试驱动和桩的设置

　　为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。

　　10.适合增量式开发的可测试性设计

　　在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。

　　11.可查询设计

　　1)对系统级别的全局变量或者状态设置查询接口;

　　2)某一业务或场景调用接口设置接口路径查询

　　12.自愈合功能

　　在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。

　　13. 输出结果

　　对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的.测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性.在设置的各个控制点或观察点的结果易于查询、修改等。

　　14.提供统一的操作执行面板

　　操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但可能被测系统是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以操作整个被测系统的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入(执行的操作)输出均在界面上执行和体现，这样比较直观。如下图所示：

原文转自：http://www.uml.org.cn/zjjs/201004222.asp