谈谈 Google 的 Test Certified

转载请联系做者，谢谢！

本文简单介绍下Google的Test Certified。

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

 

 

 

TC Level	# Projects
1	564
2	316
3	204
4	97
5	122

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

为何Test Certified？
测试认证计划基于如下一些前提：

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

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

你尝试解决哪些问题？
咱们想定位出Google是否有以下问题：

• 缺少工程测试文化。参与测试认证计划团队的增长，可让其余团队提升对测试的重视。
• 缺少标准，团队不知道从哪里开始。经过测试认证的阶梯，咱们给团队一个清晰的实现目标的层级结构。
• 缺少指导，如何提升团队的测试技能。测试导师、文档和列表提供指南。

咱们但愿每一个团队本身来决定如何以及什么时候测试他们的代码。

有什么好处？
Bugs是横在开发者和用户之间的一大障碍，咱们花了时间和金钱来创造它，却还要花更多的时间和金钱来定位、研究和修复它。而测试是已知减小缺陷的良好方式。
改进开发过程，更低的成本，更少的缺陷，更快的发布，更快乐的工程师。
(这里老调重谈，由于是06年定义的你懂得就好)

可衡量的改进
下面是参与计划的团队能够得到改进的地方：

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

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

 

 

Level 1

• Set up test coverage bundles
• Set up a continuous build
• Classify your tests as Small, Medium, and Large
• Identify nondeterministic tests
• Create a smoke test suite

Level 2

• No releases with red tests
• Require smoke test suite to pass before a submit
• Incremental coverage by all tests >= 50%
• Incremental coverage by small tests >= 10%
• At least one feature tested by an integration test

Level 3

• Require tests for all nontrivial changes
• Incremental coverage by small tests >= 50%
• New significant features are tested by integration tests

Level 4

• Automate running of smoke tests before submitting new code
• Smoke tests should take less than 30 minutes to run
• No nondeterministic tests
• Total test coverage should be at least 40%
• Test coverage from small tests alone should be at least 25%
• All significant features are tested by integration tests

Level 5

• Add a test for each non-trivial bug fix
• Actively use available analysis tools
• Total test coverage should be at least 60%
• Test coverage from small tests alone should be at least 40%

为何退休

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

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