做了个手工代码覆盖率，结果被批，原因是采集数据无效
代码覆盖率好像很多公司都有做，包括手工的代码覆盖率，大家是怎么解决手工的覆盖率的有效性问题呢，就是怎么判断覆盖率数据是一个人真正执行用例产生的，还是只是这个开发或测试随便乱点点出来的？
感觉手工的覆盖率比较适合那种 OA 流程，一步步走下来，正常来说人不会乱点。
我们做的产品是报表型的产品，每个页面包括十几个接口，把数据展示出来，只要一进去这些页面，所有请求就全部发出去了。
也就是说，我们的产品只要测试那个人打的数据比较丰富，只要误点某个页面（也不一定是误点，可能是页面之间的跳转），就差不多把这个页面全覆盖了，这手工的结果基本是不可信的，实际上根本没有测，但代码覆盖率很高
大家做的手工测试覆盖率，是不是都基本用 postman 进行一些接口请求，用开关控制上报状态？
感觉手工的覆盖率很难甄别是否有效
覆盖率只能表明有没有执行，无法表明有没有测到。而且就算是测到，也无法说明有没有测全。比较适合不同功能比较分散的场景，对于公共模块比较多的也不一定适合。
从帖主的这个场景看，不大适合用覆盖率。如果操作不多，更多是校验计算出来的数据是否正确，可能做自动化测试，断言写完整些，然后看执行通过率会更好。
代码覆盖率 100%——漏了一个业务场景没做，哪儿说去
个人理解，就算 “误点某个页面” 然后覆盖率很高，那肯定也有很低的情况。做代码覆盖率统计也不是局限于这种特殊的情况，对测试度量也有帮助，可以和测试用例互相校正，例如用例覆盖很全，但是代码覆盖率低。
针对我们实际的测试，依靠代码覆盖率来计算实际测试覆盖度肯定还是不够的，例如空指针，只有我们构造出可以造成空指针的数据，才可以测出来。
所以实际测试中一般是 codereview，sonar 合规扫描，业务逻辑测试，针对接口入参测试等等结合起来
jwos
回复
所以说只是辅助手段，比如如果代码都有遗漏，覆盖率 100% 也无意义，任何一种手段都是为了兜底，多种手段结合才有可能把产品的质量底线提升到可接受范围。
个人觉得覆盖率报告更关注的是没覆盖的部分，而不是已覆盖的部分。而且这些都只是辅助决策的，不能作为唯一参考。如果领导不认可这个的话，下面会做的很痛苦，因为统计覆盖率大都是找测试人员的茬（漏测）。
我们之前也引入了代码覆盖率统计，但是版本迭代差异很大，导致覆盖率数据也有很大的波动。后面我们采取了 2 个办法，一个是只关注增量的 diff 代码，确保 diff 代码的覆盖率可以达到一定比例（取决于语言类型）；另外我们增加了代码实时染色的功能，一个 case 执行之前覆盖率数据清零，执行完一个 case 后，根据 diff 的代码对比刚刚测试过的代码，统计出本次提交的代码完成的覆盖度情况。可以很好的配合手工测试确认本次提交的场景有木有被测到。
代码覆盖率仅供参考，场景覆盖率才是要保证的