一、引言
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. 既然要研究测试通过标准，那么自然就要求QA从需求分析阶段就开始工作。我想这是所有QA都期盼的结果。
4. 如果团队无法设计出需求的通过标准，那可能是需求不够明确或者团队缺乏相关的知识。总之，大家可以在开发前就可以知道这个需求多半是无法完整实现的。
应该还有其他的好处，大家可以来讨论一下。
软件可测试性设计
发布时间: 2009-8-06 17:27 作者: Vince 来源: 文斯测试技术研究中心
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： 软件测试技术
一、概述
随着软件行业的迅猛发展，软件测试也逐渐受到越来越多的软件公司所重视，然而开发出来的软件直接就可以拿出来做测试吗？根据近几年来的实践证明，在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行，直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持，即要求软件具有可测试性。基于可测试性的目标考虑，良好的架构设计，完备的接口，使得软件测试更加高效和可行，同时产品维护也更加便利。
本文描述的范围：可测试性定义、可测试性特征、可测试性设计。
读者对象：系统分析和设计人员、开发人员、测试人员。
参考文献：
1、《软件可测试性需求设计》 Vince
2、《高质量C++/C编程指南》 林锐
3、《软件工程思想》 林锐
二、软件可测试性定义
2.1 可测试性定义
软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。
一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。
tatp
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）软件系统由独立模块构成；
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议