AI 测试用例生成：从 Prompt 到 Skills，打造财政系统的智能用例工厂

AI 测试用例生成：从 Prompt 到 Skills，打造财政系统的智能用例工厂

作者：浅木·先生

一、写在前面

我在财政信息化领域做测试已经六年，经历了从"纯手工点鼠标"到"半自动化脚本"再到"AI 辅助生成"三个阶段的变迁。坦白说，前两个阶段虽然效率在提升，但本质上并没有改变测试设计的核心痛点——业务规则的理解和转化。

财政系统有多复杂？预算编制涉及"二上二下"的多轮审批流转，资金支付要匹配政府采购合同、校验指标类型和额度，政府采购本身又涉及品目分类、采购方式选择、中小企业预留份额等几十种业务规则组合。一个典型的资金支付场景，可能同时涉及：

• 预算指标类型（基本支出/项目支出）
• 支付方式（直接支付/授权支付）
• 政府采购标识（是/否）
• 合同匹配状态
• 收款人信息校验
• 额度控制

这些条件排列组合起来，手工设计用例几乎不可能做到全量覆盖。这正是 AI 测试用例生成的价值所在。

但我们在实践中也发现，AI 生成的测试用例，乍看"像模像样"，真往项目里一落，往往水土不服。问题出在哪里？过去两年，我和团队在财政系统中摸索了一套从 Prompt 到 Skills 的完整打法，今天把它写出来，希望能给同样在复杂业务系统里挣扎的同行一些参考。

二、先解决最基础的问题：写好 Prompt

2.1 一个失败的 Prompt 长什么样

最早我们尝试 AI 生成用例时，Prompt 是这样写的：

“请为资金支付模块生成测试用例。”

结果生成的用例长这样：

TC001：输入正确的支付金额，点击提交，系统返回成功。
TC002：输入错误的支付金额，系统提示错误。

这种用例放到财政系统里根本没法用——什么是"正确的支付金额"？校验规则是什么？有没有考虑指标类型？有没有考虑政府采购合同匹配？一个字：虚。

2.2 结构化 Prompt 的核心公式

经过迭代，我们总结出一套针对财政系统的 Prompt 模板：

## 角色
你是一位拥有 10 年经验的财政系统资深 QA，熟悉《预算管理一体化规范》和《政府采购法》。

## 业务背景
当前测试模块：国库集中支付——直接支付场景
业务规则：
1. 支付金额不得超过可用预算指标余额
2. 涉及政府采购的支付必须匹配已生效的采购合同
3. 收款人账户信息必须通过银联校验
4. 单笔支付超过 500 万元需触发大额支付审批流程
5. 预算指标类型为"项目支出"时，需关联项目立项批复文号

## 约束条件
- 技术栈：Spring Boot 微服务 + MySQL + Redis
- 接口规范：RESTful API，返回码遵循财政标准规范

## 测试设计方法
请使用等价类划分、边界值分析和状态转换图，重点覆盖：
1. 正向主流程（Happy Path）
2. 异常场景（指标不足、合同未匹配、账户校验失败）
3. 边界场景（支付金额=0、=可用额度上限、=500万临界点）
4. 状态冲突（已支付订单重复提交、已作废指标发起支付）

## 输出格式
请以 Markdown 表格输出，包含：用例编号、模块、前置条件、测试步骤、预期结果、风险等级。

这个模板的核心在于：角色 + 业务背景 + 约束 + 方法 + 格式，五要素缺一不可。

2.3 财政系统的专属 Prompt 库

针对不同模块，我们沉淀了几个高频使用的 Prompt 模板。这里分享一个预算编制的示例：

预算编制——项目支出预算申报 Prompt 模板

你是一位财政系统测试专家，请为"项目支出预算申报"功能编写测试用例。

业务规则：
1. 项目名称、主管部门、项目总金额、实施周期为必填项
2. 项目总金额不得超过部门可用财力额度
3. 实施周期超过 1 年的项目，需填写分年度用款计划
4. 涉及政府采购的品目，必须勾选"政府采购标识"并填写采购预算明细
5. 项目类型分为：新建项目、延续项目、续建项目，不同类型审批流程不同
6. 申报金额精度到"分"，不允许出现超出两位小数的金额

请重点覆盖：
- 不同项目类型的审批路径
- 金额边界（0、1分、上限、上限+1分）
- 必填项缺失校验
- 品目选择与政府采购标识的逻辑联动
- 分年度计划与总金额的一致性校验

输出表格，包含前置数据库状态要求。

这个 Prompt 生成的质量明显提升——采纳率从不足 30% 提升到了 65% 左右。

三、从 Prompt 到 Skills：让知识可沉淀、可复用

3.1 Prompt 的天然局限

Prompt 虽然好，但有一个本质问题：它是单次任务指令，用完就没了。

今天你教会 AI “预算编制要校验政府采购标识”，明天换个系统上下文，它又忘了。每次都要重新写 Prompt，这跟手工写用例有什么区别？

而且，一个复杂的财政系统可能有几十个业务模块、几百条业务规则。靠 QA 团队维护几十个 Prompt 模板，本质上还是在用人肉维护知识。

3.2 Skills 是什么

Skills 的核心思想很简单：把测试专家的方法，沉淀成可被 Agent 自动识别、重复调用、长期维护的能力模块。

如果说 Prompt 是"这次怎么做"，那么 Skill 就是"这类事长期应该怎么做"。

在我们的实践中，将财政系统测试拆解为以下几组 Skills：

Skill 1：需求分析（requirement-analysis）

负责从 PRD、设计文档、业务规则中抽取：

• 业务事件和触发条件
• 功能义务和前置条件
• 分支路径和状态变化
• 外部依赖和接口契约

Skill 2：测试对象规划（test-object-planning）

负责将需求拆解为可测试的对象：

• 业务功能对象（预算申报、支付申请、采购计划）
• 数据处理对象（金额计算、状态流转、审批链）
• 权限控制对象（角色、部门、数据权限）
• 异常处理对象（超时、重试、回滚、补偿）
• 状态迁移对象（申报→审批→下达→执行→终结）

Skill 3：边界挖掘（boundary-mining）

负责系统性检查各类边界：

• 输入边界（金额上下限、字符长度、枚举值）
• 状态边界（单据状态的可达/不可达路径）
• 时间边界（预算年度、支付时效、审批时限）
• 配置边界（品目分类、采购方式、指标类型）
• 并发边界（重复提交、多人同时审批）

Skill 4：覆盖率审查（coverage-review）

负责在最终输出前检查：

• 主流程是否覆盖所有正常路径
• 异常流程是否覆盖已知的踩坑点
• 状态切换是否覆盖全部合法转移
• 权限和角色是否覆盖所有用户类型
• 回滚、恢复、组合条件是否遗漏

3.3 一个具体的 Skill 示例

以资金支付测试为例，我们沉淀了一个"支付场景覆盖率检查"的 Skill：

skill_name: payment-coverage-review
version: 2.1
description: 资金支付模块的测试用例覆盖率自动审查

checklist:
  - id: CP001
    title: 指标类型覆盖
    description: 检查用例是否覆盖基本支出、项目支出、转移性支出三种指标类型
    
  - id: CP002
    title: 支付方式覆盖
    description: 检查是否覆盖直接支付和授权支付两种方式
    
  - id: CP003
    title: 政府采购关联
    description: 检查是否覆盖"有政府采购合同"和"无政府采购合同"两种场景
    
  - id: CP004
    title: 金额边界
    description: 检查是否包含0元、1分、可用额度、额度+1、500万临界值
    
  - id: CP005
    title: 状态冲突
    description: 检查是否包含已支付订单重复支付、已作废指标发起支付
    
  - id: CP006
    title: 收款人异常
    description: 检查是否包含账户不存在、户名不符、账户已注销
    
  - id: CP007
    title: 审批链异常
    description: 检查是否包含审批人不在岗、审批超时自动退回、多人审批意见不一致

这个 Skill 每次生成用例后自动触发，缺失的场景会标记为"建议补充"，覆盖率一目了然。

四、Agent + Skill + AI Model：三层架构实战

4.1 三层架构设计

我们最终采用的架构分为三层，参考了 Hermes Agent 的设计思路：

┌──────────────────────────────────┐
│         Agent（执行控制器）        │
│  输入判断 → 任务拆解 → 能力调度   │
│  → 结果校验 → 异常处理            │
├──────────────────────────────────┤
│         Skills（能力模块）         │
│  需求分析 / 测试规划 / 边界挖掘    │
│  覆盖率审查 / 输出格式化           │
├──────────────────────────────────┤
│         AI Model（推理引擎）       │
│  GPT-4 / DeepSeek / Claude       │
│  + RAG（业务知识库）              │
└──────────────────────────────────┘

Agent 负责"现在该做什么"——判断输入是否充分、决定先调用哪个 Skill、检查输出是否合规。

Skills 负责"这类事怎么做"——每个 Skill 封装了一段测试方法论，包含 Prompt、检查清单和可选的脚本。

AI Model 负责"内容生成"——实际调用大模型进行推理，结合 RAG 召回的历史踩坑点和业务知识。

4.2 财政系统的 Agent 工作流程

以"政府采购预算编制"模块的测试用例生成为例，Agent 的完整工作流如下：

Step 1：输入判断

Agent 检查用户输入：
- 是否有 PRD？→ 有（2026年政府采购预算编制需求文档）
- 是否有接口文档？→ 有（Swagger JSON）
- 是否有业务规则文档？→ 有（采购品目分类表、限额标准）
- 是否满足最低要求？→ 是，进入下一步

Step 2：任务拆解

Agent 决定分四阶段执行：
1. 先执行 requirement-analysis → 抽取业务规则
2. 再执行 test-object-planning → 拆分测试对象
3. 然后生成测试用例（调用 AI Model + RAG）
4. 最后执行 coverage-review → 审查覆盖率

Step 3：能力调度

Agent 调用 requirement-analysis Skill：
- 从 PRD 中抽取业务事件（预算编制、预算调整、预算调剂）
- 从接口文档中提取 API 契约
- 从业务规则中提取约束条件

Agent 调用 test-object-planning Skill：
- 拆分为：品目选择、金额填报、政府采购标识、审批流程

Step 4：生成与校验

Agent 调用 AI Model 生成测试用例，然后：
- 检查输出格式是否符合 JSON Schema
- 检查是否覆盖 checklist 中所有场景
- 检查是否存在逻辑冲突
- 如果覆盖率不足，触发重试或补充生成

4.3 RAG 知识库的构建

AI 生成用例质量高低，很大程度上取决于知识库的质量。我们在 RAG 知识库中沉淀了三类内容：

1. 基线用例
按"业务域→功能模块→功能点"三级结构组织，每个功能点对应 5-10 条基线用例，作为 Few-Shot 示例。

2. 踩坑库
记录过去两年生产环境中发现的缺陷，每条包含：

• 触发条件（什么操作导致）
• 影响范围（涉及哪些模块）
• 测试要点（以后应该怎么测）

3. 业务规则库
将财政系统的业务规则结构化存储，例如：

规则编号：BR-2026-001
规则类型：校验规则
适用模块：资金支付
规则描述：单笔支付金额超过 500 万元时，必须经过"处长审批→分管领导审批→主要领导审批"三级审批
异常处理：审批链未完成时，支付申请状态保持为"审批中"，不可支付
关联规则：BR-2026-002（大额支付额度控制）

引入 RAG 后，我们观察到两个明显变化：

• 采纳率从 52% 提升到 85%（数据基于某支付模块 3 个迭代的对比）
• 重复用例减少了 40%，因为 AI 能参考历史用例，避免生成高度相似的场景

五、踩坑实录：AI 生成用例的 7 个常见问题

两年的实践下来，踩过的坑不计其数。总结几个最典型的，希望对你有帮助。

坑 1：AI 生成的用例"正确但无用"

现象：用例写得四平八稳，但全是 Happy Path，真正容易出问题的异常场景一个都没有覆盖。

根因：Prompt 中没有明确要求 AI 关注异常路径，AI 默认选择了"最安全"的输出。

解决方案：在 Prompt 中显式要求 AI 采用"错误猜测法"，并要求输出至少 30% 的异常场景用例。我们在 Prompt 中增加了这样一段话：

“请特别注意：我司生产环境中，80% 的缺陷发生在异常路径。请至少覆盖以下异常类型：数据异常（空值、超长、特殊字符）、状态异常（单据状态不匹配、流程已终结）、权限异常（无权限操作、跨部门操作）、并发异常（重复提交、多人同时审批）。每个异常类型至少生成 2 条用例。”

坑 2：业务规则理解偏差

现象：AI 把"政府采购"的校验规则理解错了，生成的用例中合同匹配逻辑完全不对。

根因：大模型虽然知道"政府采购"这个词，但不清楚财政系统中政府采购的具体校验规则（比如：只有编制了政府采购预算的支出才需要匹配合同，且合同必须已生效）。

解决方案：将业务规则以结构化方式存入 RAG 知识库，并在 Prompt 中明确引用。例如：

“请严格遵守以下业务规则（来自规则库 BR-2026-003）：政府采购支付必须满足（1）该支出已编制政府采购预算；（2）已签订采购合同且合同状态为’已生效’；（3）支付金额不超过合同金额。不满足任何一条，系统应拒绝支付并返回具体提示信息。”

坑 3：用例颗粒度失控

现象：有的用例颗粒度太粗——“测试支付功能”，不知道到底测什么；有的又太细——“点击【提交】按钮”，变成了操作步骤而非测试场景。

解决方案：我们在 Skill 中定义了"颗粒度标准"：每条用例必须覆盖一个完整业务场景，且能通过 3-5 个关键步骤完成验证。Agent 在输出后自动检查，粒度不合规的标记为"需重构"。

坑 4：覆盖率虚高

现象：AI 说"已覆盖 95% 的场景"，但人工评审发现大量场景其实只是"提到"了，并没有真正的测试步骤和预期结果。

根因：AI 对"覆盖率"的理解和测试工程师不同。AI 认为"提到了"就算覆盖，工程师认为"有明确验证点"才算覆盖。

解决方案：引入"可执行覆盖率"指标——要求每条用例必须有明确的预期结果，且预期结果必须是可以量化的（如"返回码=0000"、“页面显示’支付成功’提示”、“数据库状态=3”），而不是"系统应正常处理"这种模糊描述。

坑 5：重复用例泛滥

现象：一次生成 50 条用例，里面有 15 条高度相似，只是金额不同。

解决方案：在 coverage-review Skill 中加入"相似度检测"步骤，Jaccard 相似度超过 0.7 的用例自动合并或去重。同时要求 AI 优先使用等价类划分方法，减少冗余。

坑 6：上下文丢失

现象：在对话式生成中，AI 逐步丢失上下文。比如第一步说了"预算编制需要审核"，第二步生成的用例就忘了这个前置条件。

根因：大模型的上下文窗口有限，长对话中早期信息被"遗忘"。

解决方案：

1. 采用 Agent 架构管理上下文，每个 Skill 执行时重新加载关键上下文，不依赖单次对话
2. 在关键节点使用 ConversationSummaryBufferMemory 组件，自动压缩和摘要历史信息
3. 限制单次对话的轮次，超过 5 轮后自动重置上下文

坑 7：模型幻觉导致"假用例"

现象：AI 生成了某个 API 的测试用例，但该 API 实际上并不存在（AI 自己编造了接口）。

根因：大模型有"幻觉"倾向，尤其是在细节层面。

解决方案：构建了"接口契约验证"环节。所有涉及 API 调用的测试用例，必须先在 Swagger/OpenAPI 规范中验证接口是否存在。如果 AI 生成的用例引用了不存在的 API，Agent 自动标记并触发重新生成。

六、效果数据与反思

6.1 量化指标

经过三个月的迭代，我们在财政系统某子模块上采集了以下数据：

最让我们惊喜的是"评审缺陷发现率"——AI 生成的用例经过人工评审后，发现的缺陷数量反而更多了。这说明 AI 并不是替代了测试工程师，而是帮测试工程师腾出了时间，让他们能更专注地做深度思考。

6.2 反思：什么场景适合 AI

根据我们的实践，AI 生成用例在不同场景下的表现差异很大：

适用场景（采纳率 > 70%）：

• 标准化的单据校验（预算申报、支付申请、采购计划）
• 接口层面的正向/反向测试
• 规则的排列组合（多种指标类型 × 多种支付方式）
• 边界值和等价类测试

不适用场景（采纳率 < 40%）：

• 高度依赖业务经验的探索性测试
• 涉及多系统联调的集成场景
• 需要深度业务洞察的风险识别
• 合规性审计相关的专项测试

所以我的建议是：把 AI 当作一个执行力超强但业务理解为零的初级测试工程师。你负责给清晰的需求、明确的规则、关键的知识库，它负责铺底稿、补覆盖、提效率。最终的判断和决策，永远在人工手里。

七、未来方向

目前我们正在尝试的几个方向：

1. 从用例生成到全流程自动化：让 AI 不仅生成用例，还能自动构造测试数据、执行测试、比对结果、生成报告

2. 多模态输入：支持从 PRD 文档、系统原型图、流程图等多种输入源中理解需求，减少对文本的依赖

3. 反馈闭环：将人工评审中对用例的增删改操作记录下来，持续反哺大模型，让 AI 的生成风格越来越贴近团队的习惯

4. 跨项目复用的 Skills 市场：将财政系统中沉淀的 Skills 标准化，让新项目可以直接引用已有的能力模块

最后说一句：测试的本质不是写用例，而是发现风险。AI 帮我们更快地写用例，并不意味着风险变少了。恰恰相反，效率提升后，我们需要把更多精力放在——什么应该测、什么优先级高、什么场景值得深挖。这才是测试工程师真正的核心竞争力。

—— 浅木·先生，2026 年 6 月