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