#SKILL进化论：测试工程师如何让AI越用越聪明

#一个测试工程师的日常

早上 9 点，你打开电脑，禅道上又多了 300 条待自动化的用例。

300 条用例，意味着 300 种不同的业务场景。每条用例都涉及到相关业务逻辑的理解，用例步骤的拆分，方法调用，断言策略的设计，跑一遍修 Bug，提交代码。

做完这些不算完，用例写完只是起点，持续的用例维护、框架升级适配、用例稳定性优化，才是真正的深水区。

#问题的本质

自动化测试用例的编写，确实存在高度结构化的部分：

但结构一样不代表工作简单。

每条用例背后都需要：

于是就有了本文的核心命题：

如何让 AI 不仅"能写"，更要"会写"——而且越写越好？

答案：SKILL + 进化。

#一、SKILL 快速入门

#1.1 什么是 SKILL？

SKILL 是 AI Agent 的扩展机制。

创建一个 SKILL.md 文件，Agent 会把它加载到工具包里。当你的任务匹配 SKILL 的描述时，Agent 自动调用它——就像测试框架根据标签自动匹配用例一样。

#1.2 什么时候该写 SKILL？

以下信号出现时，就应该考虑创建一个 SKILL：

#1.3 SKILL 的存放策略

#1.4 SKILL 的目录结构

以 write-case 技能为例，一个实战级的 SKILL 目录结构：

write-case/
├── SKILL.md                  # 主文件：工作流指引
├── checklist.md              # 写用例后执行检查清单
├── references/               # 按需加载的参考文档
│   ├── code_style.md         # 用例代码写法规范（模板、注释、fixture 等）
│   ├── assertions.md         # 断言方法速查
│   ├── dialogs.md            # 对话框速查表
│   ├── dialogs_patterns.md   # 对话框操作模式（桥接铜、跳线、筛选等）
│   ├── ele_methods.md        # Ele 对象方法、复选框、下拉框等元素操作
│   ├── keyboard_modeless.md  # 键盘操作、无模命令、放大视图
│   ├── right_click_menus.md  # 右键菜单速查表
│   └── workflows.md          # 完整操作流程（最佳实践）
└── scripts/                  # 可执行脚本
    └── fetch_zentao_case.py  # 从禅道 API 获取用例信息

核心文件只有 SKILL.md，其余文件按需引用、按需加载——主文件保持精简（约 150 行），AI 只在需要时才读取详细资料，上下文窗口不会被无关内容填满。

#1.5 一个最小 SKILL 示例

---
name: write-case
description: 根据测试用例信息（禅道ID或手动提供），生成符合项目规范的 SailWind Layout 自动化测试用例代码。
---

# Write Case

## 核心原则
1. 先看规范，再写代码
2. 调用封装方法（LayoutExport 门面类），不写底层操作
3. 断言资源统一管理（`res_assert_XX("NNN")`）

## ⚠️ 铁律（不可违反）
- **断言铁律**：中间步骤不加断言，最后一步必须有断言
- **注释铁律**：禅道步骤/预期原文一字不差保留为代码注释

## 写作流程
1. 解析输入（模块编号 / 禅道 CaseID / 手动提供步骤）
2. 从禅道 API 获取用例详细信息（如需要）
3. 读取 references/code_style.md 确认代码规范
4. 参考同模块相邻用例，复用 fixture 前置步骤模式
5. 按标准模板生成代码，同步 tag CSV，执行 checklist 检查

#二、SKILL 进化四阶段

SKILL 的核心价值不在于"写出来"，而在于"持续进化"。以下是一套经过实战验证的四阶段方法论，核心目标只有一个：

让 SKILL 自己卷自己，越用越聪明。

#阶段一：裸考 —— 给 AI 摸底

#什么叫"裸考"？

不给 Agent 任何额外提示，只给它两份材料：

1. 教材：现有用例工程（case/24/test_24_001.py、method/layout/ 方法库、断言资源 case/24/assert_res/）
2. 考题：一条具体的禅道用例需求（如 CaseID 24759：修改管脚对特性中的线宽）

然后让它自己写，目的不是要一个能用的结果，而是看清它的"原始水平"。

#裸考暴露的典型问题

以下是 write-case 项目裸考阶段发现的真实问题：

#阶段二：人工批卷 —— Human-in-the-Loop

#批卷不是"改错"，是"提炼规则"

AI 写出来的代码，乍一看像那么回事，实际跑起来十有八九有问题。

人工介入需要做三件事：

1. 修 bug    → 让脚本能跑起来
2. 改习惯    → 让代码符合团队规范
3. 做记录    → 把每次修改转化为可复用的知识

#批卷记录模板

#阶段三：出师立规 —— 让 AI 生成 SKILL

#给 SKILL 一个清晰的定位

write-case 技能回答的核心问题：

"一个合格的 SailWind Layout 自动化测试用例长什么样？"

#需要喂给 AI 的材料

1. 现有用例工程：case/24/, case/25/, case/32/ 等模块的用例代码
2. 方法库结构：method/layout/ 下的 LayoutExport 门面类及其对话框/方法模块
3. 历史批卷记录（第一轮、第二轮……）
4. 人工总结的经验教训：两条铁律、按需加载模式、禅道集成流程

然后让 AI 自己生成 SKILL——用 AI 写教 AI 的说明书。

#SKILL 文档结构建议

# Write Case

## 定位
指导 Agent 编写符合项目规范的 SailWind Layout 自动化测试用例。

## 前置知识
- 参考用例工程路径：`case/XX/`（XX 为模块编号，如 `case/32/`）
- 代码写法规范：`references/code_style.md`
- 方法库结构：`method/layout/` → `LayoutExport` 门面类，聚合所有模块操作

## 输入解析
- 1~3 位数字 → 模块编号（批量模式，写下一条未自动化用例）
- 4 位及以上数字 → 禅道 CaseID（简写模式，自动识别模块）

## 核心铁律
- **断言铁律**：中间步骤不加断言，最后一步必须有断言
- **注释铁律**：禅道步骤/预期原文一字不差保留为代码注释

## 用例写作流程
1. 解析输入，从禅道 API 获取用例信息（调用 fetch_zentao_case.py）
2. 读取 references/code_style.md 确认代码模板
3. 查找同模块相邻用例作为参考（如写 test_25_019 优先参考 test_25_018）
4. 需要元素名时读 `*_ele.py`，需要流程时读 references/workflows.md
5. 按标准模板生成代码
6. 同步 tag/XX.csv
7. 执行 checklist.md 检查清单
8. 写入 case/XX/test_XX_NNN.py

## 常见错误及纠正

### 错误 1：直接操作底层元素，不调封装方法
- ❌ `layout.dialog.message_dialog.click()`
- ✅ `layout.dialog.message_dialog.ok_btn.click()`
- **依据**：所有 UI 操作通过 LayoutExport 门面类 + 对话框元素

### 错误 2：断言资源硬编码路径
- ❌ `layout.asserts.assert_image_exist("./case_res/063.png")`
- ✅ `layout.asserts.assert_image_exist(layout.res_assert_32("063"))`
- **依据**：资源路径通过 `res_assert_XX()` 按模块统一管理

### 错误 3：修改禅道注释原文
- ❌ `# 步骤 1: 点击右键菜单`（简化了原文）
- ✅ `# 步骤 1: 选择元器件J1的2号管脚右侧中间的导线段`（原文不动）
- **依据**：注释铁律 —— 禅道原文一字不差保留

### 错误 4：中间步骤添加断言
- ❌ 每个步骤后都有 `layout.asserts.assert_xxx()`
- ✅ 仅最后一步添加断言
- **依据**：断言铁律 —— 中间步骤不断言，最后一步必断言

### 错误 5：多余导入
- ❌ `from method.layout.dialog import pin_pair_properties`
- ✅ 只导入 `pytest`, `BaseCase`, `LayoutExport`
- **依据**：所有操作通过 LayoutExport 门面类访问

#阶段四：写入规则 —— 让闭环转起来

#配套的维护机制

SKILL 写好之后，如果没有配套的更新机制，不出三个月就会和实际脱节。

在项目 CLAUDE.md 中加入以下维护规则（write-case 项目实际采用的规则）：

## 写用例后必做检查

每次使用 /write-case 技能编写完测试用例后，必须检查并更新 SKILL 文档：

1. 读取 .claude/skills/write-case/SKILL.md
2. 检查本次写用例过程中是否使用了 SKILL 中未记录的新模式：
   - 新的对话框操作路径
   - 新的元素交互方式
   - 新的断言方法
   - 新的键盘/鼠标操作
   - 新的 fixture 前置步骤模式
3. 如有发现，将新模式补充到 SKILL references 对应文档中

## 用户手动修改用例后同步 SKILL

当用户手动修改了用例文件后：

1. 对比用户修改内容与 SKILL 中的已有模式
2. 用户是否将某种操作写法改成了更优方式？（如 `mousekey.downs` → `cell_select_item`）
3. 用户是否引入了 SKILL 中未记录的新元素或方法？
4. 用用户的改法更新 SKILL references，保持文档与实际代码同步

#进化闭环

整个进化闭环可以描述为：

第一步，Agent 基于当前 SKILL 规范编写用例。例如调用 写用例 32 24800，Agent 加载 write-case SKILL，从禅道获取用例信息，参考 case/32/test_32_066.py 的写法，生成 test_32_067.py。

第二步，人工审查并批改。发现 Agent 在某个对话框操作上用了次优写法，手动改为 cell_select_item("CAM.Solder mask.Adjust")。

第三步，将这次修改模式提炼为规范，更新到 references/ele_methods.md 中：layout.dialog.object_attributes.cell_select_item("属性名").click()。

第四步，Agent 在下一次写用例时，自动加载更新后的 SKILL，在相同场景下直接使用 cell_select_item，不再犯同样的错误。

四步走完一轮，回到第一步——循环往复。每完成一轮，SKILL 就比上一轮更完善，Agent 写的用例就比上一轮更规范。

#三、SKILL 进阶技巧

当 SKILL 经过几轮进化趋于稳定后，可以进一步利用以下特性提升效果。

#3.1 Frontmatter 配置

合理的 Frontmatter 配置能让 SKILL 在正确的时机被正确的方式调用。

write-case 实际使用的配置：

---
name: write-case
description: 根据测试用例信息（禅道ID或手动提供），生成符合项目规范的 SailWind Layout 自动化测试用例代码。
---

#3.2 禅道 API 集成

write-case SKILL 的一个核心能力：与禅道项目管理系统对接，自动获取用例信息。

# 自动识别模块编号，获取禅道 CaseID 24759 的用例信息
python scripts/fetch_zentao_case.py 24759

# 批量获取模块 29 下所有未自动化的用例列表
python scripts/fetch_zentao_case.py --module 29 <项目根目录>

智能输入解析：

• 写用例 29（1~3 位）→ 批量模式，自动取模块 29 下一条未自动化用例
• 写用例 24759（4 位+）→ 简写模式，通过 modulePairs 映射表自动反推模块编号
• 写用例 27 24759 → 指定模块 27，写 CaseID 24759

自动排除已自动化用例：脚本自动读取 tag/29.csv 和 case/29/test_29_*.py 文件头部注释，将已自动化的 CaseID 剔除。

#3.3 模块编号系统与 tag CSV 同步

write-case 项目中的用例按模块编号组织：

case/
├── 24/
│   ├── test_24_001.py
│   ├── test_24_002.py
│   └── assert_res/
├── 32/
│   ├── test_32_063.py
│   ├── test_32_064.py
│   └── assert_res/
...

每个模块对应一个 tag/XX.csv 文件，记录 ScriptID → 禅道 CaseID 的映射，实现双向追踪：

063,24800
064,24801
065,24802

写用例完成后，SKILL 流程自动执行 tag CSV 同步：从文件名提取 ScriptID（test_32_067.py → 067），从文件头注释提取禅道 ID，追加到 CSV。

#3.4 按需加载参考文档

write-case 的 references/ 目录有 8 个文档，SKILL 主文件控制在 150 行以内。指令明确告诉 AI 何时读取哪个文件：

## 按需加载参考文档

- **必读**：references/code_style.md（代码模板和注释规范）
- **需要具体元素名时**：直接读 method/layout/dialog/ 下的 *_ele.py，比 references 更准确
- **需要断言方法**：references/assertions.md
- **需要对话框操作**：references/dialogs.md 或 dialogs_patterns.md
- **需要键盘/无模命令**：references/keyboard_modeless.md
- **需要右键菜单**：references/right_click_menus.md
- **需要完整流程**：references/workflows.md

#3.5 Checklist 机制

write-case 使用独立的 checklist.md 文件，包含多项检查点。写用例完成后逐项打勾：

- [ ] 用例文件头：三行注释完整（文件名、禅道ID、用例标题）
- [ ] 导入：只导入 pytest, BaseCase, LayoutExport
- [ ] Fixture：setup_teardown 存在，前置步骤注释保留原文
- [ ] 注释风格：步骤/预期严格交替，禅道原文不修改不简化
- [ ] 断言：用例最后一步骤之后必须有断言
- [ ] 断言写法：状态栏/图像比对写法正确
- [ ] tag CSV：已同步追加 ScriptID,CaseID
- [ ] 前置步骤复用：优先参考相邻用例的实际坐标和写法
- [ ] 未定义方法/元素：遇到需要添加的，不停留，直接推断写法

#3.6 相邻用例参考策略

write-case SKILL 的一个关键设计：写用例时优先参考相邻编号的用例。

如写 test_25_019，优先参考 test_25_018，再往前参考 test_25_017。

为什么？因为相邻用例通常：

• 操作同一个模块的相近功能，共享相似的 fixture 前置步骤
• 使用相同的文档资源（open_document_from_ftp 路径相似）
• 使用相同的对话框和元素，坐标和参数可以直接复用

这条策略大幅提升了 AI 写用例的首次通过率。

#3.7 动态上下文注入

SKILL 支持在加载时运行 shell 命令，将实时数据注入提示词：

## 当前项目状态
- 最近修改的用例：!`git diff --name-only HEAD~1 | grep test_`
- 当前分支：!`git branch --show-current`

#四、总结

#三个关键认知

#最后的话

最好的工具不是让人不用干活，而是让人干更有价值的活。

当 AI 帮你搞定了用例编写这类重复劳动之后，你的时间就可以花在真正需要测试智慧的事情上——设计更巧妙的测试策略、挖掘更深层次的缺陷、优化整个质量保障流程。

这才是测试工程师的升级之路。SKILL 进化，共勉。