谷歌的测试认证：目的与进程

| 2021-01-31

原文发表于 TestHome 社区，

作者：国文

Test Certified(后文简称 TC) 是 Google 内部的一个认证项目，在 8 年的时间里取得了多个里程碑，有 1700+ 的项目注册，其中 1200+ 获得了 1 到 5 级的认证，578 名导师参与。Test Certified 最早起源于 2006 年，通过多年的实践，在 Google 的很多项目中起到了积极的作用，Test Certified 使用 5 个级别的规范来定义一个项目的测试健康度，以此来促进开发人员将测试当作软件开发的一部分，尤其是单元测试。如今这个目标已经达成，TC 在今年光荣的退休了，启用了新的标准——Project Health，也许将来有机会能聊一聊。

什么是 Test Certified？

测试认证项目包含一系列递增的认证级别，每个级别定义了一个可衡量的测试目标。参与的团队达成的目标越多，获得的级别越高 (是不是有 CMMI 的感觉，不过这是一个鼓励开发测试的项目)，它是一个改进测试实践的项目。

为什么 Test Certified？

测试认证计划基于以下一些前提：

越晚发现 bug，修复的成本越高
Google 没有大规模的手工测试团队，即使有，也更愿意通过自动化来解决问题
开发人员测试来提前发现 bug 是一个相对便宜和有效的方式
没有一个 Google 自己的测试标准来让工程团队遵守

我们相信良好的测试方法是有效的软件开发的重要组成部分。测试认证计划是促进测试作为工程团队的一种文化，通过指导来养成工程团队的测试习惯。

你尝试解决哪些问题？

我们想定位出 Google 是否有如下问题：

缺乏工程测试文化。参与测试认证计划团队的增加，可以让其他团队提高对测试的重视。
缺乏标准，团队不知道从哪里开始。通过测试认证的阶梯，我们给团队一个清晰的实现目标的层级结构。
缺乏指导，如何提高团队的测试技能。测试导师、文档和列表提供指南。
我们希望每个团队自己来决定如何以及何时测试他们的代码。

有什么好处？

Bugs 是横在开发者和用户之间的一大障碍，我们花了时间和金钱来创造 Bug ，还要花更多的时间和金钱来定位、研究和修复 Bug 。而测试是已知减少缺陷的良好方式。

改进开发过程，更低的成本，更少的缺陷，更快的发布，更快乐的工程师。

可衡量的改进

下面是参与计划的团队可以获得改进的地方：

更少的紧急发布
更少的失败构建：冒烟测试可以减少发生
更高的产品信心：通过调查反馈测量
更高的变化率：团队克服对变化的恐惧 (拥抱变化，某司的口号)
更少的损坏：404，未处理异常等
降低复杂性
更高的缺陷修复率

测试认证标准 (分为五级)

级别 1

使用测试覆盖率工具 ( Set up test coverage bundles ) 。
使用持续集成 ( Set up test coverage bundles ) 。
测试分级为小型、中型、大型 ( Classify your tests as Small, Medium, and Large )。
明确标记哪些测试是非确定性的测试(Identify nondeterministic tests, 译注:非确定性测试指测试结果不确定的用例)。
创建冒烟测试集合 (Create a smoke test suite) 。

级别 2

No releases with red tests （如果有测试运行结果为红色(译注:表示运行失败的用例)就不会做发布）
Require smoke test suite to pass before a submit （在每次代码提交之前都要求通过冒烟测试）
Incremental coverage by all tests >= 50% （各种类型测试的整体增量覆盖率要大于 50% ）
Incremental coverage by small tests >= 10% （小型测试的增量覆盖率要大于 10% ）
At least one feature tested by an integration test （每一个功能特性至少有一个与之对应的集成测试用例）

级别 3

Require tests for all nontrivial changes （所有重要的代码变更都要经过测试）
Incremental coverage by small tests >= 50% （小型测试的增量覆盖率要大于 50% ）
New significant features are tested by integration tests（新增的重要功能都要经过集成测试的验证）

级别 4

Automate running of smoke tests before submitting new code （在提交任何新代码之前都会自动运行冒烟测试）
Smoke tests should take less than 30 minutes to run （冒烟测试必须在 30 分钟内运行完毕）
No nondeterministic tests （没有不确定性的测试）
Total test coverage should be at least 40% （总体测试覆盖率应该不小于 40%）
Test coverage from small tests alone should be at least 25%（小型测试的代码覆盖率应该不小于 25% ）
All significant features are tested by integration tests （所有重要的功能都应该被集成测试验证到。）

级别 5

Add a test for each non-trivial bug fix （对每一个重要的缺陷修复都要增加一个测试用例与之对应）
Actively use available analysis tools（积极使用可用的代码分析工具）
Total test coverage should be at least 60%（总体测试覆盖率不低于 60%）
Test coverage from small tests alone should be at least 40%（小型测试的代码覆盖率应该不小于 40% ）