测试工程师可能是最需要写 Prompt 的人群这话听起来有点反直觉但真不是玩笑。我们平时接触的自动化测试脚本、性能测试方案、接口测试用例本质上都是给系统下达精确指令而写 Prompt 给大模型干的也是同一件事。区别在于大模型不像接口那样有严格的参数校验它更像一个能力很强但偶尔会走神的实习生你指令写得含糊结果就跑偏。所以我一直觉得把测试工程师那套严谨的思维搬到 Prompt 编写上很多提示词不好用的问题能解决一大半。这篇内容我不是来讲什么宏大理论的就是想分享一套我自己在多个项目里反复打磨过的专门面向测试场景的 Prompt 编写框架附带可直接抄走的模板、调试思路和踩坑记录。无论你是刚接触 Prompt 的测试新人还是已经在用 AI 辅助写用例但总觉得结果不稳定的老手这篇文章应该都能给你一些实在的参考。1. 为什么测试场景的 Prompt 总是答非所问问题出在指令本身先说一个很常见的现象同一个问题别人问 AI 能得到像样的答案你问就得到一堆正确的废话。尤其在测试领域这种落差特别明显。我见过有人让 AI 写一个登录功能的测试用例结果输出了一堆验证用户名密码正确性这种等于没写的用例气得直呼 AI 不行。但真不是 AI 不行是你没跟它说清楚登录功能在你的项目里具体是什么样子。测试场景有个天然特性强上下文依赖。同样叫登录有短信验证码登录、扫码登录、第三方 OAuth 登录还有带滑块验证的登录。Prompt 里不说清楚是哪种AI 只能按它训练数据里最常见的理解来答而那个最常见往往跟你的业务差着十万八千里。这就像你把一个接口地址发给后端却不告诉他是 GET 还是 POST参数格式是什么他当然只能给你一个模棱两可的回应。另一个常见问题是指令里塞了太多目标却没有优先级。比如你写帮我检查这个页面的功能、性能、兼容性、安全性表面看很全面实际上 AI 不知道你先要什么、重点是什么于是它就在每个维度上都蜻蜓点水一下。测试工作讲究的是场景收敛和深度验证Prompt 也是一样一次让它聚焦一件事远好过让它一次覆盖十件事。还有个容易被忽略的细节很多测试同学写 Prompt 时完全不提供反面信息。什么叫反面信息就是你不需要它做什么。比如你只说要 SQL 注入测试用例没说不要包含需要额外工具的案例AI 可能就给你推荐一堆你没装的环境。测试里我们经常说用例要明确预期结果写 Prompt 也一样你希望它输出的形式、颗粒度、边界全都得定义清楚否则它只能自己发挥。2. 测试专用 Prompt 的底层框架把用例设计思维搬进指令里我说测试工程师写 Prompt 有天然优势就在于我们脑子里的那份测试思维是可以直接平移过来的。写测试用例要分前置条件、操作步骤、预期结果写 Prompt 也完全可以用这套结构。我自己实践中沉淀了一个四层结构简单说就是身份角色、背景信息、任务定义、输出约束。四个部分缺一个输出质量都会明显下滑。2.1 身份层别小看你是一个资深的XXX为什么身份这么重要因为大模型会根据你给它设定的身份动态调整它输出的语料风格、专业深度和用词习惯。有一种流传很广的说法是模型不知道自己是什么但实操中你会发现给它设定了十年经验的测试架构师这个身份后它输出的用例颗粒度明显更细会自己想到一些边界条件和异常场景。这个现象背后其实是大模型在学习时接触过不同身份的大量语料身份设定相当于一个触发器帮它从参数空间里找到更贴近该领域的那片区域。但身份设定有个坑不能只给身份不给证据。光说你是一个资深测试太虚了模型不知道资深意味着什么。更好的写法是把它具体化比如你是一个长期负责电商系统测试的资深测试工程师熟悉支付流程、库存扣减、并发场景的用例设计尤其擅长发现业务逻辑漏洞。这样模型就拿到了一份人设简历它接下来输出的内容都会往这个方向上靠。另外要提醒的是身份不要跟任务冲突。你让它扮演一个完全不懂测试的新手又问它请给我一份生产级别的压测方案这俩设定互相打架输出结果大概率四不像。身份层的设定要跟你期望的输出深度保持一致性。2.2 背景层给它吃的项目资料决定输出颗粒度背景信息是测试 Prompt 里信息密度最高的部分也是最容易被省略的部分。很多人觉得 AI 是万能的给它一个功能名就完事但 AI 不是你们项目的成员它不知道你的用户类型分几种不知道你的数据字典长什么样更不知道你的历史缺陷集中在哪个模块。你不给它足够多的背景信息它就只能用通用场景去脑补你的业务。我给项目写 Prompt 时习惯在背景层里塞这么几个要素项目类型和业务领域、目标用户特征、核心业务流程、关键数据约束。比如写一个订单退款的测试用例 Prompt我会在背景层里告诉 AI这是一个电商系统用户分个人用户和企业用户退款支持原路退回和账户余额退回退款申请后 48 小时内处理超过时效自动取消。这些信息看着琐碎但对 AI 生成用例的精准度影响巨大。背景信息还有一个作用帮 AI 建立合理的假设边界。测试领域有个术语叫预期结果AI 如果没有背景信息它无法判断什么样的结果才算符合预期。你把业务流程和规则喂给它它才能说清哪些情况是正常哪些情况算异常否则它只能输出那种验证系统能正确处理有效输入这种正确的废话。2.3 任务层把模糊目标拆成可执行的验证步骤任务定义这层核心就是解决到底让 AI 干什么的问题。不要只说帮我测一下登录功能要说清楚你要的是测试用例、测试报告、还是缺陷分析。不同的交付物输出的组织方式完全不一样。我常用一个技巧把大任务拆成子任务序列而不是给一个笼统的目标。比如我想让 AI 生成一套商品搜索功能的测试方案我不会直接说生成测试方案而是拆成三个子任务先梳理商品搜索的核心业务规则和约束条件再基于这些规则设计功能测试用例最后补充异常场景和边界条件的测试点。这样 AI 的输出就是有逻辑链条的完整方案而不是东一榔头西一棒子的碎片想法。这里其实用到了 Prompt 工程里一个叫思维链的思路。当你让模型分步思考时它的输出质量会显著提升。测试人员天然就在做分步思考这件事提取测试点、设计用例、执行验证、分析结果。把这个流程写进 PromptAI 的输出也就跟着流程走了。2.4 约束层明确不要什么和按什么格式给约束层是决定 Prompt 输出可用性的关键。很多 AI 生成的测试内容没法直接用问题就出在格式和边界上。你让它生成测试数据它给你写一堆 SQL 语句你让它给测试步骤它给你一段宏观的测试策略。这些不是它不懂是你没告诉它你想要的交付格式。我一般会在 Prompt 末尾加上明确的输出要求用表格呈现用例每行一条字段包含用例编号、前置条件、操作步骤、预期结果、优先级不要输出与测试无关的科普内容控制在多少条以内不要使用 JSON 格式不用给测试数据构造 SQL。这些要求听起来像是在限制它实际上是在帮它把输出框定在你真正能用起来的范围内。还有一个关键约束明确否定项。测试最怕的是什么漏场景。AI 生成用例时有个倾向就是喜欢写正常流程的用例对异常场景、权限场景、数据异常场景覆盖不够。你可以在约束层里写请确保覆盖以下场景网络异常、并发操作、权限不足、数据丢失、超时重试、非法输入。这等于帮 AI 划定了覆盖面它会往这个方向去补齐用例。3. 实测模板一套可以直接复制的测试用例生成 Prompt光讲框架不落地是耍流氓。这一节我给出一套我实际在用的 Prompt 模板你们可以直接套到自己项目里改改用。这套模板不是我凭空想出来的是经过多个项目验证、反复调优后的版本尤其是里面那些反常识的细节都是踩过坑之后补上去的。3.1 通用测试用例生成模板【角色】你是一位拥有10年经验的资深测试工程师长期负责大型Web系统的功能测试、接口测试和异常场景测试尤其擅长发现业务流程中的逻辑漏洞和边界条件问题。 【项目背景】这是一个B2B采购管理系统使用方为采购员和财务审批人。系统核心业务包括商品询价、生成采购单、审批流流转、订单状态变更。用户通过Web端访问移动端暂不涉及。同一采购单在同一时间只允许一个审批人操作审批通过后可修改但不能删除。 【本次任务】请为商品询价功能生成完整的测试用例集。你需要分三步完成 第一步梳理商品询价功能的核心业务规则输出一段规则描述 第二步基于业务规则设计功能测试用例覆盖正常流程、异常流程和边界条件 第三步补充你作为资深测试认为应该覆盖但容易遗漏的特殊场景。 【输出要求】 1. 测试用例使用表格形式输出包含编号、用例名称、前置条件、操作步骤、预期结果、优先级。 2. 至少输出20条用例优先级分为高、中、低三档高危场景涉及金额计算、权限控制、数据一致性必须标记为高优先级。 3. 不要输出与测试用例无关的内容不要输出测试计划和测试报告。 4. 不要只关注功能正反向请额外关注数据并发、权限隔离和状态流转异常。 5. 使用简体中文输出语气专业简洁。这套模板看着长但每个部分都对应我前面讲的四个层。实际用下来它生成的用例质量比只说帮我写商品询价的测试用例要高出几个档次。尤其是加了同一采购单在同一时间只允许一个审批人操作这条背景后AI 会自动生成并发操作、重复提交流程的用例这是没有背景信息时它一定想不到的角度。3.2 接口测试用例生成模板接口测试的 Prompt 跟功能测试不太一样它更依赖技术细节的输入。没有接口文档的完整信息AI 生成的接口用例就只能是空中楼阁。我个人用下来的经验是接口测试 Prompt 里最重要的一段是接口参数说明哪怕你只是把参数字段名和类型贴给它生成的用例可用性都会高很多。【角色】你是一名擅长接口测试的测试开发工程师熟悉RESTful API的设计规范和常见异常场景对HTTP状态码、请求头、鉴权机制、幂等性设计有深入理解。 【接口信息】 接口路径/api/v1/purchase/orders 请求方法POST 功能描述创建采购单 请求头Content-Type: application/jsonAuthorization: Bearer token 请求体参数 - merchantId (string, 必填, 商户ID) - items (array, 必填, 商品列表至少包含一项) - itemId (string, 必填) - quantity (int, 必填, 1~999) - price (decimal, 必填, 保留两位小数) - remark (string, 选填, 最长200字) 【本次任务】请为上述接口设计接口测试用例覆盖以下维度 1. 参数校验必填项缺失、字段类型错误、长度超限、边界值 2. 业务逻辑正常创建、重复提交、商品库存不足、价格精度问题 3. 鉴权与安全未带token、token过期、越权访问其他商户数据 4. 异常场景服务端超时、返回非预期状态码、响应数据格式异常。 【输出要求】 1. 用表格输出字段包含用例编号、用例标题、请求参数示例、预期响应状态码、预期响应体关键字段、优先级。 2. 每个维度至少3条用例总用例数不少于25条。 3. 请求参数示例需要写完整的JSON。 4. 不要输出接口测试的理论介绍直接给用例。这里有个细节亮点约束里让 AI 每个维度至少3条用例。这叫最小覆盖约束能防止 AI 在某些维度偷懒只写一两条。我实测过不加这个约束它会把参数校验写得很全但鉴权安全这块可能总共就给一条加了之后明显均衡很多而且每个维度用例子数量还超过了预期。3.3 测试计划生成模板测试计划类的 Prompt 跟用例类不一样它要求的是结构化的宏观思考。这种场景下我反而更少给 AI 塞业务细节而是更注重让它遵循测试计划的专业结构。因为测试计划本身有相对固定的框架AI 的训练数据里有大量样本可以参考。【角色】你是一位测试经理负责过一个大型电商平台的从零到一的测试体系建设擅长制定测试策略、评估测试范围、规划测试资源和排期。 【项目背景】我们要上线一个新的优惠券中台系统包含优惠券创建、发放、核销、过期处理、对账五个核心模块。系统预计在六周后上线测试团队共3人其中1人熟悉自动化测试1人熟悉接口测试1人是新人。目前团队没有现成的自动化测试框架需要在这六周内完成方案搭建和主要流程的自动化覆盖。 【本次任务】请为该项目制定一份可落地的测试计划包含以下章节 1. 测试范围与不测试范围的界定 2. 测试策略分别说明功能测试、接口测试、自动化测试、性能测试怎么安排 3. 测试环境与数据准备方案 4. 测试排期与人力分工 5. 风险评估与应对措施。 【输出要求】 1. 排期请按周维度拆解标注关键里程碑 2. 风险评估需要结合优惠券场景的典型风险不要泛泛而谈 3. 不要输出普适性的测试理论请直接给可执行的方案 4. 自动化测试方案要给出框架选型建议考虑团队现状和上手成本。这个模板的特点是给了足够的现实约束。团队人数、技能构成、上线时间都是约束条件AI 在有限资源下做规划输出的方案就比它凭空想象一个理想化测试团队要靠谱得多。我有一次还故意不改模板里的团队构成拿去问发现它居然能根据其中有1人是新人自动调整分工策略把新人安排在用例评审和手工执行这类风险较低的环节这个判断是符合实际的。4. 调优实录那些让 Prompt 从能出结果到结果好用的关键调整模板是死的调优是活的。我见过很多人拿到一套 Prompt 模板用了一次觉得效果一般就放弃了或者反过来用了一次觉得不错就再也不调整了。这两种都不对。Prompt 跟测试脚本一样需要持续迭代维护。下面我挑几个我自己实际碰到的调优案例讲讲每次调整背后的思路变化。4.1 从笼统指令到前置条件明确的调整最早我给一个库存管理项目写用例生成 Prompt背景描述写得很简单库存管理模块包含入库、出库、盘点功能。生成的用例问题很明显所有用例都默认操作者有权限、系统正常、数据存在。这种用例落不了地因为它没有前置条件。后来我在背景层补了一段库存管理模块的操作角色分为仓库管理员和普通员工仓库管理员可以执行所有操作普通员工只有查询权限入库单提交后需要主管审批才能生效库存数量为0时不允许出库盘点期间锁定库存操作。补了这些之后AI 生成的用例质量有了质的飞跃它开始自动设计权限控制类、审批流状态类、数据锁定期操作类的用例这正是我们项目真正容易出 Bug 的地方。这个调整给我的启发是背景信息不是装饰它是在给 AI 划定什么情况下用例需要生效。没有前置条件的用例就像没有 pre-condition 的测试步骤跑起来全靠运气。4.2 从开放输出到格式强约束的调整有一次我让 AI 生成接口异常场景的测试用例集没在输出要求里规定格式结果它给了一段大段描述每条用例用不同的结构表述。整理到测试管理工具里极其痛苦我还得手动统一字段。那次之后我把表格输出字段明确写进了所有用例类 Prompt 的约束层从此这类问题再没出现过。还有个细节刚开始我约束输出格式时只写了用表格输出结果 AI 用 Markdown 表格给我列了30多条用例但标题行每列字段长度不一样中文排版看起来很乱。后来我把列名也给固定了比如编号、用例标题、前置条件、操作步骤、预期结果、优先级效果就好很多整列数据可以直接复制进 Excel 用。4.3 从只给正面要求到补充负面清单的调整这个调整是我调优经验里最想分享的一个。最初写 Prompt 我只会写好话比如请生成详细的测试用例请覆盖所有场景请确保用例可执行。但后来发现这种正面要求有瓶颈AI 对详细的理解跟我的详细不是一回事。于是我开始在 Prompt 里加负面清单不要输出通用功能测试点比如验证页面能正常打开不要写没有前置条件的用例不要使用验证系统稳定性这类无法量化的描述不要涉及需要付费工具才能执行的测试方案。加了负面清单之后输出里正确废话的比例明显下降。当时觉得这个调整很小后来想想这就是测试里常说的预期结果约束——你不告诉它什么不算通过它就会把什么都写进通过里。4.4 针对AI幻觉的专项防御做测试的人都反感一个词不确定。但大模型恰恰就是不确定的产物它给出的信息可能看起来非常权威实际上则是它编的。在测试技术方案类 Prompt 里这个问题尤其危险。我遇到过 AI 给我推荐一个市面主流的性能测试工具我一查根本没听说过也遇到过它给了一段 Selenium 的定位写法跑起来直接报错——因为那个 API 在新版本里早就废弃了。防御方案有两个方向。一是给约束在 Prompt 里明确写如果你不确定某个工具的最新版本或API建议给出多个候选方案并标注不确定项不要编造。二是给兜底让 AI 区分确定信息和推测信息。比如要求它在输出中标注以下内容基于我训练数据中的知识部分信息可能过时请在实施前核实。这个约束看着有点蠢但真能显著降低编造率因为它给了模型一个不必假装确定的出口。5. 进阶玩法把 Prompt 变成测试团队的共享资产如果你只是一个人用 Prompt 提高效率前面几节的内容已经够用了。但我在团队里推广 Prompt 之后发现真正让效率翻倍的不是某一个人写出了一条多牛的 Prompt而是把好的 Prompt 沉淀成团队的共享资产。这条路走通了Prompt 就不只是方便工具而是变成了团队测试方法论的一部分。5.1 建立 Prompt 模板库避免重复造轮子第一个建议是建立团队的 Prompt 模板库。很多测试团队都会建测试用例库、缺陷知识库但很少听说有人建 Prompt 模板库。我把这个想法用在团队管理后效果超出预期。我们把平时写得好用的 Prompt 按场景分类存放功能测试用例生成、接口测试用例生成、测试计划制定、测试数据构造、缺陷报告撰写、自动化脚本代码生成一共六类。每类模板都标注了适用场景、最佳实践和已知坑点。新建模板需要走一个简单的评审流程评审维度就是我前面讲的四个层角色设定是否清晰、背景信息是否足够、任务拆分是否合理、约束条件是否有效。评审通过后放入公共知识库全团队都可以复用和修改。这样一来新同学上手写 Prompt 的曲线平缓了很多他不用从零开始琢磨怎么写直接在模板库基础上改成自己的项目背景就行。5.2 记录 Prompt 迭代记录追踪每次调整的效果我们测试有缺陷追踪系统Prompt 的优化同样需要追踪。我个人的习惯是给每个常用 Prompt 建一份 changelog每次修改都记录修改了什么、为什么改、效果怎么样。比如把用例数量约束从至少10条改成至少20条解决了输出用例覆盖度不足的问题或者背景层增加权限角色说明解决了 AI 不生成权限测试用例的问题。这份 changelog 在团队协作时特别有用。其他人拿到模板看到 changelog就能理解模板里那些奇怪约束是怎么来的避免重复踩坑。有一次团队里有人想把每个维度至少3条用例这个约束删掉说太啰嗦。我拿出 changelog里面记录着当初不加这个约束时输出的用例分布有多偏科他看完就理解了还回了一句这条约束还真不能删。5.3 用 Prompt 反哺测试设计让 AI 做测试思维的启发器最后想聊一个我最近在探索的方向用 Prompt 来辅助测试设计的前置分析而不是等到测试设计完了再用 Prompt 去生成用例。什么意思呢就是在设计测试方案之前先用 Prompt 让 AI 从一个独立视角去分析被测系统的风险点、业务规则、潜在缺陷再拿它的分析结果来交叉验证自己的测试设计。这个做法的价值在于绕开了自我确认偏差。我们自己设计测试方案时容易陷入思维惯性习惯性地按以前的测试套路走可能会漏掉一些新功能的特殊业务逻辑。AI 没有我们的思维惯性它的分析角度往往能带来意外启发。我有一次让 AI 分析一个积分系统的潜在测试风险它提到了积分过期时间与时区不一致这个点这是我们团队完全没考虑到的场景。后来验证下来这确实是个真实的业务漏洞。这个用法避开了AI 要取代测试工程师的伪命题。AI 不会取代测试思维它更像是一个永远在线、视角不同的测试搭子帮你把思维的盲区照亮。测试的核心永远是判断力Prompt 只是放大判断力的一种方式。我在实际项目中已经让这种AI 辅助测试设计Prompt 驱动用例生成的组合拳在多个项目的测试准备阶段省下了 30% 以上的时间。更重要的是它让团队的测试设计从一开始就更有广度和深度。如果你也想测试自己的 Prompt 能力建议从今天开始拿一个你最近正在测的模块用我这篇的模板跑一遍然后再看看输出里有没有哪些用例是你自己没想到的——如果有你就知道这套方法的真实价值了。