PDF质量保证：远不止于测试
良好的质量保证不仅关乎技术，还关乎方法和途径。
STUART FELDMAN，IBM 研究院
质量保证不仅仅是测试、分析或一厢情愿的想法。尽管它可能枯燥、困难且乏味，但质量保证仍然至关重要。
确保系统在交付时能够正常工作需要大量的计划和规范。让其他人相信系统能够正常运行需要更加细致和周到的努力。质量保证贯穿项目的各个阶段，而不仅仅是在最后草率地加上。它是一种生活方式。
什么是软件质量保证？
IEEE 标准 12207 对质量保证的定义如下：“质量保证过程是一个过程，旨在为软件产品和产品生命周期中的过程符合其特定要求并遵守其既定计划提供充分的保证。”
这句话三次使用了“过程”这个词。这是质量保证的一个关键方面——它不仅仅是一项单一的技术，还是一种方法和途径。
另一个关键点是，质量不被视为一个哲学问题，而是被视为可衡量地满足期望并符合要求。过程的严格性应根据产品和组织的需求来选择。
最后，质量保证是关于提供保证和可信度：产品应该正常工作，人们应该相信它会正常工作。
质量保证包含哪些内容？当然，测试是一项关键活动。然而，有一句格言是“你无法通过测试将质量测入产品中。” 完善的测试计划应该发现错误并衡量质量。良好的质量保证计划确保设计是合适的，实现是细致的，并且产品在发布前满足所有要求。高级组织的出色质量保证计划包括缺陷分析和持续改进。（这种反馈循环是成熟组织的特征。）
对于实体产品，质量保证涉及制造过程控制、设计评审、测试计划、统计方法等等。在宽松的实施中，会偶尔监控生产线，并在每个阶段检查少量零件。在极端情况下，每个步骤都会被监控和记录，中间产品会接受超过规格的应力极限测试，并且许多最终产品会被销毁。（碰撞测试并不总是隐喻。）只有少数产出物进入实际应用。
对于软件产品，根据组织的结构、软件的重要性、失败的风险和成本以及可用技术，有许多质量保证流程选择。这些应该是经过深思熟虑的决策，并应记录下来并定期回顾。
质量保证必须有多严格？
在理想的世界中，完美将是常态。在现实世界中，你必须做出权衡。尽管有些人声称“质量是免费的”，但情况很少如此。经过多次试验和错误，你可能会得到一个完善的流程，可以可靠且高效地交付高质量的产品。在你达到这个阶段之前，与仅仅将产品推出门相比，明显更高的质量通常需要更长且更昂贵的过程。
有许多类型的要求需要进行质量保证。有些涉及满足基本功能规范：系统或程序在预期（或意外）输入下执行正确的操作。有些涉及性能指标，例如吞吐量、延迟、可靠性和可用性。
其他主要考虑因素取决于运行环境。如果用户对维修问题的理解或能力有限，则必须在新手用户上验证系统。如果系统必须在多种情况下运行，则必须验证互操作性和环境耐受性。
在某些应用中，失败的成本非常高，以至于可以接受延迟，直到完成所有可以想象到的测试和交叉检查。在其他应用中，维修是可以接受或负担得起的，或者可以容忍错误行为。正如银行对想要借款 1000 美元的人和想要借款 100 万美元的人进行不同的信用检查一样，不同的质量保证流程适用于拼写检查器和心脏起搏器。关于高可靠性系统的许多基础工作都是为军事、航空航天和电信应用完成的，这些应用具有极其严格的要求（和庞大的项目预算）；电话交换机和大型机很少发生故障。
质量保证的严格程度范围很广
研究和实验性软件。质量要求可能相当低，过程可能仅仅比调试和少量回归测试好一点。然而，公开演示失败和论文被撤回的尴尬风险表明需要更大的投入。
商业和生产力以及娱乐工具。这些工具应该能够工作，但偶尔的故障（唉）并不令人意外。当崩溃或无效结果的后果可以接受时，可能不值得投入漫长的质量保证周期（或者许多供应商都这么说）。
业务关键型工具。关键组织软件需要更高标准的计划和测试。管理大量资金交易、直接影响人员或法律合规性所需的软件需要具有可信度以及功能性。错误可能会摧毁组织或其高管。任何开发计划都需要在质量保证方面进行大量投资，包括仔细的记录保存和分析。
广泛分散或难以维修的系统。当难以或昂贵地访问所有产品时，广泛的测试和远程维修设计是合理的。如果售出 100 万份游戏，但存在非常明显的缺陷，则升级和维修的成本很容易超过利润。芯片的设计缺陷或错误的启动 ROM 可能会导致同样不幸的结果。需要对各种各样的环境进行大量测试以建立信心，即使产品发布被多次延迟也是如此。在极端情况下，可能无法接触到产品，因为它嵌入在设备中或距离非常遥远；如果任务很重要，则产品必须设计为远程维修和/或具有异常高的质量标准。例子包括修复数百万英里之外的太空任务的著名壮举。
生命攸关和任务关键型软件。某些系统的故障可能会导致生命损失（制动系统、医疗设备）或大规模崩溃（电话交换系统、彩票管理系统）。在这种情况下，应采用精细的质量保证来避免灾难。测试和其他质量保证步骤占用超过一半的开发时间和预算并不罕见。分析必须远远超出单个组件和功能——必须保证整个系统的行为。
组织影响和方法
由于质量保证是一个过程，因此自然会期望分配专门的角色和组织来负责它。在简单且要求不高的项目中，设计人员和开发人员也可以执行质量保证任务，就像他们在传统的调试和单元测试中所做的那样。不幸的是，人们通常不愿在保证任务上花费大量时间；开发新功能要令人兴奋得多。此外，在设计期间遗漏特殊情况的人也可能在测试期间遗漏它。
因此，在较大的组织中或对于具有严格要求的产品，质量保证通常由一个单独的团队负责。理想情况下，该团队独立于开发组织，并且有权在需要时要求重新开发和重新测试。独立的质量保证人员通常负责定义流程并监控执行细节。可悲的是，质量保证人员很少与开发人员保持最好的朋友关系。
一个独立的组织能够进行深入分析，从而支持流程和产品的改进。高水平的 SEI CMM（软件工程研究所能力成熟度模型）认证和 ISO 质量认证需要大量的分析和反馈；质量保证组织是这些活动的天然场所。
质量保证组织不必庞大才能有效。相对较小的团队可以做得很好，只要他们具有独立性、流程知识和对产品的理解。质量保证人员还需要精通产品可能被搞砸、流程可能被绕过以及人员可能粗心大意的多种方式。将质量保证任务分配给团队中最资浅的成员会注定产品和人员的失败。
活动
大量的教科书和标准文档定义了质量保证的各个阶段。如果你将要负责保证质量，请阅读它们。
质量保证涉及软件项目的各个阶段。它通常需要仔细捕获和控制许多工件，以及严格的版本管理。如果没有商定的需求和规范，就不可能制定可靠且可复制的测试计划。
在传统的开发过程中，质量保证组织需要在每个阶段进行评审，并进行仔细的记录、验证和签名。测试和发布标准基于需求，发布基于测试结果。如果产品对可靠性和可用性有要求，则你需要特殊的测试环境和足够的时间来获取数据。
在敏捷编程环境中，当客户检查软件草稿时，需求可能会每隔几周更新一次，质量保证流程需要比传统环境更灵活。尽管如此，仍然必须有人负责确保基本要求的测试、快速更新和记录回归测试以及确保进度审查。（极限编程不能为变质的数据库开脱。）
软件真的比硬件更难吗？
人们已经习惯于软件比硬件有更多错误。这有很多原因
- 系统中困难、不规则、以人为本的部分留给了软件。
- 相反，硬件通常具有重复的组件和相当的规律性，因此逻辑复杂性可能远低于设计的规模所暗示的。另一方面，模拟和机械问题可能会为问题引入新的维度。
- 尽管有数十年的经验，但管理者通常在硬件设计和测试完成后才计划软件。然后既没有时间也没有预算来支持软件的适当质量保证。
- 硬件工程师在教育中以及因为他们知道更改设计不良的物理对象有多么困难，因此对质量有着根深蒂固的尊重。
软件工程师可以从他们的硬件同事那里学到很多关于严格的计划、流程和测试的知识。另一方面，硬件人员可以学到很多关于可用性、灵活性和复杂性的知识。
最大化回报
质量保证流程的细节取决于组织、人员和产品的预期用途。它可能很困难、乏味、令人厌恶、耗时且昂贵。
但它也是必要的。学会做好质量保证，以最大限度地减少痛苦并最大化回报。
STUART FELDMAN 是 IBM On Demand Business Transformation research 的副总裁。在此之前，他曾担任 IBM 高级商务研究所所长和计算机科学研究主管，然后担任互联网技术副总裁。在 1995 年加入 IBM 之前，Feldman 在 Bellcore 工作了 11 年，在贝尔实验室工作了 10 年。他是原始 Unix 研究团队的成员，并且最出名的是 Make 配置管理系统的创建者，以及第一个 Fortran-77 编译器的作者。Feldman 获得了普林斯顿大学天体物理学学士学位和麻省理工学院应用数学博士学位。
最初发表于 Queue 第 3 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，旨在确保应用程序以一致、可预测且经济高效的方式交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。本文介绍了一套核心原则和工程方法，企业可以应用这些原则和方法来帮助他们驾驭复杂的企业可靠性环境，并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongDB 将自研的 JavaScript fuzzer 添加到其工具包中，它现在是我们最多产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。这些错误涵盖了从分片到存储引擎的各种 MongoDB 组件，症状从死锁到数据不一致不等。fuzzer 作为 CI（持续集成）系统的一部分运行，它经常捕获新提交代码中的错误。
Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它的现状如何？
你可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人员一样，你可能对其他人使用这种测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户大会上分发的一项调查中的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化质量保证测试：事件驱动
对于数百万游戏迷来说，在 Electronic Arts 担任质量保证 (QA) 测试员的职位一定像是一个梦想的工作。但从公司的角度来看，与质量保证相关的开销可能看起来非常可怕，尤其是在大型多人在线游戏时代。
© 保留所有权利。