对任何系统来说,虽然我们能够进行各种类型的测试,但是,如果要测试所有可能的错误,是一个相当大的工作量,也是不可能的,因此,必须把注意力集中到能够确定的至关重要的测试条件上,而不是确定为相对不太重要的大量条件上。重点测试那些顾客和用户密切关注的系统行为,因为这些行为有可能在发行之后给用户造成不便。所以,我们需要分析系统的质量风险,根据风险来确定对系统软件我们应该测试什么。而不应该根据我们能够测试什么去测试系统软件。
质量风险分析,我觉得可以通过以下几个过程来实现。
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高——质量风险优先级在1-9。标记为高的测试用例,测试人员在执行这些测试用例的时候,如果执行用例失败,测试人员应该花费相当多的时间来重现和分离问题,并和开发人员沟通解决该问题。迭代开发周期中,在每次发布新测试版本,测试人员都要执行标记为高的测试用例。
ü 2中——质量风险优先级在9-24。标记为中的测试用例,测试人员在执行这些测试用例的时候,如果执行用例失败,测试人员应该先根据bug的严重性和优先级评估,决定是否花费相当多的时间来重现和分离问题,是否和开发人员沟通解决该问题。迭代开发周期中,发布新版本后,如果时间允许,则执行这些用例的回归测试,如果时间不允许,则不执行。
ü 3低——质量风险优先级在24-48。标记为中的测试用例,测试人员应该在执行这些测试用例的时候,如果执行用例失败,测试人员应该先根据bug的严重性和优先级评估是否需要重现和分离问题。迭代开发周期中,发布新版本后,不执行该种类的测试用例。开发周期完成后,执行回归测试时,执行该种类测试用例。
ü 4微小——质量风险优先级在49以上。标记为微小的测试用例,测试人员应该在执行测试时,如果时间紧张,可以不执行该种类的测试用例,但是,如果在执行其他种类的测试过程中,发现该种类的缺陷,应该提交缺陷报告。该种类的测试用例在回归测试时不执行。
C. 完善质量风险分析
完成质量风险分类表格后,质量风险分析基本已经结束,但是,在这个过程中,肯定存在一些归类错误或者风险优先级设置错误的地方,需要测试人员在设计测试用例或者在执行测试过程中进行完善,每次质量风险表格修改后,都需要同志项目组相关人员进行确认。