软件质量体系白皮书

由Thoughtworks发布了《软件质量体系白皮书》这篇报告。以下是对该报告的部分摘录，完整内容请获取原文查看。软件质量不能仅靠传统意义上的测试活动来保障，测试人员要延伸测试边界，以更全面、更系统的视角来构建软件质量体系，助力组织提高软件产品的质量。

1.前言

软件质量体系概述

关于软件质量，不同的人根据自身的领域知识和经验，对其有着不同的 认知：有人简单地将软件质量等同于软件测试，有人说到软件质量就会 想到是否有缺陷，也有人对软件质量的认知停留在是否好用的层面…… 实际上，软件质量内涵丰富，既包括可感知的、跟用户使用相关的外部 质量，也包括影响外部质量的软件技术架构和代码相关的内部质量，还 有整个软件开发生命周期中各个环节相关的过程质量。 在 Thoughtworks，我们认为软件开发是复杂的社会活动，随着业务形 态的增多、技术架构的演进，软件质量的复杂性不断增加，影响软件质 量的因素也越来越多。软件质量不能仅靠传统意义上的测试活动来保障， 测试人员要延伸测试边界，以更全面、更系统的视角来构建软件质量体 系，助力组织提高软件产品的质量。

如果我们开始设想一套完善的质量体系，这个体系应该包括许多方法论 和实践，并需要自上而下的管理框架和自下而上的主动意识。 •自上而下的框架是基于顶层设计，整体包括哪些部分，它们的作用 是什么，以及互相之间的关系等。 •自下而上的主动意识则是每个员工基于不同的角色，主动关注与质 量相关的工作，并积极履行应尽的质量职责。 因此，质量体系可以由以下五大部分构成：质量图景、质量策略、质量 实践、质量基础设施和质量人员。

质量图景 质量图景是质量体系的概览，展示组织的整体质量愿景和战略规划。它 通常包括组织对质量定义、目标、价值观、标准、流程、方法和指标等 方面的要求和规定，旨在为组织提供一个整体的、统一的、可持续的质 量管理框架，以确保产品或服务能够持续地满足客户的需求和期望。 质量策略 质量策略是规划和指导质量实践活动开展的指南，包括测试流程、测试 左移、持续测试、测试右移、质量门禁和质量度量等策略。 质量实践 质量实践是基于质量策略开展的具体质量活动，是实施质量保障的核心。 质量实践贯穿整个软件开发生命周期，包括需求分析阶段、需求实现阶 段和线上运维阶段。

质量基础实施 全流程的标准化和大规模的自动化是高效实施质量实践的关键，而质量 基础设施是标准化和自动化的有力支撑，包括支撑标准化策略规范落地 的全流程管理平台、支撑持续自动化测试的工具框架和环境等。 质量人员 清晰的质量图景，明确的质量策略，规范的质量实践，成熟的基础设施， 最终都需要质量人员来实施，质量人员是质量体系的基石。质量人员不 仅指测试人员，包括所有参与质量工作的人员。质量人员相关的质量文 化建设、质量能力建设、绩效管理和多角色协同等，都是质量体系需要 考虑的内容。

灯塔作为一个指引方向的比喻，我们可以用它来描绘软件质量体系的整 体构成。灯塔的各个部分与质量体系的各个组成部分对应如下： 灯塔顶部的灯光代表质量图景。 灯塔的灯光为船只指引方向，质量图景为整个组织软件产品质量提供了 明确的导向。 灯塔的主体代表质量策略和质量实践。 正如灯塔的主体，质量策略和实践构成了整个质量体系的主体，是实现 质量目标的核心。 灯塔的工作人员代表质量人员。 灯塔工作人员的努力使得灯塔能发挥其功能，质量人员的高效协同是实 现质量目标的必要条件，而质量文化和团队价值观决定了质量体系各个 部分如何发挥作用。灯塔的基石代表质量基础设施。 灯塔的电源系统和通信设备是灯塔的基石，为其正常运行提供必要支持， 就像质量基础设施在质量体系中为质量实践的实施提供支撑一样。 将质量体系框架与灯塔概念相结合，我们可以更直观地展示质量体系的 各个组成部分以及它们之间的关系。灯塔为船只提供了指引，确保航行 安全，同样，一个完善的质量体系为组织的软件产品提供了明确的质量 方向，有助于确保软件系统达到高质量标准。

2.质量策略

测试流程 这里的测试流程并不是指执行某项测试需要哪些步骤，而是指在软件开 发生命周期中需要在哪些环节实施测试相关活动。测试流程的定义就是 将这些内容固化下来，形成规范。团队全体成员可以基于这些规范来执 行相应的测试实践。测试流程通常与软件开发流程密切相关，需要基于 开发流程来定义。 为什么需要定义测试流程？ 如果没有流程规范，大家随意开展测试工作，会导致混乱。测试流程相 当于测试活动开展的框架，类似编程框架。可以用来批量培训人员，让 大家按照统一的方式来实施测试，规范每个人的测试行为，减少犯错的 可能性，尽可能提高测试的效率和有效性。

测试左移 测试左移并不是全新的测试方法，而且早在 2001 年，Larry Smith 就 在他的文章《Shift-Left Testing》中提出了测试左移的概念和相应的实 践。测试左移的本质就是尽早地进行测试相关的工作，将这些工作移到 开发过程的早期（例如业务分析和设计过程），让 QA 和 Dev 参加需求 分析和需求评审，尽早进行测试分析，从而发现不合理的需求，不合理 的设计等。

为什么需要将测试左移？ 首先，众所周知，软件开发中最大的浪费是返工。无论是因为修补 Bug 而返工，还是因为需求理解错误而写错了代码而返工，都是巨大的浪费。 测试左移是解决这些浪费的有效实践之一。 其次，软件缺陷产生的主要原因包括：业务设计本身有误、Dev 对业务 需求理解有误、Dev 编写代码有误等。测试左移的主要目的是在编码阶 段之前统一 BA、QA 和 Dev 的认知，以尽可能防止由于理解不正确或 不完全而导致的缺陷，并将测试工作左移到 Dev 编写代码的过程中，以 防止代码编写错误导致 Bug。

因此测试左移能为项目带来以下收益： •早发现早修复：测试左移可以尽早发现业务需求、架构设计和代码 中的缺陷，从而能够及时修复它们。 •节约返工成本：测试左移可以减少代码开发完成后的缺陷数量，从 而节约修复它们所需的返工时间和人力成本。尤其是时间成本最为 重要，降低时间成本可以提高软件交付的效率，缩短交付时间。 •更好的团队协作：测试左移需要 QA 与 BA 以及 Dev 进行大量合作， 从而可以促进团队不同角色人员更好地协作。 •更好的测试有效性：测试左移也可以帮助 QA 以及 Dev 更好地分析 和理解业务需求、更多的业务分支和异常情况，并且可以帮助 QA 获得更有效的、覆盖率更高的测试用例，也可以帮助 Dev 更准确和 全面地进行任务拆分，从而获得更高质量的产品。 •更早的自动化测试：由于测试左移可以在开发之前获得有效性更高 的测试用例，从而可以帮助 Dev 和 QA 更早更好地实施自动化测试。 在项目中实施自动化测试时，测试左移是一个重要的起点。测试左 移实施得好，可以为自动化测试打下良好的基础，尤其是编写高有 效性的验收条件或验收测试用例，能够帮助团队更好地实施自动化 测试和 TDD 等。

测试右移 测试右移是与测试左移相对应的，它将测试活动从独立测试阶段右移到 生产环境，也称为“生产环境下的 QA”。 由于生产环境的特殊性，测试右移并不是简单的测试活动右移，而是通 过一些实践活动获取生产环境下用户行为、日志等质量相关信息，利用 这些信息为前期的需求、开发和测试工作提供反馈，促进相应工作的优 化改进，以更好地实现质量内建。

为什么需要将测试右移？ 随着软件技术和架构的不断演进，软件系统的基础设施日趋复杂，业务 和数据量也大量增加，生产环境中不稳定的因素在持续增多，导致系统 行为变得难以预测，软件系统的不确定性日益严重。 人们无法通过预先设定的测试场景和测试脚本来有效地测试软件，开发 和测试环境已经不够用，软件系统的质量保障工作受到挑战，软件系统 变得愈加脆弱。为了应对这种不可预测性和脆弱性，需要将测试活动右 移到生产环境中。 测试右移将质量保障的范围从需求扩大到生产环境，增加反馈来源，结 合持续交付，可以帮助持续提高产品质量和优化业务价值，增强软件产 品的反脆弱能力。

持续测试 持续测试将测试作为整个软件开发过程中不可或缺的一部分，在各个环 节进行测试验证活动。它对每个不同版本进行频繁的测试，内容包括持 续功能测试、性能测试、安全测试等。形式可以是静态分析和评审，也 可以是动态的手动和自动化测试。持续测试包括以下两个方面的内容： •在软件开发全流程的每个环节，通过频繁执行不同的测试活动，实 现多环节的全面缺陷快速发现。 •通过持续集成，将代码静态扫描和自动化测试集成到流水线，并针 对每次提交到版本仓库的代码进行持续、自动化的验证。

为什么要持续测试？ 只在软件“开发完成”以后才进行测试，反馈得太晚，这个阶段测试发 现的问题导致返工修复成本高。而全生命周期的持续测试可以快速获 取反馈，尽早发现过程中可能的缺陷和偏差，以降低成本，提高质量。 例如： •对每次向版本仓库提交的代码都执行自动化的单元测试和验收测 试，可以快速地为 Dev 提供关于本次代码变更的反馈，以便及时修 复相关的缺陷。

3.质量实践：需求阶段

需求澄清 需求澄清是指在交付开发前，由不同角色触发的对需求内容进行澄清和 确认。简单来说，就是需求相关的各个角色对需求本身产生的问题进行 协调的过程。需求澄清是需求进入开发前必不可少的一步，也是提升需 求质量的关键环节。在需求澄清中，QA 需要发挥关键作用，提出有意 义的问题，促进需求质量的提升。

为什么需要澄清需求？ 澄清需求价值 需要明确业务价值和用户价值的理解是否一致，这是确保需求价值正确 交付的关键。开发中常见的一个误区是“做的不是用户想要的”，这通 常是由于需求价值的理解和传达出现了问题。 对齐需求理解 在价值共识的基础上，对齐需求还需要各个角色对需求细节的理解达成 一致，例如对业务分支、用户使用方式和常见异常情况的处理等。

减少返工 进行需求澄清有助于减少开发过程中的返工。如果在开发前未对需求进 行有效澄清，有可能导致在开发过程中，需求交付价值、业务流程、业 务细节等方面出现较大变更，进而造成返工的浪费情况。 明确完成定义（DoD） 通过澄清验收标准，可以帮助各个角色对需求完成的定义有清晰的理解 和共识。尽早确定需求的验收标准，可以最大限度地确保开发过程不偏 离需求价值。

需求评审 需求评审由需求相关的关键角色共同参与，针对即将付诸开发的各个需 求逐一审视，验证需求价值，讨论实现方案和技术方案，明确需求交付 成功的验收标准。有时也会在需求评审时进行需求拆分方法和拆分粒度 的讨论。

为什么需要评审需求？ 需求评审的价值和需求澄清是类似的，也起到确认需求价值、对齐需求 理解和降低需求风险的作用。除此之外，需求评审的最主要价值是获得 对需求的确认，明确这些需求可以进入研发阶段。 另外，在需求评审的过程中，检验需求的价值和完整性非常重要。这有 助于减少需求传递中的失真，并且能够提前识别和干预需求交付的风险。

4.质量实践：实现阶段

Kick off Kick off 全称为 Story Kick off（用户故事启动），也叫开卡，是指在 Dev 开始实现用户故事之前，与 BA 和 QA 再次澄清和确认自己对用户故事 内容的理解。这是用户故事（或需求条目）生命周期中的一个环节。

为什么要做 Kick off ？ 1. Kick off 主要价值在于确保 BA、Dev 和 QA 对用户故事内容的理解 一致，减少因理解不一致产生的缺陷和返工； 2. 虽然在需求澄清和需求评审等确认环节中进行了确认，但随着需求 进一步细化，用户故事的内容可能会发生或多或少的变化。此外，时 间间隔较长可能会导致对故事的理解发生偏差。因此，在正式开发 之前再次进行澄清和确认是非常必要的。

单元测试 单元测试主要是针对软件系统中的一个代码片段（称为单元）进行自动 化测试，以检查该代码片段是否满足设计和功能要求。在基于过程式语 言的代码中，一个单元通常可以是一个模块（module），更常见的是一 个独立的函数（function）或者过程（procedure）。而在面向对象语 言的代码中，一个单元通常是整个接口，例如一个类（class）或一个 方法（method）。通常由 Dev 负责编写单元测试。

为什么需要单元测试？ 对于大型的软件系统，使用黑盒功能测试进行测试时，很难保证代码的 测试覆盖率。而且，功能测试执行速度缓慢，通常需要在真实测试环境 中执行，这导致 Dev 无法快速获得有关其新编写代码质量的反馈，导 致问题无法及时修复，很可能致使整个项目延期。 其次，单元测试可以有效地帮助 Dev 进行代码重构。因为它在 Dev 完 成代码重构之后快速执行，可以快速发现重构后的代码是否破坏了原有 的功能，从而增加 Dev 重构的信心。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）