看了不少精准测试的文章,我收集如下，这些主要是大厂出品，内容也比较精彩和全面,是了解精准测试比较全面的文章.

• 网易严选的精准测试实践
• 字节跳动精准测试实践，SmartEye 背后的设计逻辑
• 精准测试之过程与实践 | 京东云技术团队
• 走出回归测试困境，爱奇艺精准测试体系建设
• 关于智能化、精准化测试的一切，这 50 个问题我们帮你整理好了！

我摘录一些这些文章中关于精准测试的概念目标的说明：

网易文章的说明:

• 精准测试的概念: 借助一定的技术手段、通过辅助算法对传统软件测试过程进行可视化、 分析及优化的过程，使得测试过程更加可视化、智能、可信和精准
• 精准测试的目标: 非常精确和智能的软件来解决传统软件测试过程中存在的问题,在测试资源有限的前提下，将用例精简到更加有针对性，提高测试效率，有效的减少漏测风险
• 精准测试的核心：双向追溯,代码和用例可以做到匹配和关联，从而实现测试用例的精准覆盖

或者用字节文章中的说明:

在日常的研发活动中，我们经常会遇到下列场景：

• 这次需要研发自测保障了， 我的用例集是不是全都有效覆盖了？
• 这次技术重构改动挺大的，会影响哪些已有功能？
• 基础工具 SDK 有重大升级，我是涉及到的业务方，哪些功能需要测试验证？
• 版本要上线了，大家都走一下全量回归 Case，测试重点在哪里？回归测试用例集全量执行是不是必要的？
• 在项目研发团队中的每个同学质量标准是不是都统一了？

京东云：

精准测试是中国自己有知识产权的完全的理论体系，它同时关注功能点和代码相关逻辑这样一个方法论，是一种灰盒的测试模式。
最开始在 2014 年的国际软件测试大会上发布精准测试的时候，它叫穿线测试，英文名字叫 Threading Test，
表达了精准测试的本质，Threading 这个英文单词本身有两个含义，一个是穿线一个是线程，
建立用例和代码的关系，相当于把黑盒和白盒关联起来，做黑盒测试也能看到白盒数据，同时把开发和测试能够关联起来，测试一做完，
开发的逻辑马上就能自动生成。另一个层面，精准测试最本质就是线程测试，因为精准测试基于覆盖率白盒理论产生，
它跟白盒最大的区别是它的覆盖率是线程级的，也就是说要追溯到用例这个级别。

京东云文章中 Thread testing 的疑问

对于京东云文章中说到精准测试一开始是 threading testing,由于提到是精准测试的起源，想来一开始的目的是比较有意义的，
所以特意查了一下：

1. thread testing 这个术语 (terminology/glossary) 令人惊讶的在istqb-Standard Glossary of Terms Used in Software Testing
   这个网站上查不到,那这个从哪里来？哪个 2014 年的国际软件测试大会上发布？再一查，还是没有查到，可能是我的搜索能力有限

2. 再查了一些外网关于这个 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.

几个搜索出处:

• professionalqa-thread-testing
• geeksforgeeks-thread-testing

综合以上，个人认为 thread testing 不是精准测试的起源，而是如何尽可能尽早的进行主要功能的集成测试，用一个测试 (thread test) 尽可能
覆盖足够好独立的功能. 你说他精准吧，可能也说的通，但是他的定义是集成测试的一种，所以还是集成测试.

关于精准测试解决的问题的疑问

总结以上几个文章我总结的一些我自己认为精准测试要解决的问题:

1. 没有办法精确定义改动需要跑哪些 Case，如果每次都全跑太浪费时间成本高
2. 对改动进行测试之后，没有办法进行评估，评估所做的测试是否已经全部覆盖了变化

看了这些文章之后，这些精准测试系统主要实现的思路都是:

1. 收集代码变化，确定代码对哪些接口有影响
2. 收集执行测试用例之后的代码覆盖率数据，确定哪些代码覆盖没有做到
3. 使用可视化的方式展示哪些代码变化，哪些接口可能有影响，推荐哪些用例

以上我觉得都很好，但是在小公司，自己的疑问就是:

1. 做一个这个精准测试的平台成本是多少，收益是什么？
2. 关于代码变化，有哪些影响，人工沟通和检查是否可以确认？
3. 如果都是通过系统推送出来，然后人工确认，那么和直接人工对着代码确认相差的成本和收益是什么？
4. 如果单独到一个接口的变化，如果有全量的接口自动化，那么这个接口变化，是否可以自动触发全量接口的回归测试？成本在哪里？ 为什么还需要额外进行精准测试？
5. 精准测试平台对于有漏侧可以承担责任吗？如果每一个测试只是负责自己熟悉的一小块，代码 review 可以替代这些精准测试吗？
6. 还有通过代码分析的方式去了解调用链路可以现在已经有日志追踪系统了或者类似的 skywallking 这种可以追踪调用链的工具， 为什么还要自己写一套从代码开始的实现？不应该生产的调用链路更能表示实际使用情况，从而从实用和准确

考虑以上的一些问题不能得到回答，还是觉得放弃精准测试平台这个路，可能做好一下几点就足够了:

1. 接口变化： 通过追踪接口定义文件就可以了解，无论是 swagger 还是 openapi 格式，这个追踪变化的实现要比代码层的实现成本低很多
2. 接口有变化，全量接口回归测试，这个是无脑操作，没有成本
3. 新的测试用例的新加和影响范围的评估，通过和开发沟通，查看代码也可以达到，毕竟自己负责系统，也挺熟悉的，分析出来的结果可能也会进行再加工和讨论 并不能减少多少成本
4. 用例管理起来，可以知道哪些是高优先级用例，如果需要全面重构，精准测试和全量回归工作量预计相差不会太大，而如果只是 1，2 个接口的改动， 选择高优先级用例和 review 之后的结果需要的用例也能满足，或许精准测试会再提供一些提示，但是这些提示从文章中我没有看到哪些特殊情况特殊的点容易 遗忘的，所以我判断其实可能也不会太多这样的 Case，因为可能特殊点再测试用例库里面就没有，如果测试用例库里面有，那么在选高优先级用例的时候也能包含
5. 针对回归测试的代码覆盖率或许有用，但是文章中还是没有实际的例子来说服我代码覆盖率可以发现的 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.