精准化测试介绍
- 一、精准化测试是什么?
- 二、什么是代码插桩?
- 三、两种插桩方式
- Offine模式:
- On-the-fly插桩:
- 四、jacoco覆盖率报告展示
- 五、增量代码覆盖率监控原理
- 六、精准测试系统架构图
- 七、全量与增量覆盖率报告包维度对比
- 八、全量与增量覆盖率报告代码维度对比
- 九、实践案例
- 十、覆盖率测试局限性
- 十一、对精准化测试的畅想
一、精准化测试是什么?
传统的软件测试技术主要基于测试人员对业务的理解,但由于经验与真实业务数据的差距,肯定会测试不充分,所以很多情况下,测试结果无法精确保证对软件质量的定义和判断。
精准化测试技术从字面理解,就是非常准确的测试,这意味着要用量化的数字说话。
精准化测试是一种可追溯的软件测试技术 。通过构建一套计算机测试辅助分析系统,对测试过程的活动进行监控,将采集到的监控数据进行分析,得到精准的量化数据,使用这些量化数据进行质量评价,利用这些分析数据可以促进测试过程的不断完善,形成度量及分析闭环。
精准化测试的核心思想就是:使用非常精确和智能的软件来解决软件测试的问题,从根本上引领软件测试从经验型方法向技术型方法的转型。质量的评估不再靠经验,而是通过精准的数据来判定。
二、什么是代码插桩?
就是在字节码中插入探针
三、两种插桩方式
在测试前先对文件进行插桩,然后生成插过桩的class或iar包,测试插过桩的class和jar包后,会生成动态覆盖信息到文件,最后统一对覆盖信息进行处理,并生成报告。
JVM中通过-javaagent参数指定特定的jar文件启动Instrumentation的代理程序,代理程序在通过ClassLoader装载一个class前判断是否转换修改class文件,将统计代码插入class,测试覆盖率分析可以在JVM执行测试代码的过程中完成。(企业一般都用这个)
- 原理:用一个干净的class包,在装载过程中,通过动态代理去给它动态插入探针。
- 两种方式对比:
- On-the-fly无需提前进行字节码插桩。
- On-the-fly无需停机(Offine需要停机),可以实时获取覆盖率。
- On-the-fly更加方便获取代码覆盖率,但是代理服务会有一定的性能损耗。
四、jacoco覆盖率报告展示
其中绿色的是被爬过的,红色的没被爬过,黄色的是逻辑判断语句,它里面的逻辑判断语句有的被爬过,有的没有五、增量代码覆盖率监控原理
当项目改动较少内容的时候,做全量代码覆盖率显然不合适,我们只希望看到代码改动范围的覆盖率,这个时候我们就要做代码的diff - diff原理
- git diff给2个分支号,会输出2个版本的差异
- 3,4行的减号加号是要diff的a,b版本
-20,11
,减号代表老版本,表示老版本从20行开始往下数11行+20,15
,加号代表新版本,表示新版本从20行开始往后数15行- 为什么前面是11行,后面是15行呢,从图中可以看出是因为减了1行,加了5行(11-1+5)
- 解析diff行
- 解析后json格式diff行,拿到行号
- 把差异行号变成差异方法的列表,获取method级别的diff信息(就是下图右边的)
-
通过AST(抽象语法树)把开发写的静态java代码实例化成java对象,然后获取到里面的类,方法行信息,进行加工。如果is_changed等于true,表示方法被修改过
-
通过上面的步骤获取到改动的接口列表后,我们就可以清楚知道哪些接口被修改了,我们可以配一个钉钉提醒,如果开发改了代码没通知我们就可以去找他们啦哈哈哈
-
六、精准测试系统架构图
首先从gitlab拉取代码–>通过git diff命令加工成json数据–>把json数据传到AST–>拿到diff method list–把它传到jacoco里,探针转化为行号,对代码进行染色,生成代码维度报告–>
七、全量与增量覆盖率报告包维度对比
八、全量与增量覆盖率报告代码维度对比
九、实践案例
-
接到一个提测通知
-
生成空白增量报告,这里可以看出开发只改了这个方法,红色表示没有测过
-
进行初步的流程性测试,发现无法跑通
-
我们又去进行了覆盖率测试,根据覆盖率报告分析逻辑走向
-
恢复数据后流程走通
-
再去拉一下覆盖率报告
-
主流程走通后观察项目覆盖率情况,发现其他流程还没通呢
-
没有覆盖的代码块,逐个击破
-
把发现的bug反馈给开发
-
开发修复了bug
-
精准化测试后的报告,说明逻辑已经完全覆盖
-
精准化测试后的覆盖率数据
-
使用覆盖率工具校正过的用例。有了这个工具测试无需跟开发过多的沟通就可以获取想要的信息,还是很方便的
十、覆盖率测试局限性
覆盖率测试不是万能的,这只是针对代码层的,比如开发漏写了某一段逻辑,这个是检测不出来的