前言：

这篇不讨论「AI 能不能写好测试用例」。 只记录一件事：怎么把平时写用例时的检查规则，整理成一个可复用的 Skill，用的时候直接生成一版可 review 的用例初稿。

目标很简单：

• 不绑定具体项目

• 不需要复杂架构

• 0 基础照着做，也能跑出来

一、先说明做什么

这里的 Skill，你可以理解成：

一段固定规则的 Prompt，

不是智能体，不是工作流，也不是自动化测试。

我只做了三件事：

• 把写测试用例时常用的规则写清楚

• 固定输出结构

• 让需求作为输入，每次换需求就能用

二、这个 Skill 解决什么问题？

在日常测试里，最耗精力的不是「想用例」，而是反复做这些检查：

• 用例结构是不是乱了

• 有没有只写“符合预期”

• 有没有只覆盖正常流程

• 有没有悄悄脑补业务规则

所以我想要的是：

先生成一版结构稳定、不乱编规则的用例初稿 然后再人工 review、补充。

三、Skill 的核心思路

规则固定，需求可变，输出可控。

• 规则：我来定

• 需求：每次输入

• 输出：统一结构

四、可复用 Skill Prompt

你是一名测试工程师视角的测试用例生成助手。

你的任务是：
根据用户输入的【需求描述】，生成一组【结构化测试用例】，用于功能测试设计。

====================
【输出格式要求】
====================

每条测试用例必须严格包含以下字段（顺序与名称不得修改）：

用例名称：
前置条件：
操作步骤：
预期结果：

====================
【生成原则】
====================

1. 场景覆盖原则
- 必须覆盖以下三类场景：
  - 正常流程
  - 异常流程
  - 边界情况
- 用例数量控制在 6～12 条，优先覆盖核心业务路径

2. 操作步骤原则
- 操作步骤必须是明确、可执行的用户或系统行为
- 使用“点击 / 输入 / 选择 / 提交 / 校验”等具体动作描述
- 禁止使用“进行相关操作”“完成流程”等抽象表述

3. 预期结果原则
- 预期结果必须是可验证的结果
- 可通过页面提示、状态变化、数据变化或接口返回判断
- 禁止使用“系统正常工作”“符合预期”等空泛描述

4. 规则来源约束（非常重要）
- 不得臆造需求中未明确给出的业务规则
- 如必须使用假设规则（如长度上限、截止时间、次数限制）：
  - 必须在【前置条件】中明确标注为“假设规则”
  - 或注明“需与产品/需求确认”

5. 输出限制
- 不要输出任何解释、分析、总结或设计说明
- 不要描述你的思考过程
- 只输出测试用例本身

====================
【需求描述】
====================

{{input}}

{{input}} 表示用户输入的需求描述。

五、从零开始操作步骤

1. 登录进来，到技能商店：https://www.coze.cn/skills

2. 点击 创建技能

3. 点击到 技能 这里，注意，要选对位置。

4. 输入上面的 skill prompt

5. skill 在创建了，等着创建成功就行。

6. 完成后，可以在右侧输入需求，测试一下效果，也可以直接点击右上角 部署

7. 部署完成后，在我的技能里面，点击 立即使用

8. 输入需求，这里我以日报agent 的项目需求进行输入：

用户每天需要提交日报并完成打卡：

• 同一天只能打卡一次

• 日报当天可以多次提交，后一次覆盖

• 未提交日报不允许打卡生成用例后可以进行下载

9. 生成用例后可以进行下载

点评一下，这里生成的用例

这是一个非常重要的升级点：

跨日打卡：

假设规则：系统日期已切换至新的一天

零点边界：

需与产品/需求确认零点打卡逻辑

这一步，直接和 90% AI 生成用例拉开了。

六、这里刻意限制了 Skill 不做的事

这一步很关键，不然容易“看起来很强，实际不稳”。

这个 Skill 不会：

• 自己决定业务规则

• 替产品做决策

• 输出“符合预期”

• 当成最终测试用例

它只做一件事：

把一版结构完整、可 review 的用例先跑出来。

七、这个 Skill 适合什么、不适合什么

适合：

• 快速起一版基础测试用例

• 新需求刚出来，还在理逻辑

• 日常测试中减少重复劳动

不适合：

• 直接作为最终用例提交

• 复杂状态机 / 强依赖历史数据的场景

八、当前阶段的小结

目前这个 Skill 对我来说，更像一个：

把重复脑力活前移的工具。

能不能在更多复杂项目里稳定使用，

还需要后续继续实践。

---

后面如果有新的调整，我会再补记录。