质量风险分析（下）

         质量风险分析（下）   软件测试

        质量风险分析过程

　　不管选择哪种技术，都可以遵循一个相似的质量风险分析过程。

　　1.识别质量风险分析小组；

　　2.选择一种技术；

　　3.识别质量风险，对风险进行优先排序。选择合适的风险缓解方式。（不仅包括测试的各个阶段，而且包括审查需求、设计和代码、编程技术等一系列检查范围等等）；

　　4.如果风险分析小组识别出需求、设计、代码或其他项目文档、模型或已交付产品的问题，会报告这些问题，寻求解决方法；

　　5.审核、修改和定稿质量风险分析文件；

　　6.检查质量风险分析文件纳入项目库的变更控制之下。

　　7.定期（比如，重要的项目里程碑，如需求、设计和实施阶段完成，测试准备及退出审查时）及出现新的信息（比如，测试周期完成）时，检查并更新风险分析，增加新的条目并重新估算新条目的风险等级。

　　作者更喜欢利用头脑风暴或类似有启发性的技术，把步骤3作为一个单独的单元进行。但是，在被风险分析控告的人和质量风险分析小组之间，他把这一步作为一系列会话，甚至是一对一的会话，执行了。

　　除了选择合适的技术，为了在质量风险分析过程中获得更多有用的东西，还有必要选择合适的参与者。需要一个在测试和质量方面代表所有利益相关者利益的跨职能的小组。如果不是代表所有各方的利益，那么就有可能遗漏一些关键的风险，也可能过高或过低的估计了一些风险的等级。

　　谁是关键的利益相关者？一般的规则是有两个群体。首先，理解顾客和/或用户需求和利益的那些人，或者与测试过程有直接关系的那些人。（必要时，顾客和用户也可能参与进来。）从商业方面考虑，他们能帮助评估出潜在问题的影响力。其次，洞察系统技术细节的那些人。从技术方面考虑，他们能帮助评估出潜在问题的可能性。

　　在过程中，除了有信息收集的性质，建立共识也是至关重要的。关注商业和关注技术的参与者都能、也应该协助进行风险优先级分类，并选择可以减轻风险的战略方案。

　　案例分析：质量风险分析过程

　　对互联网应用来说，作者把质量风险分析看作一系列的会话，并与组织中的关键管理者和技术领导进行讨论。他已经起草了销售需求和设计规范，以及一个可在各利益相关者之间共享的高水平系统的构思。这个风险分析讨论在作者和他的助手之间就测试工作已经达成了坚实的共识。

　　质量风险分析过程有两个需要注意的副作用。第一，它解释了系统的版本是不断演变的，不是一成不变的，尤其是在细节上。对什么有风险、什么质量优良达成一致意见，有助于促进理解共识对系统质量的意义。第二，风险分析（连同随后的测试设计工作）突出了需求和设计文档的许多问题。解决问题，防止缺陷进入测试过程。

　　拿文档安全应用来说，作者的客户没有书面的规范。拿互联网应用来说，建一个共享版的系统。幸运的是，作者能够利用一个下午的时间召集所有的利益相关者召开一个关于质量风险分析的会议。由此产生的文档可作为测试重点指南和测试设计过程的第一步。

　　除了创建有用的文档，还有两个需要注意的副作用。第一，开发小组决定采取措施积极主动地预防缺陷发生。令人鼓舞的是质量风险分析会议上，开发主管和技术领导采取诸如加强设计和代码审查的质量风险减缓措施。第二，风险分析文档成为实际需要的文件。由于质量风险分析侧重于不做什么，所以他们会否定地表达需求。

　　用质量风险的总体等级确定测试资源

　　质量风险分析应该识别风险本身及与其相当等级的风险。要确定风险的等级，其可能性和影响力是考虑的主要因素。作者喜欢把这两项分为五个等级：非常高、高、中、地、非常低。失效模式及效应分析考虑三个因素--发现问题的严重性、优先级和可能性--变化范围从1到10。

　　把这两个（或三个）因素转化为一个，聚合风险等级，人们可以运用质量风险分析小组的集体判断，一个公式或一个表格。在互联网应用案例的分析中，作者依靠集体判断来决定风险适当的总体等级。在文件安全案例分析中，他按照失效模式和效应分析标准从三个因素的等级级别中得到从1到1000风险优先级数，然后它被分解成代表不同总体风险的等级范围。要使用表，首先建立一个类似表3所示的查找表，然后在每个风险条目两个因素的基础上，用它来分配风险的总体等级。假设给定总体风险等级，然后人们就可以用它们来确定他或她想要进行测试的范围。例如，可能采用的规则列于表4中。

　　在表4中，注意不进行非常低和低风险范围的测试。对于中、高和非常高的风险，他或她承诺通过增加时间和工作量进行测试，以减少相关风险。那么每个级别合适的分界线在哪里呢？这是利益相关者的又一个问题。做那个界别的测试会使利益相关者感觉满意，每个风险得到充分的缓解。

　　这个问题的答案必须是切合实际的。在没有任何限制的情况下，人们可能喜欢对大多数而不是所有风险做大量测试。然而，如前所述，这是不可能的。所以，风险分析的每个参与者要问的是：“通过测试来减轻风险，我愿意消耗--在时间、项目预算、甚至是可能失去功能方面--的是什么？”

　　案例分析：把相关的质量风险作为向导

　　在互联网应用项目中，作者遵照的是表4的规则。风险通过各种方式，把测试集和工具的高级设计降低为测试用例和数据的低级设计和执行。假如作者按照瀑布/V-模型系统开发生命周期着手于一个中型项目，那么这种程度的架构是合适的。

　　在文件安全应用项目中，这个方法是很不正式的。整个项目小组中的每个人都明白测试小组将会高度关注高风险，较少关注中风险，可能会完全不关注低风险。假设作者按照相对灵活的系统开发生命周期着手于一个小型项目，那么这种非正式是合适的。

　　整个生命周期风险的缓解和管理

　　到此为止，读者已经看到质量风险分析过程是怎样的，以及由此产生的文档可作为测试设计的依据。但是，它也能在整个项目中为质量工作者提供指导。让我们看看分析帮助缓解和管理质量风险的七种方式，。

　　第一，为什么等着测试来缓解重要的质量风险？就像文件安全案例分析（参见图1）中显示的，质量风险缓解活动包括各种质量安全工作。在作者做过的许多项目中，需求、设计、代码的审查被证明是有用的。采用和遵照编码标准有助于程序员避免有危险的架构。防御性的编程技术，如结对编程、测试第一编程，及代码调试器逐步检测代码发展过程中的错误。在生命周期的各个阶段，尤其是早期，越重要的质量风险，就越巧妙地包含了多个质量保证工作的重点。

第二，在他或她设计和开发测试的时候，他或她可使用质量风险分析文档确保其完整性。暂时假设他或她按照表4的方法，在这种情况下，测试团队开发的每个测试用例应该映射到一个或多个中、高或非常高的范围，每个中、高、或非常高风险的风险范围应该映射到一个或多个测试用例。相对风险越高，那个风险范围的测试就越多。如果想要明确了解测试人员适当地涵盖了所有风险，让他们明确这个映射关系，有时称为跟踪矩阵（参见，例如， Craig and Jaskiel 2002）。

　　第三，在准备运行测试的时候，他或她可以用这个跟踪矩阵，从风险到测试用例中选择首先执行哪个测试。一个好的优先级测试用例执行的经验规则是：在查找微小缺陷之前先查找重大的缺陷。所以，再次依照表4的方法，测试出的非常高的风险应该先于测试出的高风险，也应该先于测试出的中风险。

　　第四，在开始测试时，他或她应该收集实际测试结果并找到真正的--非潜在的--缺陷。在每个风险范围内的缺陷种类和数量应该有风险分析准确的反馈意见。如果非预期的地方出现了很多缺陷，可能是技术风险--就是说，缺陷出现的概率与某些风险范围相关--高于以前的想法。如果危险缺陷出现在认为缺陷微小的地方，可能是商业风险--就是说，缺陷的影响与某些风险范围相关--高于起初的想法。如果能跟踪测试结果，并且缺陷能恢复到测试执行的第一天，那么就可以在他或她认识的基础上，调整风险分析和测试焦点（Black 2002）。

　　第五，继续执行测试，他或她会发现测试的时间少于需要的时间。项目组扭转非预期的规格变化、多于预期的测试周期、程序员和供应商的迟到交付：所有这些会给测试施加压力。通过跟踪伴随特殊测试用例风险的相对等级，可以通过最小化风险增加的方法，智能地调整将要执行的测试量。

　　第六，到达开发项目的末期，他或她有时发现需要做较多变更，增加最后一个功能，或修复最后一个缺陷。经常需要做一些重复测试（即，回归测试），以保证不会破坏之前可以正常工作（即，系统中没有造成回归测试）的地方。要选择一个回归测试集，人们可以--可能应该--分析变更，决定伴随着特殊变更、条件或缺陷修复的回归测试的可能性。但是，人们也可以--可能应该--用质量风险分析来选择最重要的测试。

　　第七个和最后一个优势，注意在这篇文章中作者多次提到可追溯性。捕捉和支持这里所描述的所有优点的最好方法是创建一个可追溯数据库。这种数据库的高级实体关系图如图2中所示。在这个图表中，注意如何把质量风险与测试用例、测试用例与测试结果和缺陷、测试结果和缺陷与质量风险关联起来。这使得报告测试结果不仅根据--毕竟相当抽象的数量--测试用例数量（例如，运行、通过和未通过的）和缺陷数量（例如，被发现、已修复和剩余的）而且根据通过测试缓解的风险和依然居高不下的风险。

　　一个警示性的案例分析

　　质量风险分析过程中的一个约定被打破了。作者的客户有了详细的书面规范，有一个8个人共享版系统的核心。但是，所有的利益相关者都太忙而没有时间进行风险分析，他们让作者和他的助手们进行风险分析。

　　他们是这样做的，部分是面对面交谈、通过电话、邮件联系，但是大多数是根据需求和设计规范进行分析的。然后，他们对质量风险分析文档的意见进行交流。少数利益相关者会提出意见，因为只有少数人阅读了此文档。不过，这个分析是他们关注的唯一指南， 他们制订并准备执行这些测试。

　　在这一点上，计划和预算的压力使项目经理减少了广度和深度测试，这些减少根本没有按照风险分析去做。项目的管理团队并没有承诺进行风险分析，他们不清楚这会告诉他们什么。因此，他们根据他们对质量风险相关等级的有限理解，武断地决定放弃哪个测试和保留哪个测试。根据这个经验，作者得出了一个结论：对成功的质量风险分析过程来说，涉及适当的利益相关者，并确保利益相关者参与到合适的风险等级中去比提供大量的文件更重要。

　　结论

　　本文中，作者解释了人们如何以及为什么把风险分析作为测试和其它质量保证工作的基础。他讨论了如何把传统项目的风险管理思想扩展到包括系统在内的质量风险管理。他包括为潜在问题建立质量风险相关等级的可能性（技术风险）和影响力（商业风险）的因素。

　　在罗列了一般概念之后，作者转移到了力学之上。他审查了五种质量风险分析技术：非正式的、ISO9126、暴露成本、失效模式和效应分析、危险性分析。他涵盖了一个进行质量风险分析的通用的、适应性强的过程。

　　最后，作者回顾了应用于质量风险分析的多种方法。质量风险分析为智能的测试设计和开发提供了基础。然而，这仅仅是个开始。作者也展示了在整个项目生命周期中，人们会继续用质量风险分析开展重新评估、管理和缓解系统质量风险的工作。

　　参考文献

　　Black, R. 2003. Critical testing processes. Boston: Addison-Wesley.

　　Black, R. 2002. Managing the testing process, second edition. New York: John Wiley and Sons.

　　Craig, Rick, and Stefan Jaskiel. 2002. Systematic software testing. New York: Artech House.

　　ISO. 2000. ISO 9126-1:2000 Information technology: Software product quality. Geneva, Switzerland: International Organization for Standardization.

　　Jones, T. Capers. 1995. Estimating software costs. New York: McGraw-Hill.

　　Juran, J. M. 1988. Juran on planning for quality. New York: Free Press.

　　Stamatis, D. H. 1995. Failure mode and effect analysis. Milwaukee: ASQ Quality Press.

　　传记

　　Rex Black是RBCS公司的总裁和首席顾问，他是一个有20年软件和系统工程的老手，软件、硬件和系统测试的领导者。十多年来，RBCS为其全球范围内的用户提供培训、咨询、人员配备、现场、非现场、以及离岸项目实施方面的服务。RBCS的许多用户遍及4大洲的16个国家，包括Adobe 公司（印度）， 上海贝尔阿尔卡特银行， 第一银行，思科， Comverse公司，戴尔公司，美国国防部，日立公司， NDS公司， Reef公司， 和Schlumberger公司。他受欢迎的第一个著作《Managing the Testing Process》，现已发行第二版，已经在全球卖了30，000册，包括日语版、中文版、印度语版。他的最新著作《Critical Testing Processes》是2003年出版的，已经卖出了2，000册，其中包括翻译成日语和俄语的版本。Rex也写了许多文章，同时还在各种美国和国际会议上发表论文、参加研讨会和演讲。

原文转自：http://www.ltesting.net