|
测试过程中主要会考虑质量的风险,也要考虑项目的风险,比如沟通风险,需求变更风险,资源风险等等。
首先讨论质量风险分析, Rex Black 曾写过一本软件测试核心过程的书,我买了一本(中文),其中质量风险分析就是 12 大测试核心过程之一。在项目开始阶段,熟悉项目的同时,也要召集相关人员讨论这个项目存在或潜在的质量风险,制定优先级,制定 action plan ,归档,追踪。风险分析也是测试计划中必不可少的一个部分。质量风险分析的文档可以作为测试设计的依据。而令人遗憾的是,都没有认真进行过质量的风险分析,一般都是武断地被决定放弃哪个测试和保留哪个测试,我也曾在我的 test plan 中列出测试部门认为的风险因素 ( 曾私下与开发部门讨论 ) ,发现根本没有人去认真阅读此文档。
进行质量风险分析,通常情况都会在测试条件下对系统的质量风险进行识别和优先排序。一般地,这些风险会根据主要风险类别,比如功能,性能,安全等,进行分组或组织。风险分析也会运用已完结项目的历史缺陷和失败数据。 Rex Black 书中详细介绍了质量风险分析的过程,这个过程只是个参照,根据公司的实际情况和项目需求,可以省略一些步骤或增加一些步骤。具体的过程如下:
1 )找出关键的测试和质量 stakeholders 。获得 stakeholders 参与质量风险分析的承诺。(获得公司管理层的承诺,找到 PM, Development Lead, Design lead… 等,推销质量风险管理)
2 )就质量风险分析的技术和方法问题,对关键渉众进行调查。如果合适的话,就提出一种技术,并获得在技术和方法选择上的一致意见。(大体上四种技术方法: 非正式的 --- 列出系统中潜在问题的列表,然后与关键涉众一起给这个列表中的项目确定优先级; ANSI/ISO 9126 标注 --- 在质量的六个特征之中 ---- 功能,可靠性,可用性,效率,可维护性和可移植性( FRUEMP ) --- 定义了质量的子特征,根据每个子特征测量系统的质量度量,最后将这些度量翻译成一种质量评估的方法;发现的费用 ( cost of exposure , COE ) --- 找出潜在的问题和它们产生的影响,然后评估当这个问题发生时对业务产生的费用,以及发生这个问题的可能性;失效模式与影响分析( FMEA ) --- 找出潜在的问题,了解他们的影响(对于顾客和用户),然后对他们进行分类(采纳涉众的建议),按照严重性(对系统的冲击),优先级(对商业利益的冲击)和发生的可能性(失败的几率)
3 )向关键渉众收集关于质量风险,与这些风险相关的失败模式,这些失败对于质量的影响以及风险的优先级方面的意见。找出降低每种风险的推荐措施。(指导质量风险分析过程的测试人员很重要,不仅要有一定的质量分析技术的技能,还要有一定的管理技能,能够 解决冲突和不同意见,确保会议按照日程和时间表进行等才能。此外,必须就有一定的信誉和高层领导的支持。)
4 )在分析中报告在其他项目文档中找到的任何早起错误,例如不明确的需求或需求丢失,以及设计问题等等。( 在测试开始之前发现潜在的错误非常关键,首先,分析能够发现含糊的,不可测试的或无法达到的需求和设计缺陷等的实例。其次,除了发现问题之外,质量风险分析过程也能够指出解决办法。第三,优先级确定的过程是一种给编程组的提前通知,指出我们将会测试什么。)
5 )以文档形式记录对应于所使用技术的质量风险。将这些文档在渉众之间传阅以得到批准。根据需要重复第 3 , 4 , 5 步,以最后确定质量风险,它们的优先级以及推荐措施。
6 )将质量风险分析文档检入项目的资料库或配置管理系统中,将这份文档置于变更控制之下。(创建一个可追溯性的数据库)
要全面考虑质量风险的来源,质量风险不仅来源于产品和系统本身,也与项目过程和组织环境有关。比如开发团队的技能和经验,修改 bug 的质量和需要的时间等,比如到达开发项目的末期,还有许多需求变更,不经增加了风险,也增加测试工作量,这时候就要 要选择一个回归测试集,分析变更,决定伴随着特殊变更、条件或缺陷修复的回归测试的可能性,也应该 -- 用质量风险分析来选择最重要的测试。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/Lynn_yan/archive/2009/09/02/4511173.aspx |
|