前端精准测试简介

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

今年从零开始完成了前端精准测试整体功能的开发，在基于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项目文件间的调用关系；
结合对项目源码的分析，解析出页面间的调用关系，脚本文件与页面间的调用关系，并在CCG服务上进行固化存储；
通过diff代码，结合CCG调用关系数据，开发前端精准测试链路分析功能；
通过分析项目源码，解析样式文件与页面的对应关系，通过CCG固化存储，以便分析项目样式文件的调用链路；

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插件自动注入功能，因为前端框架，脚手架太多，没有办法自动注入，此功能就由开发同学来完成。所以前端精准测试全流程包含：链路分析，用例推荐，用例执行，覆盖率分析等核心流程。