对于精准测试，有人或者团队做过并成功落地的吗？网上看到一些介绍的思路，不知道大家各自的落地情况如何。
M
没有
目前的阶段成果：测试团队愿意自主且自助的使用精准测试能力（基于内部基础设施搭建了一个比较简单的平台），用于每轮系统测试过程的评估，我们不做覆盖率的卡点，只希望测试人员能够结合被测版本的增量报告来补充测试场景（发现有变更代码没覆盖，就去分析原因，如果觉得需要补充测试场景，就去补充然后继续执行）。
精准测试应该也挺多东西的，你理解的精准测试是啥样的？
我们之前招了个 jd 的精准测试专家，结果来了不会测试，只会整活
据我有限的圈子内得到的反馈是大部分没有落地的， 极少数有落地的地方，业务团队都反馈效果不好。 这也是没办法的事情，精准测试这个东西很多人都把目光聚焦在了调用链分析和 AI 上，聚焦在了用例推荐上。 但很多人都忽略了一个网络段子 -- 人工智能是有多少人工就有多少智能。 这个段子虽然有失偏颇但其实也说明了人工智能是建立在大量的人工作业的基础上。 比如拿精准测试来说，推荐用例的前提是测试团队维护了非常精准的用例库，这些用例会随着研发代码和产品需求的更新而更新。 光是这一点其实 9 成 9 的团队就做不到。 还有就是产品的需求和代码架构非常频繁的变动的，如何建立起一个自动化的自学习（自动拉取最新数据最新代码并进行模型训练，并进行指标更新进而更新模型）也是一个非常大的工程（用人工的方式维护模型是肯定不行的）。并且很困难，比如监督学习的数据是要打 label 的（总结一下就是哪部分代码对应哪条或者哪些测试用例），目前大部分的 AI 团队都要花费很大的成本建立标注团队去人工打 label。 如果这些问题都解决了， 还需要面对人性， 就是这些用例推荐不是 100% 准确的（AI 做不到 100% 的精准与召回），如果推荐错误，导致线上出问题，那么谁来背锅？ 目前所有团队的做法是业务测试人员背锅， 那么问题来了，我用你的东西， 你的东西不保证准确，出了问题要我自己来背锅。 那么我为什么要用你的东西？
所以其实精准很难落地，不是因为大家普遍看到的 AI 和代码分析这样的技术问题。 而是要面对海量用例的维护问题，人工标注数据问题，模型更新问题和人性问题。
综上所述， 以我有限的圈子得到的结果， 能把精准落地而且业务反馈非常好的团队，我暂时还没见到。
孙高飞
回复
太对了 很多 ppt 吹得很好 搞得公司都想玩 但是一瞅用例 写的人都看不明白 还想和代码挂钩？
但是 ppt 里是不会特地强调这个前提的，说实话，我觉得能搞成这个的，真是屈指可数
太长不看：前团队的同事最近几个月成功在内部某大型业务里落地了。
精准测试方案，基本都是围绕这测试覆盖率和代码调用链技术做各种手段。标准的精准测试方案，无论是服务端还是客户端，大多都离不开前期的人工成分，比如客户端的关键思路是通过录制用例的方式将覆盖的代码路径和这个测试用例绑定起来，最后通过代码路径上的变更感知来推荐对应用例，可以是手工用例，也可以是 UI 自动化用例；同理服务端也大差不差。
之所以不好落地是因为 “录制” 这个事情本身就有很大成本，再加上历史录制的用例还要定期更新，意味着还有不小的长期维护成本，除此之外甚至还有 “打标” 等更多人工成本在里面，除非项目足够的大且足够的稳定，不然效果很差。至少据我所知，在字节跳动内部，头条、西瓜、抖音这些 app 都没有大范围落地这种标准的精准测试。
再来说我身边的成功案例，是一个非标准的精准测试方案。回到精准测试本身，无非是想通过某些手段将执行的用例数量删减到一个合理范围，从而聪明地降低测试工作量的同时还能保证相近的测试效果。这个落地业务本身有国内国外版本，之前的策略是两个版本发版都需要全量回归用例，通过落地精准测试，在国内版本依然全量回归的前提下，针对国外版本只做 diff 上的回归（这里就涉及国内国外版本的差异的引入源，主要是 编译配置、Feature Gateway、差异化文件标记等，方案是如何识别到这些差异源关联的功能，在细节上也会有各种人工保证的前提，没说起来那么简单与智能），最后每个版本节省了 “海量” 回归人力。
而这个精准测试案例，最重要的是它带了业务特性，相比于标准的方案，它满足了更多前提条件，需要解决的问题不需要那么 “广泛”。
定制化的有，通用的少。咨询师的 ppt 里都有无数的落地案例。
搞不了，你看我的发的帖子，我应该算推的比较早的了。
我遇到的问题，没有人担责。
什么意思呢？
开发说，这个全量测一下，我们精准查一下，发现只要做 30%，那么老板会问，真的只要 30% 么？出了问题算谁的？
咨询师的诸多案例里面，无一例外的走了 testcase-code-mapping 的路子，这种本来就不该成功，成本大过天，落地个毛线，repost 一下历史观点：
我这边还会有个问题，我是银行，很多项目组之前会存在数据依赖。
那就需要一套完全的可控的造数手段，这意味着你要去完全了解下游系统，或者他们配合你。
基本没这个可能。
所以我现在搞的一些精准都是一些面子工程了。
实施过一段时间的精准测试，通过覆盖率数据反推用例优化等，但最后坚持不了太久。
主要会面临几个实际的问题
- 沟通成本、能力成本等问题。 中小型公司的 QA，功能 QA 的代码能力很弱，习惯点点点，分析代码倒推用例弥补一个是增加额外工作量，一个是对他们有能力要求，此外复杂业务逻辑代码部分还需要和开发 GG 聚焦才能分析。
- 可靠性问题。 版本增量代码未覆盖补充用例后，全覆盖不等于 没 BUG。即覆盖率作为准入标准或卡点是不可靠的，它是个锦上添花的作用。
- 每轮测试后分析覆盖数据的成本问题， 同上。
不确定我们做的算不算。
目前有一套检测增量代码系统，可以检测到两个 commit 之间的差值，进而找到对应影响的接口。
拿到这批接口后，我们会重跑 jvm-sandbox-repeater 录制到的接口请求。
目前这套已经接到持续集成中了，每次开发部署代码之后都会和线上版本进行对比，跑一遍涉及到的旧接口。
但是局限性还是比较大，只能说有点帮助，但是不多。
目前正在推进中，只打算做到覆盖率的增量报告展示，用来做测试辅助。 后面的调用链分析和用例关联不打算搞。
自己开发了一个 java 代码改动影响范围分析工具，也是检测到两个 commit 之间的代码改动，进而找到对应影响的接口，感兴趣可以试用一下，github 地址：https://github.com/baikaishuipp/jcci
我们是用了滴滴开源的 jacoco，做了一个功能测试覆盖率统计的平台
csl
回复
感觉我也是这样的，属于人肉精准测试吧。。。但是他们想做的好像是更高大上的东西，通过模型，算出代码变更时，需要用到哪些测试用例。。。。
我们的精准测试体系已经落地了，现在在效率工程团队用了一年多了。通过使用精准测试，评估需求改动范围，解析调用链路，精准定位影响范围；根据变动，推荐需要回归的用例，大大提高了测试效率；同时，在测试完成后，又可以通过全量和增量报告分析测试的覆盖率，增量了测试的信心。
孙高飞
回复
"推荐用例的前提是测试团队维护了非常精准的用例库，这些用例会随着研发代码和产品需求的更新而更新" 。 这句话太对了，不要说用例了，就产品需求文档和产品都是不断变动的，传统的用例维护都没办法真正做好，很多测试用例还是测试完成后补充的，半年后迭代几个版本就基本荒废了。感觉精准和 UI 自动化一个样，只能用在不频繁版本迭代的项目里，但是话又说回来，都不怎么迭代了，搞精准干嘛、、、、、、
测试新人
回复
必须有啊，漏测率是一个基本的指标，还会统计增量覆盖率，召回率，精确度，筛选率等精准测试的基本指标。通过相应的指标评估测试质量，对比每轮测试的效率，各个版本的测试质量等等吧！
做了两三个月，精准覆盖率与全量时的覆盖率一致， 准备落地项目，项目组停了
实际使用中感觉基本上没有用
推荐用例我都用了 3 年了，我不觉得录制的成本有多高。
一个有代表性的需求录 1-2 个用例，录 1 个用例也就 1 分钟的时间。录用例的时机就是在功能测试阶段，功能测的差不多了就录一个 general 的用例，当然，用例的描述要清晰，数据、环境、步骤、需求描述都要完善。
BTW，即使不做用例录制，测试人也得做用例基线整理吧？如果连用例基线都不整理，就不要搞精准测试了，连基本的测试素质都不具备。
另外一个问题，代码一直变，用例库会越来越大。是的，每个版本都要录用例，这时推荐的用例要有精简的算法，考虑的因子包括用例的新鲜程度，覆盖 diff 方法的数量等等，经验看用例的新鲜程度是最重要的。
再另一个问题，要尽量减少无效方法的干扰，例如去掉网络的方法，关注跟业务线强相关的方法。精准测试不是全部有效，只是部分有效，部分有效我理解为跟自己具体业务团队强关联，就会有 hard code。试图做一个超级大的系统去解决所有问题感觉不太现实。
