转载请联系作者，谢谢！
当你作为初创企业或项目的唯一测试人员，一个人一杠枪，你如何开始测试的工作？你是作为一条孤狼，面对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个月的时间，这个过程可以让测试人员和开发人员紧密的合作起来，同时也给开发人员不断灌输质量的意识。