如何利用AI编写测试用例

m0_63878364

386人浏览 · 2026-06-17 18:07:48

m0_63878364 · 2026-06-17 18:07:48 发布

随着 AI 能力的不断提升，它能帮助我们完成的事情也越来越多。在软件测试工作中，AI 可以用来辅助理解需求、整理测试点、补充测试场景，并生成测试用例。

不过，AI 生成测试用例并不是简单地把需求文档丢给它，然后让它直接输出结果。这样虽然能很快得到一份用例，但实际可用性往往不高。本文会结合实际使用经验，分享一种更适合日常测试工作的方式：如何让 AI 生成更贴近业务、更容易落地的测试用例。

一、直接让 AI 根据需求生成用例，为什么效果不好

最开始使用 AI 写测试用例时，常见做法是把需求文档直接发给 AI，然后让它根据需求生成测试用例。

这种方式确实很方便，但也有一个明显问题：AI 往往只会围绕当前输入的需求内容进行分析。需求里写了什么，它就生成什么；需求里没写清楚的地方，它通常不会主动结合项目已有逻辑去补充。

例如，一个需求只描述了新增某个页面配置项，AI 可能只会关注这个配置项本身是否展示、是否可以保存，却容易忽略：

这个配置项和已有业务流程之间的关系；
不同角色、不同页面、不同设备下是否应该生效；
历史功能是否会被影响；
异常输入、边界情况、多语言等细节场景。

所以，直接让 AI 根据单份需求文档生成用例，生成速度很快，但用例往往不够完整，也不一定符合真实业务。

二、第一步：先建立项目业务知识库

为了解决这个问题，我们需要先让 AI 了解项目本身。

这里的“业务知识库”不需要一开始做得很复杂。简单来说，就是把项目中稳定存在的业务规则、页面逻辑、角色权限、状态流转、字段规则等内容整理出来，形成一份可以长期复用的业务资料。

在实际操作中，可以先从这些内容开始整理：

核心业务流程：用户从哪里进入，经过哪些步骤，最终完成什么操作；
页面和功能说明：每个模块有哪些入口、按钮、字段和状态；
角色权限：不同角色能看到什么、能操作什么；
业务规则：哪些条件下展示，哪些条件下隐藏，哪些状态不能操作；

整理好这些内容后，再让 AI 从文档中提取出可以复用的知识点。这样做的目的，是让 AI 在后续写测试用例时，不只是看当前需求，而是能够结合项目已有逻辑一起思考。

以下是提炼业务规则的skill

---
name: extract-knowledge
description: >-
  从文本、Word、PDF 中提炼业务知识碎片，打标签并按模块分类写入 case/knowledge-base。
  在用户要求入库、提炼文档、学习资料、更新知识库、解析 Word/PDF 业务文档时使用。
---

# 知识碎片提取与分类

本 Skill **仅负责** 从原始材料提炼知识并写入知识库，不做需求分析、不写测试用例。  
**与 run-testcase 分工**：跑用例时默认**不**入库；用户输入「是否更新知识库：是」或 `run.py --update-kb` 时，run-testcase 会调用本 Skill 逻辑；也可单独调用本 Skill 维护文档。

## 路径约定（相对项目根）

| 用途 | 路径 |
|------|------|
| 知识库（按模块） | `case/knowledge-base/by-module/` |
| 知识库（公共规则） | `case/knowledge-base/common/` |
| 知识库（扁平/跨模块） | `case/knowledge-base/fragments/` |
| 原始材料（可选） | `case/sources/` |
| 碎片模板 | `knowledge-base/by-module/_template.md`、`common/_template.md`、`fragments/_template.md` |

在 `testing-script` 仓库根目录工作时，上述路径均以 `case/` 为前缀。

## 输入来源

| 来源 | 处理方式 |
|------|----------|
| 用户粘贴文本 | 直接提炼 |
| 人工录入 | 按用户口述/打字内容提炼 |
| Word `.docx` | `python-docx` 读取段落文本 + 解包 `word/media/*` 识别内嵌图片中的页面文案/按钮/状态信息；无依赖时提示用户粘贴正文或 `pip install python-docx` |
| PDF | `pdfplumber` 按页提取文本；无依赖时提示安装或粘贴 |

**支持**：图片内容识别（含 docx 内嵌图片）。

**不支持**：音视频（除非用户已转为文本）。

读取 Word/PDF 示例：

```bash
pip install python-docx pdfplumber
```

```python
# Word
from docx import Document
text = "\n".join(p.text for p in Document("case/sources/xxx.docx").paragraphs if p.text.strip())

# PDF
import pdfplumber
with pdfplumber.open("case/sources/xxx.pdf") as pdf:
    text = "\n".join(page.extract_text() or "" for page in pdf.pages)
```

## 执行流程

### 1. 确认输入

- 明确来源类型（文本 / Word / PDF）与文件路径
- 若材料过长，按章节分段提炼，最后合并去重

### 2. 提炼碎片

从材料中提取 **可测试** 的知识点，每条碎片包含：

- 业务规则、默认值、开关状态
- 数值限制、次数、上下限
- 状态流转、权限、异常表现
- 用户可见提示/文案要求（体验类）

对包含图片的材料，必须执行“图文融合”：

- 先提取正文规则，再逐图识别 UI 文案、按钮、徽标、告警样式、入口位置。
- 仅把可验证信息写入碎片（例如按钮文案、告警标题、卡片字段）；不确定的视觉细节标记为「待确认」。
- 当图片与正文冲突时，记录冲突并在 `边界与异常` 标注「文档冲突待确认」。

**不要**写入：无关背景、重复表述、无法验证的猜测。

### 3. 分类与打标签

对每条碎片：

1. **定 module / pages** → 决定写入 `by-module/{模块}.md`（模式 1.1）
2. **打 tags**（模式 1.2，必填，见 [reference.md](reference.md)）
3. 生成唯一 `id`：`kb-YYYYMMDD-序号`
4. 填写 `source`、`updated`

**分类规则**：

| 情况 | 写入位置 |
|------|----------|
| 属于单一模块/页面 | 追加到 `by-module/{模块名}.md` |
| 属于平台公共规则（如 Shopify） | 追加到 `common/{平台名}.md` |
| 跨 2 个及以上模块 | `by-module` 主模块文件 + `fragments/frag-{id}.md`（或仅 fragments，tags 列全相关模块） |
| 用户指定只用标签模式 | 每条写入 `fragments/frag-{id}.md` |

### 4. 去重合并

- `Grep` `knowledge-base` 中已有 `id`、`title`、关键句
- 已存在 → 更新原碎片并刷新 `updated`
- 不存在 → 追加（`by-module` 文件内用 `---` 分隔新碎片）

### 5. 输出回报

```markdown
## 入库结果

| 操作 | 文件 | 碎片 id | 标签 |
|------|------|---------|------|
| 新增/更新 | by-module/AI功能.md | kb-... | … |

### 摘要
- 共提炼 N 条碎片，新增 X 条，更新 Y 条
### 未收录（待确认）
- …
```

## 碎片正文结构

必须包含小节：`规则摘要`、`关键规则`、`边界与异常`、`测试关注点`。

## 禁止事项

- 不分析需求、不匹配需求、不生成测试用例
- 不编造来源中未出现的规则（不确定写「待确认」）
- 不写入 `~/.cursor/skills-cursor/`

## 附加资源

- 标签与分类细则：[reference.md](reference.md)
- 示例：[examples.md](examples.md)

三、第二步：给 AI 一份“写用例的参考规则”

有了业务知识库之后，AI 生成的用例会比之前好一些，因为它已经能结合一些业务背景来分析需求。

但在实际使用中，还会遇到另一个问题：AI 不一定会像测试人员一样，从多个角度主动补充测试场景。

比如我们平时写用例时，会自然想到：

涉及页面展示时，要看不同分辨率、不同设备是否正常；
涉及文案时，要看是否支持多语言、长文案是否换行或撑破页面；
涉及输入框时，要看空值、超长、特殊字符、重复值；
涉及权限时，要看不同角色是否都符合预期；
涉及配置项时，要看保存后是否生效，刷新后是否保留；
涉及前后台联动时，要看 B 端配置是否正确影响 C 端展示。

这些经验如果只存在测试人员脑子里，AI 是不一定能完整想到的。

所以，可以再准备一份“测试用例编写参考规则”，把平时写用例时经常会考虑的场景整理进去。之后每次让 AI 生成测试用例时，都要求它结合这份规则一起分析。

举个例子，如果需求涉及界面文案，就提醒 AI 额外考虑：

默认语言下文案是否正确；
切换语言后文案是否翻译；
文案过长时是否换行、截断或遮挡按钮；
不同屏幕宽度下展示是否正常。

如果需求涉及设备兼容，就提醒 AI 额外考虑：

Windows 浏览器；
Mac 浏览器；
iOS 手机端；
Android 手机端；
桌面端和移动端展示差异。

这样做以后，AI 生成的用例会更接近测试人员平时的思考方式，而不是只围绕需求表面内容展开。

 文案与界面展示

| 触发条件 | 必须考虑 | 建议测法 |
|----------|----------|----------|
| 涉及**固定文案**（标题、按钮、提示、占位、系统提示） | **页面翻译 / 多语言** | 切换界面语言（`kb-301`）后：文案是否翻译、布局是否撑破、功能是否仍可用 |
| 涉及**用户可见 PRD 原文** | 默认语言 + 至少一种非默认语言 | 原文与翻译后文案分别写进预期；未翻译处标 BLOCKED |
| 涉及**消息区文案**（AI 回复、卡片、操作记录） | 与 **智能翻译条** 共存（`kb-20260603-003`） | 消息语言 ≠ 翻译设置时出现翻译条；一致时不出现 |
| 涉及**长文案** | 换行、截断、窄屏 | 超长标题/描述/备注不遮挡按钮 |