软件测试 AI Skill 01:从需求文档生成可执行测试用例

文章导读 · 3个核心看点

很多测试同学第一次让 AI 写用例，输入只有一句话：根据这份需求生成测试用例。

结果通常看起来很完整，却藏着三个问题：它可能把常见业务习惯当成当前项目规则；不同轮次生成的用例结构不一致；功能、接口、性能和自动化标准混在一起，最后还要人工重新整理。

这一篇是“软件测试 AI Skill”系列的第 1 篇。我们先不追求自动执行，而是把最基础、也最容易失控的一步做好：把 PRD、需求说明或接口文档，稳定地转成可执行、可评审、可保存的测试用例。

一次性的 Prompt 能告诉 AI“这次要做什么”，但很难长期约束“以后每次都按什么标准做”。

测试用例生成 Skill 的作用，是把触发条件、通用测试策略、不同测试类型的标准、输出字段和保存规则固定下来。这样换一份需求时，变化的是业务内容，不变的是团队的用例方法。

本文采用的示例 Skill 名称是 doc-based-testcase-generator，目录可以这样组织：

其中，SKILL.md 负责说明何时触发、采用什么通用策略、如何工作以及何时保存；references/ 放四类用例的覆盖标准；assets/ 放团队现有的 Word 或 Excel 用例模板；docs/ 保存说明材料或生成结果。

一句话概括：你负责提供可信的需求，Skill 负责按固定方法和标准生成候选用例。

— 测试用例生成 Skill 的输入、标准与输出

这个 Skill 最适合处理可复制的需求文本，例如 PRD、需求说明、用户故事、接口文档、OpenAPI 描述、Markdown 或表格内容。

如果材料只有截图、PDF 扫描页或不可复制的 Word 页面，先把关键内容转成文本再输入。原因很简单：AI 只有读到准确的字段、状态和约束，才能把用例追溯回需求。模糊截图可以作为辅助，但不应该成为唯一证据。

发起请求时，除了粘贴正文，最好再补四项信息：

可以直接使用下面这份输入框架：

这一步的目标不是把 Prompt 写得很长，而是让输入具备范围、重点、格式和边界。

通用策略负责正向、反向、边界值、等价类、状态与流程等基本覆盖；四份参考标准负责把不同测试类型进一步写细。

功能用例：看流程、状态、角色和数据

功能用例至少要覆盖主流程、分支与异常流程、端到端场景、合法与非法状态迁移，以及不同角色允许的操作和越权行为。涉及页面时，再补必填校验、多步骤操作和回退；跨模块时，要写清前置数据和关联结果。

用例标题最好能概括“谁在什么条件下做什么，预期什么”，步骤必须可以执行，预期结果要能与 PRD 对照验收。

接口用例：看参数、错误码、鉴权和并发

接口用例不能只测一个成功响应。要继续检查必填缺失、类型或格式错误、边界值、可选参数不传或传空、成功响应结构，以及文档里定义的每个错误码。

如果接口有鉴权，还要覆盖未带凭证、凭证无效或过期、越权访问。只有文档明确涉及幂等、并发或限流时，才加入重复提交、超并发和限流用例，不能凭常识硬补。

性能用例：先有指标，再设计负载

性能用例需要明确响应时间、吞吐量或 QPS、资源容量等指标，再区分基准、稳态负载、峰值或尖峰、长时间稳定性场景。每条用例要写清并发、时长、数据量级、通过标准和观察点。

如果需求没有性能指标，正确输出不是虚构一个数字，而是把“目标值、环境规格、数据量级”列为待确认。

自动化候选：先判断值不值得自动化

适合自动化的用例通常规则稳定、可重复、执行频率高、断言明确、接口或页面可脚本化，而且测试数据和依赖能够构造。

强主观、探索性、一次性、低频，或者环境与数据难以自动恢复的场景，可以保留为手工用例或低优先级候选。Skill 负责标记，最终是否进入自动化排期仍由测试团队决定。

一份可用的结果，至少应包含：用例编号、用例标题、模块或接口、用例类型、优先级、前置条件、测试步骤、预期结果和备注。

以登录模块为例，生成结果不应该停留在“测试正确密码、测试错误密码”，而要落到下面这种粒度：

这里故意没有写具体提示语、HTTP 状态码或锁定时长，因为示例需求没有提供这些规则。Skill 可以把缺口暴露出来，但不能把猜测伪装成已确认需求。

第一步：准备文档内容

把需要覆盖的 PRD、需求说明或接口文档整理为可复制文本。只截取本次模块，避免把无关背景、旧版本说明和已废弃规则一起送入。

第二步：发起生成请求

说明“根据这份文档生成测试用例”，再补充接口、性能、自动化候选或公司模板等侧重点。Skill 会按 SKILL.md 选择通用策略，并加载对应的参考标准。

第三步：评审结果并按需保存

结果可以直接显示在对话中，也可以明确要求保存到指定目录或对齐 assets/ 里的 Word、Excel 模板。默认不应静默写文件；只有你给出保存要求或路径时，才落盘。

第一，规则有出处。每个关键预期都能回到需求、接口契约或已确认的业务说明。

第二，步骤可执行。换一个测试人员，也能按前置条件和步骤复现，而不是只看到“验证登录功能正常”。

第三，结果可观察。页面提示、接口响应、数据库状态或日志事件至少有一个明确观察点。

第四，优先级合理。核心链路、资金与权限风险不能因为用例很多而被普通场景淹没。

第五，未知项已标记。业务规则、环境差异和数据依赖如果未确认，就保留“待确认”，不要直接进入回归集。

AI 在这里最适合做的是扩大候选范围、统一结构和减少重复整理；测试工程师负责确认业务事实、风险权重和最终放行。

用 AI 生成测试用例并不难，难的是每次都按同一套标准生成，并且让结果可以评审、执行、保存和追溯。

从第一个 Skill 开始，先把输入、标准、输出和人工门禁固定下来。这样后面继续接接口分析、自动化脚本、执行结果和测试报告时，整个流程才有可靠的起点。

下一篇，我们继续拆“软件测试 AI Skill 02”：如何让 AI 从接口文档中补齐异常场景，而不是只会生成成功用例。