覆盖率能到多少也和项目源码的情况有关, 像我们项目里就有一些代码不可能或是不需要覆盖的代码, 比如没有被任何地方调用的 (没被注释掉), 开发写的测试方法, 异常处理部分等. 除去上面这些, 能覆盖的尽量覆盖到
效益上, 首先还是回归测试速度快, 增加了新的功能了, 可以立即跑一遍. 其次一些复杂的功能, 走正常的功能逻辑可能很费劲才能测试到, 编写覆盖脚本要快速的多. 覆盖的同时也可能发现新的测试点, 或是开发没有考虑到的异常情况处理等

41% 指的是覆盖代码行数占比？那还不太够，许多异常场景都没考虑到

别想靠自动化发现 bug，你这个思路是不对的

觉得这个行覆盖率做到什么程度，才能真的有收益呢？

感觉你的方向反了，应该是为了得到 xx 收益，因此在行覆盖度上需要达到 xx 水平。目标应该是获得 xx 收益，而不是行覆盖度达到多少。

如果发现提高全量代码的行覆盖率没有获得收益，建议要复盘分析下这些原来没覆盖，现在覆盖的代码是否存在质量风险，如果大部分通过阅读代码，就可以确认没啥风险或者风险很小，那费劲覆盖它也只是求个心安而已，很难获得很大的收益。建议是先阅读未覆盖部分的代码，找到风险大的部分再针对性覆盖，同时做好覆盖后其实也发现不了 bug 的风险预期，控制好投入。

另外，对于 “发现更多 bug ” 这个收益目标，用覆盖率作为手段可能性价比不大高。要在测试阶段发现更多 bug ，应该考虑引入更多、更复杂但实际可能出现的场景。从这个点出发，可以考虑怎么提高测试设计能力进而设计出更全面的用例、引入内部其他人员体验测试等让测试过程中可以覆盖更多意想不到但可能出现的场景、提高程序可测性（说大白话就是多加一些能让场景模拟更简单的后门）让你可以更方便地注入各种想要的异常。技术上则可以引入随机测试（比如移动端的 monkey 测试、遍历测试）、模糊测试 (fuzz testing)、混沌工程等手段快速创造更多的异常场景。

要想避免做了之后得不到收益，建议是一开始多花时间思考预期能获得的收益和可能得不到收益的风险，衡量好投入收益比再做。虽然是句正确的废话，但要真正做到还是得花一些功夫的。