蒲冬梅
本文先简单介绍了跟需求相关的几个概念,接着介绍了基于需求的测试分析的流程,并对每个流程环节做了详细的介绍。
【关键词】需求 测试 基于需求的测试
1 需求工程的基础知识
1.1 需求的定义来源:[IEEEStd610.12-1990]
(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。
1.2 需求的层次及关系
1.2.1 需求的层次
需求从层次上分由客户需求和系统需求组成。
客户需求:用户提出的产品应用操作具体的需求。
系统需求:由前面两种类型衍生出的需求,子需求,包含产品具体的属性,质量,约束,限制等内容。
1.2.2 质量需求与非功能性需求的区别
一个非功能需求要么是一个不明确的功能性需求,要么是一个质量需求。
例:需求描述为:R1:系统应该是安全的。
形容词“安全的”具体指什么?
为了保证系统是“安全的”系统应具备哪些属性?
如何检验所实现的系统是否是“安全的”?针对安全每个涉众可能都有自己的解读。这些掩盖了不明确的功能性需求的非功能性需求应当进行精化。
如何修改?
(1)每个用户使用系统之前必须使用用户名和密码(功能性需求);
(2)系统应每隔4个星期提醒用户更改密码(功能性需求);
(3)用户修改密码时,系统应确认新密码至少包含8个字符并同时包含数字和字母(功能性需求);
(4)存储于系统中用户名和密码必须得到保护,以防止被盗(质量需求—完整性)。
2 基于需求的软件测试分析
2.1 什么是测试需求?
关于测试需求,目前业界并没有一个明确的标准定义,通常认为软件测试需求是明确现阶段需要“测什么”,也即确定测试对象和测试范围。
测试需求不同于软件需求,在基于需求的测试中,软件需求是软件测试需求分析的主要依据;测试需求是为了测试“软件需求”而需要的准备必要条件。
测试需求应该覆盖全部已定义的业务流程,以及功能和非功能方面的需求。
2.2 开展基于需求测试分析的准备活动
为了便于测试需求分析人员正确、完整地理解需求,需要开展以下活动:
2.2.1 需求文档阅读
主要目的是熟悉产品业务背景、部署环境以及产品的功能和非功能特性。
2.2.2 业务知识培训
主要目的是提高对产品功能及业务的理解能力。
2.2.3 业务流程及规则分析
主要目的是提高需求传递的质量。
2.2.4 确定测试需求分析方法
根据产品功能和技术背景,确定测试需求分析方法、测试类型,同时提取公共需求。
2.3 基于需求测试的分析步骤
2.3.1 测试需求采集
测试需求采集以软件开发需求为依据,首先要确保软件需求的正确性,继而从中提取具有可测试性的需求或特性,由此生成原始测试需求。
其中,可测试性是指对于我们提取出的每一条软件需求或需要实现的每一个特性,都必须存在一个可以明确预知的结果,可以用某种方法来明确的判断此需求或特性是否符合需求文档中的描述。
测试需求采集方法:
(1)根据被测软件需求规格说明、其他等效设计文档、相关标准、背景资料等,建立开发需求列表;
(2)针对开发需求列表中的每一条开发需求,形成可测试的测试需求;测试需求列表包括“需求标识”、“测试需求描述”和“信息来源”。
(3)其中,需求标识为软件需求对应的开发文档及章节号;如无对应文档,则可用隐含需求、遗漏需求标识;
(4)测试需求描述为对应软件需求的简述;
(5)信息来源可为:具体开发文档、相关标准、与客户或开发人员沟通、培训等。
由以上方法形成的原始测试需求列表中,可能会存在重复和冗余的测试需求,可对其进行删除或合并;同时也需要对过于简略的测试需求进行细化。
2.3.2 测试需求分析的方法
(1)功能交互分析法:针对有业务需求的产品;需求分析的对象是不同业务模块之间的业务流程和业务规则。要求分析人员对整个系统的业务比较了解;功能交互的重点在验证数据流转的正确性;与测试类型分析法不同的是:测试类型分析法针对需要或功能点,而功能交互分析法是针对需求或功能点之间;可并入测试类型分析法的功能性测试中。
(2)经验分析法:该方法是将具有代表性的测试积累形成经验库,以方便重用;如果经验有代表性,可并入测试类型分析法。
(3)测试类型分析。软件测试可以划分为不同的测试类型,如:功能测试、用户界面测试、安全性测试、接口测试、压力测试、结构测试、容量测试、完整性测试、恢复性测试、兼容性测试等等。
从软件质量子特性角度来看,对每一条测试需求,都可确定对应的质量子特性。不同的质量子特性对应不同的测试内容,也即对应不同的测试类型。
在实施过程中,我们可以建立一个质量子特性和测试类型的对应关系表,那么对于确定的质量子特性,我们就可以使用该表格来确定测试类型。
此外,在确定测试类型时,我们还需要考虑以下几点:
(1)测试类型对应的情况说明;
(2)常见测试类型对被测软件的覆盖程度;
(3)测试类型是否包含被测软件的特殊情况。
2.3.3 基于需求的测试管理技术
在实际的软件开发过程中,软件需求通常会不断的變化;软件需求一旦发生变更,我们的测试需求也必须随之变化。如何在不断变动的需求中确定各阶段的测试内容,这就需要对测试需求进行有效的管理。
一个较为有效的方法是建立测试需求跟踪矩阵,对测试需求变更进行管理。
将按照上文所述的测试需求采集方法、测试需求分析方法确定下来的开发需求、测试需求、测试类型等内容填入表格,我们可以建立测试需求跟踪矩阵,测试需求跟踪矩阵可能包括的列有:测试需求编号,原始测试需求描述,测试点编号,测试要点,测试用例编号范围。测试需求跟踪矩阵需要跟随需求变化不断的维护。软件需求一旦变化,就需要启动配置管理过程,将软件需求变化相关的测试内容进行同步变更。
3 总结
测试需求明确需要“测什么”,即确定测试对象和测试范围。基于需求的测试以软件开发需求为主要依据,通过测试需求分析,形成可测试内容。基于需求的测试是一种最根本的软件测试,可以验证需求的正确性,可以设计出充分且必要的测试集,更好地保证测试的质量和进度。
参考文献
[1]Bender-Requirements Based Testing Process ? 2009 Bender RBT Inc.17 Cardinale Lane Queensbury, NY 12804 518-743-8755.
[2]刘柏,唐龙利,陈大圣.基于需求的测试用例设计方法研究[J].中国船舶工业综合技术经济研究院,2011.
作者单位
广州赛宝认证中心服务有限公司 广东省广州市 510000