精准测试是个错误

如果你已经了解了精准测试在行业的主流做法，你可以跳过相关内容。

行业里对于精准测试的定义

在网上流传着一些精准测试的定义（如果你对这些定义不感冒，可直接跳到我个人的定义）：

自网易陈逸青（2020）的定义：

借助一定的技术手段、通过辅助算法对传统软件测试过程进行可视化、分析及优化的过程，使得测试过程更加可视化、智能、可信和精准。原文：https://www.infoq.cn/article/xuu91crqa4hcjz8uomjs

来自HSBC的测试咨询专家齐磊（2021年）：

通俗点讲：核心基于源代码变更分析，结合分析算法，确定影响范围，提升测试效率。原文：https://www.infoq.cn/article/2feiv8a5kogaqlbzwosh

来自星云测试（2022年）：

精准测试一句话概括就是：测试用例和代码之间的追溯，这是它最本质的东西。精准测试的本质决定了它抓住了测试的一个核心要点。原文：https://testerhome.com/topics/34557

来自得物技术（2023年）：

精准测试是基于源代码变更分析，结合一些分析算法，从而确定改动代码影响的范围，设计测试用例进行针对性测试，一方面可以提升测试效率，另一方面精准测试还可以将测试用例与程序代码之间的逻辑映射关系建立起来， 而这个过程则是通过工具去采集测试过程执行的代码逻辑及测试数据。这两个点也正是精准测试的核心：正向追溯和逆向追溯。原文：https://tech.dewu.com/article?id=43

以下是来自网易严选的架构图：

image.png

我个人的定义

在笔者看来，精准测试的定义应该是这样的：它是一种能力，能只针对变更进行测试，而不是每次变更都进行全量测试。注意，我指的是“变更”，而不只是“代码变更”，也就是说所有类型的变更，包括手动变更。

精准测试的思路并不复杂，分成三个步骤：

1. 1. 找到变更；

2. 2. 根据变更找到相关联的测试用例；

3. 3. 只执行相关联的测试用例。

其实，把这种方法叫增量测试（Incremental Testing） 更准确，更合适。毕竟你是针对增量的代码变更进行测试。

如果不是针对增量变更进行测试，你也能只执行一个你想测试的测试。难道这样不算精准测试吗？

国内行业主流的实现精准测试的方法

步骤一：找到代码变更

通过commit之间进行差异对比。

步骤二：根据代码变更找到相关联的测试用例

要做到“根据代码变更找到相关联的测试用例”，我们就必须知道代码与测试用例之间的关系。

比如针对一个web应用，获取这个关系的做法是在执行测试的同时，做以下事情：

1. 1. 将流量记录下来；

2. 2. 将因流量而执行地代码的调用链记录下来；

3. 3. 将测试用例的元数据与代码调用链的关系记录下来；

这个过程就完成了对被调用代码与测试用例之间的映射关系的建立。

另，现实往往存在很多未被测试用例覆盖到的代码，这时，通过静态代码分析和测试覆盖率计算技术结合，生成未被测试到的代码的报告。

可以看出，通过以上方式“找出代码与测试用例之间的关系”的成本是极高的。所以，在这个领域会有：引流平台、测试用例管理平台、精准测试平台等等平台。这也给大家一个感觉，我们要先有一个平台才能做到精准测试。

说到底就是通过插桩技术，构建代码的执行路径，并找到对应的测试用例之间关系。

目前在网上看到大多还只是针对Java语言或者C++来实现精准测试，其它的语言的案例没有见到。

步骤三：只执行相关联的测试用例

当有了代码与测试用例之间的关系，只执行相关联的测试用例就简单很多了。

主流方法的坑

以下是齐磊总结的精准测试存在的问题：

1. 1. 基于手工测试的精准测试建立映射关系繁杂，如果需求改变频繁，用例维护以及之间的关系维护需要耗费大量时间精力。

2. 2. 精准测试需要一定的自动化测试的覆盖，这样做起来更有意义，例如 api 自动化测试，如果本身用例过少，与代码之间关联关系不多时，变更代码后可能不会得出什么结果。

3. 3. 最好有对应的用例管理系统，能够方便的帮助我们建立与代码之间的关系。

4. 4. 需要投入开发能力强的 QA 或者测试开发建立整套系统环境，但长远考虑，将精准测试嵌入整个公司的质量平台中，不管对于新项目还说维护项目来说都是一种提升。

5. 5. 项目生命周期需要较长，短期项目花费巨大精力开发和维护整套精准测试系统得不偿失。短期项目可以利用精准测试以 api 测试覆盖率作为衡量标准。不去建立繁杂的关系，只监控 UI API 测试覆盖率迭代时的变更来达到目的。

但是，个人认为齐磊总结的内容没有问题，的确都是坑。但是那些不是精准测试的坑，而是国内行业主流的实现方式的坑。直白地说就是喝水时，喝水的角度错了。

为什么主流实现方法从方向上就是错的

为什么我认为以上地坑是由实现方法导致的？以下是我的论点，欢迎讨论指正：

该方法只局限于单一语言

准确来说，精准测试不应该只针对代码的变更，而是所有的变更。更不应该只针对单一语言的变更，而是可以针对所有的语言。

因为精准测试的定义本身不局限于某个语言的代码变更，而是对一个软件工程中所有的变更而言。一次SQL的变更，你是否需要精准的知道要执行哪些测试？一个前端的CSS代码的变更，你是否需要精准的知道要执行哪些测试？

目前行业里主流的方法，只是针对单一语言下的场景而设计的。按同样的思路是无法做到多语言的。我说的多语言指提同一工程下的多语言，不是指相互独立的单语言工程。

只能在平台上做精准测试

即，我们首先需要一个平台，才能做到精准测试。

但我们希望在开发者本地开发环境就可以做到精准测试。

最后

文章标题并不是说“精准测试”本身是一个错误，是想说上述的实现方法是一个错误方法。

那，什么样的方向是正确的呢？请关注我，接下来，我会谈。

往期好文推荐：

• 比构建速度，Bazel是Gradle的10倍，不服不行！！！