基于浏览器请求录制与AI代码生成的E2E接口自动化测试实践

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 办公效率, 编程
原文链接： https://mp.weixin.qq.com/s/wHvOWQspdro3J7aD6O0bsA

摘要

阿里妹导读以阿里云DataWorks为例，介绍如何通过浏览器录制插件捕获真实请求数据，结合AI编程工具自动生成接口封装与测试用例，解决复杂平台产品自动化测试中接口多、参数杂、数据流深的核心难题。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）一、引言：复杂平台产品的自动化测试之痛在企业级软件测试领域，有一类产品让自动化测试工程师感到尤为头疼——复杂业务逻辑的平台型产品。以阿里云DataWorks为例，它是一个集数据开发、数据集成、数据质量、数据地图、数据服务、运维中心、数据治理等十余个子模块于一体的大型平台。这类产品有几个显著的测试难点： 1. 接口...

核心内容

阿里妹导读

以阿里云DataWorks为例，介绍如何通过浏览器录制插件捕获真实请求数据，结合AI编程工具自动生成接口封装与测试用例，解决复杂平台产品自动化测试中接口多、参数杂、数据流深的核心难题。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）

一、引言：复杂平台产品的自动化测试之痛

在企业级软件测试领域，有一类产品让自动化测试工程师感到尤为头疼——复杂业务逻辑的平台型产品。

以阿里云DataWorks为例，它是一个集数据开发、数据集成、数据质量、数据地图、数据服务、运维中心、数据治理等十余个子模块于一体的大型平台。这类产品有几个显著的测试难点：

接口数量庞大且无标准文档

这类平台的前端与后端通过大量HTTP请求进行通信，涉及近20个微服务端点。这些接口大多是内部网关层封装，没有像OpenAPI那样标准化的接口文档——测试工程师想知道"创建一个数据质量规则需要调哪个接口、传什么参数"，唯一的办法就是打开浏览器开发者工具，手动操作一遍，然后从Network面板中找到对应请求。

接口间存在复杂的数据流依赖

一个完整的测试场景往往需要串联5~20个接口调用。例如，测试"创建数据质量自定义模板规则"这一功能，需要先查询目录树，创建目录，检查名称是否冲突，再创建模板，最后查询验证——每个接口的返回值（如目录ID、模板ID）都是下一步的入参，数据流环环相扣。

多版本并行演进

产品以季度为周期持续迭代，接口路径、参数结构、返回体格式都可能发生变化。测试框架需要同时维护多个版本的接口封装，旧版本不能动，新版本要新增。

认证机制复杂

不同于简单的Token认证，这类平台的HTTP请求需要Cookie加CSRF Token双重认证，且不同版本的获取方式不同。

二、传统人工编码时代：
一个测试工程师的典型一天

让我们回到AI辅助编码工具出现之前，看看一个测试工程师要怎样为这类平台编写一个E2E自动化测试用例。

2.1 工作流程总览

2.2 各阶段的具体工作

阶段一：需求理解与抓包（约1小时）

测试工程师首先需要理解这个测试用例要覆盖什么功能。然后打开浏览器，手动在平台上执行一遍完整的测试操作。

这个过程中，工程师需要同时打开浏览器开发者工具，切换到Network面板，仔细观察每一步操作触发了哪些接口调用。关键问题在于：

一次页面操作可能触发5到10个请求，其中只有1到2个是真正的业务请求，其余是心跳、静态资源、权限校验等
工程师需要凭经验判断哪些请求是核心业务请求
需要逐个点开请求，手动记录URL路径、请求方法、请求体结构、返回体结构

阶段二：接口封装（约2小时）

确认需要封装的接口后，工程师要做几件事：

在现有代码中搜索：框架中有近20个接口封装模块，总计数千个方法，需要用IDE全局搜索确认是否已有同类封装
理解HTTP请求封装模式：框架的HTTP请求通过统一方法发送，需要理解URL参数、Body参数的构建方式
手动编写代码：将抓包得到的请求信息翻译为代码

-

// 手动编写的HTTP请求封装示例public ApiResponse createQualityRule(Long projectId, String ruleName, Integer ruleType, String checkExpression, Long tenantId) { return httpClient.post("/api/quality/rules") .queryParam("projectId", projectId) .body(new JSONObject() .put("projectId", projectId) .put("ruleName", ruleName) .put("ruleType", ruleType) .put("checkExpression", checkExpression) .put("tenantId", tenantId) ) .execute();}
这里最容易出错的地方是：参数名拼写错误、参数遗漏、数据类型不匹配。因为全程是人工从开发者工具面板中手抄过来的，一个驼峰拼写的差异就会导致接口调用失败。

阶段三：用例编排（约1~2小时）

接口封装完成后，需要在测试用例类中确定继承关系、编写初始化方法、将多个接口调用按正确的业务顺序编排、处理接口间的数据流（前一个接口的返回值作为后一个接口的入参）、编写断言。

阶段四：调试修复（约1小时）

这往往是最耗时的阶段：参数名写错导致接口返回400、数据类型不匹配导致JSON解析异常、接口调用顺序错误导致业务逻辑报错、返回体字段路径取错导致空指针。

保守估计，传统方式编写一个中等复杂度的测试用例（涉及10到15个接口），需要5到6小时。

三、新范式：录制插件 + AI编程的化学反应

3.1 核心思路转变

传统方式的本质问题在于：人需要充当"接口信息的搬运工"——从浏览器Network面板手动搬运到代码中。这个过程不仅低效，而且极易出错。

新范式的核心思路是：

让录制插件自动捕获完整的请求-响应信息，让AI自动理解这些信息并生成正确的代码。

3.2 录制插件：从"人眼抓包"到"机器捕获"

我们开发了一个浏览器扩展，专门用于自动捕获测试过程中的所有网络请求。

使用流程

从使用者的角度看，录制插件的操作极其简单：

插件提供四按钮状态机（开始/暂停/继续/停止），并实时显示录制计数。录制过程中，插件在后台自动拦截页面发出的所有XHR/Fetch请求，捕获完整的请求体和返回体，自动过滤非业务请求（如静态资源、心跳包），并按时间戳统一排序。

录制数据格式

录制结果以JSON数组导出，每条记录包含完整的请求-响应对：

-

[ { "method": "GET", "url": "https://bff.example.com/api/quality/tree?projectId=100001", "requestBody": null, "responseBody": "{\"requestId\":\"xxx\",\"data\":[ ],\"code\":200}" }, { "method": "POST", "url": "https://bff.example.com/api/quality/catalog?projectId=100001", "requestBody": "{\"projectId\":10

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充