可测试性需求讲述.doc

软件可测试性需求设计 一、引言　　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的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。　　特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。 [讨论] 需求的可测试性 需求需求 敏捷模式中强调User Story的可测试性。我觉得在传统模式中，强调需求的可测试性也有非常大的好处。 1. 用户需求以文字性描述居多，如果需求有测试通过标准，那么开发和测试人员都可以有一个容易遵循的规则。 2. 需求有通过标准，说明开发测试以及需求分析人员都达成了共识，减少工作中的分歧。 3. 既然要研究测试通过标准，那么自然就要求Q