测试管理 谈谈 Google 的 Test Certified

oscarxie · 发布于 2016年08月23日 · 最后由 davidyang 回复于 2017年09月22日 · 最后更新自管理员 monkey · 1533 次阅读
本帖已被设为精华帖!

转载请联系作者,谢谢!

本文简单介绍下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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 35 条回复
605

不错,对于还没有养成测试习惯的公司或者团队来说参考意义很大。

11264

果然不一样

104 seveniruby 将本帖设为了精华贴 08月23日 18:20
104

加精理由: 揭秘了Google内部对项目质量的一种评估方法. 值得参考学习

118

评估方法太好

6853

收藏下来,好好看_^

110

#4楼 @seveniruby 我也想再加精一次。

118

不过我很好奇,这些level是否一个一个高上去的意思?为啥5的认证通过会比4高

118

卧槽。。我看到了第四项有一个神奇的项目。。。。。我瞬间就懂了。。。。

4035

国外的人就喜欢搞方法论,做任何事情都有方法,不仅自己用还卖给别人,通过各种培训、认证、标准。。。大把大把的捞钱。再看看国人啥都是临时的,小公司嘛当然就靠人了,公司做大了发现临时的搞法不行就高薪聘请外国的专家顾问, 说到底这些东西本质上没有啥很高大上的,也都是来自工程实践中的经验总结提炼,只不过被包装了下,我们不知啥时也能学聪明点。。。

110

#10楼 @defias 这个和国内国外没关系吧。这里说的TC也不是各种培训、认证、标准。谷歌还是比较少出来推广他们的方法论的。

118

#10楼 @defias 此言差矣。方法论是方法论,但要实践出来,要体系化还是很难的。就如恒温说的,Google的东西还是很有价值的,而且并不是什么培训,认证等。Google的这套TC其实套在各种项目,企业中还是很有借鉴意义的,而且也有很多的缘由在其中。这就和后面说的PH一样

4035

@monkey @Lihuazhang 申明下,我不是针对这篇帖子里的TC认证,只是看到这篇帖子引申联想到的。。。

118

我大概看了下,不过我是真心不知道我理解的对不对了。有些还是不清楚。。。

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%

899

#10楼 @defias 这个方法论转换的吧,有点不一样,你可以从第一级开始看起。其实可以看成测试检查项。

115
oscarxie · #16 · 2016年08月24日 作者

#10楼 @defias 这个不是方法论,这是实践,里面有很明确的目标,是开发一眼就看得懂的,我们就是要抛弃CMMI,RUP,敏捷等那样的繁文缛节(文中没提是不想引起误会),使用简单可达成的列表。这个是Google内部总结出适合自己的指南,供大家参考

—— 来自TesterHome官方 安卓客户端

115
oscarxie · #17 · 2016年08月24日 作者

#14楼 @monkey 等我后面再写个逐条解释吧

—— 来自TesterHome官方 安卓客户端

119

非常不错的成熟度模型啊。结合自动化测试成熟度模型,测试成熟度模型及实践总结出来的。非常值得借鉴。

113

特 地 前 来 点 赞。

104

#10楼 @defias 你说的那些认证是国内那些机构在忽悠. 国外这些优秀的公司是没推认证的. 他们又不靠这个挣钱.

104

#7楼 @Lihuazhang 论如何在精华帖上青史留名

5694

期待详细解读版~

96

#14楼 @monkey 给陈劳斯手工点赞!

5819

赞!Debugging sucks, testing rocks. 哈哈

133

这个在google测试之道那本书里不是详细展开过的吗

115
oscarxie · #27 · 2016年08月25日 作者

#26楼 @shenkai600 那本书是老大写的,我是一线战斗人员写体会。

6469

TC可能是最适合Google的,但不一定适合其他公司,思想和经验可以借鉴。可能很多人觉得外国的月亮都是圆的,没必要捧上天

115
oscarxie · #29 · 2016年08月26日 作者

#28楼 @quqing 欢迎大家来分享自己公司的成功经验。

1419

进行认证有助于企业形成自己的测试标准,有标准的话,测试才有办法去体现自己的团队价值,同时也有助于帮助研发团队形成良好的质量思维。 这个思想非常值得借鉴。 点赞。

110

#28楼 @quqing 我觉得这个tc适合所有全攻全守的研发团队。

5819

#14楼 @monkey

这个我不是很清楚。是为每个重要的bug fix增加对应的case

每个(重要的)bug都是由于测试点的遗漏
其实也就是要求补充这个测试点的case

其实自动化测试或者单元测试好说
手工测试的话,可操作性没有那么强了,至少我接触过的测试团队没有能做好这一点的

118

#32楼 @cyj86 的确,这个是比较难做的。

5819

@oscarxie

非常好的指导,有一点不太清楚,请指点!

文中多次提及 integration test
手工功能测试包括在内么?
还是说这套准则完全是针对自动化测试或者单元测试的呢?

12204

#34楼 @cyj86 我的理解 都是指自动化测试吧

110 Lihuazhang Mobile Testing@Google 演讲的感受 中提及了此贴 07月17日 01:17
1925

我理解的level1-5全是建立在自动化体系成熟的基础上,不断改进才得来的一套方法,对我们公司目前先做好level1,给自己加油!~

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册