@seveniruby 您好，已修改，请审核

单元测试是最基础，投入产出比最高的测试，CI 连单元测试都没有，确实是蛮遗憾的事情。

测试是否稳定，确实是能否进入 CI 的重要条件

感谢支持！！！

实现层面是另外一个话题，大家感兴趣的话我可以另写一篇文章讲述背后的技术栈

谢谢支持！

不支持的东西多着呢，我能说数学符号公式都不支持么

谢谢支持 -:)

代码覆盖率确实很基础，也很客观。把重心放在代码覆盖率上面是可以的。尤其是如果能够把黑盒测试的代码覆盖率给搞明白就更好了

谢谢意见！缺陷覆盖率确实有点 KPI 的意思，见过把这个作为测试团队成绩向领导请功的

在我们这里，是通过 tag 实现的。每个需求会有编号，每个测试用例都会打上 tag，标记的是对应的需求的编号。这样，哪些需求被哪些用例被覆盖到，哪些需求没有用例覆盖，就比较清楚的。例如，Robot Framework 就支持给用例添加 tag：https://stackoverflow.com/questions/22314808/how-do-you-add-tags-to-data-driven-tests-in-robot-framework

敏捷确实让人很难停下来歇息会，节奏太快了。

谢谢支持！

谢谢大佬指教 "Rayleigh Distribution"看起来蛮厉害的，我去了解下。

说明下，标题里的框架具体指的是单元测试框架。

谢谢留言。CI 的内容确实因项目差异很大。我们目前的 CI 包括静态检查 (语法/代码风格/复杂度/重复度等)，单元测试，单元测试覆盖度检查，组件测试，集成测试，以及基于真实硬件的冒烟测试。基本上除系统测试之外的各级别测试都包含进来了。有一点要说明的就是在代码合入前和代码合入后，CI 都需要执行，而且执行的内容差不多。

苦逼啊，说多了都是泪

好吧

有道理，说有价值容易，能算出价值多大就难了

@ 思寒_seveniruby 你好，已修改。

好像邀请我了？申请开通专栏。

有道理

补充一下，其实文章还漏了一种调试手段，那就是设置断点进行单步调试。例如：pdb。

装饰器大法好!

谢谢支持;)