这 2 个场景与我的实践经验结论很接近，我也补充一些场景，展开说说最近 2 年和精准沾边的实践落地情况。

场景 1： 开发需求外改动，例如他重构了某个方法，但是没告知你这块有改动。
场景 2： 开发改了 1 个方法，这个方法被多个接口调用，有部分接口不在你这个需求改动内。
补充场景 3：新迭代来了一些需求，原来项目增加了一些新的代码，哪些是新增、变动的代码？这部分测的怎么样？哪些测过了，哪些没测过（聚焦在新迭代范围内的精准）。

以上 3 个场景，我们已经做到了代码与用例对应，就是说，每一个 CASE 都有一个执行 CASE ID，这个 ID 对应一个用例，同时，对应相关应用下，走过这个 CASE 的代码的覆盖率。

以上 3 个场景在功能测试、接口测试的工作中，确实是有收益的。但不容易落地，通用性也不是很好，主要是指，不一定能在不同的团队中都发挥好的作用，他对于接入系统本身是否合适有比较大的依赖性。

难落地的主要问题有以下几点：
1）有些团队不搞自动化，没办法在每个迭代里都保证全部代码的覆盖率到一定的百分比。
2）有些团队测试是 A 外包公司，开发是 B 外包公司，平时工作很忙，沟通日常工作还好，但沟通怎么落地这个 “精准” 很难。推起来比较累，推新工具反而增加了了他们原有的工作量，质量收益也没那么高，意愿也不大。但凡这种测试和开发不是一家公司的，普遍都是搞了几个月后不搞了。
3）有些团队就算搞自动化，用例维护也受不了，比如开发来了个什么公共框架的底层代码修改，瞬间几百个接口自动化运行直接变异常，随后团队无奈只能选择一小部分自动化作为回归用例，导致精准覆盖率的数据变得不好看，同时也失去了很多价值和作用。
4）对于不搞自动化测试的团队，也尝试配套推广落地了一套流量回放的工具，想办法省去接口化的脚本编写，对于有些团队来讲有用，对于有些团队来讲，作用不大（视业务类型、系统架构等多方面因素），并且流量回放的工具有些时候还需要开发 mock 掉一些有状态的代码，前期开发也需要参与接入流量回放的工作，成本不低，培训成本也高。
5）精准覆盖率不够虽然能反应测试不充分。但覆盖率足够，也不代表测试一定没问题，比如有些异常处理逻辑，开发根本没考虑到，代码都没写全，你覆盖率再充分，但场景没想到，bug 还是会泄露。所以还是依赖测试本身自己发现问题的能力。有些领导认为，精准测试只是辅助，告诉你哪里测少了。有些领导认可，有些领导认为不性价比不高。

所以上述这些问题都是 “精准测试” 的前提条件，想把 “精准测试” 真正用起来，用的有价值，等于需要建设一个配套的系统，还需要有一股较大的推力。先要让精准能够出来数据，随后还要配套各种分析报表和降低分析成本的功能开发。同时还得看团队成员的结构、现有测试方式以及领导意愿。虽说这 3 个场景有价值，但为了得到这些价值，前期投入的成本和收益比却可能非常低，短期也不见得看得到好的效果，使用或者不使用精准对于线上 bug 泄漏数量减少这笔账也没几个人能说的清。这些问题都是我们在参与落地 “精准测试” 时碰到过的一些问题。