其他资讯
AI提示词
如何写ChatGPT提示词将测试场景补成覆盖异常路径的用例表完整攻略
摘要
通过四步提示词设计可引导ChatGPT生成覆盖异常路径的测试用例表：定义场景输入结构、用
要让ChatGPT真正帮你生成覆盖异常路径的测试用例表，光说“写点异常用例”可不够——模型天生就爱往“正常流程”上靠，你得下四道明确的指令才能把它拽回来。下面这套方法，是经过多次迭代总结出来的，每一步都踩过坑。
先说核心结论：提示词需要同时约束输入结构、强制枚举边界与非法值、指定输出格式，并且直接切断模型默认的“只写正常流”的惯性。四个步骤，缺一不可。
### 第一步：定义清晰的场景输入结构
在提示词的开头，就得把场景描述的字段模板固定死，别让ChatGPT自由发挥。要求用户严格按「功能模块」「主流程动作」「输入要素」三栏填写。举个例子：
> 【功能模块】登录页｜【主流程动作】提交手机号验证码｜【输入要素】手机号（11位纯数字）、验证码（6位数字）、网络状态（在线/弱网/断网）
这一步如果不写清楚，ChatGPT会把“输入要素”理解成模糊的业务名词，比如“用户信息”。一旦变成这种抽象概念，后续根本推导不出空值、超长、特殊字符这些具体的异常点。现实中踩过这个坑的人不在少数。
### 第二步：用否定指令 + 示例封住正常路径依赖
直接禁止生成“正常成功”类的用例——这是最关键的一步。在提示词里明确写：**不要包含任何预期结果为“登录成功”的用例；所有用例必须触发校验失败、系统报错、页面卡顿、数据错乱等可观察的异常现象。**
紧接着给一个强对比示例，让模型一眼看懂边界在哪：
- **错误示范** → 「输入正确手机号和验证码 → 登录成功」
- **正确示范** → 「输入手机号为138001380000（12位）→ 前端提示“手机号格式错误”，且不发起API请求」
这里有个必须守住的底线：**每个用例必须明确写出“触发条件 → 实际响应 → 可观测现象”三层结构**。缺一层，异常路径就漏掉了。比如只写“触发条件”不写“实际响应”，测试人员根本不知道系统到底该给什么反馈。
### 第三步：强制枚举四类异常维度
这一步是内容生成的骨架，必须把异常来源分类穷举清楚。
**方法一：按输入值类型穷举**
对每个「输入要素」分别生成：空值/Null、超长（如手机号输15位）、超短（如验证码输3位）、非法字符（手机号含字母）、格式错位（验证码含中文逗号）。注意，这里的“格式错位”往往被忽略——比如前端限制输入框只能输数字，但通过API直接传中文逗号就可能触发后端校验不同的分支。
**方法二：按系统层切分异常源**
- 前端拦截类：未发请求就报错（如正则校验失败）
- API返回异常类：HTTP 4xx/5xx、空响应体
- UI渲染异常类：验证码框显示`undefined`、弹窗内容错位
- 数据一致性异常类：验证码校验通过但账户被锁定，或账户已注销仍在Session中
**方法三：按环境变量注入故障**
- 网络层：弱网（首包延迟 > 3s）、断网、DNS污染
- 设备层：iOS Safari禁用localStorage、Android低内存杀后台后回前台
- 时间层：系统时间倒拨24小时导致token签名校验失败
特别提示：方法三里「系统时间倒拨」这个点，在OAuth2.0/JWT场景下几乎必现`SignatureInvalid`错误，但很多测试工程师容易忽略。必须单列一条，因为这类bug线上影响面极大——用户手机时间不准，就直接无法登录。
**方法四：组合异常**
两条甚至三条异常同时存在时，比如“弱网 + 输入超长字符 + 验证码含特殊符号”，这类组合往往能挖出深层逻辑漏洞。提示词里最好给一个示例。
### 第四步：锁定输出为带字段的表格文本
最后一步是格式固化。**直接用具体格式字符串把输出结构焊死**，禁止模型返回Markdown或自然语言描述。推荐格式：
```
输出严格为纯文本表格，字段顺序固定：
用例ID | 场景简述 | 异常触发操作 | 前置条件 | 预期异常现象 | 检查点（DOM/API/日志） | 优先级（P0/P1/P2）
```
其中「检查点」字段必须指定验证手段——光写“出现错误提示”不够，要精确到比如「检查Chrome DevTools Network面板是否出现`/login`接口调用」或「`grep -i "invalid_code" app.log`」。否则测试人员拿到用例根本没法执行，这个表格就废了。
这一步如果不锁死格式，ChatGPT大概率会返回长篇段落式描述，测试人员没法直接导入TestLink或Xray，又得手动整理，效率大打折扣。
---
最后想说的是：这四步看似简单，但每一步都在跟ChatGPT的“懒惰倾向”做对抗。它天然想把用例写成“正常流程 + 少数异常”，而我们要做的是硬把它拉回“全异常路径”的轨道。只要提示词里把这四个约束都塞进去，生成出来的用例表直接拿来跑测试，基本不会有遗漏。你可以在实际项目中试试，有任何偏差欢迎回来讨论。
### 第一步：定义清晰的场景输入结构
在提示词的开头，就得把场景描述的字段模板固定死，别让ChatGPT自由发挥。要求用户严格按「功能模块」「主流程动作」「输入要素」三栏填写。举个例子：
> 【功能模块】登录页｜【主流程动作】提交手机号验证码｜【输入要素】手机号（11位纯数字）、验证码（6位数字）、网络状态（在线/弱网/断网）
这一步如果不写清楚，ChatGPT会把“输入要素”理解成模糊的业务名词，比如“用户信息”。一旦变成这种抽象概念，后续根本推导不出空值、超长、特殊字符这些具体的异常点。现实中踩过这个坑的人不在少数。
### 第二步：用否定指令 + 示例封住正常路径依赖
直接禁止生成“正常成功”类的用例——这是最关键的一步。在提示词里明确写：**不要包含任何预期结果为“登录成功”的用例；所有用例必须触发校验失败、系统报错、页面卡顿、数据错乱等可观察的异常现象。**
紧接着给一个强对比示例，让模型一眼看懂边界在哪：
- **错误示范** → 「输入正确手机号和验证码 → 登录成功」
- **正确示范** → 「输入手机号为138001380000（12位）→ 前端提示“手机号格式错误”，且不发起API请求」
这里有个必须守住的底线：**每个用例必须明确写出“触发条件 → 实际响应 → 可观测现象”三层结构**。缺一层，异常路径就漏掉了。比如只写“触发条件”不写“实际响应”，测试人员根本不知道系统到底该给什么反馈。
### 第三步：强制枚举四类异常维度
这一步是内容生成的骨架，必须把异常来源分类穷举清楚。
**方法一：按输入值类型穷举**
对每个「输入要素」分别生成：空值/Null、超长（如手机号输15位）、超短（如验证码输3位）、非法字符（手机号含字母）、格式错位（验证码含中文逗号）。注意，这里的“格式错位”往往被忽略——比如前端限制输入框只能输数字，但通过API直接传中文逗号就可能触发后端校验不同的分支。
**方法二：按系统层切分异常源**
- 前端拦截类：未发请求就报错（如正则校验失败）
- API返回异常类：HTTP 4xx/5xx、空响应体
- UI渲染异常类：验证码框显示`undefined`、弹窗内容错位
- 数据一致性异常类：验证码校验通过但账户被锁定，或账户已注销仍在Session中
**方法三：按环境变量注入故障**
- 网络层：弱网（首包延迟 > 3s）、断网、DNS污染
- 设备层：iOS Safari禁用localStorage、Android低内存杀后台后回前台
- 时间层：系统时间倒拨24小时导致token签名校验失败
特别提示：方法三里「系统时间倒拨」这个点，在OAuth2.0/JWT场景下几乎必现`SignatureInvalid`错误，但很多测试工程师容易忽略。必须单列一条，因为这类bug线上影响面极大——用户手机时间不准，就直接无法登录。
**方法四：组合异常**
两条甚至三条异常同时存在时，比如“弱网 + 输入超长字符 + 验证码含特殊符号”，这类组合往往能挖出深层逻辑漏洞。提示词里最好给一个示例。
### 第四步：锁定输出为带字段的表格文本
最后一步是格式固化。**直接用具体格式字符串把输出结构焊死**，禁止模型返回Markdown或自然语言描述。推荐格式：
```
输出严格为纯文本表格，字段顺序固定：
用例ID | 场景简述 | 异常触发操作 | 前置条件 | 预期异常现象 | 检查点（DOM/API/日志） | 优先级（P0/P1/P2）
```
其中「检查点」字段必须指定验证手段——光写“出现错误提示”不够，要精确到比如「检查Chrome DevTools Network面板是否出现`/login`接口调用」或「`grep -i "invalid_code" app.log`」。否则测试人员拿到用例根本没法执行，这个表格就废了。
这一步如果不锁死格式，ChatGPT大概率会返回长篇段落式描述，测试人员没法直接导入TestLink或Xray，又得手动整理，效率大打折扣。
---
最后想说的是：这四步看似简单，但每一步都在跟ChatGPT的“懒惰倾向”做对抗。它天然想把用例写成“正常流程 + 少数异常”，而我们要做的是硬把它拉回“全异常路径”的轨道。只要提示词里把这四个约束都塞进去，生成出来的用例表直接拿来跑测试，基本不会有遗漏。你可以在实际项目中试试，有任何偏差欢迎回来讨论。 来源：互联网
免责声明
本网站新闻资讯均来自公开渠道，力求准确但不保证绝对无误，内容观点仅代表作者本人，与本站无关。若涉及侵权，请联系我们处理。本站保留对声明的修改权，最终解释权归本站所有。
