转载请联系作者，谢谢！

• No releases with red tests
  基于 Level1 搭建的持续集成，持续发布选用的 CL(changelist) 就可以取自 CI 系统最后跑通的 CL，因为持续集成中包含了冒烟测试，那么发布到开发或测试环境上的系统，测试关注的是其他类别的用例。

• Require smoke test suite to pass before a submit
  在 Level1 中已经划分出了冒烟测试集，在每次代码审核通过后，开发在提交代码前再次运行冒烟测试，这样保证每次提交代码，冒烟测试都是通过的，节省了后期修复的成本。(不知道你是否遇到过开发提交代码后通知测试可以测了，可是你一访问系统就碰到问题，所以类似的 BVT 是强制的，并且推到每一次代码提交)
  代码审核工具可以定义规则，只有通过冒烟测试后才能成功提交代码到代码库，如果失败，发送邮件给开发。
  

• Incremental coverage by all tests >= 50%
  这一步是真正的需要提交测试代码。你团队的新代码至少要有 50% 是有测试代码的。它没有规定一定是哪种测试类型，也没有规定哪部分代码，也不是每次变更都要有 50% 覆盖率，而是新代码总的覆盖率要有 50%。这样方便团队灵活的决定在何处何时提高测试覆盖率。开发可以通过 TAP 工具跟踪增加的覆盖率。

• Incremental coverage by small tests >= 10%
  新代码小型测试覆盖率至少 10%。从历史数据上看，小型/中型/大型的比例是 70/20/10，这个比率不是硬性规定，可以给各团队作为参考。

• At least one feature tested by an integration test
  虽然小型测试很重要，用来验证各个独立组件是否工作正常，但同时也需要更大的端到端的测试来验证系统功能是否正常工作。这个指标要求至少有一个集成测试来验证一个功能点。比如一个 webdriver 用例来验证 web 应用。

Level2 除了持续发布的配置，后几项都与测试代码相关，从中可以看出，想要获得认证，需要搭建起 UT 框架，填充测试用例；需要搭建 UI 测试框架，并包含一个用例验证一个功能点

• Require tests for all nontrivial changes
  所有变更都需要有对应的测试，这个要求开始需要辛勤的劳动了。换句话说，这也是项目受益的开始。没有测试你无法发现开发过程中的问题，对你的代码修改是否工作没有信心。测试是对代码健康和稳定的投资，部分经验和数据表明，Google 认为测试是一个软件项目专业与否的标志。所以这项指标是团队承诺将测试当作开发流程一部分的关键点。

• Incremental coverage by small tests >= 50%
  小型测试覆盖率至少 50%，这是 Level2 的延续。

• New significant features are tested by integration tests
  新做的大功能都要有对应的集成测试，这个重要功能根据团队自己定义。