前端精准测试简介

前端精准测试简介

一,   前端精准测试架构介绍

    今年从零开始完成了前端精准测试整体功能的开发,在基于istanbul插件的基础之间,实现覆盖率数据的采集,并根据服务端和移动端精准测试的整体架构,实现前端精准测试体系。整体架构及核心功能介绍如下:

l  覆盖率

  •  借助于istanbul插件下的babel-istanbul-plugin, vite-istanbul-plugin和webpack-istanbul-plugin插件,对Vue,React项目实现插桩,进行覆盖率数据的采集;

  • 利用chrome插件实现对覆盖率数据的定时上传,并在页面刷新,打开新页面,关闭页面和置于后台时等特殊场景实现覆盖率的上传;

  •  利用nyc生成项目覆盖率数据全量,结合git diff过滤全量覆盖率数据生成增量报告的生成。

  •  解决istanbul, nyc无法对diff代码,在完全没有执行的情况下生成覆盖率报告,以帮助业务同学查漏补缺;

l  调用链路分析

  • 借助于ts-dependency-graph和dependency-cruiser,生成vue和react项目文件间的调用关系;

  •  结合对项目源码的分析,解析出页面间的调用关系,脚本文件与页面间的调用关系,并在***G服务上进行固化存储;

  • 通过diff代码,结合***G调用关系数据,开发前端精准测试链路分析功能;

  •  通过分析项目源码,解析样式文件与页面的对应关系,通过***G固化存储,以便分析项目样式文件的调用链路;

l  追溯关系

  • 优化服务端关联用例Chrome插件,在关联服务端用例的同时,根据配置同时关联前端用例;

  • 通过关联用例时,对用例执行时刷新页面,打开新页,关闭新页时覆盖率数据合并,生成整体用例完整的覆盖率数据;

  • 解析用例对应的覆盖率数据,通过覆盖的页面文件,代码块,函数块,建立起用例与页面的关联关系,生成正向和逆向追溯关系。

l  用例推荐 

  • 通过git diff 分析出需求修改的代码文件列表,并解析出修改的行号;

  • 通过调用链路,分析出脚本文件,样式文件影响到的页面文件;

  • 通过需求修改的文件,行号,反查与文件关联的用例,再通过覆盖的语句块,函数块来过滤关联的用例;

  • 对推荐出来的用例进行全面分析,根据用例的覆盖链路对用例去重,最后生成推荐用例列表;

l  全流程

  • 结合链路分析,用例推荐,用例执行,覆盖率分析等功能,开发前端全流程功能;

  • 根据推荐用例的结果,创建测试计划,在测试计划执行完成后,生成对应需求的覆盖率报告;

  • 如果全流程执行过程中有覆盖率数据,则自动生成覆盖率报告,后续还可以手工生成覆盖率报告。

二,前端覆盖率

     前端覆盖率相关的资料网上也有一部分,但是真正介绍清楚的不多。我们这边其他团队也做了一套东西,不过是开发主导的,一切从开发的角度出发,使用成本比较高。后来我们调研了相关资料,从测试角度出发,开发的前端覆盖率测试功能,主要包括以下三部分内容:

1,覆盖率数据采集

      借助于istanbul插件下的babel-istanbul-plugin,vite-istanbul-plugin和webpack-istanbul-plugin插件,对Vue,React项目实现插桩,进行覆盖率数据的采集。这也是业界常规的做法,虽然我们也能看到其他的收集覆盖率的工具,但底层是一样的,封装的越多,使用越不灵活。

    通过对前端项目进行插桩,项目打包部署后,访问页面的输出端window.__coverage__就可以得到当前页面操作的覆盖率数据,是JSON格式的数据。随着操作的执行,覆盖率数据会不断地变化。

2,覆盖率数据上传

     对页面进行操作的时候,覆盖率数据是存储在浏览器的本地存储中的,刷新页面,关闭页面等操作会导致数据丢失。为了生成覆盖率报告,需要定时将数据上传到指定的服务器。

     为了对被测对象产生最小的影响,我们采取chrome插件的方式,通过用户输入的域名,需求信息,自动收集浏览器的数据,定时把覆盖率数据上传到指定的服务器。同时在页面置到后台,页面刷新,页面关闭等特殊场景,也上传覆盖率数据,保证数据的完整性。整个插件的覆盖率上传控制逻辑如下所示:

3,覆盖率Agent

     覆盖率其实就是完成一系列覆盖报告生成逻辑,其流程图在上面已经介绍。而istanbul插件的特性来分析一下得出,覆盖率数据为chrome浏览器加载的页面或是用户执行的页面的覆盖情况,是以json文件来记录覆盖的文件信息(文件路径,语句块起始位置,函数起始位置,分支起始位置),用户操作覆盖率的情况等。对于完全没有执行到的文件,是无法获取其覆盖率数据的。

l  全量报告的生成:将用户上传的覆盖率数据进行合并,nyc merge合并成一个文件,然后对合并后的json文件进行处理,主要是把文件中的文件路径替换成agent上项目源码的路径,否则报告中的代码文件无法渲染。替换完成后,使用nyc report生成覆盖率报告即可。

l  增量报告的生成:增量报告的生成有两个方案,一是,对增量文件进行插桩,然后生成报告,但是这样就无法生成全量报告;二是,通过git diff拿出增量文件以及修改的行,来过滤全量报告。本项目采取的是第二种方案,通过增量文件过滤全量覆盖率数据,然后根据更改的行号,处理覆盖的情况。另外,如果增量文件在全量报告中没有,就生成一个文件信息,语句块,函数块,分支信息都为空。这样生成的覆盖率报告中,对应的文件为灰色的,但是可以指导业务同学查漏补缺。

三,调用链路分析

       前端调用和服务端,移动端的都不太一样,它没有明确函数级别的相互关联关系,对于脚本文件虽然有函数,但也不能分析函数与函数的调用关系,这是没有意义的。前端只能分析页面与页面,页面与组件,脚本文件与页面,样式文件与页面间的调用关系。从网上调研了一下,发现借助于ts-dependency-graph和dependency-cruiser,生成vue和react项目文件间的调用关系;但是要生成整体项目页面间的调用链路的话,还需要对数据做进一步的处理。

      整体生成调用链路的流程图如下所示:

      这个调用链路分析的粒度还是比较粗的,以页面为单位进行的分析,生成调用关系的时候,也是根据diff的文件,反查影响到的页面。这就会存在如下问题:

  • 改动一个文件的部分页面,会分析出这个文件所有的调用链路,可能在影响范围外;

  • 有可能脚本文件,样式文件无法对应到页面,评估不出其影响范围;

可以做的更加精细化一些,主要增加如下分析:

  • 页面与组件间的调用关系,具体区分哪个是组件,组件改动的话,页面需要回归测试;如果页面改动,不影响组件的话,可以不测试组件;

  • 脚本文件具体影响到页面的哪些行,以引用脚本文件中的函数行号为主,没有改动到相应的行号,则不用回归影响的页面;

  •  样式文件也是同样的,分析具体引用样式文件中的函数的页面行号,这样就能将样式文件+函数,对应的具体的页面,减少影响范围。

如果做如上分析的话,可能会增加分析时间,需要在具体的项目中做出优化,此部分内容缺乏调试与调优。

四,追溯关系

前端关联用例的话,需要分析出用例执行过程中,对页面,脚本文件有执行覆盖情况,这样的信息在window.__coverage__中已经以json数据的格式展示出来,只需要解析出来进行保存。

1,用例关联插件

而追溯关系数据,必须从关联用例开始,为了减少业务同学的工作量,在关联用例的时候前后端用例同时进行关联,所以优化服务端关联用例插件,核心逻辑如下所示:

这里面存在以下问题:

  • 一个用例操作过程中,可能会包括各种状态:页面刷新,打开新页面,关闭页面或是结束用例录制等;

  •   一个用例只有要状态变化,就上传覆盖率数据,这就会产生一个用例对应多个覆盖率数据文件的情况;

  •  通过需求ID和用例ID来区分用例对应的覆盖率数据。

2,用例覆盖率解析

    当用例对应的覆盖率文件上传到精准测试平台后,需要解析一下用例对代码的覆盖情况,用例解析流程如下:

注意以下几个要点:

  •  用例解析前,需要把一个用例对应的所有覆盖率文件进行合并,然后再解析,否则会造成数据的丢失;

  • 目前解析的是用例影响到的页面文件tsx,vue文件,没有记录脚本文件,其实也可以保存脚本文件的覆盖情况;

  • 解析覆盖情况时,取用例覆盖文件的语句块,函数块,而不是具体的代码行;后面可以调研一下,能否精确到代码行;

  • istanbul插件无法对样式文件进行插桩,所以也没有样式文件的覆盖情况,这个需要业务同学自行确认。

五,用例推荐

     前端用例推荐和服务端,移动端原理上是类似的,就是推荐出本次需求改动的代码,影响到的代码需要回归的测试用例;但是核心算法又不相同,没有办法使用圈复杂度,函数行号等一系列数据指标进行计算用例分数,目前前端精准测试用例推荐流程如下所示:

当前的推荐策略完成了如下功能:

  • 通过diff代码,拿到需求修改的文件列表和行号列表;

  • 通过对文件进行过滤,分情况查询用例,查询调用关系,过滤函数;

  • 过滤函数是通过行号是否在用例关联的页面的语句块,函数块内,如果在则选择函数,不在则放弃;

  •  粒度有点儿粗,暂时还没有其他的算法,在后面业务使用过程中,再逐步细化,添加相应的算法进行筛选。

六,全流程

      整个的核心思想就是提供各个可单独使用的功能模块,又有串起各个模块的全流程,一键化操作。和移动端不同的是,前端没有处理istanbul插件自动注入功能,因为前端框架,脚手架太多,没有办法自动注入,此功能就由开发同学来完成。所以前端精准测试全流程包含:链路分析,用例推荐,用例执行,覆盖率分析等核心流程。

1,全流程流程图

现在的全流程功能的流程如下图所示:

     将所有单独的功能串联起来,实现一键化执行所有流程。注意每个环节都要添加上循环检测执行过程,由于前端全流程没有打包环节,执行速度还是非常快的。

2,全流程功能分析

现在全流程基本功能没有问题,主要有两个核心数据需要完成。

(1)用例与代码关联

     所有推荐的基础就是用例与代码的关联,然后再通过一系列关联推荐算法,让用例越来越精准。所以关联用例是前提的,需要业务同学在使用过程中,不断在关联手工测试用例与相应的代码,只有建立了这个关系,才能更好地推荐。

(2)推荐算法优化

    当前的推荐算法只是查询,针对于前端用例,由于在录制过程中业务同学对录制的时机可能掌握的不够好,录制的操作步骤有前置或是后置操作,这就造成了一个用例与非常多的代码有关联,推荐的时候不太好过滤,这就造成了推荐用例过多的情况。

(3)用例关联的细化

     现在用例关联的时候,只关联了用例覆盖的页面的覆盖率数据,对于脚本文件没有存储其覆盖的情况,推荐的时候通过脚本文件查询影响的页面,进而推荐,粒度有点儿粗,后面需要细化一下。

    增加样式文件的调用链路分析和用例推荐,由于istanbul没有办法对样式文件进行注入,所以覆盖率数据是拿不到样式文件信息的。我们可以过滤一下项目的源码,解析出样式文件与页面文件的关系,再分析页面文件,找到样式文件影响到的页面文件行号,进而细化其影响面,生成调用有关系和推荐数据的时候过滤用例。

七,总结

    现在前端精准测试整体功能已经开发完成,覆盖率已经在几个业务线进行使用,通过分析覆盖率增量报告,查找遗漏的地方,再补充用例提高覆盖范围。经业务同学反馈,效果明显,通过覆盖率也增加了测试的信心。

    其他环节有待在各个业务线进行使用,主要是要关联测试用例,这个是整个精准测试的基础,后面在使用中,逐步对业务中的特殊场景,不规范的编码进行兼容,同时优化用例推荐算法,以实现以最小的测试用例集达到最大的测试覆盖,以提高测试效率。

转载请说明出处内容投诉
CSS教程_站长资源网 » 前端精准测试简介

发表评论

欢迎 访客 发表评论

一个令你着迷的主题!

查看演示 官网购买