#让AI学会写用例：自动化测试用例SKILL养成记

"我不想写用例，但我更不想一辈子都在写用例。" —— 一只不想卷的测试工程师

#前言

写自动化测试用例这件事，说白了就是个"熟练工种"。写多了，手熟了，但人也麻了。

更可气的是，当你好不容易摸清门道，准备躺平的时候，项目又来了新需求、新框架、新玩法……然后你又开始新一轮的"熟悉-熟练-麻了"循环。

直到有一天，我悟了：与其自己卷自己，不如让AI卷AI。

本文就来分享一套"AI教AI写用例"的实战心法，核心目标就一个：让SKILL自己卷自己，越用越聪明。

#一、先让AI"裸考"

#1.1 什么是裸考？

就是不给Agent任何提示，直接让它参考现有用例工程，自己写一条自动化测试用例脚本。

这一步的目的是什么？摸底考试。

你得让Agent先自己发挥一把，看看它的"直觉"是什么样的——是直接照搬现有代码，还是有自己的理解？是会写正确的用例结构，还是会放飞自我写出一堆天马行空的代码？

#1.2 操作步骤

1. 给Agent准备一份"教材"：现有用例工程（包含方法库、用例示例、断言资源等）
2. 给Agent一道"考题"：一条具体的PMS用例
3. 让Agent自己写，写完不要管

#1.3 你会看到什么？

裸考阶段，Agent写出来的东西大概率会有这些问题：

这些问题不可怕，反而是好事——它们就是你后续教学的"重点"。

#二、人工"批卷"：让Human-in-the-Loop发挥作用

#2.1 为什么需要人工介入？

AI写出来的东西，乍一看像那么回事，但真跑起来，十有八九会有各种问题。

这时候就需要人工介入，做两件事：

1. 修bug：让脚本能跑起来
2. 改习惯：让代码符合团队规范

#2.2 批卷的艺术

批卷不是简单地把错误改掉，而是要：

• 记录错误类型：这次是什么类型的错误？
• 总结规范要求：团队对这类问题有什么约定？
• 提炼最佳实践：怎么写才是"标准答案"？

举个🌰：如果Agent写了一个很长的用例函数，你就把它拆分成多个步骤；如果Agent用了错误的断言方式，就告诉它应该用哪种断言。

#2.3 批卷记录模板

建议人工维护一个"批卷记录"，格式如下：

## 批卷记录

### 用例：test_xxx_001

| 问题 | 修改前 | 修改后 | 规范依据 |
|-----|-------|-------|---------|
| 命名 | testFunction | test_xxx_001 | 用例命名需以test_开头+模块+ID |
| 断言 | assert True | assert_image_exists | 使用统一的断言方法 |
| 资源 | hardcode路径 | 使用Config变量 | 资源路径需统一管理 |

这个记录非常重要，因为它会成为第三阶段的"教材"。

#三、出师立规：让Agent生成write-case SKILL

#3.1 什么是write-case SKILL？

简单说，就是一个专门教你怎么写自动化测试用例的"说明书"。

它应该包含：

• 用例工程的结构说明
• 命名规范（用例、方法、断言）
• 代码模板和示例
• 常见错误及正确写法
• 批卷记录的精华提炼

#3.2 怎么生成？

让Agent基于以下材料，自己生成SKILL：

1. 现有用例工程的结构和示例
2. AT开发规范文档
3. 批卷记录（第一轮、第二轮……）
4. 人工总结的经验教训

#3.3 SKILL文档结构建议

# write-case SKILL

## 定位
教Agent如何编写符合团队规范的自动化测试用例。

## 前置知识
- 参考用例工程路径
- AT开发规范
- 方法库结构

## 核心原则
1. 先看规范再写代码
2. 调用封装方法而非底层实现
3. 断言资源统一管理

## 用例写作流程
1. 获取PMS用例ID和标题
2. 参考工程中的示例用例
3. 复制PMS步骤到代码注释
4. 基于注释编写脚本
5. 检查命名、调用、断言是否符合规范

## 常见错误及纠正
### 错误1: xxx
**错误写法**: xxx
**正确写法**: xxx
**依据**: AT开发规范第X章

### 错误2: xxx
...

#四、写入规则：让机制保障闭环

#4.1 在AGENTS.md中增加维护机制

光有SKILL不够，还得有配套的"使用说明"，确保SKILL能被持续优化。

在AGENTS.md中加入以下内容：

## 用例SKILL维护规则

### 写用例后必做
1. 写完用例后，检查是否符合write-case SKILL的规范
2. 如果发现SKILL中没有覆盖的场景，**必须更新SKILL文档**
3. 更新内容需包含：场景描述、正确写法、示例

### SKILL.md维护规则
- 新增用例类型时，同步更新SKILL
- 发现SKILL与实际不符时，修正SKILL而非迁就
- 重大变更（框架升级、工具切换）需重构SKILL

### 手动修改用例后同步
- 如果人工修改了Agent写的用例，需将修改原因同步到SKILL
- 格式参考"批卷记录模板"
- 定期汇总，形成新的规范条目

#4.2 闭环流程图

┌─────────────────────────────────────────────────────────┐
│                      SKILL进化闭环                       │
└─────────────────────────────────────────────────────────┘

    ┌─────────┐      ┌─────────┐      ┌─────────┐
    │ Agent写用例 │ ──▶ │ 人工批卷 │ ──▶ │ 更新SKILL│
    └─────────┘      └─────────┘      └─────────┘
         ▲                              │
         │                              │
         └──────────────────────────────┘
              (学习最新SKILL再写新用例)

#五、总结：让SKILL自己卷自己

这套方法的核心逻辑就一句话：把人工经验变成Agent可以学习的规范，让每一轮"批卷"都成为SKILL进化的养分。

关键点回顾：

只要你坚持这个循环，用不了几轮，你就能发现Agent写的用例越来越"像样"了——命名规范了、调用正确了、断言也标准了。

到时候你就可以腾出手来做更有意思的事了，比如：

• 研究怎么让用例跑得更快
• 优化测试覆盖率
• 或者，干脆摸会儿鱼 🐟

最后送大家一句话：最好的工具不是让人不用干活，而是让人干更有价值的活。SKILL进化之路，共勉。