​​

各位质量爱好者大家好。今天的文章并非技术类的。有时候，泛泛地聊聊流程和质量也是一件不错的事情。今天，我想和大家分享一些关于质量关卡的想法。你听过这个词多少次呢？一次都没听过？听过一次？还是每天都能听到呢？无论你是否听过这个词，我相信你在过去都曾运用过它。也许你知道自己用过，也许不知道，但我觉得在你当前的项目中，是可以运用质量关卡的。

本文的目的仅仅是把我们已有的知识梳理整合一下，其中也包括我所掌握的知识啦 ：） 但在我们开始整理思路之前，让我们试着回想一下，质量究竟是什么呢？

​​

从质量到质量关卡
根据 ISO 9000:2015 标准，质量被定义为 “客体的一组固有特性满足要求的程度”。

对于软件产品而言，质量简单来说代表着产品的卓越程度或水平。然而，它涵盖了多个方面，包括功能性、可靠性、性能、安全性、可用性和可维护性等，所有这些方面都有助于满足利益相关者的期望和要求。

我们要如何控制工作质量呢？我们通过质量关卡来实现这一点，质量关卡充当着检查点，以确保在开发的每个阶段都能达到相应的标准。

质量关卡是设置在开发过程关键阶段的检查点，用于在进入下一阶段之前评估产品是否符合预先设定的质量标准。这些关卡就像是控制机制，能够在从需求收集到部署的每个阶段预防缺陷，并确保符合相关要求。

当我们谈到质量关卡时，常常会把它们和编码阶段联系起来。然而，质量关卡并不局限于编码阶段 —— 它们适用于整个软件开发生命周期（SDLC），确保从需求收集到部署的每个阶段的质量。

​​

软件开发生命周期（SDLC）的每个阶段都有一组明确规定的标准，在进入下一阶段之前必须满足这些标准。要继续推进项目，所有的强制性标准都必须得到满足，而有些标准可能是可选的。然而，如果未能满足所需的标准，就应该阻止进入下一阶段，以此来确保质量控制。

不过，这只是一个宏观的视角。从技术层面上讲，每个阶段可能由多个子阶段组成，在进入下一个主要里程碑之前，阶段内的进展是逐步推进的。

我们接下来的目标是梳理软件开发生命周期（SDLC）的每个阶段。然而，我们并不打算涵盖所有可能的标准，因为这些标准可能会因项目规格和特定需求而有所不同。相反，我们将重点关注在每个阶段通常用于确保质量的关键方面。​​

需求阶段
在进入设计阶段之前，需求必须定义明确、清晰且可测试，以避免日后出现代价高昂的变更。

在我看来，这个关键阶段常常被忽视，从而导致在后续开发阶段出现问题。有几个因素会导致这种情况的发生，包括缺乏领域知识、流程效率低下以及时间压力。

为了有效地控制这个阶段，最佳方法是使用任务管理工具（例如，JIRA、Azure DevOps、Trello）并结合结构化的检查表。这些工具有助于跟踪进度、执行审查流程，并确保在进入下一阶段之前，需求符合定义的质量标准。

当然，确切的方法取决于你团队的工作流程、项目的复杂程度以及可用的工具，但是实施一个结构化的验证过程可以大大降低后续开发阶段的风险。

可能的标准：

• 需求完整性：记录所有功能和非功能需求。
• 清晰度：不存在模糊、冲突或不明确的需求。
• 可行性检查：需求在技术和实践上是可实现的。
• 利益相关者批准：业务和技术团队已经审查并批准了需求。
• 追溯矩阵：每个需求都与业务目标和测试用例相关联。

​​

设计阶段
在开发开始之前，软件架构和设计必须结构良好，并且与需求保持一致。还应该定义编码规范，包括通用的和特定的规范，例如 API 设计标准、用户界面设计标准等等。在开始编码阶段之前，你可能需要通过这些质量关卡。

可能的标准：

• 架构审查：系统架构具有可扩展性、安全性且高效。
• 设计一致性：遵循设计模式和最佳实践。
• 性能考量：考虑了可扩展性、响应时间和负载能力。
• 安全措施：完成了威胁建模和风险评估。
• 利益相关者批准：架构师和关键利益相关者已经审查并签署了设计方案。

​​

编码阶段
在进入下一阶段之前，代码应该编写良好、易于维护并且经过测试。

这可能是我最喜欢的质量关卡阶段了，因为在这个阶段有很多实现自动化的机会。你是否在对拉取请求（PRs）进行代码审查呢？你是否在衡量单元测试的覆盖率呢？你是否已经设置了静态分析工具和安全代码扫描工具呢？

这些以及许多其他关键问题，都有助于在进入下一阶段之前确保代码质量。最棒的是什么呢？这些步骤中的许多都可以实现自动化，在所有要求都得到满足之前阻止进入下一阶段 —— 而且无需人工干预。

将这些方法与测试金字塔相结合，可以对软件质量产生显著的积极影响。通过将自动化质量关卡与结构良好的测试策略相结合，你可以确保不同层次的测试 —— 单元测试、集成测试和端到端测试 —— 能够高效协同工作，尽早减少缺陷并提高整体稳定性。

但我们有点赶时间。让我们进入验收测试阶段吧。

可能的标准：

• 代码审查：进行同行评审以确保遵循最佳实践。
• 编码标准：代码遵循预先定义的惯例和行业标准。
• 静态代码分析：使用自动化工具检查代码异常、安全漏洞和可维护性问题。
• 单元测试：达到最低的测试覆盖率百分比（例如，80%）。
• 安全合规性：代码库中不存在关键漏洞。

​​

验收测试阶段
在发布软件之前，软件应该满足业务需求，并根据验收标准进行验证。

这个阶段也是自动化测试的理想阶段，尤其是对于回归测试而言。然而，这不仅仅是运行测试那么简单 —— 而是要确保应用程序真正准备好发布。在这个阶段，我们定义的验收标准就充当了我们的质量关卡，决定着我们是否能够自信地进行部署。

为了简化这个过程，可以实施两种强大的方法：持续交付（CD）和持续部署。

• 持续交付（CD）：确保每一个变更都经过测试，并且随时可以部署，但在上线之前需要人工批准。
• 持续部署：将每一个经过验证的变更直接推送到生产环境中，无需人工干预，确保快速且频繁的发布。

这两种方法都高度依赖自动化测试、安全检查和部署管道，以便在快速交付新功能的同时保持稳定性。

质量控制（QC）和质量保证（QA）工程师可能对这个阶段非常熟悉。但你要问问自己：你真的了解你项目中的质量关卡吗？或者，为了确保团队成员之间的清晰理解和协调一致，明确地讨论并定义这些质量关卡会不会更好呢？

可能的标准：

• 功能测试通过：执行并通过了关键业务流程的所有测试用例。
• 用户验收测试（UAT）：最终用户确认系统满足他们的需求。
• 回归测试：之前功能中没有引入关键问题。
• 性能测试：系统在预期的工作负载下能够正常运行。
• 缺陷分类：审查所有未解决的缺陷，并解决关键 / 阻塞性问题。

​​

发布阶段
在部署之前，软件必须稳定、安全，并且准备好投入生产使用。发布策略可以是一份关键文档，其中概述了质量关卡的各项内容。在进行发布之前，考虑所有必要的步骤是至关重要的，因为这些步骤可能非常关键。最佳方法可能是制定一份检查表。不过，采用自动化步骤的持续部署也是一个不错的选择。你甚至可以考虑自动化文档记录步骤。

可能的标准：

• 部署检查表：完成所有预发布活动。
• 回滚计划：制定并测试了回滚程序。
• 安全审计：系统中不存在重大漏洞。
• 基础设施就绪：生产环境已准备就绪，并且满足系统要求。
• 获得签署批准：业务、开发和运营团队批准了发布。

​​

维护阶段
我们的软件已经发布了 —— 任务完成！是时候放松一下了。来喝杯啤酒吧！

但是等等…… 遗憾的是，这还不是结束。软件发布之后，必须对其进行持续监控和维护，以确保持续的质量和性能。如今，“右移测试” 方法也非常流行，即在已发布的产品上继续进行测试活动。也许可以运行一些不会对数据造成损害的自动化脚本。

可能的标准：

• 监控到位：日志记录、警报和监控工具都已启用。
• 事件响应计划：制定了处理生产问题的明确程序。
• 缺陷跟踪：记录、优先处理并解决报告的缺陷。
• 性能监控：系统满足正常运行时间和响应时间的预期。
• 持续改进：收集并分析反馈，以便用于未来的改进。

​​

审查、规划并实施质量关卡
构建质量关卡的第一步是审视我们现有的内容。这意味着要快速进行一次内部审核，看看是否存在任何现有的质量检查点 —— 即使我们之前没有将它们视为 “质量关卡”。将这些检查点映射到软件开发生命周期（SDLC）的不同阶段也很有帮助，这样可以全面了解我们的现状。

一旦我们知道了已经具备的内容，下一步就是集思广益，思考我们可能还需要什么。这可能包括对代码质量、安全性、性能或合规性等方面的检查。目标是列出一系列潜在的质量关卡，以帮助改进我们的流程。这里重要的是专注于那些肯定能帮助你解决一些问题的质量关卡。

从这一步开始，我们可以开始对这些质量关卡进行优先级排序，并讨论首先实施哪些关卡最有意义。循序渐进的方法效果最佳 —— 从最关键的关卡开始，然后随着时间的推移，在我们收集反馈并完善流程的过程中逐步扩展。

​​

最后
质量关卡充当着检查点，防止问题在软件开发生命周期（SDLC）中进一步发展。虽然具体的标准可能会因项目和业务需求而有所不同，但拥有明确定义的质量关卡可以确保以结构化的方式交付高质量的软件。

还有一件事我忘了提：为了保证透明度，将这些内容记录下来总是有好处的，把所有事情都摆在明面上，这样也能让新成员更容易参与进来。

你觉得怎么样呢？你的项目中有完善的质量关卡吗？或者你有没有发现一些可以改进的地方呢？祝你好运，愿力量与你同在！

‍