软件可测试性需求设计一、引言1、目的提高软件的可测试性，加快测试进度，提高测试效率。2、范围描述的范围主要是可测性设计的特征，考虑方向及设计方法。3、读者对象系统分析员、设计人员、开发人员。二、测试所需文档1、需求规格说明书2、概要设计说明书3、详细设计说明书4、系统功能清单5、系统运行环境搭建指导书6、系统操作指导书三、可测试性设计需求可测试性主要是指被测实体具有如下特征：可控制性、可分解性、稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。1、可控制性设计需求1）全局变量的可控制性设计需求在外界使用适当的手段能够直接或间接控制该变量，包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。2）接口的可控制性设计需求各接口在外界使用适当的手段能够直接调用对该接口进行操作，这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。3）模块的可控制性设计需求对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。4）业务流程的可控制性设计需求在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。5）场景的可测性设计需求将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。2、可分解性设计需求1）业务流程的可分解性设计需求对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。2）场景的可测性设计需求对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。3、稳定性设计需求测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。4、易理解性设计需求1）设计文档的易理解性设计参考标准内容描述主次要分清依赖关系描述明确2）接口的易理解性接口功能明确参数有意义3）业务的易理解性4）场景的易理解性5、可观察性设计需求1）业务执行状态和过程可观察性设计需求2）异常情况可观察性设计需求6、测试驱动和桩的设置为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。7、适合增量式开发的可测性设计在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。8、可查询设计对系统级别的全局变量或者状态设置查询接口；某一业务或场景调用接口设置接口路径查询。9、自愈合功能在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。10、输出结果对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。11、提供统一的操作执行面板操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但由于被测系统可能是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以执行整个被测系统操作的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。[讨论]需求的可测试性需求需求敏捷模式中强调UserStory的可测试性。我觉得在传统模式中，强调需求的可测试性也有非常大的...
