详细说说 Google Test Certified 的各级——Level 2,3

转载请联系做者，谢谢！

 

 

 

• 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
  新作的大功能都要有对应的集成测试，这个重要功能根据团队本身定义。