AI Native测试工程实践：用知识图谱与大模型重构仓储机器人调度系统的端到端测试工作流

整理编辑｜TesterHome社区

2026年8月，在深圳举办的MTSC2026第十五届中国互联网测试开发大会上，北京极智嘉科技系统部测试开发Leader汪磊磊带来了《AI Native 测试工程实践：用知识图谱与大模型重构仓储机器人调度系统(RMS)的端到端测试工作流》的深度分享。

当前行业内多数团队的AI测试应用仍停留在“辅助生成脚本”的局部提效阶段，实际落地中普遍面临效果不达预期、用例稳定性差、端到端质量不可控等问题。北京极智嘉科技团队针对仓储机器人调度系统这一复杂业务场景，跳出“AI工具化”的思路，从AI Native的工程范式出发，搭建了以知识为核心、技能为方法、框架为支撑的完整测试体系，实现了端到端测试流程的智能化重构。

极智嘉是一家全球领先的智能机器人企业，成立于2015年，总部位于北京。凭借先进的机器人和人工智能技术，极智嘉打造了高效、柔性、可靠的全品类物流解决方案，赋能智能仓储和智能制造两大场景。以下为该公司团队的实践分享：

一、为什么“AI写脚本”总是不好用？

很多团队都试过用AI写测试脚本，但大概率没达到预期。问题的根源不在AI不够强，而在于有没有给它搭好对应的工程约束。AI独自上阵，天然过不去三道关：

领域认知空白：机器人调度系统中，一条用例背后涉及任务如何分配与调度、机器人怎么响应与移动、容器/货格状态如何流转，全程由异步回调驱动。AI只看得见接口输入输出，对背后的运行逻辑一无所知。
知识散落无关联：API规范、业务流程、数据库表结构三处孤立，文档各自为战、互不引用。AI搜索只能拿到碎片化片段，推不出业务全貌，上下游关系全靠人工串联。
用例落地极脆弱：端到端用例每条包含10个以上步骤，前置要构造依赖数据与环境，执行是多步骤接口调用链，后置要验证多组件状态、清理数据还原环境，一个入参错误就会导致整条用例失败。

进一步拆解会发现，真正的瓶颈从来不是脚本代码，而是工作流。表面上看AI在单个节点都能辅助完成工作，但串联起端到端流程时就会出现信息断裂，整体质量不可控。传统测试工作流无法被AI接管，有三个深层原因：

上下文不连续：每个AI技能各自为政，缺乏共享的任务记忆与状态传递；
知识不结构化：核心业务知识散落各处，AI难以获取完整准确的背景信息；
框架隐式成本高：复杂测试框架存在大量隐式上下文，AI极易误用引发异常。

基于这些痛点，团队提出了AI Native的核心公式：

AI Native = 知识结构化 × 框架DSL化 × 流程编排化

三种范式的本质差异

核心维度

传统测试

AI辅助模式

AI Native模式

|
| --- | --- | --- | --- |
|

AI角色定位

不存在，纯人工执行

被动工具，需人工发起调用

主动流程参与，按阶段执行并反馈

|
|

核心工作单元

全流程人工，用例到报告手写

聚焦局部，一段代码/函数

聚焦整体，需求到交付完整闭环

|
|

上下文承载

人脑记忆，依赖个人经验

仅限当次对话，转瞬即逝无留存

跨阶段持久化，上下文贯穿全流程

|
|

知识获取来源

文档+经验，人脑+纸质文档

人工粘贴，碎片信息临时提供

结构化知识库，企业级图谱

|
|

异常失败处理

人工排查，手动定位修复

人工发现，手动修复

自动分类+修复建议，人工确认即可

核心结论非常明确：同样用大模型、同样写Prompt，最终的效果差距，在于“知识-技能-框架”的三角体系有没有搭建起来。

二、测试工程的三大支柱：缺一即塌

AI Native测试工程由三大支柱构成等腰三角形结构，缺一角就会整体塌房：

Knowledge（知识）：业务领域知识，是所有推理的底层支撑；
Skill（技能）：Agent执行能力，是落地的方法载体；
Framework（框架）：工程体系，是输出的承载保障。

只做Prompt工程，幻觉率会非常高，AI不了解业务，给出的结果看似正确但实际没有业务价值；只有静态知识库，不会产生任何执行价值，只能供人查阅。

从行业演进来看，Agent领域落地已经走过了四个阶段：

Phase 1：Prompt工程（2022-2023）：解决“怎么和AI说话”的问题；
Phase 2：工具+RAG（2023-2024）：装上手眼，通过检索实现执行；
Phase 3：Agent编排（2024-2025）：多Agent长链路分解，各类Agent平台涌现；
Phase 4：领域落地（2025-至今）：核心挑战是“专业领域可信可用”。

当前的普遍瓶颈是：通用场景跑得好，一到专业领域就卡在“推理”环节。从感知到推理再到行动，推理环节必须要有领域知识做支撑。行业缺失的不是更好的RAG，而是完整的领域知识基础设施——包括知识图谱（世界模型）、约束体系（行为边界）、记忆系统（经验积累）。

三、整体架构：Pipeline + 三层支撑

极智嘉团队将整套AI Native测试体系设计为“全流程Pipeline + 三层支撑结构”，实现从需求到报告的端到端贯通。

完整Pipeline流向

整个测试流水线从需求输入到报告输出形成完整闭环：需求收集（Jira/Confluence原始需求）→ 需求分析（输出req-spec.md）→ 用例设计（输出testcase.csv）→ 转换脚本（输出test_*.py）→ 调试执行（输出pytest_result.json）→ 报告生成（输出test_report.md）。

三层支撑架构

Pipeline背后由三层架构提供底层支撑，自下而上分别是：

中心化记忆层：沉淀团队踩坑记录、约定规范、技术决策，启动时通过session hook自动加载上下文，执行过程中通过过程Hook自动归档知识点，实现跨会话的经验积累。
知识索引+框架DSL层：

知识索引侧：通过graphify构建业务文档图谱、codegraph构建测试工程图谱，实现按层级精准检索；
框架DSL侧：封装Biz业务操作、Selector数据选型、Callback异步等待、Teardown状态恢复等基础能力，提供统一的业务语义接口。

功能执行层：对应各阶段的具体测试工作，包括需求分析、用例设计、脚本生成、调试执行、报告输出等。

人机分工：清晰的角色边界

整套体系采用“人做门禁决策、AI在约束内执行、系统提供底层支撑”的协作模式，各阶段分工明确：

阶段

人（门禁决策）

AI（约束内执行）

系统（支撑）

|
| --- | --- | --- | --- |
|

需求阶段

提供需求素材、确认业务规则

Volere规格分析、领域建模

graphify知识召回、mem上下文注入

|
|

用例阶段

评审场景覆盖度、确认约束清单

ISTQB选型、MAET×GWT展开用例

断言链推导、约束清单检索

|
|

脚本阶段

确认断言精度、确认修复建议

语义分解生成脚本、复用biz DSL

codegraph符号复用、测试文件落盘

|
|

调试阶段

判断根因真伪、处理环境异常

6类根因分类、证据链诊断

实体查询、SQL执行辅助诊断

|
|

报告阶段

审核报告结论、归档质量基线

生成结构化Markdown、聚合质量基线

执行测试用例、产出结果文件

四、核心落地实践

1. 多层知识索引：解决“测什么”的核心问题

为了让AI准确找到与测试需求相关的知识，团队设计了“按层递进、不足时升层”的多层搜索流程，共四层检索+中心化记忆，各层协同工作、互相佐证。

L1：CodeGraph代码图谱： 测试工程符号索引，覆盖已有方法、调用链、枚举值，解决“代码链路”问题。例如搜索wait_callback→match_callback→字段匹配的完整代码链路。
L2：Graphify文档图谱： 业务文档知识图谱，覆盖模块关联、状态字段、约束条件，解决“文档关联”问题。例如水位控制问题会牵连6个模块，通过图谱可一次性召回全部关联内容。
L3：本地文档库： 存放API、流程、表结构、术语表、约束规则等测试业务文档，本质是“告诉AI怎么测你的业务”。
L4：外部源码： 调度系统源码、产品设计库，提供最精确的实现细节。
mem：中心化记忆： 查询相关踩坑记录、团队约定、历史边界问题，沉淀团队经验。

以搜索robot_type_phase字段为例，三层检索会分别返回代码链路、文档关联、记忆教训，互相印证。对比传统的grep单一搜索，多层检索可以补齐跨文档关联、语义全貌、代码链路和经验沉淀，避免只见字段不见逻辑。

2. 框架封装：封装的不是代码，是复杂度

行业中有观点认为“AI写的代码就是日抛型”，但极智嘉团队认为，AI写的代码同样需要高标准的可维护性要求。框架封装的核心理念，是封装复杂度，而不是封装代码。

对比传统写法与DSL写法的差异非常明显：

传统HTTP写法（约40行）：需要手写信封body、处理认证重试、解析返回结果、轮询回调、编写teardown清场逻辑，全流程都需要人管控，AI不知道底层怎么配，只能靠猜。
DSL写法（约4行业务陈述）：统一入口、业务语义命名、回调声明式等待、清场能力内建，AI只需要关注业务逻辑，无需关心底层实现。

QA.rms.query.get(SHELF).where(shelf_lock="NORMAL").random()
resp = QA.rms.task.request(GO_FETCH, shelfCode=...)
QA.callback.robot(resp.task_id, SHELF_ARRIVED)
Teardown.p.recover(self._case_passed

DSL写法从根源上降低了脚本出错的概率，同时环境恢复能力内建，大幅提升了用例的稳定性和可维护性。

3. Skill体系：AI的分工化协作

AI测试体系的核心是技能（Skill）的分工，团队累计建设了几十个技能，其中核心高频技能共六个，覆盖全流程各环节：

qa-req-analyze：需求分析，Volere规格分析、领域建模
qa-case-design：用例生成，ISTQB选型、MAET×GWT、评审
qa-case-implement：用例转脚本，语义分解、复用biz DSL
qa-script-debug：结构化调试，6类根因分类、证据链诊断
qa-report-write：测试报告，聚合三源数据、质量基线
qa-pipeline-run：Pipeline编排，6段流水线、断点续跑

设计1：阶段门禁——可回滚的独立阶段

全流程共设置6个阶段，每个阶段输出独立文件，设置严格门禁检查：

收集需求内容 → 2. 需求分析 → 3. 用例生成 → 4. 转换脚本 → 5. 调试 → 6. 报告

门禁机制带来三个核心价值：

可追溯：每阶段成果可留存、可查阅，能精准定位哪个阶段出了问题；
可回流：评审失败精准回流到对应阶段，无需重跑全流程；
断点续跑：按产物存在性跳段执行，缺什么从哪继续，提升执行效率。

设计2：MAET × GWT × 约束驱动

团队将主流测试方法论固化到技能中，从根源保障用例质量：

MAET主流程遍历：强制每特性完整遍历Main（主流程）、Alternative（替代流程）、Exception（异常流程）、Termination（终止流程）四条路径，保证场景覆盖完整。
GWT行为骨架：严格遵循Given（前置条件）-When（操作动作）-Then（断言预期）结构，倒逼AI输出逻辑严密、可执行的步骤。
约束驱动边界锁定：依据全量业务规则清单反推用例覆盖边界，告别凭灵感臆想，保证边界场景不遗漏。

设计3：结构化调试——六类根因分类处理

调试阶段预设六类根因约束，每类对应明确的处理策略，避免无效重试：

根因类别

典型失效表现

AI处理策略

|
| --- | --- | --- |
|

SCRIPT

语法/import/断言写错，如ModuleNotFoundError

修一次即止，不重跑

|
|

FLOW

断言失败但API/DB正常，用例流程设计有误

回流到用例设计阶段

|
|

CONTAINER

容器位置/状态异常，导致任务无法执行

数据清理 + 环境重置

|
|

ROBOT

机器人状态异常，故障/低电/无响应

查询实体状态，对应处理

|
|

SERVICE

API/DB状态不符规则，疑似服务bug

分类记录，触发上报

|
|

TIMEOUT

单条执行超2分钟，无法通过改脚本解决

立即标记跳过，不死磕

技能迭代：类CI的自动评估闭环

技能调试的一大痛点是“不知道改哪句话会影响产出”，团队采用类似CI的自动化评估方式，让AI交叉评测代替人工手动调试，形成6阶段迭代闭环：

就绪检查：准备评估数据、预置数据与断言；
快照当前SKILL：记录基线效果；
并行派发：优化版与基线版两组并行执行；
Grader子Agent打分：生成评分结果，聚合通过率；
聚合基准：统计对比通过率数据；
人工评审：评审、改写、追加历史规则。

以qa-req-analyze技能为例，经过4轮迭代，基线从初始71%，到加术语填写规则82%，加实体独立块+5条断言95%，最终加标注前置规则达到100%，每次变更都可追溯、可回滚，大幅节省了手动调试精力。

五、落地踩过的三个坑与解法

坑1：知识不准——文档与实现不一致

现象：GO_RETURN回库场景中，文档写明的目标参数优先级为latticeCode > destAreaId > destLaneIds，但系统实际实现为latticeCode > destLaneIds > destAreaId，区域和巷道优先级写反。AI信任文档后基于错误优先级生成用例，导致断言失败且难以定位——用例逻辑看着没问题，根源是知识源头错了。

根因：坑的根因不在AI，而在知识源头。AI能力越强，错误知识就会被放大得越快。

解法：通过调试实测结果纠正文档，强制知识源与系统实现对齐；文档中标注“待补充”的内容，调试后补全真实状态字段。核心原则是：知识可证伪、可纠错，而不是盲信文档。