详细说说 Google Test Certified 的各级——Level 1

转载请联系做者，谢谢！

当你做为初创企业或项目的惟一测试人员，一我的一杠枪，你如何开始测试的工做？你是做为一条孤狼，面对10个甚至更多的开发，努力的作一条龙服务(加班加到死)；仍是想从1到11的转变？

也许你听到过这些话：

 

 

 

 

2006年Google内部2位工程师建立了一个项目叫Testing Grouplet(这是一个20%时间的项目，Gmail就是20%时间孕育的产品)，此项目旨在推进开发人员测试，这是一个文化转变的项目。

 

• 提升对自动化测试重要性的认识
• 经过不断改进测试框架和组件来减轻编写测试的痛苦
• 提供信息和指导开发人员达到良好的测试实践

咱们的座右铭：Debugging sucks. Testing rocks.

 

 

Testing Grouplet下面又包含好几个项目，好比Testing on the Toilet(每周在厕所里贴张测试小技巧)， Design for testability principles(代码可测试性)还有今天要介绍的Test Certified。
以上交代下TC背景，下面开始解说下TC Level 1，如何从0到1。

---

 

 

 

• Set up test coverage bundles

代码覆盖率系统能够识别你运行的测试针对的是哪行代码，这有2个好处，1个能够查看哪些地方须要更好的覆盖，另外一个是能够衡量覆盖率，以便改进。内部基础工具提供了一个代码覆盖工具，只须要在build文件中加上配置，那么在代码审查的时候，代码审查系统会自动计算覆盖率，默认使用的是语句覆盖，若是须要条件/断定覆盖，那么修改配置就好。
Google内部是使用blaze(如今开源了，叫Bazel)来编译代码，只须要配置build文件，对于开发人员来讲没有压力，第一步就这样走出了。

 

• Set up a continuous build
  搭建持续集成，相信不少公司已经这么作了。Google的持续集成系统叫作TAP (Test Automation Platform)，开发每提交一个CL(changelist)， TAP系统就会进行编译和测试。
  可是仅仅是持续集成仍是不够，若是编译失败或是里面的测试失败，须要及时的修复，因此须要从开发人员中征集志愿者来组成一个build cop，及时的处理失败，这样后续的发布系统才能拿到跑绿的Cut CL。

• Classify your tests as Small, Medium, and Large
  将测试分红小型、中型、大型，为何不叫单元测试、集成测试、系统测试呢，这是由于要和系统资源匹配，当在代码中指定测试的size(一个简单的标识)，那么基础工具分配给相应的资源。虽然说Google的服务器分布在世界各地，几百万上千万的服务器分配到内部成千上万的项目后也是紧巴巴的。

   
  
  理想状态下你须要不少小规模快速的测试来覆盖大部分的代码，这样你可以快速的获得运行结果来修复问题。这是一个单元测试养成习惯的过程，随着项目的进展，提交单元测试成为吃饭睡觉同样的天然。

   

• Identify nondeterministic tests
  识别不肯定行测试。对同一个代码运行测试后会获得不一致的行为，可能有几个缘由，好比测试依赖外部系统，测试运行须要某种特定条件(时间或地点)，相互干扰的测试。
  那么你确定不但愿这类测试打断持续集成，这样会浪费时间精力来定位究竟是失败仍是flaky，提早隔离出来单独运行分析。一样的在build文件中能够加入规则。

• Create a smoke test suite
  建立一个冒烟测试集，冒烟测试不能发现全部问题，可是能够保证产品功能主干正常运行，能够发现最大的问题。持续集成加入冒烟测试后按每CL的频率运行，这样团队对产品的信心更强。

---

完成Level 1大概也就1个月的时间，这个过程可让测试人员和开发人员紧密的合做起来，同时也给开发人员不断灌输质量的意识。