软件测试的风险管理及应用

黄碧玲

(浙江省电子信息产品检验所，浙江杭州310007)

0 引言

目前我国的软件测试行业与发达国家相比还有比较大的差距，主要体现在软件测试的意识、技术和规范上［1］。像欧美国家的软件业起步较早，成熟度高，开发商对软件质量的控制力度很强。国内软件业起步晚，发展很不成熟，软件测试更是处于弱势地位。国内软件公司中能达到ISO和CMM(能力成熟度模型)高级认证的很少，不规范的软件开发普遍存在，很多方面没有做到标准化和规范化。公司专职测试人员与开发人员的比例集中在1:3—1:5左右，这与国外软件业1:1的比例相差甚远。随着用户对软件质量要求的提高，测试服务体系初步形成［2］。在软件测试过程中，应依靠技术与服务来征服用户，注重测试方法与质量。为了尽可能地减少测试风险，引入风险管理技术［3］。系统的风险管理可以尽早识别项目中蕴含的风险、采取适当的预防措施、制定应变计划，从而消除潜伏的风险因素或降低风险事件发生时对软件项目造成的冲击。

1 风险与测试

1.1 风险概述

风险就是在软件测试过程中有可能发生的某些意外事情，并且在最糟的情况下对测试对象产生巨大的负面影响甚至导致失败［4］。软件测试的风险管理就是对可能遇到的风险进行计划、识别、评估、应对、监控的全过程活动的总称。

1.2 风险与测试的关系

软件测试是一种风险管理策略，它可以用来验证产品是否满足了功能需求［5］。在基于需求规格说明书的测试中，风险和测试之间的关系类似线性关系。即测试任何内容都会降低软件的风险。如图1所示。

但是在实际测试过程中，Pareto的“80/20”理论，即“80%的风险来自于20%的功能”更符合风险和测试之间的关系，因此风险和测试之间的关系如图2所示。

图1 风险和测试的线性关系

图2 风险和测试的曲线关系

从图2中可以看出，测试人员应采取一个更加合理的测试策略以优化工作量的分配，即测试人需要首先关注图中的F区域，从而减少风险［6］，如图3所示:

图3 不同策略下的风险和测试

图3中曲线可以看出，如果测试人员基于风险划分优先级，并将测试工作量首先放在高风险和高优先级的区域，覆盖测试项目50%的风险需要付出的工作量要少得多［6］。

2 风险管理过程

风险管理的目的是通过管理软件开发生命周期中的风险，减少对测试项目造成不利影响的事件发生的可能性。在国际软件测试认证委员会大纲中，风险管理包括风险识别、风险分析和风险控制等3种活动。以国际软件测试认证委员会大纲为例，讨论这3种风险活动。

2.1 风险识别

风险识别应在项目的早期进行，在测试计划开始时就进行测试相关的风险识别，以明晰对项目构成威胁的因素，便于制定规避风险和降低风险的计划及策略。

风险识别过程是将不确定性转变为明确的风险陈述，并以文档的形式记录。根据不同的组织和项目特征可采用不同的风险识别方法。不论是产品风险，还是项目风险，测试人员都可以通过专家咨询、独立评估、使用风险模板、头脑风暴法、检查表法等其中的一项或多项技术进行识别［7］。

2.2 风险分析

风险分析是研究那些被识别出来的风险，确定每个风险的可能性及其严重程度，并得到每个风险的风险级别。

ISO/IEC 9126标准中列出了该质量特性。风险发生的可能性分为5种:非常低、低、中等、高、非常高;风险严重程度分为5种:可忽略、次要、中等、严重、非常严重。

测试人员可以通过定量或定性的方法确定风险的可能性和严重程度。通常来说，定量分析风险比较困难，而定性分析则相对容易。因此测试过程中通常采用定性的方式定义风险的可能性及其严重程度。我们也可以把定性和定量的方法相结合，将风险发生的可能性和严重程度用相应的数值代替，两个值相乘得到一个量化的风险等级，并且与风险阀值相比较。若计算得到的风险级别大于定义的风险阀值，那么需要采取相关的风险应对措施以降低风险级别。

2.3 风险控制

2.3.1 风险减轻

风险级别由风险发生的可能性和严重程度两个因素决定，因此通过降低这两者可以降低风险的级别。当它降低到一个可以接受的阀值，就认为成功地实现了风险的应对。

2.3.2 风险应急

当风险成为现实，就需要相应的应急措施降低事件产生的影响程度。如果想让风险管理工作更有效，就需要采用“风险排序”策略，重点关注“优高先级”风险，立即执行风险的应对措施。

2.3.3 风险转移

不消除风险，而是将风险转移给第三方。例如:买保险、软件功能模块的开发外包给第三方。

2.3.4 忽视或接受风险及其产生的后果

识别的风险经过分析和评估之后，确认在可接受范围之内，这时可以接受风险。其次，针对应对风险的成本比不应对的成本还要高，也可以接受风险。再者，如果风险无法采取合适的应对措施和活动来避免、转移或者减轻风险，也只能采取接受风险的策略。

2.3.5 风险追踪

在风险受到控制后，要及时进行风险跟踪。监视风险状况，检查风险应对策略是否有效、跟踪机制是否可行;不断识别新的风险点并制订应对措施。

3 软件测试中的主要风险及应对措施

测试风险是不可避免的，它总是存在的［8］。在软件测试工作中主要的风险有:

(1)对产品认识的风险。质量需求或产品特性理解不准确，造成测试范围分析误差，结果某些地方始终测试不到或验证标准不对;

(2)测试人员风险。相应的测试阶段开始时，相关测试人员因故不到位;

(3)时间进度风险。需求突然变化，导致测试用例修改或重写，测试时间不够，资金投入增加;

(4)质量目标风险。质量标准不是很清晰，如适用性测试、易用性测试等;

(5)测试充分性的风险。测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景，部分缺陷不易重现等风险;

(6)测试环境风险。特定的测试环境不能到位，造成测试结果有误差;

(7)测试工具风险。相关测试工具未准备好，或测试人员的对新工具无法熟练运用等;

(8)回归测试一般不运行全部测试用例，是有选择的执行，必然带来风险。

针对上述软件测试风险，可以采用以下的方法进行风险控制:

(1)关于人员风险，可以增加培训，包括对项目背景培训、质量标准培训、软件测试工具培训、人员上岗培训等，以提高测试人员综合素质，并对每个关键技术岗位培养后备人员，作好人员流动的准备;

(2)关于时间进度风险，可采取前文提到的测试策略优化措施，对测试用例和测试人员进行优先级排列，确定测试覆盖率，选择重要的和风险级别高的测试开展，从而降低风险和尽快提高软件质量;

(3)关于测试环境问题，可以通过事先列出要检查的所有条目，测试环境设置好后，由其他人来检查测试环境的搭建，便可有效降低测试环境不足带来的风险;

(4)对测试中不易重现的缺陷，要通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险;

(5)对系统需求质量低下或者不完整的，应召集有关人员讨论哪些是需要测试的、哪些是不需要测试的、测试深度等问题，以此来识别需求规格说明书中存在的不足;

(6)有些测试风险可能会带来非常严重的后果，应该把这种高风险转化为低风险，或进行风险转移。如产品发布前夕，在某个不是很重要的新功能上发现一个严重缺陷，如果修正这个缺陷很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉那个新功能转移这种风险。

4 结束语

风险管理是软件测试过程中必不可少的一项工作。本文阐述了软件测试风险管理的主要过程、风险和测试的关系、主要风险及应对措施。在测试项目实施中，必须严格按照风险管理计划对项目的风险进行管理，以规避风险或将风险降低到较低的程度。

［1］ 楠族开心果.国内软件测试现状分析及对策［EB/OL］.http://bbs.51testing.com/viewthread.php?tid=330009，2010－11－08.

［2］ Wangyue中国软件测试行业现状调查报告［EB/OL］.http://www.test8848.com/news/797.html，2011 －06 －23.

［3］ 张瑾.软件质量管理指南［M］.北京:电子工业出版社，2009:130－144.

［4］ 郭宁，周晓华.软件项目管理［M］.北京:清华大学出版社、北京交通大学出版社，2007:199—206.

［5］ William E Lewis，David Dobbs，Gunasekaran Veerapillai.陈绍英译.软件测试与持续质量改进［M］.北京:人民邮电出版社，2011:9－16.

［6］ 马均飞，郑文强.软件测试设计［M］.北京:电子工业出版社，2011:252－269.

［7］ Rex Black.刘琴，周震漪，郑文强，等译.高级软件测试卷1［M］.北京:清华大学出版社，2011:48－58.

［8］ 朱少民.全程软件测试［M］.北京:电子工业出版社，2007:358－374.