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

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

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

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

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

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

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

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

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

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

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

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

　　图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.51testing.com

相关阅读：质量风险分析（上）