可测试性需求分析的维度

1、可测试性需求分析维度一、引言1、目的提高软件的可测试性，加快测试进度，提高测试效率。2、范围描述的范围主要是可测性设计的特征，考虑方向及设计方法3、读者对象系统分析员、设计人员、开发人员。二、测试所需文档1、需求规格说明书2、概要设计说明书3、详细设计说明书4、系统功能清单5、系统运行环境搭建指导书6、系统操作指导书三、可测试性设计需求可测试性主要是指被测实体具有如下特征：可控制性、可分解性、 稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、 控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软 件系统的任何功能有影响，不能产生附加的活动或者附加的测试。1、可控制性设计需求

2、1）全局变量的可控制性设计需求在外界使用适当的手段能够直接或间接控制该变量，包括获取、 修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口 中操作。2）接口的可控制性设计需求各接口在外界使用适当的手段能够直接调用对该接口进行操作， 这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于 向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接 口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系 统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需 的参数人为的能够轻易达到和提供。3）模块的可控制性设计需求 对于每个相对独立的模块设计好所需要的驱动和桩都能单

3、独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。4）业务流程的可控制性设计需求 在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。5）场景的可测性设计需求 将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。2、可分解性设计需求1）业务流程的可分解性设计需求对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。2）场景的可测性设计需求 对于复杂的场景需合理设定分解点，在测试时能够对其进行分解3、稳定性设计需求测试模块发布合理，不能在后期追加的模块为前期所测模块引入 新的不必要的测试活动。4、易理解性设计需求1）设计

4、文档的易理解性设计参考标准内容描述主次要分清依赖关系描述明确2）接口的易理解性接口功能明确参数有意义3）业务的易理解性4）场景的易理解性5、可观察性设计需求1）业务执行状态和过程可观察性设计需求2）异常情况可观察性设计需求6、测试驱动和桩的设置为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入 点。7、适合增量式开发的可测性设计在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难 易程度和真实性。8、可查询设计对系统级别的全局变量或者状态设置查询接口；某一业务或场景调用接口设置接口路径查询。9、自愈合功能在某一场景中局部出现故障时设置多路选择或者其他干涉进行 跳转执行使其具有正常逻辑功

5、能。10、输出结果对于任何一项操作都要能产生预期的输出，不管是正确的还是错 误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管 是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测 试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或 观察点的结果易于查询、修改等。11、提供统一的操作执行面板12、提需求分析维度操作面板元素主要由输入和输出元素组成，如所执行的操作和对 应的输出，但由于被测系统可能是一个比较复杂的系统，由多个可以 独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也 比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可 以执行整个被测系

6、统操作的独立模块，一种是以命令的形式执行操作 直接以printf语句的形式输出查看，另一种是以GUI的形式，输入 （执行的操作）输出均在界面上执行和体现，这样比较直观。特别对于执行某一场景时要跟踪该场景的关键过程和执行后的 输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶 段监控，将监控范围内的数据输出以供测试人员分析。第一层：功能性上保证。做好本职工作，考虑正常的业务主线以 及各种异常流，尽量不出现问题。测试的最重要最基本的问题，就是保证产品质量，做到发布上线 没问题，那么，在需求评审的时候，首先了解这个需求本身是做什么， 具体是怎么做的，考虑业务正常操作的主干线，以及，还要考虑

7、各种 异常流（比如用户的其他非法操作等）这里再引入一个三种流派的概念： 1:基本流：也称为基线，正常的操作，最终完成预期效果； 2:备选流：其实备选流分成2 种，一种是不同的做法，最终达成 目标效果；另一种是不同的做法，最终没有完成预期效果。3:异常流：就是上述备选流里面的，不同的做法，但最终未完成 预期的情况。也称之为基本流的异常情况。正常工作中，把备选流放入基本流中，统一为基本流，记录正常 的场景，而异常流就记录基本流的异常情况，这样会更清晰。第二层：从技术层面给予考虑，考虑实现问题。 比如说，产品说，我要在这里显示一个图，有 xxxxxx 的效果， 这个时候技术可能就会说，这个我们目前技术上没法实现，因为这边 是怎么怎么写的，接口是怎么调用的。而测试也是可以这样，比如说，产品说，我们要支持批量生成入 库信息采集表，同兼容 10000 的并发情况；这个时候，测试就考虑， 这个我们目前可能实现不了，因为批量生成的时候，会在 wms 后台对 应生成待审核数据，而之前做过压测，这个接口承载不了这么大的