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

乔梁 | 2021-01-31

原文发表于 TestHome 社区,

作者:国文

链接:谈谈 Google 的 Test Certified

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% )

TC 为什么退休

  • 团队成员的测试习惯已经养成
  • 标准是静态的,级别达成后团队可能没有再进一步的动力,甚至项目实际情况已经降级了
  • 大部分项目到了 level 3 就不动了
  • Project Health 出现了,全自动(无需人工干预)且动态的(每天)考量项目的健康度,覆盖整个生命周期的考量,设计到开发、测试、发布和部署。

参考: https://mike-bland.com/2011/10/18/test-certified.html