精准测试实践-测试范围分析| 京东云技术团队

京东云开发者
• 阅读 306

一、背景

需求迭代过程中产研漏评估业务影响点是bug漏到生产环境的主要原因之一。减少漏评估问题的发生是提升交付质量的重要方向,精准测试是除依赖产研人员能力及经验外的另一种分析业务影响点的方式。

二、实践方案

1.方案简介

下面介绍针对java单应用的代码改动影响自动分析方案。

1)原理介绍

基于代码依赖关系分析改动的代码影响到哪些入口代码(接口、消息、任务等入口方法)。

举例,如下图,假设某应用改动了底层方法1,则基于代码间调用关系可以分析出方法a、b、z为被方法1影响的该应用最外层入口方法。



精准测试实践-测试范围分析| 京东云技术团队



2)实施流程介绍



精准测试实践-测试范围分析| 京东云技术团队



代码依赖分析方案详细介绍:

a.基于asm框架对java字节码文件进行解析,可解析出代码间调用关系。

举例,下图为字节码文件部分内容的截图,方法中的invokexxx指令为字节码中调用方法的指令,用asm字节码分析框架,可分析出如在methodA中调用了methodB。



精准测试实践-测试范围分析| 京东云技术团队



b.以提测分支与master分支含diff的方法作为查询对象,结合方法间调用关系数据,可查出某方法影响到哪些入口方法

三、实践效果

结合coding的webhooks,实现代码提测后自动获取代码diff及其影响代码的自动分析。



精准测试实践-测试范围分析| 京东云技术团队



四、未来规划

基于分析出的影响接口、消息入口信息,结合对应接口的测试用例,可以进一步实现测试用例的推荐与自动运行,及结合代码覆盖率分析能力自动给出测试覆盖率报告。

作者:京东科技 吕俊

来源:京东云开发者社区

点赞
收藏
评论区
推荐文章
前端精准测试实践
作者:京东云质量部背景随着前端技术发展,已经转变为数据绑定为主流的框架方式,与后端服务一样,前端代码实现也会涉及相互依赖,引用这些场景,那么应该如何准确的评估前端代码改动的影响范围?依赖开发评估?依靠经验评估?或者直接前端自动化全回归?手工测试全回归?显然
云原生引擎单元测试实践
快速迭代的开发工作中如何提高代码质量一直是团队痛点,特别是没有测试支持的开发团队。合理的使用单元测试,并关注单元测试通过率、代码覆盖率可以有效提高代码质量。今天就来讲讲云原生引擎单元测试实践。
精准测试之过程与实践 | 京东云技术团队
精准测试是一套计算机测试辅助分析系统。精准测试的核心组件包含的软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统,这些功能完整的构成了精准测试技术体系。
浅谈如何更好的进行需求评审 | 京东物流技术团队
怎样能够让需求评审更高效、保质呢?作为测试人员又如何在其中发挥价值呢?根据自己的工作经验,下文介绍如何在需求评审中做到更规范,来减少评审过程出现的问题,以此提高需求评审效率、提升需求评审会议质量,来营造一个比较轻松的产研合作氛围。
精准测试探索 | 京东云技术团队
什么是精准测试?通常研发提测的需求有代码变更,针对研发的代码变更点以及关联点进行测试,我们称之为精准测试。
测试用例设计方法六脉神剑——第六剑:心法至简,百家之长集成
1引言在前面几篇文章中,为大家介绍的都是系统的方法论,但在实际需求测试的过程当中,受到外部环境及业务逻辑的影响,比如涉及多需求耦合、浏览器缓存堆积等情况,仅针对当前需求设计出的测试用例就会有覆盖不全的问题,此时就需要借助以往的经验进行反向错误推测,辅助其他
新支点小玉 新支点小玉
11个月前
信息化建设项目验收
信息化建设项目验收确认测试内容一般包括:需求评审、测试方案、实施测试及回归测试、资料评审四部分。(一)验收评测工作主要包括:文档分析(招投标文件、建设合同、可研分析、需求规格说明书等)、测试方案制定、现场测试、问题单提交回归测试、测试报告;(二)验收测试内
陈哥聊测试 陈哥聊测试
10个月前
如何选择合适的自动化测试工具?
自动化测试是高质量软件交付领域中最重要的实践之一。在今天的敏捷开发方法中,几乎任一软件开发过程都需要在开发阶段的某个时候进行自动化测试,以加速回归测试的工作。自动化测试工具可以帮助测试人员以及整个团队专注于自动化工具无法处理的各自任务,但困难的部分就是选择
京东云开发者 京东云开发者
3个月前
精准测试之探索
一、怎样的技术•百度百科:精准测试是一套计算机测试辅助分析系统。精准测试的核心组件包含的软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统,这些功能完整的构成了精准测试技术体系。•其他定
代码影响范围工具探索
祖传代码不敢随意改动,影响范围无法评估。并且组内时常有因为修改了某块代码,导致其他业务受到影响,产生bug,影响生产。2.研发提测完成后,测试进入测试后经常会向研发询问本次需求改动影响范围,以此来确定测试用例,以达到精准测试,提升整个需求的质量,缩短交付周期。那么,如何才能规避这种隐患?有没有一种工具能够协助代码研发及review人员更加精确的判断当前代码改动影响范围,有没有一种方法能够提供除了业务逻辑条件验证,针对代码作用范围,给测试人员提供精确验证链路?