从理论到实践,精准测试的初创之路
01痛点问题
作为测试同学,一定或多或少的在日常测试工作中碰到过以下场景:
• 小明最近在测试一个新功能。他写了一大堆用例,但是他总是担心自己的用例是否真的有效且全面。他想知道自己的测试是否做到了有效覆盖,但是他不知道如何评估。
• 小红在UAT环境回归测试,测试重点在哪里?回归测试用例集全量执行是不是必要的?
• 小兰在对接技术重构/SDK升级/基础组件优化需求时,对于测试验证范围的盲区?
• 小白在面对增量代码注入时,如何感知链路血缘关系并识别上下游调用影响范围?
• ......
随着公司业务快速的发展,业务的复杂度和项目数量同步提高,项目管理过程中呈现更快速的迭代、响应的趋势,如何利用有限测试资源应对项目快速迭代的同时保障高质量交付是测试领域面临的主要问题之一,在传统测试过程中,面临了如下的痛点:
1.测试范围主观评定,范围大,成本高。微服务的广泛应用使得业务颗粒级别更小,原子性、隔离性更强,但随之给QA带来的影响范围评估难度增加,过往测试QA主要基于需求文档,用户角度主观判断,实施大范围的回归测试。
2.测试效果主观判定,存在遗漏风险。测试过程中是否执行,过往依赖于用例执行记录,测试用例无法映射到实际程序的改动,无法精准的评估本版本变更的代码逻辑是否准确覆盖。
3.链路血缘关系及增量代码影响范围。增量代码注入后,对于链路血缘关系影响判断不清,无法识别影响范围及影响点,导致遗漏上线或全量回归。
以上问题往往会导致测试范围覆盖不完全导致生产漏测的质量问题,或是因为对改动影响面未知,QA投入过量时间全量回归测试,导致时间浪费的效率问题。为了提高测试质量和效率,测试急需一套更精准高效的测试分析技术和评估方法。于是,基于代码链路分析的精准测试,进入我们的视野。
02解决思考
如何追溯代码和用例的关系?
精准测试是基于源代码变更分析,结合分析算法,从而确定改动代码影响的范围,从而进行针对性测试,进一步提升测试效率,不仅如此,精准测试还可以将测试用例与程序代码之间的逻辑映射关系建立起来, 而这个过程则是通过工具去采集测试过程执行的代码逻辑及测试数据。这两个点也正是精准测试的核心:正向追溯和逆向追溯。
• 逆向追溯:
对基于需求实现的程序代码分析,分析出代码改动内容,从而告诉QA程序改动的影响范围,从而精准评估测试范围。从而使得测试范围更明确,避免全量测试造成的资源、时间浪费,释放出的人力成本可投入更底层的测试工作。
同时分析出的改动数据可作为迭代变更的特征内容,数据打通自动化平台,可以做。
• 正向追溯:
利用agent技术监控测试执行过程,分析出哪些代码被覆盖到,哪些代码没有被覆盖,从而统计测试覆盖率,通过代码覆盖率,找出漏测的地方,可以更精准的进行验证,减少重复工作,从经验型的主观判断向精准的数据可视化转变。
如何解决测试人员痛点问题?
对于以上痛点,精准测试从测试范围和测试效果两条线出发,分别给出了解决方案。
1)通过代码diff和bcel代码分析,分析出修改代码涉及的方法和调用链,进而收集影响的接口。这样,需要测试的内容,就了然于胸了。
2)通过测试的执行,使用jacoco等工具,获取执行代码的覆盖率,通过和代码diff内容的匹配,可以计算出测试的执行,对修改内容的覆盖,这样,测试的覆盖情况,就清晰明了。
03技术实现
精准测试分层架构
精准测试平台的设计和分层如下:
精准架构的底层,依赖一些开源的工具(如Jacoco、bcel、javaParser等),往上结合业务,做了一层封装,内部则采用工厂模式的设计模式来实现每个核心组件的独立使用和流程编排。最上层则对外提供一系列api,给测试平台以及其他调用方来使用。
精准测试落地方案
精准测试作为一个业务测试辅助的技术,在设计之初遵守两个原则:
1.自动融入流程,人为0感知(项目流程、测试流程):以不增加额外流程、0人力成本为原则,在必须要的环节进行异步流程的接入:
>项目流程:基于devOps发布平台的提测环节,以项目、按流水线为维度,精准服务进行异步创建(同时支持手工创建),以保证每周迭代提测、部署需求的全量覆盖。
>测试流程:不更改测试流程。
2.数据结果提高感知(主动感知、触达):受制于用户使用习惯,对于新事务的熟悉和接受存在一个适应期,因此在测试平台的提测、用例编写、任务执行、报告生成等关键页面融入精准分析数据展示,并结合平台的消息提醒、飞书通知等增加业务人员的结果感知,减少测试遗漏。
流程如下图:
精准测试核心能力
1)自动创建精准分析任务
• 接收提测信息:和现有发布平台打通,提测单创建后,自动获取信息(提测项目、分支、commitid等),创建精准分析任务
• 接收编译jar包信息:提测服务发布后,接收下发的jar包信息,并下载jar包(用于后续静态分析调用链)
2)代码Diff分析
• 拉工程代码:主要用于后续切换分支、获取包名和模块信息、代码Diff计算等操作。
• 代码Diff计算:主要是基于开源的gitlab api和JavaParser来做代码Diff计算以及AST语法树分析,分析出变更的类、方法以及内部相关信息。
3)代码静态分析
• 生成调用链:使用becl分析jar包的class文件,生成全局方法调用关系,再依据diff分析出的影响的方法,分析出方法往上的调用链,直到出口方法或者接口
4)上下游依赖分析
• 通过链路追踪,能够获取到变更接口上下游服务和接口的影响。
5)自动推荐/创建接口测试用例
• 推荐接口用例:根据分析出的变更方法影响的调用链,整合影响到的接口,并从我们的自动化测试用例库来筛选和匹配的自动化用例推荐
• 创建接口用例:对于新接口,或没有用例的接口,支持按模板或通过AIGC生成自动化用例
精准测试使用前后对比
04精准亮点
分析内容可视化
在精准测试的应用层面,我们集成在测试平台里,同时融合进测试日常工作中,简洁、直观的展示精准分析的结果,并将结果直接触达用例编写和内部沟通IM。
1)通过gitlab API获取开发分支的代码改动,分析改动的文件、类和方法,展示在平台上。
2) 通过代码diff分析出的结果,结合对应服务的JAR包,分析出变更方法的调用链。
同时通过AIGC协助分析。提高分析结果可读性。
3) 通过变更方法的调用链分析,汇总出影响的接口,并推荐已有的接口用例,可供测试人员执行验证。
4)精准分析完成后,会通过飞书消息,直达提测单关联的测试人员。同时,在测试平台,会通过关联需求, 在用例编写页面,提醒并展示精准报告。
接口自动化赋能
传统自动化测试,人工沟通、维护成本较高,利用精准分析接口的能力,打通接口平台,自动生成对应接口脚本、场景用例。同时结合AIGC的能力,提高用例编写效率。
变更风险自动评估
以变更方法为分析对象,基于代码知识库,可以获取变更方法是否为有效代码变更,以及变更方法的复杂度、代码耦合度等静态分析数据。再基于代码链路分析结果,可以实时获取变更方法影响的调用链、链路热度、方法热度等动态采集数据。从而可以实现精准评估变更方法的风险等级和实际影响对象。为此,我们建立了以下变更风险评估模型:
F(R) = F(M) + F(E) + F(M,H) + F(H)
其中:F(R) 为方法变更风险等级,F(M)为方法复杂度,F(E)为方法代码耦合度, F(M,H)为链路热度,F(H)为变更方法热度。
最后基于风险评估模型计算的结果,评估出对应需求的风险等级。
05 后续规划
精准测试v1.0版本于10月上线,已接入技术部所有项目发布流水线。实现了100%的提测需求覆盖率,后续规划主要集中在:
○ 分析范围扩充:扩充对对中间件影响的分析,提高分析数据的全面性,减少遗漏风险。
○ 关键数据提取:当结果数据过多时,无法给到用户直观的建议,所以平台对数据持续的下钻归因分析,去除噪音数据。提高数据的价值。
○ 覆盖率数据应用:执行覆盖率数据结合接口用例建立映射关系,辅助进行用例推荐。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取