如何建立用例与代码的关系-QECon-精准测试-案例解读

精准测试是近些年比较热的一个话题。笔者一直认为这是一种治疗大厂“富贵病”的“靶向药”。对于一般公司而言，面对的问题是自动化测试用例过少，甚至没有的问题，还没到测试用例过剩需要挑拣的地步。因此，如果没有过万的接口自动化用例，可以不用拉到底，只了解一下代码覆盖率统计即可。 精准测试的一个技术基础，就是覆盖率统计。通过覆盖率报告，可以了解到一次执行过程，对被测应用的代码覆盖情况，包括类、方法、代码行等。再通过代码增量的统计，就可以了解本次新增代码的覆盖率情况。

初步的增量覆盖率统计，一般也有以下的实践

1）通过 覆盖率报告（如Jacoco）+Git Diff 来计算 这是最常见和最简单的方案。首先获取到全量的覆盖率报告，然后再叠加Git Diff获取的增量代码报告，进行增量代码覆盖率的计算。 通过sonar提供的能力，可以通过一行命令实现增量代码覆盖率的统计。 mvn sonar:sonar -Dsonar.branch.name=目标, -Dsonar.branch.target=基线

2）通过Git Diff获取到增量代码，让Jacoco只扫描增量代码，形成覆盖率报告。 基于此生成的覆盖率报告，天然就是增量报告了。 3）不使用Git Diff，而是通过通过代码库如，Gitlab的接口来获取增量代码情况。

在获得了代码覆盖率尤其是增量代码覆盖率之后，一般就可以据此了解新增代码的覆盖情况，评估是否需要进行补充测试以及未测试的风险情况。让测试人员不再闭着眼睛进行所谓的“黑盒测试”了。也就是所谓的，测试更加“精准”了。 在这个基础之上，精准测试就被提了出来。而精准测试的其中一个技术基础，就是如何建立应用代码和测试用例之间的关联关系，进而可以执行最少的用例获得最大的代码覆盖率，达到“精准测试”的目的。

在原先覆盖率报告的基础上，思考这个问题，就发现这其中有两种关系需要建立， 1）用例-代码覆盖关系， 通过代码覆盖率报告建立的是代码（类、方法、代码行、分支等）是否被覆盖的情况。也就是关注，一个用例或者一个用例集的（增量）代码覆盖率情况。 2）代码-用例覆盖关系， 在原先代码覆盖率报告的基础上，翻转两者关系，建立代码-用例之间的关系。原先关注的是一个测试用例覆盖了哪些代码，通过倒排，了解这个代码（类、方法、行、分支）被哪些测试用例覆盖。 通过建立这个关系，就能获取到覆盖了某个代码的测试用例的清单。只要通过Git Diff了解到代码有变化，就可以根据这个清单来实现测试用例的自动筛选。

这个关系的建立，一般是通过单个用例的覆盖率报告解析和倒排实现的。

image.png

来源：## 基于自动化用例的精准测试探索

首先是通过单个用例的执行，来获取到这个用例的覆盖率报告。这个可以通过例如Junit5的扩展或者在@AfterEach里面触发Jacoco Dump来实现。 然后再进行倒排。在覆盖率报告中，可以了解到这单个用例覆盖了各个类的方法的清单。然后对这个矩阵进行转置，得到各个类的方法是否被这个用例覆盖的情况。 每个用例都执行并进行了上述操作后，就能得到每个类的方法的用例清单了。这些用例都会覆盖本方法。 也就是说，如果某个方法有变化，涉及到该方法的所有用例都可以被优先执行。

这就是精准测试背后的朴素逻辑，也就是如何建立代码和用例的关系。

本次QECon上看到了一种新的方法，也就是通过测试用例在请求中提供用例唯一标识发送给被测应用，再通过改造Jacoco的数据结构，将原先标识是否被覆盖的boolean 标志位改造成MapM<String，boolean>,用于存储各个用例对于目标代码的覆盖情况。以下是这个议题的两张片子，

来自于《基于Jacoco的代码覆盖率实时监控与精准测试实践》的这个话题，提供了一种新的建立用例和代码之间关系的思路。通过这种方式，就无需再实施每次用例执行进行dump的繁琐方式了。应该是可以大幅提升关系建立的效率和准确率。

关注本公众号，输入“QECon-SZ” 获取2021年QECon大会深圳站的全场PPT（含主场和15个专场的PPT）