夜雨聆风好文翻译，原文链接
https://dev.to/he4rt/metricas-de-qualidade-de-software-na-era-da-ia-334o
我们正处于软件开发领域的一场变革之中，这已不是什么新鲜事——人工智能正在接管越来越多的开发活动。这让我不禁思考：从现在开始，我们将要衡量什么？或者说，我们将以什么作为软件质量的衡量标准？这正是我在这篇文章中要谈论的话题。
在讨论度量指标之前：先了解你团队所处的阶段
在我们正式进入度量指标之前，需要先理解我们团队当前所处的阶段。我完全可以在这里直接丢出一些度量指标，然后让你自动应用到团队中——但这很容易，问题是，这些指标真的适合你的实际情况吗？
我经常对He4rt Developers辅导班的学生们说的一句话是： 我要这个干什么用？ 软件代表着现实世界的需求，因此，衡量软件的成功和品质，在很大程度上取决于它们试图满足什么样的需求。
现在让我们进入度量指标的话题，我喜欢把它们分成两组：
• 面向利益相关者的度量指标 • 面向团队的度量指标
软件质量并不只是缺陷数量的问题——它既体现在最终客户如何接受这个软件，也体现在这个软件是如何被开发出来的。
面向利益相关者的度量指标
在我目前所在公司的这段时间里，尤其是在数字化转型的过程中，我学到的一件事是：向外界展示有多少缺陷被打开或修复，并不能告诉相关人员真正重要的信息——那就是产品质量到底怎么样。为了帮助自己做好这件事，我总是试着站在一个对软件开发周期没有深入了解的客户的立场上去思考。
当一个质量保证工程师或者整个团队来向我展示一个迭代或一个季度的成果时，我最想看到的第一件事是：生产环境中有多少问题——但不仅仅是数量，还有我花了多长时间来解决它们。
平均修复时间（MTTR，即Mean Time to Resolve/Repair）
这是一个著名的度量指标，它显示从问题被发现到在生产环境中被解决所花费的时间。根据你的开发流程不同，这个指标可以有多种衡量方式。如果你的流程是客户先向技术支持报告问题，技术支持进行初步评估，然后问题才交给团队解决，那么你可以在两个时间点进行衡量：技术支持评估问题并给出初步意见所花的时间，以及这个技术支持工单真正变成一个缺陷并进入解决流程所花的时间。
自动化测试覆盖率
另一个值得向利益相关者展示的有趣指标是自动化测试的数量——但是，不能孤立地看这个数字。我想你肯定已经听腻了“99%的测试覆盖率并不代表质量”这种说法，但问题在于，你怎样才能把这个指标呈现给利益相关者，让他们看到你的团队在自动化测试上所做的投资价值呢？
在这种情况下，需要分析的一个重要问题是：测试覆盖率是否真的覆盖到了系统中的关键场景。举个例子：如果在你的情境中，平均修复时间很高，但测试覆盖率也很高，这就意味着你的测试覆盖率并没有覆盖到真正需要被覆盖的地方。
DORA指标
除了上述指标之外， DORA指标 也是帮助进行这种诊断的强大助手。
DORA指标（即DevOps研究与评估，DevOps Research and Assessment，现在是Google Cloud的一部分）最初是为了衡量软件交付性能而诞生的，但实际上，它们就像是整个流程质量的一个温度计——因为那些既能快速交付、又很少出事故的团队，往往都拥有一个构建良好的高质量流水线（包括测试、代码审查、可观测性等方面）。
官方来源：dora.dev —— DORA（Google Cloud）关于区分高绩效团队的度量指标和能力的持续研究。建议直接阅读原始来源，以跟踪模型的最新更新，例如将可靠性（Reliability）作为第五个指标纳入。
部署频率（Deployment Frequency）团队多久将代码部署到生产环境一次。更小、更频繁的部署更容易测试，如果出了问题，也更容易隔离原因——每次部署积累的变更越少，意味着需要调查的变量就越少。部署频率下降可能是团队害怕破坏生产环境的症状，通常是由于对测试缺乏信心。
变更前置时间（Lead Time for Changes，即从代码提交到上线的时间）从一次变更被提交代码库，到它真正在生产环境中运行所花费的时间。变更前置时间过长，往往意味着在耗时的手工验证阶段存在瓶颈，或者因为在周期后期才发现缺陷而导致返工。这个指标能反映出测试是在早期进行的（左移测试，即shift-left），还是只在最后阶段才进行，从而阻碍了交付。
变更失败率（Change Failure Rate）导致生产环境出问题的部署所占的百分比（例如事故、回滚、紧急修复）。这是DORA指标中与测试流程质量关系最直接的一个。它与测试覆盖率直接相关：如果这个指标很高，就意味着你的测试覆盖率太低，或者像前面说过的那样，没有覆盖到真正需要覆盖的内容。
服务恢复时间（Time to Restore Service）在生产环境发生事故后（如回滚、紧急修复、配置修正），平均恢复服务所需的时间。它衡量的是当——不是"如果"——出现问题的时候，团队的反应能力。质量保证工程师可以通过帮助设计回滚测试、功能开关（feature flags）和部署后冒烟测试（smoke tests）来直接影响这个指标，这些措施可以加速问题的发现和回滚决策。
可靠性（Reliability——DORA模型中最新的度量指标）系统在日常运行中满足用户对可用性和性能预期的程度，而不仅仅是在发生事故时。它将用户感知到的质量与非功能性测试工作（性能、可用性）联系了起来——它提醒我们，质量不仅仅是"没有缺陷"，而是系统在实际使用中表现良好。
面向团队的度量指标
面向利益相关者的度量指标对团队了解他们所产出的东西的状态非常有帮助，但有时候，你可能更想看到软件开发过程本身的质量。在这方面，我们可以采用一些更具体的度量指标。
根本原因分析（Root Cause Analysis）
这类指标帮助我们发现软件中或开发过程中发生的问题的规律，并据此制定行动计划。举个例子：如果我遇到很多与需求缺失相关的问题，我就可以在任务中把需求描述得更明确一些，然后过两三个迭代，再来验证这类根本原因是否变得不那么频繁了。
上线前发现的缺陷
你还可以提取一些与缺陷相关的其他指标，比如：在功能上线到生产环境之前，我们发现了多少缺陷？这些数据既可以来自手工测试的执行，也可以来自添加新功能时失败的自动化测试。
返工率
你还可以计算返工率，这个指标既可以帮助你判断缺陷数量是否在上升，也可以在规划中发挥作用。当你的团队通常有10%的返工率时，你就可以和产品负责人在一个迭代内预留10%的余量来处理可能的缺陷。这样一来，规划就变得更现实，预期也更为一致，客户和团队都会更加满意。
结语
面对这场数字化转型，重要的是我们要认识到，有一些度量指标可以帮助我们衡量开发周期和产品质量——而关键在于，它们中的任何一个，如果孤立地看，都无法带来真正的价值。这些指标需要放在一起解读，相互交叉验证，并且始终回到最初那个问题：我要这个干什么用？
随着人工智能提高了代码产出，趋势是我们会在更短的时间内写出更多的代码、交付更多的功能、做出更多的决策。而正因如此，度量将变得比现在更加重要：如果以前一个团队需要几天才能生成一定量的代码，而现在只需几个小时就能生成同样数量，那么错误也可能以同样的速度成倍增加——只是很多时候，这些错误要等到上了生产环境才会被发现。
因此，我认为在这个新场景下，质量保证工程师的角色不仅仅是更快地测试以跟上人工智能的步伐，更是要确保我们在关注正确的数据。光有速度却没有对交付内容的可见性，是毫无意义的。所以，我想留下的建议是：不要把度量指标看作是用来填满仪表盘的数字，而要看作是你的流程通过这些数字向你提出的问题。然后，用人工智能来帮助你更快地回答这些问题——而不是用它来替代提问的习惯。
#软件质量 #AI时代 #DORA指标 #测试覆盖率 #MTTR #数字化转型 #QA角色 #DevOps #根本原因分析 #交付性能
