ToolNavs 发现实用AI工具
提交工具 登录
返回Ai提示词
测试用例提示词:贴入需求描述,AI一次列出正常、边界和异常用例

测试用例提示词:贴入需求描述,AI一次列出正常、边界和异常用例

Ai提示词 • Admin • • 14 次浏览

测试用例提示词要解决的,是需求评审完之后最耗时间的那一步:功能点都懂,可真坐下来写用例,正常流程写得顺,边界值和异常情况总要漏掉几条,等提测后才在缺陷单里补回来。下面这段提示词先把用例的分类、表格列和预期结果的写法全部定死,再把需求贴进去,AI 返回的就是一张能直接执行、也能导入用例管理工具的表。

这段提示词适合什么场景

新功能提测前补用例、老功能改版时整理回归清单、产品经理自己核对验收标准,都适合用它。前提是手里有一段写清楚的需求描述,原型说明、需求文档段落、用户故事都可以;如果只有一句口头需求,先把背景、入口、规则和限制补成一小段文字再贴,输出质量会差很多。

可直接复制的提示词

你是一名有 8 年经验的软件测试工程师。请根据下面的需求描述,设计一套可以直接执行的测试用例。

需求描述:{{需求描述}}
补充信息:{{补充信息,例如涉及的页面或接口、账号角色、数据限制;没有就写无}}

输出要求:
1. 用表格输出,列依次为:用例编号、用例标题、前置条件、操作步骤、测试数据、预期结果、优先级、用例类型。
2. 用例类型必须覆盖四类:正常流程、边界值、异常与报错、权限与角色,每类至少 3 条。
3. 边界值必须写出具体数值,例如长度上限、金额上限、提交次数上限,不要只写“输入最大值”。
4. 预期结果必须能核对:写清页面提示文案、数据变化或状态变化,不要写“功能正常”这类空话。
5. 表格之后单独列出“需求没写清、需要确认的问题”,把歧义逐条列出;不要自己编造规则把空白补上。

先输出表格,再输出待确认问题,表格前不要写长篇说明。

两个变量怎么填

  • {{需求描述}}:把需求原文整段贴入,包括业务规则、字段限制和状态流转,越具体越好。只写“做一个优惠券功能”,AI 只能按通用电商规则猜,猜出来的用例和你们的真实规则对不上。
  • {{补充信息}}:写清测试时能拿到什么,例如有哪几种账号角色、是否有现成的测试数据、功能走 App 还是网页。角色信息尤其重要,权限类用例全靠它生成。

填好之后长什么样

把需求换成“用户修改收货地址,地址文本最长 100 字,省市区必选,保存后新地址立即生效”这一小段,返回的表格里会出现这样的行:

编号标题测试数据预期结果类型
TC-04地址输入 100 字保存恰好 100 字的地址保存成功,列表页显示完整地址边界值
TC-05地址输入 101 字保存101 字的地址保存被拦截,提示字数超限边界值
TC-09未选择区县直接保存省、市已选,区为空定位到区县字段并提示必选异常与报错

看到这种带具体数值的行,说明提示词起作用了;如果返回的全是“验证保存功能正常”式标题,把输出要求第 3、4 条重复强调一遍再发一次。

结果不满意时这样追问

  • 用例太浅:追问“只保留高优先级用例,并为每条补上反向验证:故意输错时系统应该怎样拦截”。
  • 漏了重复提交:在补充信息里加上“同一用户可能连续点击保存”,再让它补一类“重复操作”用例。
  • 想转成自动化脚本:追问“把高优先级用例改写成 Playwright 测试步骤,每条给出定位方式和断言”。

最后提醒一句:AI 生成的用例适合做第一稿和查漏清单,涉及支付、权限和数据删除的用例,上线前仍要由测试人员按真实环境逐条跑一遍,尤其是它在“待确认问题”里列出的那些歧义点,往往正是需求评审时全场都没想清楚的地方。

推荐工具

更多