• 问题一 怎么解决这个成本和收益的问题呢?

    在平台落地过程中, 我们也发现单测的成本问题, 不仅是研发侧为提高单测覆盖率付出的实际编码成本, 更是研发侧对覆盖率指标的质疑。

    我们摸索出的可行模式: 收窄覆盖率指标, 看的见的收益

    1. 从整个Repo的覆盖率指标收窄为热点代码块的覆盖率指标, 热点代码块的来源是根据线上代码执行的频率选取的
    2. 从历史代码问题导致的Bug中, 统计出能在单测阶段发现的问题, 并以此形成单测改进规范, 推动规范落地 这样达到的目的就是让研发侧真切的感知到, 你的单测覆盖是真正跟线上功能和故障捆绑在一起的, 而不是一个KPI指标。

    问题二 单测的覆盖率目标是怎么做到合理的设定?

    从以下几个维度考量设定:

    1. 当前项目单测实际情况
    2. 当前项目的是否为核心服务
    3. 当前项目本季度的业务开发繁忙情况
    4. 覆盖率指标选取(行/方法/分支...)

    总结下来就是: 在不影响业务开发情况下的一个够得着的覆盖率指标。

  • 如何保证软件质量 at June 14, 2020

    如果想了解如何从数据维度衡量代码质量,建议您看看https://testerhome.com/articles/24210

  • 看来您也是行家,感谢支持~

  • 没有实践过,但我认为可以这么做:每个SDK独立插桩,独立调用接口上报覆盖率信息,独立维护sourcemap进行映射。依赖SDK的总工程,是没有办法帮助已编译的包插桩的

  • 在我们的工程实践中,是的。但具体用法参考这个啦:https://github.com/istanbuljs/babel-plugin-istanbul

  • Author only
  • 覆盖率平台开发实践 at June 02, 2020

    原生的jacoco是按class info来区分exec文件,如果测试阶段的代码一个是A分支,一个是B分支,如果这两个都是从同一个父分支上clone下来的话,那这俩分支merge是没有问题的,如果这两个源分支不一样,merge的时候就会失败。。所以这其实应该是个代码规范问题,因为一般来说都是从master上拉下来几个分支,然后开发在上面开发自己的代码,测试的话就部署这些开发分支测试,这样的分支是可以merge的,而且因为咱们的覆盖率是按不同环境来的,一般一个环境下的merge是没有问题的,如果要把不同环境比如stable和sit环境的覆盖率merge,我这里还没测试过,目测是不行的😳

  • 覆盖率平台开发实践 at May 29, 2020

    平台提供了merge功能,测试同学可以选择把srint开始到结束的覆盖率merge起来,拿到的就是一个完整的覆盖率数据。

  • 覆盖率平台开发实践 at May 29, 2020

    速度大概在一分钟左右,但是因为咱们的手动环境下的任务比较多,有时候cpu比较满的时候可能要花上五分钟左右等待队列。

  • 说说我的理解:

    • nyc 是新版 istanbul,解决了大量istanbul存在的问题
    • nyc 和 istanbul 都用于【本地运行,本地统计覆盖率】的场景
    • istanbul-middleware 是 istanbul 的一个 用于【多端运行,在服务端统计覆盖率总和】的场景

    然后说说问题:
    istanbul有问题,一般报告和实际覆盖的行,往往有一两行偏差。我们对比过 coverage 和报告中的覆盖行数确实是一样的,因此我们怀疑 babel-plugin-Istanbul 太旧,如果工程用到较新的babel/webpack编译时,插桩可能就不太准确

    如果我理解没错的话:

    • 你贴的 Repo 似乎仅做了单元测试,属于【本地运行,本地统计覆盖率】的场景,这并不需要用到 middleware。升级nyc是没毛病的选择
    • 但 nyc 未提供 middleware,对于【多端运行,在服务端统计覆盖率总和】的场景,我暂时没有什么好的解决方案

    不知道我理解对不对,你有什么好想法我们可以接着讨论

我们是酷家乐质量效能团队。