引言

在AliExpress跨境电商的复杂业务场景下，复杂业务模式（例如跨境、本地）、多类型物流方式、分国家运营策略、多币种、多语言等各因子叠加，测试经常面临测试数据构造复杂且困难、学习成本高、耗时长等问题。测试用例的初衷是验证业务逻辑，却被数据构造的“脏活累活”绑架了。

如今，大语言模型与原子工具库的结合，可以重新定义测试数据构造的工作模式。我们构建的测试数据智造助手，让"生成一个命中单品补贴的pop待评价订单"这样的复杂需求，只需一句自然语言描述即可自动完成全链路数据构造。

一、核心痛点

以构造一个包含业务类型、组合营销优惠、物流线路等多种条件的测试数据为例：测试往往需要辗转于测试商家后台、营销运营工作台、各业务域的测试工具平台等多个系统，记忆各种参数规则，耗时费力地拼接出一个完整的测试场景。

随着业务的快速扩张，测试数据的复杂性和多样性持续增长，更加暴露出了传统的数据构造模式存在以下痛点：

• 多域依赖：测试数据构造依赖交易、支付、营销等多个业务域，工具分散于不同平台，操作链路冗长；
  
• 协作成本高：跨域工具使用需多团队协调，理解成本和重复工作量巨大；
• 效率瓶颈：人工构造复杂场景（如各状态订单、组合优惠等）耗时高达小时级，增加了测试执行的时间。

二、破局思路

通过引入AI智能聚合编排测试数据构造能力，构建统一调度中台，可以有效解决这些问题，提高测试数据构造的效率和质量。

核心思想：通过LLM大模型+RAG技术实现自然语言驱动，结合多业务域原子工具单点调用和链式调用，实现全链路测试数据"所想即所得"。

三、目标

从0-1建设AE测试数据智造Agent，统一测试工具AI接入方式，聚合多业务域测试原子能力，解决测试数据构成本高、造耗时长等问题，实现“提效”、“降本”、“提升覆盖率”，在自动化场景中实际运用。

• 提效：将复杂场景（如跨境订单、组合优惠）的测试数据构造耗时从小时级缩短至分钟级。
• 降本：减少开发&测试时在数据构造的理解成本和重复工作量。
• 覆盖率：覆盖订单生命周期，支持多个核心业务域的复杂场景。

四、智造Agent实现方案

4.1设计思路

• 用户以自然语言提出询问时，Agent 会依据用户输入的内容，在 RAG 测试工具知识库中进行信息检索。RAG技术能帮助 Agent 精准匹配到与用户问题相关的信息。
• Agent 将用户提出的问题以及从知识库中检索到的信息，一同输入到 LLM 大语言模型中。大语言模型凭借其强大的语言理解能力，对用户的意图进行识别和分析，并将用户意图分为测试信息查询、原子数据构造和链路数据构造这几类。
• 基于识别出的用户意图，Agent 会匹配相应的一个或多个原子工具，以及链路调用工具的规则。这些原子工具是实现数据构造的基础组件，各自具备特定的数据处理功能。同时，Agent 会从用户问题里提取出原子工具必要的关键参数。
• 依据知识库中的业务规则、数据模板和相关知识，使用提取出来的参数调用工具库中的原子能力生成符合用户需求的测试数据。最后，Agent 将生成的测试数据进行合理组装，以清晰、易懂的格式回复给用户，完成整个测试数据生成与反馈的流程。

举个🌰

用户指令：给商品id为123456（示例ID，非真实数据）的商品生成一笔退货退款的订单。

Agent处理流程：

1.使用用户的问题去匹配知识库中的场景，与“退货退款”链路的背景内容关联度最高。2.将用户问题和知识库匹配结果共同传入大模型，识别用户意图为通过退货退款链路构造测试数据，该链路涉及的原子工具及调用顺序规则为：下单—>支付—>发货—>确认收货—>申请退货退款—>同意退货—>退货—>同意退款。3.提取必要参数商品id：123456（示例ID，非真实数据），将其作为入参传给下单原子工具。然后将下单工具生成的订单id传给支付工具，之后按照按照顺序调用原子工具。4.将状态推进成功的订单回复给用户。

4.2Agent架构设计

• 前端交互：提供自然语言输入界面，用户通过描述需求（如“构造一个使用平台券的pop商品订单”）触发流程。
• 语义解析：结合RAG从知识库中匹配工具链规则信息和原子工具信息，再通过LLM大模型解析用户意图。
• 原子工具调度：根据工具链规则信息和原子工具信息调用原子工具服务（HSF/HTTP请求），实现原子工具间的依赖关系与参数传递，生成用户想要的测试数据。

因此可以抽象为三层系统架构，具体如下：

4.2.1规则抽象层

通过构建《原子能力工具库》、《工具调用规则库》的知识库实现。

原子能力工具库：每个原子工具定义工具描述、提问示例、参数说明以及原子工具维度的参数映射规则。

工具调用规则库：将业务场景抽象成原子工具调用规则，再通过DAG有向无环图的方式进行规则的定义。

4.2.2执行调度层

工具链调用：编写数据智造prompt提示词使大模型能够根据规则生成对应的执行计划。

参数透传：在工具链上的规则输出的结果会根据参数语义透传给后续工具，不需要人工进行干预。

失败重试策略：工具调用失败自动触发重试，重试超过5次触发断点，需要人工确认。

4.2.3原子工具层

通过AI应用开发平台的工具箱能力执行原子工具的真实调用，从而实现测试数据的自动构造。

4.3关键实现模块解析

4.3.1AI应用开发平台

基于AI应用开发平台进行对话型AI智能体设计，在Agent中调用RAG知识库、LLM大语言模型、自定义工具等能力实现AE测试工具构造功能。

# Role: AE测试数据构造助手——全链路测试数据生成专家

## Profile
- **Author**: AE测试团队
- **Version**: V0.1.1
- **Language**: 中文  
- **Description**: 专注通过自然语言交互，自动化生成覆盖交易、支付、营销等全业务域的复杂测试数据，实现"所想即所得"。
## 核心原则
1. **三源数据优先级**  
   `用户输入参数 > 常用测试数据 > 原子工具默认值
2. **文档引用规范**  
   - 链路流程 → 《工具调用规则库》  
   - 工具定义 → 《原子能力工具库》  
   - 默认数据 → 《常用测试数据》

## Core Capabilities
1. **意图精准识别**  
   - 支持识别7大场景类型：  
     `基础订单生成 | 营销活动构造 | 逆向流程推进 | 跨境场景模拟 | 用户资产管理 | 数据状态查询 | 异常场景构造`  

2. **参数深度提取**  
   - **常规参数**：商品ID、用户ID、订单ID 
   - **场景扩展参数**：  
     {
         "营销活动": ["活动类型", "优惠门槛", "叠加规则"],
         "逆向流程": ["纠纷类型", "退款原因", "风控等级"],
         "跨境场景": ["关税模式", "物流渠道", "货币类型"]
     }
3. **动态链路生成** 基于目标状态自动裁剪工具链（如"已支付"状态仅调用创建+支付工具）
A[输入解析] --> B{是否跨域?}  B -->|是| C[组合规则引擎]  B -->|否| D[单域规则匹配]  C & D --> E[工具链执行]  E --> F[结果聚合]

## Workflow (严格遵循)
1.**提取请求参数**
...

2. **工具调度阶段**  
环境适配 → 根据用户输入的环境特征选择对应工具版本
链式执行 → 按《工具调用规则库》定义的工具顺序执行
参数桥接 → 自动将上游工具出参映射为下游工具入参
状态演进 → 每个工具执行后必须推进业务状态到目标阶段

3. **异常处理机制**  
...

## Output Format(强制规范)
...

4.3.2原子能力工具库构建

梳理研发测试过程中测试数据构造&测试数据查询的原子操作进行封装和抽象，并在AI应用开发平台的工具空间对工具封装成API。

4.3.3测试工具知识库建设

为了让 AI 智能体能够精准识别用户意图，并使用正确参数调用工具组件，因此通过结构化工具描述文档搭建 RAG 测试工具知识库。该知识库是 AI 智能体理解用户需求和执行任务的关键基础。

需要维护的测试工具知识库涵盖两大部分：

• 原子测试工具描述文档：将原子测试工具的使用背景、使用说明以及使用范例整理后录入知识库。AI 智能体在识别到具体业务场景时，就能快速匹配到对应的原子工具，进而实现数据构造和数据查询。

工具名称：请填写工具名称。
工具描述：请填写工具描述、使用场景，方便大模型理解工具。
提问示例：请填写提问相关的示例，支持多条。
参数说明：参数名称-参数描述（是否必填）以及参数枚举

• 数据构造链路描述文档：把数据构造链路的背景信息、原子工具的调度链路以及具体原子工具名称都输出到知识库中。如此，AI 智能体在面对特定业务场景时，便能准确对应到具体的数据构造链路，然后依照链路顺序调用原子工具，完成数据构造任务。

链路名称：退货退款链路
链路背景：售后退货退款是指买家在下单支付完成，货物确认收货后买家申请退货退款，卖家同意退款的链路。用户用淘宝账号购买指定itemId的商品并且支付生成淘宝订单号orderId。在买家确认收货后的时候买家提交退货退款申请，生成退款单，退款单号disputeid,然后卖家同意退货，买家退货，最后卖家同意退款申请。
链路信息：下单—>支付—>发货—>确认收货—>申请退货退款—>同意退货—>退货—>同意退款

五、Agent应用实践

AE测试数据智造Agent应用场景是多方面的。目前已接入钉钉答疑群和个人助手，以问答的方式作为业务日常测试的测试助手；也可以作为自动化测试（如接口自动化、用例自动化、压测等）的测试数据提供方，以HSF的接入方式对外提供数据构造基础能力。

针对对外提供的数据构造基础能力，我们做了以下的系统架构设计来保障数据构造的准确性和稳定性。

5.1外部接入架构设计

5.1.1漏桶算法限流

由于LLM大模型存在token、QPM限制，而上游平台会批量调用触发限流，所以需要做限流方案。

为了解决这一问题，需要对流量整形，限制对AE测试数据智造Agent的请求频率，避免触发LLM服务端限流，保障系统的稳定性。

限流算法选型：漏桶算法

实现思路：将请求视为水流，将其放入一个“漏桶”中，桶的出口以固定速率流出请求，从而实现对流量的平滑控制，从而以恒定的速率请求AE测试数据智造Agent。

漏桶容量 = 预估峰值流量 * 1.2)

漏水速率 = LLM每分钟限制 / 60 * 安全系数（如0.8）

5.1.2标准化输出

（1）业务错误场景处理

测试数据无法构造的场景对于AE测试数据智造Agent来说并不是系统错误，是属于业务层面的错误，直接请求不会返回错误码和错误信息。

因此在接口适配层识别这些业务错误的场景，返回对应的业务错误码和错误信息。

（2）标准化错误码

AI应用开发平台构建的Agent在系统错误时返回的错误码不符合AE的规范，因此在接口适配层按照AE的标准规范进行错误码的转换。

（3）输出结果标准化处理

由于上游对数据输出的格式要求严格，如果输出格式只写在AI规则里的话容易因为AI的幻觉导致输出的格式不符合规范。

JSON Schema校验：定义严格的响应结构模板，自动修复或拒绝非法格式（如字段类型错误、多余字段）。

5.1.3日志+监控

通过日志的方式，记录执行链路中的关键数据，并进行监控，分析大模型的执行结果，提供可监控、可分析的稳定性保障能力。

日志：场景+问题入参+Agent响应+标准化后输出结果+traceId，通过traceId串联从外部请求到Agent调用的全链路日志。

基础监控：Agent的RT和接口成功率。

业务监控：监控无法构造出测试数据的场景等。

执行分析：对无法构造出测试数据场景进行记录和分析，进行后续测试数据构造功能的迭代。

5.1.4缓存

目的：减少重复调用Agent的token开销，提升批量用例执行效率，减少耗时。

缓存键设计：对用户输入参数（如场景描述、业务参数）计算唯一哈希值，作为缓存主键。

缓存策略：成功结果缓存30分钟，失败结果缓存2分钟（防穿透）。

六、结果

当前Agent已完成8500+次问答（含调试）。简单测试数据构造场景，人工构造预估需要5分钟，AI可降至1-3分钟，提效约50%；复杂场景（如涉及长链路工具），人工构造预估1小时，AI可降至10-15分钟，提效约70%。

当前已完成的核心能力如下：

• 原子工具调用：共接入85+原子工具，覆盖交易下单、购物车、订单、营销、支付、逆向、商家、商品、招商等核心场景诉求。
• 链式数据构造：打通交易、营销、逆向跨域链式规则执行，实现各类订单状态数据、营销订单数据等的一键全流程构造。
• 业务域接入友好：各业务域原子工具和数据链路构造规则可以按照规范直接完成接入，无需感知Agent内部逻辑。
• 多环境支持能力：实现环境感知路由机制，支持根据用户需求动态切换线上/预发/项目隔离环境。

七、未来展望

测试数据构造正在经历从"手工操作"到"智能服务"的转型。当各业务域的测试工具完成原子化改造，当大语言模型真正理解业务语义，我们距离"所想即所得"的终极目标将越来越近。未来的测试工程师可以更专注于场景设计而非数据准备，用创造力推动质量保障体系的持续进化。

这种智能化改造的价值不仅限于测试领域，其背后构建的业务语义理解能力和跨域协作机制，为整个研发体系的效能提升提供了新的可能性。或许在不远的将来，我们今天构建的智能助手，将成为新一代研发基础设施的重要组成部分。

来源  |  阿里云开发者公众号

作者  |  明朗