dirtyhand-tester 为什么放弃精准测试平台？
看了不少精准测试的文章,我收集如下，这些主要是大厂出品，内容也比较精彩和全面,是了解精准测试比较全面的文章.
- 网易严选的精准测试实践
- 字节跳动精准测试实践，SmartEye 背后的设计逻辑
- 精准测试之过程与实践 | 京东云技术团队
- 走出回归测试困境，爱奇艺精准测试体系建设
- 关于智能化、精准化测试的一切，这 50 个问题我们帮你整理好了！
我摘录一些这些文章中关于精准测试的概念目标的说明：
网易文章的说明:
- 精准测试的概念: 借助一定的技术手段、通过辅助算法对传统软件测试过程进行可视化、 分析及优化的过程，使得测试过程更加可视化、智能、可信和精准
- 精准测试的目标: 非常精确和智能的软件来解决传统软件测试过程中存在的问题,在测试资源有限的前提下，将用例精简到更加有针对性，提高测试效率，有效的减少漏测风险
- 精准测试的核心：双向追溯,代码和用例可以做到匹配和关联，从而实现测试用例的精准覆盖
或者用字节文章中的说明:
在日常的研发活动中，我们经常会遇到下列场景：
- 这次需要研发自测保障了， 我的用例集是不是全都有效覆盖了？
- 这次技术重构改动挺大的，会影响哪些已有功能？
- 基础工具 SDK 有重大升级，我是涉及到的业务方，哪些功能需要测试验证？
- 版本要上线了，大家都走一下全量回归 Case，测试重点在哪里？回归测试用例集全量执行是不是必要的？
- 在项目研发团队中的每个同学质量标准是不是都统一了？
京东云：
精准测试是中国自己有知识产权的完全的理论体系，它同时关注功能点和代码相关逻辑这样一个方法论，是一种灰盒的测试模式。
最开始在 2014 年的国际软件测试大会上发布精准测试的时候，它叫穿线测试，英文名字叫 Threading Test，
表达了精准测试的本质，Threading 这个英文单词本身有两个含义，一个是穿线一个是线程，
建立用例和代码的关系，相当于把黑盒和白盒关联起来，做黑盒测试也能看到白盒数据，同时把开发和测试能够关联起来，测试一做完，
开发的逻辑马上就能自动生成。另一个层面，精准测试最本质就是线程测试，因为精准测试基于覆盖率白盒理论产生，
它跟白盒最大的区别是它的覆盖率是线程级的，也就是说要追溯到用例这个级别。
京东云文章中 Thread testing 的疑问
对于京东云文章中说到精准测试一开始是 threading testing,由于提到是精准测试的起源，想来一开始的目的是比较有意义的，
所以特意查了一下：
thread testing 这个术语 (terminology/glossary) 令人惊讶的在istqb-Standard Glossary of Terms Used in Software Testing
这个网站上查不到,那这个从哪里来？哪个 2014 年的国际软件测试大会上发布？再一查，还是没有查到，可能是我的搜索能力有限再查了一些外网关于这个 thread testing:
Thread Testing is one such type of software testing that is usually
conducted during the early stages of System Integration Testing.
A thread is the smallest unit of work that can be carried out by the system and
it is mainly used to verify the functional capabilities of a specific task or thread.
In thread testing, testers focus on testing individual logical execution paths
in context of the entire system.
几个搜索出处:
综合以上，个人认为 thread testing 不是精准测试的起源，而是如何尽可能尽早的进行主要功能的集成测试，用一个测试 (thread test) 尽可能
覆盖足够好独立的功能. 你说他精准吧，可能也说的通，但是他的定义是集成测试的一种，所以还是集成测试.
关于精准测试解决的问题的疑问
总结以上几个文章我总结的一些我自己认为精准测试要解决的问题:
- 没有办法精确定义改动需要跑哪些 Case，如果每次都全跑太浪费时间成本高
- 对改动进行测试之后，没有办法进行评估，评估所做的测试是否已经全部覆盖了变化
看了这些文章之后，这些精准测试系统主要实现的思路都是:
- 收集代码变化，确定代码对哪些接口有影响
- 收集执行测试用例之后的代码覆盖率数据，确定哪些代码覆盖没有做到
- 使用可视化的方式展示哪些代码变化，哪些接口可能有影响，推荐哪些用例
以上我觉得都很好，但是在小公司，自己的疑问就是:
- 做一个这个精准测试的平台成本是多少，收益是什么？
- 关于代码变化，有哪些影响，人工沟通和检查是否可以确认？
- 如果都是通过系统推送出来，然后人工确认，那么和直接人工对着代码确认相差的成本和收益是什么？
- 如果单独到一个接口的变化，如果有全量的接口自动化，那么这个接口变化，是否可以自动触发全量接口的回归测试？成本在哪里？ 为什么还需要额外进行精准测试？
- 精准测试平台对于有漏侧可以承担责任吗？如果每一个测试只是负责自己熟悉的一小块，代码 review 可以替代这些精准测试吗？
- 还有通过代码分析的方式去了解调用链路可以现在已经有日志追踪系统了或者类似的 skywallking 这种可以追踪调用链的工具， 为什么还要自己写一套从代码开始的实现？不应该生产的调用链路更能表示实际使用情况，从而从实用和准确
考虑以上的一些问题不能得到回答，还是觉得放弃精准测试平台这个路，可能做好一下几点就足够了:
- 接口变化： 通过追踪接口定义文件就可以了解，无论是 swagger 还是 openapi 格式，这个追踪变化的实现要比代码层的实现成本低很多
- 接口有变化，全量接口回归测试，这个是无脑操作，没有成本
- 新的测试用例的新加和影响范围的评估，通过和开发沟通，查看代码也可以达到，毕竟自己负责系统，也挺熟悉的，分析出来的结果可能也会进行再加工和讨论 并不能减少多少成本
- 用例管理起来，可以知道哪些是高优先级用例，如果需要全面重构，精准测试和全量回归工作量预计相差不会太大，而如果只是 1，2 个接口的改动， 选择高优先级用例和 review 之后的结果需要的用例也能满足，或许精准测试会再提供一些提示，但是这些提示从文章中我没有看到哪些特殊情况特殊的点容易 遗忘的，所以我判断其实可能也不会太多这样的 Case，因为可能特殊点再测试用例库里面就没有，如果测试用例库里面有，那么在选高优先级用例的时候也能包含
- 针对回归测试的代码覆盖率或许有用，但是文章中还是没有实际的例子来说服我代码覆盖率可以发现的 Case 不在高优先级用例场景覆盖中的
所以最后还是放弃精准测试平台这个路，管好测试用例，做好接口自动化，做好代码 review 和开发沟通或许是目前最合适的方法。
题外话
既然查了一下相关内容，然后一时对于代码插桩这个描述，是在不知道是个什么东西，最后查了一下，英文是: code instrumentation 这个
不确定为什么要翻译成代码插桩，但是我也不知道翻译成什么好， 就是叫成代码插桩感觉哪里不对,不能叫代码测量吗？
In software engineering the need for secure and high quality software has spurred intense
research activity in the areas on software debugging, testing and constraint analysis.
Code instrumentation is a common technique used to track application behaviour.
The most popular usages for code instrumentation are software debugging,
performance analysis, monitoring, distributed computing and aspect oriented programming.
Typical instrumentation techniques provide information about code coverage during software testing activities.
Current approaches make use of instrumentation by inserting additional code that monitors the behavior of a specific component.
This thesis presents and applies two novel approaches that use an instrumentation technique:
(1) A Runtime Debugging approach is aimed at detecting and resolving runtime faults in object-oriented code.
The approach relies on bytecode instrumentation in order to provide code coverage for predefined unit tests.
The results are analysed using Reverse Engineered techniques. The approach consists in merging both succesfull and
faulty code execution traces and detecting the faults by analysing the differences in the output traces.
(2) A Security Constraint Checking approach uses the notion of security consistency in designs. Byte code instrumentation techniques are used to provide code coverage for selected unit tests. Direct acyclic graphs are constructed from the output traces using reverse engineered techniques. The graphs contain object method calls in a similar manner to UML Sequence Diagrams. This approach uses the results of the instrumentation to check for consistency with design generated security constraints. Furthermore this approach analyzes these views for
security inconsistencies, and generates a set of recommendations.
点赞，没有蛮目跟从
先说题外话：
instrumentation 有控制仪器的含义，instrumentation 也是 javaagent 机制当中两个入口 premain 和 agentmain 函数中，由 jvm 提供的操作句柄，通过他可以设置自定义的类字节码转换器，从而实现对代码的插桩，但这并不是 inst 的全部，具体不在展开
再聊聊一些个人观点
1.关于精准测试平台的作用，我们现在是开发做一份变动影响分析，测试做一份变动影响分析，精准测试平台再根据规则算出来一份，三份互相查漏补缺，从而努力达成 “尽量把变动的影响分析全了” 的这个目标
2.为了实现上述的目标，精准测试平台需要存储和计算，这就要求了一定的代码能力，产品思维，和对技术框架，业务规则甚至软件测试本质的洞察，是需要有一定的积累才能进行一些尝试的东西
3.采用注入 skywalking 等遵循 OpenTracingAPI 这样的全链路监控工具固然好，但也不是所有公司的产品都是 Java 微服务的形式，也有单体，也有 C/C++ 的服务，有时候，应用内调用链也是关注的一部分，在此目的上，做代码调用链路分析这个目标其实并不冲突，并且，代码调用链路分析这个事儿，本身并不复杂，就是个会者不难难者不会的问题
我其实一直有这个疑问，以前精准测试说是为了精准定位到哪个接口改动然后执行对应的自动化用例，但是全量自动化用例执行真的没多少成本，并且自动化用例都是半夜时跑的，所以还真挺好奇一开始提出这个概念的人，是怎么说服大家的
小狄子
回复
我觉得这些都没有问题，我只是考虑我自己实际的情况分析，同时想看看如果要做怎么做成本更低，
- 比如你说 OpenTracingAPI，Skywalking 只是一个例子，事实上如果一个公司多语言的话，我第一反应链路 Trace 会比从代码 AST 解析出来分析要方便，否则你每个语言来一套？
- 而追踪接口变化，我第一反应也是觉得通过 API Spec 文件差异更容易实现，而我们确实也是多语言也使用 API Spec 先行这种方式进行开发，所以我觉得没有必要去做 AST 方式或者 Parse 代码方式去实现；
- 至于内部调用链和 Opentracing API 个人理解没什么冲突，如果 Tracing ID 一直传下去，直到返回，远程和内部调用没多大区别，至于是不是 JAVA 微服务，问题是我看到的例子大部分 code instrumetation 都是用 JVM 做例子，JACOCO 做例子的，如果是 JAVA 微服务，反而我觉得可能成本相对低一些，毕竟很多人都做了这个，至于其他语言的，我不确定成本会到哪里
- 另外就是关于精准的判断遗漏，工程师还是会加入，那么你说为了防止遗漏，我觉得没问题，只是我们可能还没到这个程度，公司小选择相信人，毕竟最终你还是要工程师做决定，那就考虑省去这部分平台建设
- 代码调用链路分析这个事儿，本身并不复杂，就是个会者不难难者不会的问题， 这个肯定的，几乎所有的问题都这样
测试新人
回复
那大概是业务体量还不够复杂。
公司内某业务回归几万条用例，几个外包测几天才能回归完成，如果精准测试能将这几万条缩减成几千条，就可以省了若干外包的人力成本。多出来的人力可以考虑裁掉节省开支，也可以拿来支持其他业务需求，还是很划算的。
另外，精准的作用不能只是捞对应的自动化用例，手工用例也应该捞出来。否则这个精准测试就做得很有问题了。
王稀饭
回复
业务体量还不够复杂，这个确实，不过呢也不算太简单，同时业务体量这个东西很有迷惑性，是指功能多？还是指用户量多。如果用户量多，其实呢不一定用例多。业务复杂，使用人少，也可能用例很多，所以这个光一句业务体量不够复杂本身就不够清晰.
公司内某业务回归几万条用例的问题，需要精准测试，但是呢，重复的多少？没人愿意去重新搞搞清楚的可能也是有的？
另外为什么要全量回归呢？不是拆分了微服务了吗，不是敏捷小步快走吗？那么如果还是动一下要几万个 Case，那么微服务的意义在哪里，敏捷的意义在哪里，是不是先反思一下领域拆分问题？
如果精准到几千条，那我想问下，如果直接通过优先级是 P1-P2 的过滤一下筛选，几万条能过滤到几千条吗？然后这个几万条用例，一条用例的定义是什么？是一个步骤还是一个场景？
个人觉得更全面的了解一下实际情况对我做决定很有帮助，所以多问几个问题。先谢过！
我也分享下放弃继续搞精准测试平台的经验。
原因有以下几点：
- 花了半年搞了个雏形用了几下就没有再用了。——原因就是不如全量跑，都跑也花不了多久
- 用来衡量用例质量（手工 + 测试）的目的，因为维护成本巨大而放弃，原因有项目结构因素、人员素质参差不齐等
现在有点后悔，后悔原因如下：
- 作为自己的产物之一，被我自己否掉，领导觉得我没有成果
- 衡量用例质量，可以做的更自动化和简单，可惜我放弃了，没有继续深入做
有些东西，虽然实际用的时候很鸡肋，但是给 PPT 撑下内容还是 OK 的，有时候不能从纯技术方向来分析做事的意义。。。
之前有过试运行大概两个月，效果不好。
一个是成本太高了，其结果都是人工在检查，一个版本仅一个服务大量的变更一个个看过去头都大，更不要说其他服务了，然后变更没覆盖到的都是一些兜底异常的逻辑，不走单元测试基本测不到，最后结果就是聊胜于无
第二个是对检查的人要有基本的代码能力要求，看不懂的人光看没覆盖到的只会去找研发问为什么哪里漏掉了，久而久之兴趣就下去了就没人搞了
王稀饭
回复
“精准的作用不能只是捞对应的自动化用例，手工用例也应该捞出来。否则这个精准测试就做得很有问题了” 这句话说到点子上了，精准的很大的一部分作用是减轻手工回归的压力，节省的人力可以投到其他方面，但是现实是很多所谓的精准测试只是筛选自动化用例，落了下乘，但是为什么不去筛选手工用例呢，不是不想，而是干不了，很多地方手工用例管理的很差，用例质量也参差不齐，存在的形式也多种多样，如何与精准测试关联也存在很多问题。
其实不仅是精准测试、还是各种效能平台，不建议小团队去搞，想搞这个起码要有研发部门一把手这样级别的领导支持，有一个实力尚可的测开团队才行，如果就测试团队几个人闭门造车，最后的结局就是一个 kpi 项目（当然 kpi 项目也是有意义的），很难落地，不如多找几个外包，多写几条接口自动化来的实际。
我理解的精准测试是一个很泛的东西，目前我们主要做了 2 个落脚点：1. 代码覆盖率统计（主要看变更）2. 代码影响入口统计（先不说上下游）。
这 2 个东西对我们团队的质量影响都非常深远，是有实实在在收益。
我简单提 2 个常见场景，你们也看看这 2 个场景在自己团队发生的概率大不大，风险大不大。
场景 1： 开发需求外改动，例如他重构了某个方法，但是没告知你这块有改动。
场景 2： 开发改了 1 个方法，这个方法被多个接口调用，有部分接口不在你这个需求改动内。
这 2 种场景，均会出现未经过测试上线而导致的问题，分析后它们可能均属于测试范围判断不准确，1 属于你不知道开发的改了啥 2 是你知道开发改了啥，不知道影响了啥。
那这 2 个问题如果不通过精准测试，你可能需要怎么去预防，无非就是你需要 CR 代码，你也得对研发代码熟悉，自己能通过 code diff 发现，但显然这对大多数测试来说是门槛巨高的。
那我刚提到的精准测试 2 个落脚点，就是能很好预防和降低问题发生，有了精准测试，那这 2 个场景在我们团队可能场景就会这样。
场景 1 ，测试发现他执行完了测试，但是还是有未覆盖的代码，能力强自己就做一层分析，能力弱点他可以跟研发确认，这个改动方法是干啥的，为啥我测试覆盖不到，我需要补充什么用例呢，这时开发可能就说，哦，这个是啥啥啥的，我做了优化，是啥啥啥功能的。
场景 2，测试根据精准测试给出的影响的接口，这时一个改动模块外的接口在列表里面，测试自然就判断到这个入口也受影响，进而进一步是否需要覆盖验证。
当然一切，还得建立一个完善的质量门禁，合理设置门禁值等一系列看似和精准测试无关，但他又影响到精准测试出成绩的动作。
最后补充下，平台研发成本和使用成本。
研发成本:
我们代码覆盖率基于滴滴二开，当然我们做了很多改动了，包括精准到方法覆盖率的清空等等并和 CICD 等打通，我们从立项到第一个版本上线前后端各自 1 个，大噶 3 个月周期，当然后面我们陆陆续续还加了很多功能和优化，入口推荐同样前后端各自 1 个，前后不到 1 个月就上第一个版本了。
使用成本：
这东西很难定，但随着我们各平台打通，交互上优化完善，目前最大的成本不在平台使用，而是 QA 发现无法覆盖的代码，做判断或者找研发确认，这个成本反而是最大的，但！！！！ 这是必须的！！！
有个东西，叫变更管控， 变更管控中最重要的就是代码变更管控，如何管控这块， 精准测试 - 代码覆盖率就非常重要。
至于很多讲的， 例如 通过代码变动推荐用例，这块难点怎么做到 代码和用例的关联关系。 难，但是也不是不可能，理论可行。 我们不做任何的用例和点关联， 我们只做影响入口判断出来后，把影响入口的自动化全部自动执行一遍。
再提一个，精准测试中代码覆盖率对我们统计的一个落脚点：我们把代码覆盖率和自动化测试打通，我们能给出每次执行自动化的服务的代码覆盖率。 也许你会觉得花里花哨，但是我认为他也是一种考量你自动测试覆盖率的一个重要指标。
为啥感觉你这一段看着好像互联网黑话
，没有恶意，能展开详细讲讲嘛，比如 沉淀到流量池，数据血缘，沉淀出知识图谱，代码大模型的能力加持（用的啥模型？啥部署方式呢），
个人观点，不喜可喷
- 对很多的行业，精准测试是个谎言，并不能带来实质性的帮助，可能可以有些白盒测试的辅助作用，仅此而已，能否精准测试和被测系统的结构设计关系太大，能够被精准测试的系统，质量风险也不大，例如基本简单的增删改查系统，不能被精准测试，不敢被精准测试的系统质量风险也高，比如 ERP，物流系统，复杂工业软件
- 自动化测试本质就该在某种策略设计下尽量全量的跑，分批的跑，覆盖那些你没识别到和开发也没评估到的问题，至于自动化的运行时间的解决，可以通过并行执行，加机器等解决，这些做好了都能带来更好的收益
- 你的测试模型是什么决定了怎么做精准测试，几个人能透彻的讲清楚针对一个系统的测试模型是什么？大部分对系统的分析是个 NP 问题，是不确定的，不可准确归类的
米阳MeYoung
回复
代码覆盖率统计，这里是包括单元测试，集成自动化测试，手工测试么？
光这个覆盖率的 merge 就劝退了大部分公司了。
在本地生活的时候，搞过一段时间类似的精准，一开始感觉挺有收益的，后来并行大了，连执行常规用例都要加班了，就顾不上了。
有时候挺感叹，如果人力充足，时间充足，各种测试方法论都非常可行，但是现实就不是这样。
simonpatrick
回复
业务体量复杂，肯定是基于业务架构和业务链路来说的复杂，和用户量没有关系。
典型如大厂里平台性质的业务，拿大家都知道的淘宝天猫来说，app 抽象起来就是一个平台，上面承载这五花八门各个团队的业务，而这些业务之间也不完全是互相独立的，常常是网状关系，技术和业务多少有关联。这种情况下就可以定义为业务体量复杂。
假设现在就是一个数字计算器工具 app，即使成千上万的人在使用，它一样是一个很简单的技术实现，从代码量、调用链路、技术结构、开发人员等各个维度来说都不复杂。【但是呢，重复的多少？没人愿意去重新搞搞清楚的可能也是有的？】我没有很理解在问哪一方面，是指回归用例是否存在重复吗？我猜测可能会有但是不多，因为回归用例要定期 review 保鲜，增加或删减回归用例是经常的事情。
这个质疑出发点是好的，至于别人的业务是不是这样就不清楚了。【为什么要全量回归用例】，首先这几万条用例本身并不是全量用例，它就是经过筛选的回归用例，很不可置信对吧
，我也这么觉得。
另外这是客户端形态的业务，回归测试是端到端的行为，也就是从客户端做测试执行，一并覆盖到业务视角的重点服务端链路。发版好像是三周或一个月一次。
可能楼主对服务端更熟悉，下意识认为这个是服务端的回归。但往往 ToC 的业务，更重视客户端回归，因为面向用户的就是一个客户端或 app。服务端回归相对简单，想什么时候跑接口自动化就什么时候跑，只要保证环境隔离，不太需要绑定具体的时间节点或者外部配合。
业务拆分就如上所说，一个平台类型的 app，不可能一个团队回归，比如淘宝直播有直播的团队回归，钱包优惠券有支付的同学回归……，所以这个几万条用例也可能不是一个团队的用例。优先级概念的确很有用，但是优先级概念是业务视角出发的一种概念。精准测试是技术视角出发的概念，本质是面向任何变更，回归用例的精简只是它一个落地场景，它和按优先级砍用例在结果上有一定相似与重合，但是在过程上不是一回事。
肯定不能说 “对于所有代码变更，我一律只跑 P0-P2 的用例，业务就没有质量问题” 对吧？同理，精准测试是一种门槛更高的补充手段。这里说的用例，都是指一个完整的测试执行和断言过程，精细到具体操作，这些基本概念我理解大家都是对齐的。
恒温
回复
嗯， 所以这里又涉及到代码分支模型管理，例如你多个版本合并一块测试，又分开上线，那这个覆盖率一会合一会分，确实都很头疼。 但是，这再我们这边基本不存在，不是所我们没需求并行，而是我们也做了这块治理。 其中涉及到质量流水线治理，我们控制着提测和上线的出入，我们覆盖率根据自动生成的 release 分支生成，不同需求会生成不同的 release 分支，版本并行多了，release 分支多了，避免互相抢占环境，我们又做了环境治理上做了多泳道，不同需求不同泳道服务，不同覆盖率不互相影响，同一个服务的一次版本我们手工或者定时拉取覆盖率是做自动合并的，下个版本或者并行版本 release 分支不一样了，自然不会互相干扰。
恒温
回复
精准测试的代码覆盖率能很好落地执行，几乎 0 成本使用，得益于 1. 统一的研发架构 2. 统一的 CICD 打通 3. 质量流水线 - 分支模型的推广 4. 软路由多泳道环境的具备。 这些有各自的作用，又促进了代码覆盖率的易用性。
测试新人
回复
其实最关键的就是去砍手工用例，正如大家说，自动化用例执行本身就不会花费多少人力，所以砍自动化用例不痛不痒。跟手工用例关联的重点就是覆盖率录制，录制这个行为确实有成本，但是大体还是可控的，看业务情况可以不定期录制。
如果单独到一个接口的变化，如果有全量的接口自动化，那么这个接口变化，是否可以自动触发全量接口的回归测试？成本在哪里？ 为什么还需要额外进行精准测试？
我之前也是有同样的疑问，精准测试推出来的用例，本质就是部分用例与全量用例执行的区别，为什么还要费时费力做精准测试系统，除非全量用例执行需要很长时间，但接口测试正常情况下能跑一个小时，已经到了几千个用例级别。
一切为了面试，好不好用不晓得反正我上家公司做了
Ouroboros
回复
那真的是挺可惜的，现在一些头部证券、银行、智能工业都在使用。前期人工将测试用例录入确实挺麻烦的，对接自动化就挺简单，如果自动化程度不高，前期应该先看覆盖率，不做用例和代码的一一绑定，启动录入工具后，把这个阶段的测试用例全部执行，然后再结束录入。这样同样可以看到漏测和软件的覆盖率，一样可以提高软件质量，没有什么成本，先出个成果，给领导看看。之后在搞用例和代码的一一绑定。
其实你们都在着重考虑后端的精准实现了。能否再进一步实现前后端的精准打通？
上面有人也提到，精准的最终不仅仅是要关联到自动化用例，手动的也要关联到，但是维护成本太高。
那是否可以这样，后台的代码逻辑关联到各个接口，再通过前端调用接口的逻辑，与前端关联起来，在整理一套前端的映射（如安卓下的，登录接口与 loginactivity 绑定）， 手动用例也标明用例所属的 activity，从而达到手动用例的关联关系？
测试新人
回复
手工用例录入不精确，自然精准测试平台推荐的用例就不正确。通常精准测试平台是有功能（异常监控、聚类分析等）对录入的测试用例进行分析，防止测试用例与代码不对应。
巅九
回复
还能对录入用例进行分析？ 这是用了什么方法做到的。就例如一个价格输入的范围是 1 元到 10 元，现在开发修改了边界值判断改为 0.1 元到 100 元。精准测试根据开发的改动推荐的是价格边界值限制验证的用例，但这里面其实还有个相关逻辑，就是如果购买了 10 元的最大值，就随单赠送礼品。现在最大值改成 100 了，但这个需求的相关功能用例是被归类到下单功能里的。那这种情况能分析到吗？（当然一般的设计都是读取配置，不会写死，我这里就是大概举例一下）
测试新人
回复
可以分析。例如聚类分析的方式，例如测试人员要执行一个 90 元的测试用例，这种情况下是会随单赠礼，在执行录入时，测试人员误操作，少输入一个 0，输入成 9 元，录入完成后，也测试人员没有发现。经过聚类分析后，这个 90 元的用例会显示在 10 元以下的测试用例集中。这时就可以揪出这个有问题的测试用例录入。
Barry250
回复
精准测试现在可以进行前端到后端的全链路的追踪。例如前端是网页、移动 APP 等等，语言是 JS（JS 原生、Vue、React……），后端是服务器，语言是 Java、C/C++。一条测试用例它从前端到后端的代码运行轨迹全部追踪。所以说精准测试是系统级测试，不单单是一个子系统、库或微服务。跨微服务、跨线程的用例也是可以追踪。并且最终展示的覆盖率可以是整个软件的覆盖率，也可以是分开展示。
文章也许是对的，但是 现实不能这么操作，兄弟们还得吃饭，得找点活给大家。这是一个能保住兄弟们饭碗的立项。
我们之前做了一个事情，只有 Android 端。就是统计变更代码的覆盖率，发现没有覆盖的，再针对去覆盖。如果是做成很自动化，再关联用例，那成本其实很高。所以能找出告诉你未覆盖的部分就很有用。
0 .
我写过一篇文章《为什么要做精准测试？》，和你这篇要唱对台戏了，不过涉及到很多内部技术，无法发出来，
米阳MeYoung
回复
我们公司也是基于滴滴的 super-jacoco 做了二开，但是目前遇到几个问题：1、业务用例已经执行，但是涉及的类代码却未覆盖，查了些资料说是 Spring AOP CGLIB 代理导致的 jacoco 统计不到，我不知道你们这块怎么处理的？（确实用到了 CGLIB 反射）2、我们是敏捷的开发模式，一个需求在同一套测试环境上会多个版本多次部署，如果 1 版本的 A 类测试完后收集代码覆盖率；假设过程中发现实现逻辑不对，这时候 A 类中做了修改，重新打版本 2 部署测试后再收集覆盖率，我们现在是做了 2 次的合并，但是发现代码覆盖率的合并结果是不对的，针对以上 2 个问题请教下是如何解决的呢？号
米阳MeYoung
回复
这 2 个场景与我的实践经验结论很接近，我也补充一些场景，展开说说最近 2 年和精准沾边的实践落地情况。
场景 1： 开发需求外改动，例如他重构了某个方法，但是没告知你这块有改动。
场景 2： 开发改了 1 个方法，这个方法被多个接口调用，有部分接口不在你这个需求改动内。
补充场景 3：新迭代来了一些需求，原来项目增加了一些新的代码，哪些是新增、变动的代码？这部分测的怎么样？哪些测过了，哪些没测过（聚焦在新迭代范围内的精准）。
以上 3 个场景，我们已经做到了代码与用例对应，就是说，每一个 CASE 都有一个执行 CASE ID，这个 ID 对应一个用例，同时，对应相关应用下，走过这个 CASE 的代码的覆盖率。
以上 3 个场景在功能测试、接口测试的工作中，确实是有收益的。但不容易落地，通用性也不是很好，主要是指，不一定能在不同的团队中都发挥好的作用，他对于接入系统本身是否合适有比较大的依赖性。
难落地的主要问题有以下几点：
1）有些团队不搞自动化，没办法在每个迭代里都保证全部代码的覆盖率到一定的百分比。
2）有些团队测试是 A 外包公司，开发是 B 外包公司，平时工作很忙，沟通日常工作还好，但沟通怎么落地这个 “精准” 很难。推起来比较累，推新工具反而增加了了他们原有的工作量，质量收益也没那么高，意愿也不大。但凡这种测试和开发不是一家公司的，普遍都是搞了几个月后不搞了。
3）有些团队就算搞自动化，用例维护也受不了，比如开发来了个什么公共框架的底层代码修改，瞬间几百个接口自动化运行直接变异常，随后团队无奈只能选择一小部分自动化作为回归用例，导致精准覆盖率的数据变得不好看，同时也失去了很多价值和作用。
4）对于不搞自动化测试的团队，也尝试配套推广落地了一套流量回放的工具，想办法省去接口化的脚本编写，对于有些团队来讲有用，对于有些团队来讲，作用不大（视业务类型、系统架构等多方面因素），并且流量回放的工具有些时候还需要开发 mock 掉一些有状态的代码，前期开发也需要参与接入流量回放的工作，成本不低，培训成本也高。
5）精准覆盖率不够虽然能反应测试不充分。但覆盖率足够，也不代表测试一定没问题，比如有些异常处理逻辑，开发根本没考虑到，代码都没写全，你覆盖率再充分，但场景没想到，bug 还是会泄露。所以还是依赖测试本身自己发现问题的能力。有些领导认为，精准测试只是辅助，告诉你哪里测少了。有些领导认可，有些领导认为不性价比不高。
所以上述这些问题都是 “精准测试” 的前提条件，想把 “精准测试” 真正用起来，用的有价值，等于需要建设一个配套的系统，还需要有一股较大的推力。先要让精准能够出来数据，随后还要配套各种分析报表和降低分析成本的功能开发。同时还得看团队成员的结构、现有测试方式以及领导意愿。虽说这 3 个场景有价值，但为了得到这些价值，前期投入的成本和收益比却可能非常低，短期也不见得看得到好的效果，使用或者不使用精准对于线上 bug 泄漏数量减少这笔账也没几个人能说的清。这些问题都是我们在参与落地 “精准测试” 时碰到过的一些问题。
刺猬
回复
针对覆盖率合并的问题我已经解决了，可以查看我的帖子https://blog.csdn.net/qq_34418450/article/details/135386280?spm=1001.2014.3001.5502
如果测试用例特别少的情况下精准测试的确没啥意义，全量跑一遍不香吗？但如果说我的测试用例数是百万级别的，这个价值才显现出来。哈哈。。
之前我们做过一个，是这样的。只做了 Android 端，只是一个检查工具，测试照常测试，系统会告诉你测试的代码层级的覆盖，你再看哪些没覆盖到，为什么没覆盖，需不需要扩大测试覆盖。