首页 > 代码库 > 详细说说 Google Test Certified 的各级——Level 2,3

详细说说 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
      新做的大功能都要有对应的集成测试,这个重要功能根据团队自己定义。

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