如何做软件的质量风险分析

上一篇 / 下一篇  2007-08-29 19:10:10 / 个人分类:测试理论

       对任何系统来说,虽然我们能够进行各种类型的测试,但是,如果要测试所有可能的错误,是一个相当大的工作量,也是不可能的,因此,必须把注意力集中到能够确定的至关重要的测试条件上,而不是确定为相对不太重要的大量条件上。重点测试那些顾客和用户密切关注的系统行为,因为这些行为有可能在发行之后给用户造成不便。所以,我们需要分析系统的质量风险,根据风险来确定对系统软件我们应该测试什么。而不应该根据我们能够测试什么去测试系统软件。

        质量风险分析,我觉得可以通过以下几个过程来实现。

 A   确定质量风险分类

 软件测试中,有一些通用的质量风险分类,总结如下,

 

质量风险分类

该分类包括哪些问题

功能性

引起特定的功能不能工作的失败

负载,处理能力和容量

在额定的并发使用高峰时出现失败

可靠性/稳定性

引起系统过分频繁停机或停机时间太长

压力,错误处理和恢复

由于超过峰值或非法条件(例如由于故意产生的错误引起的副作用)引起的失败

日期和时间处理

日期或者时间的算法,格式,定时事件和其他与时间相关的操作中产生的失败

运行和维护

危及连接操作的失败,包括备份和恢复过程,补丁和升级等等

数据质量

在处理,存储或读取数据时的失败

系统性能

在预期的负载之下没有能够按照预定的时间完成任务

本地化

在特定场所中的失败,包括字符集的处理,对语言的支持,语法,词典和同义词功能,以及错误和帮助信息

兼容性

在某些应该支持的浏览器,网络,操作系统,或其他与环境相关的因素中的失败

安全/隐私

没有能够保证系统和保密数据免于收到欺骗性的或恶意的不当使用

文档

给用户或者管理员提供的安装或操作指南中的失败

接口

组件之间的接口失败

 根据这些通用分类,结合之前的项目经验,对将要测试的系统质量风险进行分类。在需求评审完毕后,组织项目相关人员参与系统质量风险分类制定,以保证尽可能准确。

 B   确定质量风险优先级

 系统质量风险优先级可以根据三种因素,严重性,优先级,发生的可能性

 严重性:该种类型的质量风险错误产生的后果的严重程度,按照下面的标准从1(破坏性最大)到5(破坏性最小)范围的数值评分。

 ü        1数据丢失――引起用户或系统数据的丢失

 ü        2功能丢失——系统主要功能丢失,或者主要不能使用

 ü        3能够克服的功能丢失――用户可以通过复杂或者变通的方式实现主要功能的使用。

 ü        4功能的部分丢失――主要功能模块的部分不重要功能丢失或无法使用

 ü        5表面错误――允许用户使用正常的功能,但是有明显的缺点,比如易用性

 优先级:该种类型的质量风险错误产生后,修复错误的紧迫性。取值范围从1(最需要修正)到5(最不需要修正)变化

 ü        1紧急的——必须立即解决

 ü        2重要的——必须在发行之前解决

 ü        3有价值的——错误会严重降低系统对于一个或多个用户的价值,应该尽量解决

 ü        4有需要的——如果条件允许,在本次版本中解决,否则,在下个版本中解决

 ü        5可忽略的——如果有需要,在以后发行的升级版本中解决

 发生的可能性:该种类型的质量风险错误产生的可能性。其值在1(最可能发生)到5(最不可能发生)之间。评定发生的可能性应该考虑这集中因素。

 Ø        该种质量风险类型包含的错误在系统中存在的可能性有多大

 Ø        该种质量风险类型包含的错误被开发人员遗漏的可能性有多大

Ø        该种质量风险类型包含的错误在系统的日常运行中,出现的可能性有多大

 ü        1很可能发生

 ü        2可能发生

 ü        3有可能发生

 ü        4可能性不大

 ü        5可能性很小

           将严重性,优先级,发生的可能性的数字相乘,则得到质量风险优先级数值,其取值范围在1(非常严重的)到125(微不足道的)。

        根据质量风险优先级数值,我们可以确定测试用例优先级数值,具体如下

 ü        1高——质量风险优先级在19。标记为高的测试用例,测试人员在执行这些测试用例的时候,如果执行用例失败,测试人员应该花费相当多的时间来重现和分离问题,并和开发人员沟通解决该问题。迭代开发周期中,在每次发布新测试版本,测试人员都要执行标记为高的测试用例。

 ü        2中——质量风险优先级在924。标记为中的测试用例,测试人员在执行这些测试用例的时候如果执行用例失败,测试人员应该先根据bug的严重性和优先级评估,决定是否花费相当多的时间来重现和分离问题,是否和开发人员沟通解决该问题。迭代开发周期中,发布新版本后,如果时间允许,则执行这些用例的回归测试,如果时间不允许,则不执行。

 ü        3低——质量风险优先级在2448。标记为中的测试用例,测试人员应该在执行这些测试用例的时候如果执行用例失败,测试人员应该先根据bug的严重性和优先级评估是否需要重现和分离问题。迭代开发周期中,发布新版本后,不执行该种类的测试用例。开发周期完成后,执行回归测试时,执行该种类测试用例。

 ü        4微小——质量风险优先级在49以上。标记为微小的测试用例,测试人员应该在执行测试时,如果时间紧张,可以不执行该种类的测试用例,但是,如果在执行其他种类的测试过程中,发现该种类的缺陷,应该提交缺陷报告。该种类的测试用例在回归测试时不执行。

C   完善质量风险分析

    完成质量风险分类表格后,质量风险分析基本已经结束,但是,在这个过程中,肯定存在一些归类错误或者风险优先级设置错误的地方,需要测试人员在设计测试用例或者在执行测试过程中进行完善,每次质量风险表格修改后,都需要同志项目组相关人员进行确认。

 

 


TAG: 测试理论

 

评分:0

我来说两句

Open Toolbar