聊聊 Google 的 Project Health

2022-02-25 本文已影响0人 TesterHome

原文由国文发表于TesterHome社区，原文链接

最近几年业内各大厂商的效能研发建设如火如荼，取得长足进展，每年 MTSC 大会效能专场更是经常爆满。
几年前写过谈谈 Google 的 Test Certified，之后拖延症发作一直没介绍，这次就聊聊 Project Health(项目健康度简称 PH)。

总体目标是通过在软件生命周期早期发现问题和低效率来提高工程生产力，包括开发、测试、发布和部署。

直接指标：是否存在测试以及它们是否在使用中？
效率：工具和流程是否有效？（工程师不太可能经常使用慢速工具。）
负面影响：是否存在可以通过早期发现来预防的问题？

根据内部工具定义了一个可自动获取的指标集，既能展示整个项目的级别，也能显示具体某项指标的级别。

测试可以发现问题的最早阶段是在提交代码之前。我们应该鼓励运行预提交测试，鼓励项目在这个阶段使用封闭的、隔离的、小的和快速的单元测试，因为如果开发人员不得不等待很长时间，那么他们更有可能跳过这些测试。

tap-greenness 持续集成通过率
这是一个直接指标，高水平的绿色通过率表明单元测试得到积极维护，保持这个指标绿色意味着减少开发人员的挫败感。
预提交通过，才可以提交代码，同时持续部署系统 Rapid 才能从最近的绿色 CL(Changelist) 构建版本。
注：TAP 是 Test Automation Platform 简称，Google 内部持续集成工具平台
tap-flakiness 持续集成不稳定率
如果持续集成中的测试经常不稳定，它们不仅不能提供明确的成功或失败指标，而且会消耗额外的资源，降低对 TAP 状态的信任并导致工程师忽略测试结果。存在的不稳定测试越少，就越容易检测到真正的故障。
presubmit-coverage 预提交测试覆盖率
期望预提交测试覆盖率比较高，因为预提交中大量测试是单元测试。
presubmit-ignored 预提交测试忽略率
期望预提交测试被忽略的测试越少越好
presubmit-latency 预提交测试延迟
衡量提交前测试执行时间

release-duration 发布间隔
单个发布周期花费的平均持续时间，这里也包含了发布过程的手动阶段。
release-granularity 发布粒度
统计每次发布包含的代码变更数，更短的发布周期引入的代码变更会更少。
release-cherrypick-count 发布打补丁次数
理想情况下我们希望每次发布都能顺利的通过测试后上线，但是如果发现严重问题，我们可能会采取回滚、打补丁或者重新发布一个版本，这项指标用来统计打补丁引入的代码变更数。