1. 为什么你的AI测试用例生成效果不理想？
我最近在技术社区看到不少同行抱怨："用AI生成的测试用例根本没法用！"、"写出来的全是废话！"、"覆盖的场景完全不靠谱！"。作为一个在测试领域摸爬滚打十年的老兵，我必须指出一个残酷的事实——95%的测试工程师在用错误的方式给AI下指令。
上周我review了一个团队的自动化测试代码，发现他们用这样的提示词生成测试用例："为登录功能写测试用例"。结果AI返回了20条用例，其中15条是重复验证用户名密码必填，剩下5条是毫无意义的边界值测试（比如输入1000个字符的用户名）。这就像让米其林大厨煮泡面——不是厨师不行，是你没给对食材清单。
2. 测试用例生成的三大核心提示原则
2.1 明确测试目标层级
AI需要知道你在测试什么层级的逻辑。对比这两个提示词：
❌ 错误示例："测试登录功能" ✅ 正确示例："针对Web系统的用户名密码登录模块，编写界面交互层的功能测试用例，重点验证：1) 不同浏览器下的元素渲染 2) 错误提示的显隐逻辑 3) 登录状态cookie设置"
我常用的目标层级模板：
[系统类型]的[模块名称]模块，编写[单元/集成/系统]测试用例，重点验证： 1) [核心业务逻辑1] 2) [关键异常场景2] 3) [特定技术实现3]2.2 提供上下文约束
没有约束条件的测试用例就像没刹车的赛车。看看这个真实案例：
某电商团队用AI生成购物车测试用例时，AI给出了"测试100万件商品加入购物车"的用例。实际上他们的系统设计上限是999件。应该这样写提示词：
"生成B2C电商平台购物车模块的测试用例，已知：
- 系统限制：单次添加≤999件
- 业务规则：跨境商品不能与普通商品合并结算
- 技术实现：Redis缓存超时30分钟"
2.3 定义验收标准颗粒度
这是最容易被忽视的关键点。对比两组提示词：
❌ 模糊标准："测试支付功能" ✅ 明确标准："生成移动端支付宝支付的测试用例，每个用例必须包含：
- 前置条件（如：已绑定银行卡）
- 操作步骤（点击→输入→确认）
- 预期结果（包含界面变化+后台日志特征）
- 重要程度标记（P0/P1/P2）"
我的验收标准检查清单：
- [ ] 是否包含正向/逆向场景？
- [ ] 是否标注了优先级？
- [ ] 是否关联到需求ID？
- [ ] 是否包含验证点具体值？
3. 不同测试类型的提示词配方
3.1 功能测试用例模板
作为[角色]，我需要测试[功能模块]的[具体场景]， 已知业务规则： 1. [规则1] 2. [规则2] 技术约束： 1. [约束1] 2. [约束2] 请生成[数量]个测试用例，要求： - 包含[比例]%的异常流测试 - 每个用例标明验证的[需求编号] - 使用[Given-When-Then]格式 - 特别关注[边界条件]实际案例：某金融APP的转账功能
作为测试工程师，我需要测试手机银行转账功能的核心流程， 已知业务规则： 1. 单日累计限额5万元 2. 对方账户需先验证姓氏首字 技术约束： 1. 交易超时时间2分钟 2. 不支持并发交易 请生成15个测试用例，要求： - 包含30%的异常流测试 - 每个用例标明验证的REQ-228 - 使用Given-When-Then格式 - 特别关注金额边界值和超时场景3.2 性能测试用例模板
针对[系统组件]的[性能指标]测试， 环境配置： - [硬件规格] - [网络条件] - [软件版本] 测试策略： 1. 基准测试：[并发量]用户，[业务场景] 2. 负载测试：从[起始值]到[峰值]的[递增方式] 3. 稳定性测试：[持续时间]的[压力水平] 验收标准： - [指标1] ≤ [阈值1] - [指标2] 保持在[范围] - 错误率 < [百分比]3.3 安全测试用例模板
对[系统入口点]进行[安全测试类型]测试， 重点关注： 1. [漏洞类型1]防护 2. [合规要求2]符合性 测试约束： - 不使用[禁止工具] - 避开[敏感时间段] - 遵循[测试规范] 预期输出： - 每个漏洞的[重现步骤] - [风险等级]评估 - [修复建议]方向4. 高阶提示词技巧
4.1 链式提示法
不要指望一个提示词解决所有问题。我常用的三段式链式提示：
第一轮：需求澄清
你是一位资深测试专家，现在需要为[系统名称]设计测试用例。 请先向我提问，收集必要的需求信息。 每次只问一个问题，直到你认为信息足够。第二轮：用例生成
基于以上信息，请： 1. 列出所有业务规则对应的验证点 2. 对每个验证点设计3种测试方法 3. 标注可能遗漏的边界条件第三轮：用例优化
对上述用例进行： 1. 去重合并相似用例 2. 按[优先级标准]排序 3. 补充前置条件清理步骤4.2 对抗性测试设计
让AI自己找漏洞的提示词：
假设你是系统的恶意攻击者，请： 1. 找出[功能模块]最可能被滥用的3个路径 2. 为每个路径设计看似合法的异常操作 3. 预测系统可能出现的非预期行为4.3 基于代码的用例生成
对于已有代码库的情况：
分析以下[代码片段]： [粘贴关键代码] 请： 1. 提取所有条件判断语句 2. 为每个条件设计2个测试输入 3. 生成对应的mock数据模板5. 常见坑点与解决方案
5.1 用例重复率高的问题
现象：AI反复生成相同场景的不同表述
解决方案：在提示词中加入：
避免生成相同验证目标的用例，每个用例必须满足： - 验证不同的业务规则 - 或使用不同的输入组合 - 或针对不同的技术组件5.2 边界条件覆盖不足
现象：AI只生成常规值测试
解决方案：明确要求：
必须包含以下边界测试： 1. [类型1]的极小值/极大值 2. [类型2]的非法格式 3. [状态3]的临界转换5.3 验证点不明确
现象：用例中只有操作步骤没有预期结果
解决方案：模板强制约束：
每个测试用例必须包含： [操作步骤] -> [系统反应] -> [数据库变化] -> [日志特征] 四重验证点6. 工具链实战建议
6.1 Postman+AI工作流
我的自动化测试配方：
- 用AI生成用例大纲
- 导入Postman生成集合
- 用AI补充测试数据
- 人工校验关键断言
示例提示词：
基于以下API文档： [粘贴Swagger片段] 请： 1. 生成10个测试场景 2. 为每个场景设计3组测试数据 3. 给出预期的status code和response字段验证规则6.2 Selenium脚本生成技巧
高效提示词结构：
为[页面URL]的[功能模块]编写Selenium测试脚本， 要求： 1. 使用Page Object模式 2. 包含显式等待逻辑 3. 对[元素定位器]做异常处理 4. 输出allure报告注解 已知元素定位方式： - 用户名输入框：id=username - 密码输入框：xpath=//input[@type='password']6.3 与测试管理平台集成
对于TestRail等平台：
将以下测试用例转换为TestRail兼容的CSV格式： [粘贴用例文本] 要求： 1. 按[模板字段]映射 2. 添加自定义标签 3. 保持步骤和预期结果的分列我在实际项目中发现，当AI生成的用例要导入JIRA时，提示词中加入"每个用例的摘要不超过50字符"能大幅减少后续维护成本。
