原文由 国文 发表于 TesterHome 社区，原文链接
最近几年业内各大厂商的效力研发建设热火朝天，获得长足进展，每年 MTSC 大会效力专场更是常常爆满。
几年前写过谈谈 Google 的 Test Certified，之后迁延症发生始终没介绍，这次就聊聊 Project Health(我的项目衰弱度简称 PH)。
概述
总体目标是通过在软件生命周期晚期发现问题和低效率来进步工程生产力，包含开发、测试、公布和部署。
[](https://testerhome.com/upload…!large)
我的项目衰弱指标将用于计算我的项目的衰弱程度，通常分为以下几类：
间接指标：是否存在测试以及它们是否在应用中？
效率：工具和流程是否无效？（工程师不太可能常常应用慢速工具。）
负面影响：是否存在能够通过晚期发现来预防的问题？
PH Level
依据外部工具定义了一个可主动获取的指标集，既能展现整个我的项目的级别，也能显示具体某项指标的级别。
[](https://testerhome.com/upload…!large)
Presubmit Tests (预提交测试)
测试能够发现问题的最早阶段是在提交代码之前。咱们应该激励运行预提交测试，激励我的项目在这个阶段应用关闭的、隔离的、小的和疾速的单元测试，因为如果开发人员不得不期待很长时间，那么他们更有可能跳过这些测试。
- tap-greenness 继续集成通过率
这是一个间接指标，高水平的绿色通过率表明单元测试失去踊跃保护，放弃这个指标绿色意味着缩小开发人员的挫败感。
预提交通过，才能够提交代码，同时继续部署零碎 Rapid 能力从最近的绿色 CL(Changelist) 构建版本。
注：TAP 是 Test Automation Platform 简称，Google 外部继续集成工具平台 - tap-flakiness 继续集成不稳定率
如果继续集成中的测试常常不稳固，它们不仅不能提供明确的胜利或失败指标，而且会耗费额定的资源，升高对 TAP 状态的信赖并导致工程师疏忽测试后果。存在的不稳固测试越少，就越容易检测到真正的故障。 - presubmit-coverage 预提交测试覆盖率
冀望预提交测试覆盖率比拟高，因为预提交中大量测试是单元测试。 - presubmit-ignored 预提交测试疏忽率
冀望预提交测试被疏忽的测试越少越好 - presubmit-latency 预提交测试提早
掂量提交前测试执行工夫
Test Coverage (测试覆盖率)
- absolute-coverage 全量测试覆盖率
- incremental-coverage 增量测试覆盖率
Releases (公布)
- release-duration 公布距离
单个公布周期破费的均匀持续时间，这里也蕴含了公布过程的手动阶段。 - release-granularity 公布粒度
统计每次公布蕴含的代码变更数，更短的公布周期引入的代码变更会更少。 - release-cherrypick-count 公布打补丁次数
现实状况下咱们心愿每次公布都能顺利的通过测试后上线，然而如果发现重大问题，咱们可能会采取回滚、打补丁或者从新公布一个版本，这项指标用来统计打补丁引入的代码变更数。
GCP 我的项目的概览
[](https://testerhome.com/upload…!large)
Test Certified 比照 Project Health
我的项目衰弱度是施行测试认证规范的一个子集，旨在通过关注能够主动计算和更新的指标和信息源来建设产品或我的项目的健康状况。要想获取一个我的项目或产品更残缺的状态，须要逐渐引入更多的信息。
[](https://testerhome.com/upload…!large)
参考
Google Cloud Platform 的实际，GCP: Move Fast and Don’t Break Things (Cloud Next ’19)
PPT：https://speakerdeck.com/ankitmehta/gcp-move-fast-and-dont-break-things
视频：https://www.youtube.com/watch?v=xCKfiCSNjaw
播种前沿测试开发技术 · 学习先进品质治理方法 · 结识测试大咖和行业精英 ↓↓↓