AI手工测试用例的实践进阶之路

这篇文章分享一条真实的落地路径：我们不是直接追求“AI 一键生成完美用例”，而是先用 MVP 验证方向，再用 1.0 补齐输入解析、Prompt 工程化、知识工程和检索闭环，最后把能力沉淀到测试智能体并skill化赋能“小龙虾”。文末会给出可直接复用的实践方法与避坑点。                                -- AI用例生成项目组

手工测试用例一直是质量保障的核心资产，但在今天的研发节奏下，传统模式正在暴露结构性瓶颈。

第一，输入信息碎片化。测试同学面对的不再只是 PRD 文本，还包括交互原型、业务流程图、技术方案、接口改造说明和代码差异。信息源变多后，理解成本线性上升，遗漏概率却是指数级上升。

第二，时间窗口持续收缩。需求评审、开发联调、提测上线都在加速，留给测试设计的时间越来越短，很多团队被迫在“覆盖深度”和“交付速度”之间做取舍。

第三，质量依赖个人经验。相同需求在不同测试同学手里，输出风格和覆盖深度差异明显；一旦换人，历史经验无法稳定复用。

第四，知识沉淀难形成复利。历史用例、缺陷复盘、业务规则都在，但缺少统一组织和高质量召回机制，导致“有知识，不好用”。

所以我们当时的判断是： 真正需要升级的不是写作效率，而是测试设计这条生产链路本身。

2.1 思路：工程化关键环节，不推翻人工流程

MVP 没有追求功能大而全，而是围绕一条最小可用链路做闭环：

需求理解 -> 功能点提取 -> 场景设计 -> 结构化输出

这条链路本质上仍然遵循人工测试思维，只是把高重复、高消耗、强经验依赖的环节交给模型与工作流系统。

MVP闭环架构

MVP版本延续人工测试思路，把需求理解、功能点提取、用例设计与结构化输出串成可运行闭环。

2.2 交付方式：支持探索和交付两类场景

为了覆盖实际工作场景，我们在 MVP 中提供了两种使用方式：

• 对话模式：适合需求澄清、快速追问、拿初稿。
• XMind 模式：适合形成结构化资产，直接进入评审、执行和沉淀。

MVP对话生成示例

MVP已支持对话式生成，输入自然语言后可快速产出测试点与测试内容草稿。

2.3 目标：验证 AI 可行性

MVP 重点验证两个问题：

• AI 是否真的能沿着测试思维链路工作，而不是只会“写得像”？
• 哪些问题是“单模型 + 单 Prompt”无法自然跨越的？

我们很快得到答案：方向是对的，但链路还有明显短板。

3.1 多模态理解弱，难识别图中关键信息

在真实测试场景里，大量核心信息不在正文，而在原型图、流程图、架构图里。MVP 对这类信息的解析能力有限，导致输入偏差直接传递到输出。

3.2 长上下文不稳定，复杂就遗漏

当需求涉及多个角色、模块和状态流转时，模型难以稳定维持全量上下文，容易出现覆盖不完整、边界条件缺失、异常路径漏测。

3.3 领域语义缺失，仅像用例而不可执行

缺少业务术语、流程规则、历史缺陷模式时，结果会出现典型问题：格式正确、措辞专业，但与业务重点不贴合。

这三类问题直接指向一个结论： 问题核心不在模型参数，而在输入治理、知识组织与生成流程设计。

4.1 思路：从一次性交付到可维护工作流

1.0 的升级不是“换个更强模型”这么简单，而是从工程角度重构整条链路：

• 输入侧：支持多源材料接入和前置解析；
• 处理中间层：做结构化抽取、知识补全、分步生成；
• 输出侧：保证格式统一、去重优化、可评审与可追踪。

1.0 总体工作流

1.0 阶段从单点生成扩展为多源输入、结构化解析、知识补全、用例设计与格式化输出的完整流程。

4.2 输入前置：功能点先抽象再生成用例

我们把链路升级为：

多源输入 -> 智能解析 -> 功能点抽取 -> 补全校验 -> 用例生成

和 MVP 相比，最大的变化是把“输入前置处理”独立成能力层。这样做的收益非常明显：当上游输入被标准化后，下游生成稳定性显著提升。

功能点前置抽取流程

文档解析与功能点生成前置后，系统先完成模块拆分和补全校验，再进入具体用例设计。

4.3 多模态解析：图像信息统一语义链路

1.0 将图像理解纳入主链路，通过视觉特征提取、OCR 文本识别与语义对齐，将原型图、流程图、时序图转换成可计算的结构化描述。

多模态解析流程

多模态解析把非文本输入结构化，补齐纯文本方案的理解盲区。

关键价值不在“识别图片”本身，而在于把图像中的测试证据转成系统可消费的上下文。

4.4 Prompt 工程化：走向可治理模板

我们把 Prompt 能力分阶段演进：

• 一体化 Prompt 阶段：迭代快，但 token 成本高、维护成本高；
• 模板化 Prompt 阶段：按测试类型、业务背景、输出规范拆分组合；
• 工程化 Prompt 阶段：引入版本管理、模板复用、扩展机制。

Prompt模块化设计

Prompt 设计从单段长提示词演进为可组合输入模块。

Prompt 分层治理

Prompt 体系逐步演进为按测试类型、业务背景和模板能力分层组合的可维护结构。

Prompt 工程化的本质是： 把模型推理边界、输入结构和输出约束前置，让系统能持续迭代，而不是每次从零试错。

4.5 知识工程+RAG：让生成带上业务语义

在复杂业务里，单靠模型参数很难准确覆盖领域语境。我们把知识体系拆成三层并持续运营：

• 业务背景层：术语、流程、角色、规则；
• 技术文档层：接口定义、改造方案、代码知识；
• 测试经验层：历史用例、高频风险、缺陷模式。

知识工程体系

知识工程将业务背景、技术文档、测试经验统一纳入建模、验证和版本管理流程。

同时，检索链路从“查到文档”升级为“筛到证据”：

检索 -> 精召回 -> 生成 -> 验证

并逐步引入混合检索、子问题拆解、LLM 精召回与假设性答案增强。

检索增强闭环

检索链路从基础召回升级为增强闭环，使模型拿到的上下文更聚焦、更可用。

5.1 核心指标：不只看“生成条数”

我们重点跟踪三类指标：

• 覆盖质量：是否覆盖主链路、边界、异常、回归关键点；
• 生成效率：从需求输入到可评审草稿的时间；
• 可用稳定性：不同复杂度需求下输出的一致性与返工率。

核心指标视图

5.2 阶段观察：短板即优化方向

在 1.0 阶段，单次生成规模平均约 10 条，距离完整场景覆盖仍有差距。我们把问题进一步收敛为两点：

信息理解深度仍有提升空间；

知识检索准确率需要继续提高。

这也是为什么 1.0 后续迭代重点放在输入解析、知识组织和精召回，而不是盲目堆模型能力。

阶段性过程数据

5.3 实际结果：具备产品化基础

截至当前，这套能力已用于 462 个需求，覆盖 全年交付需求约 6.2% ，累计节省约 120 人天。

这个结果不代表“终局最优”，但证明了一件关键的事： 系统已经从实验性质，进入可规模化演进阶段。

前文用数据说明了“AI测试用例生成”已迈入实际应用阶段。但随着需求增多、团队协作变复杂、资产管理压力增加，单一的用例生成工具难以应对产能和质量挑战。

要破解这些问题，关键不是简单增加功能，而是升级系统架构，实现平台化、组件化和协同化。我们通过组件解耦和 Skill 编排，让用例生成、补全、评估等能力协同工作，打造全链路、可治理的测试智能体平台。

简而言之，不是“多了个生成工具”，而是将分散的工具整合为智能平台，各环节可以灵活组合和演进，满足更复杂业务和更多团队的需求。

6.1 体系概览：全链路协同

在新的架构里，我们不再把用例生成看成一个孤立动作，而是把需求理解、测试设计、提测补全放进同一条研发链路。平台核心目标有三个：一是让能力可组合，二是让过程可治理，三是让结果可沉淀。

• 多源输入协同：统一承接需求文档、设计说明、代码 Diff、历史用例等多模态输入，减少上游信息割裂。
• 统一过程治理：通过 Prompt 管理、上下文聚合、知识库、Skill 路由与效果评估贯穿主链路，让生成过程“可观测、可复盘、可优化”。
• 结果资产闭环：把评审反馈、提测补全、质量度量和复盘结论持续回流到知识层，形成“生成-验证-再生成”的正循环。

测试智能体系统新架构：组件化、多 Skill解耦与灵活编排

平台将 AI 用例生成、评审校验、Prompt 治理、知识沉淀、效果分析等能力全部组件化，并通过 hclaw Skill 灵活编排，最终实现测试全链路可协同、可持续优化。

6.2 研发主链路细化：生成 Skill 与补全 Skill 协同

为了避免“一个智能体做所有事”带来的复杂度失控，我们把核心流程拆成两个职责清晰、上下游衔接紧密的 Skill：一个负责设计阶段的高质量生成，一个负责提测阶段的差异化补全。二者协同之后，链路才能真正闭环。

6.2.1 测试设计阶段 —— 用例生成 Skill

• 我们把需求理解、测试点拆分、场景扩展、结构化输出等步骤模块化，确保每个节点都可观测、可降级、可替换。
• 输入层支持 Git Diff、Codebase Diff、API Schema、产品文档等多种载体，并通过统一规范完成数据整合，降低输入形态差异带来的波动。
• 路由策略、特征抽取、输出模板等规则通过配置托管，让“经验依赖”变成“可复用平台策略”，不同团队可以按业务特征快速接入。

6.2.2 提测阶段 —— 用例补全 Skill

• 我们把“提测即补全”做成默认机制：生成初稿、追踪变更、对齐用例库，不再依赖人工逐条兜底。
• 依托图谱变更影响分析，系统可以精准映射到 XMind 主干和分支节点，并对增量补齐项自动标注【新增】【修改】，让代码变更与业务覆盖关系一一对应。
• 补全过程采用标准化、幂等化设计，支持 Zen/经典 XMind 双格式输出，方便评审回溯、过程审计与跨版本比对。
• 在业务价值上，它解决的是“临近提测阶段最容易漏测”的问题，让回归覆盖从事后补救变成流程内建能力。

核心价值总结：两类 Skill 分工明确、相互衔接，前者负责“高质量生成”，后者负责“变更场景补全”，共同打通需求设计到回归验证的完整链路。最终沉淀下来的不只是更多用例，而是一套可持续增长、可迁移的测试资产生产机制。

如果你所在团队也在推进 AI 用例生成，建议优先落实这 6 条：

• 先做闭环，再做精度极致：没有闭环，优化点无从落地；
• 先治输入，再调模型：输入质量决定结果上限；
• Prompt 必须工程化管理：版本化、模块化、可回滚；
• 知识库必须面向“测试证据”建设：不是文档堆积，而是场景可用；
• 指标要覆盖全链路价值：可用率、覆盖率、返工率比“生成条数”更关键；
• 业务团队必须深度参与：平台单边建设很难持续贴合一线场景。

回看这条路径，我们经历的不是一次简单的“模型接入”，而是一场测试工程体系升级：

• MVP 验证方向；
• 1.0 补齐输入解析、Prompt 工程化、知识工程与检索闭环；
• 下一阶段迈向测试智能体化与工具链协同。

在测试领域，AI 最终拼的从来不是“模型有多炫”，而是： 能不能把测试方法、业务知识和工程体系组织成一条长期可演进的生产链路。