软件可测试性设计

1、软件可测试性设计-基于需求规格层面testung上海博为峰软件技术有限公司2010年11月2日r&sttjng系统名称可测试性设计文档编号文档名称可测试性设计版本号V1.0起草人审核人审核意见四维图新和博为峰软件联合制定Testing修订情况版本修改人员备注V1.0宋光照初始版本 TOC o 1-5 h z 引言5 HYPERLINK l bookmark26 o Current Document 可测试性需求5 HYPERLINK l bookmark32 o Current Document 可测试性设计5 HYPERLINK l bookmark35 o Current Document

2、 需求可测试性检查清单6 HYPERLINK l bookmark38 o Current Document 可测试性主要面临的问题6 HYPERLINK l bookmark47 o Current Document 可测试性通用检查点6 HYPERLINK l bookmark50 o Current Document 测试用例的可设计性检查点6 HYPERLINK l bookmark53 o Current Document 测试执行的可控性检查点7 HYPERLINK l bookmark56 o Current Document 测试结果的可观察性检查点7 HYPERLINK l

3、bookmark59 o Current Document 需求可测试性案例分析81弓|言可测试性是软件的一个基本属性，它的好坏决定了产品是否易于测试，是否易于定位问 题。因此，可测试性的重要性不言而喻。该技术在提高开发设计质量，提高测试效率、充分性，降低问题发现、定位成本，提高 可维护性、可靠性等多个方面都有广阔的应用空间。2可测试性需求软件可测试性需求是产品需求包中的一种非功能需求，它是一种非功能属性方面的设计 约束。为了方便对可测试性需求进行归类，将可测试性需求分为3类：内建可测试性需求：是一种对可测试性能力、机制的需求，例如：存储过程机制、引擎 接口、测试环境架构等方面的需求，均属于此

4、类可测试性需求；公共可测试性需求：主要针对平台软件、操作系统、数据库等与业务无关的公共子系统 的可测试性需求。例如：操作系统资源核查：内存、定时器、队列、消息包等；各种数 据库资源核查，进程切换堆栈，死锁检测等等方面的需求，均属于此类可测试性需求；特性可测试性需求：主要是针对业务相关的可测试性需求，例如，设置车道信息的可测 试性需求，设置危险信息的可测试性需求等，尽量描述成参数化的、易读的需求。3可测试性设计可测试性的特性包括很多方面，其中最主要的是这么几个：可设计性、可控性和可观察 性。所以在软件设计时要全面地考虑对这些特性的满足程度。具体来讲，可设计性主要是指软件在满足需求的基础上尽量简单

5、、无冗余，并且软件也 能被分解为独立的模块进行单独测试。简单的话，从软件的角度讲，复杂度低，出错的可能 性就低；而从测试的角度讲，简单即意味着测试的成本和难度降低，测试输入则更容易实施。 而可分解为独立模块这也是将大型软件的测试简化的关键方法，当分解为独立部分后，则测 试时只需要相关部分的输入输出。可控性是软件易于施加外部输入和控制内部状态的能力。测试执行的一项主要工作就是 向被测软件施加输入，输入越多、输入间的关系越复杂、输入接口的通用性越差就越难施加 输入，可控性也就越差。另一方面，为了验证软件的某些特殊功能或测试软件在某些特殊情 况下的反应，可能需要软件处于一些非正常状态，此时就需要能够

6、控制软件内部状态。可观察性是软件易于观测外部输出、监控内部状态的能力。测试执行过程中的另一项主 要工作就是观测和收集测试结果，软件的输出是否明显、是否易于观察、输出数据是否易于 收集都将影响软件的测试效果。对于外部输出不明显、不易于观测或输出数据过少等情况， 就要求软件能方便地监控内部状态、辅助判断测试结果。4需求可测试性检查清单4.1可测试性主要面临的问题需求规格中，“字段描述”中对输入的参数，尤其隐性输入参数描述不完整;需求规格中的业务规格描述，缺少清晰的主线；需求规格中，输出的描述，缺少清晰的主线；在使用Use case描述需求的时候，缺少清晰的关于异常流程的主线；在使用流程图描述需求的

7、时候，缺少清晰的判断分支和和结果状态描述；在使用顺序图描述需求的时候，缺少清晰的业务规则对应的描述；（请分别举例）4.2可测试性通用检查点1是否所有的分配需求都在SRS中体现？是 否2在SRS中定义需求时，是否避免使用那些会引起歧义的术语， 诸如也许、可能等，每条需求都清晰无歧义？是 否3是否在SRS中清楚地描述了软件要做什么及不做什么？是 否4是否在SRS中描述了软件使用的目标环境，指明并简短描述了 目标环境中其它相关软件产品/子系统/模块？是 否5每一个需求是否切实可行、前后一致、彼此不冲突？是 否4.3测试用例的可设计性检查点1每个具体Use Case是否全少涉及一个actor？是 否2

8、Use Cas e的前置条件和后置条件是否说明了状态而不是事件？是 否3是否在SRS中说明了对每个输入（包含隐形输入）的验证措施， 并描述了每个输入的属性如：度量单位、边界值、时序要求等 等？是 否4是否在SRS中说明了对每个输入（包含隐形输入）的处理？是否5是否在SRS中说明了每个输出项（包含隐形输出）是如何输出 的，并且描述了每个输出的属性如：度量单位、边界值、时序 要求等等？是 否6Use Case之间是否避免存在非常相似的行为或事件流？如果 存在-而且您还希望它们的行为在将来也相似-您应该将它 们合并为一个Use Case。这便于在将来引入变更。是 否7是否明确定义了Use Case之

9、间的包含关系？（如事件流的一部 分被构建为另一个Use Case的模型，应该让新Use Case使用旧 的事件流；或事件流的某一部分成为另一个Use Case的组成部 分，应该提取该分支流并让上述的Use Case使用它。）这样， 便于重用老的Use Case的测试用例是 否8是否明确说明Use Case的事件流开始及结束的方式和时间？是 否9Use Case的基本事件流和备选事件流是否可以到达相应的成功 后置条件或失败后置条件？是 否10是否避免有过于复杂的Use Case？如果要使Use Case模型易 于理解，易于构造测试用例，您最好将复杂Use Case进行分解。是 否11是否清楚地说明了 Use Case与Actor之间的父互信息？是 否12是否已经对系统环境中的所有角色都进行了说明和建模？是 否13是否所有的性能需求和其他质量需求可测量或能通过测试来 进行验证？是 否4.4测试执行的可控性检