转载请联系作者，谢谢！
本文简单介绍下 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 是整个生命周期的考量，设计到开发、测试、发布和部署)
我理解的 level1-5 全是建立在自动化体系成熟的基础上，不断改进才得来的一套方法，对我们公司目前先做好 level1，给自己加油！~
进行认证有助于企业形成自己的测试标准，有标准的话，测试才有办法去体现自己的团队价值，同时也有助于帮助研发团队形成良好的质量思维。 这个思想非常值得借鉴。 点赞。
TC 可能是最适合 Google 的，但不一定适合其他公司，思想和经验可以借鉴。可能很多人觉得外国的月亮都是圆的，没必要捧上天
#26 楼 @shenkai600 那本书是老大写的，我是一线战斗人员写体会。
这个在 google 测试之道那本书里不是详细展开过的吗
赞！Debugging sucks, testing rocks. 哈哈
期待详细解读版~
#7 楼 @Lihuazhang 论如何在精华帖上青史留名
特 地 前 来 点 赞。
非常不错的成熟度模型啊。结合自动化测试成熟度模型，测试成熟度模型及实践总结出来的。非常值得借鉴。
我大概看了下，不过我是真心不知道我理解的对不对了。有些还是不清楚。。。
Level 1
-
Set up test coverage bundles
搭建好计算测试覆盖率的模块和系统。但这个我理解应该不仅仅是 code coverage 吧，感觉像是一个整体的体系，具体不明。求告知
-
Set up a continuous build
搭建持续集成
-
Classify your tests as Small, Medium, and Large
测试分类
-
Identify nondeterministic tests
这个不理解，特地去查了下。可见http://martinfowler.com/articles/nonDeterminism.htmlunstable 的 case。。如果正确的话，应该是指那些
-
Create a smoke test suite
冒烟测试
Level 2
-
No releases with red tests
red tests 应该是指自动化测试中的 fail。有 fail 的自动化测试用例就不发布
-
Require smoke test suite to pass before a submit
这个应该类似于以前的 bvt，在每个模块提交之前都应该经过冒烟的 case
-
Incremental coverage by all tests >= 50%
增量代码总用例的覆盖率超过 50%
-
Incremental coverage by small tests >= 10%
增量代码 small 标签的用例覆盖率超过 10%
-
At least one feature tested by an integration test
集成测试至少覆盖一个新功能点。不过这个我不知道理解的对不对。
Level 3
-
Require tests for all nontrivial changes
所有的修改都需要有对应的测试用例集
-
Incremental coverage by small tests >= 50%
增量代码 small 标签的用例覆盖率超过 50%
-
New significant features are tested by integration tests
新增重要的功能点必须经过集成测试
Level 4
-
Automate running of smoke tests before submitting new code
之前的升级版。在新代码 check in 之前一定需要执行自动化 bvt 冒烟测试
-
Smoke tests should take less than 30 minutes to run
冒烟控制 30 分钟以内
-
No nondeterministic tests
没有 unstable 的用例，这也是我觉得最难的
-
Total test coverage should be at least 40%
总体覆盖率至少 40%
-
Test coverage from small tests alone should be at least 25%
small 类型的测试覆盖率至少 25%
-
All significant features are tested by integration tests
所有的重大功能都必须经过集成测试
Level 5
-
Add a test for each non-trivial bug fix
这个我不是很清楚。是为每个重要的 bug fix 增加对应的 case
-
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%
small 类型的测试覆盖率至少 40%
@monkey @Lihuazhang 申明下，我不是针对这篇帖子里的 TC 认证，只是看到这篇帖子引申联想到的。。。
国外的人就喜欢搞方法论，做任何事情都有方法，不仅自己用还卖给别人，通过各种培训、认证、标准。。。大把大把的捞钱。再看看国人啥都是临时的，小公司嘛当然就靠人了，公司做大了发现临时的搞法不行就高薪聘请外国的专家顾问， 说到底这些东西本质上没有啥很高大上的，也都是来自工程实践中的经验总结提炼，只不过被包装了下，我们不知啥时也能学聪明点。。。
卧槽。。我看到了第四项有一个神奇的项目。。。。。我瞬间就懂了。。。。
不过我很好奇，这些 level 是否一个一个高上去的意思？为啥 5 的认证通过会比 4 高
#4 楼 @seveniruby 我也想再加精一次。
收藏下来，好好看_^
评估方法太好
加精理由: 揭秘了 Google 内部对项目质量的一种评估方法. 值得参考学习
果然不一样
不错，对于还没有养成测试习惯的公司或者团队来说参考意义很大。