做测试这行的人最近应该都试过拿AI帮忙写用例、补自动化脚本、分析缺陷报告。工具确实快但你用几次就会发现一个问题同一个模型有人能一口气生成七八条能直接落地执行的用例有人生成的东西看着字数不少仔细一读全是套话预期结果全是“系统正常返回”“页面展示正确”这种没法断言的废话。差别不在模型在你给模型的那段“输入协议”——这就是测试工程里的AI提示词工程。我在团队里折腾了大半年从最开始几个人拿着通用聊天窗口瞎试到后来把提示词当成和测试用例、测试数据一样的资产去管理踩了不少坑也沉淀了一套能直接用的打法。今天这篇东西不聊理论就把我在测试工程里搭提示词体系的全过程拆开讲包括底层的思路、模板怎么设计、怎么把提示词固化进项目资产、怎么排查那些“AI突然不好用了”的现场问题。无论你是初学AI测试的工程师还是想在公司里推AI测试流程的团队负责人这篇都能给你一个可以复制的起点。1. 测试行业用AI提示词的底层困境1.1 通用大模型为什么“不懂测试”很多人觉得提示词就是“把需求发给AI再问一句帮我写测试用例”这是最大的误区。通用大模型其实对软件测试有自己的理解但那个理解是“网上各种博客的平均值”不是你们项目的实际情况。你把一个订单功能的需求文档丢给它它确实能写出下单、取消、查询这类常规用例但问题在于第一它不知道你的业务规则。电商和ERP同样有“订单”这个概念但前者关心优惠叠加、库存扣减、支付回调后者关心审批流、单据状态机、组织权限。通用模型不会自动知道你业务的特殊规则除非你在提示词里明确告诉它。第二它不知道你的团队标准。你们的用例模板长什么样、优先级怎么定、一条用例要不要包含数据库断言、要不要关联需求编号这些在每个公司都不同。大模型不读你团队的制度文档它默认按照“大多数人的写法”来。第三它不知道哪些内容属于“领域里不该碰的”。很多系统有灰度开关、管理员专用功能、定时任务等非用户可见行为这些不写进提示词AI是猜不出来的。说白了AI不是测试专家它是一个“学习能力极强但缺乏项目上下文”的新同事。你要在提示词里把测试工程师入职第一天该知道的东西告诉它。这就是测试工程里提示词工程的第一步补上下文而不是提要求。1.2 提示词不是“问一句话”而是“一份工作协议”我见过很多团队把提示词当成“优美的句子”花大量时间琢磨“请”“务必”“高质量”这些礼貌词方向就偏了。在测试工程里提示词更像一份你和AI之间的工作协议它规定四件事任务边界这轮对话只做什么凡是超出范围的一律不做。比如“只生成接口测试用例不生成UI用例不写自动化代码”。输入物料AI要完成任务需要哪些信息你明确列出来。比如需求文档、接口定义、功能点清单、历史缺陷记录。输出契约返回结果长什么样用什么格式每个字段什么含义。比如“输出Markdown表格包含用例编号、前置条件、步骤、预期结果、优先级”。验收标准什么样的输出算合格什么算不合格。比如“预期结果必须可断言禁止出现‘系统正常’这类不可验证的描述”。把提示词当成协议之后你会发现同一套模板可以换不同需求反复使用因为协议框架是稳定的变的只是输入物料里贴进去的需求文本。这也就是为什么我说提示词工程在测试领域是可以体系化的它不是写一条“咒语”而是设计一套“协作规范”。2. 测试专用提示词的六要素拆解2.1 场景、角色与任务让模型回到“测试工程师”的状态搞清楚了底层逻辑我们来拆一套我实际在用的测试专用提示词结构。整个结构拆成六个要素缺一个生成质量都会明显下滑。首先是场景设定。你告诉AI当前处于什么测试阶段、什么测试类型、关注什么质量维度。比如“现在做订单模块的回归测试重点关注支付回调失败后的状态一致性”。场景设定的意义在于AI会围绕这个维度去分配注意力不会漫无目的地什么都测。我试过完全不写场景让它直接生成用例结果十条用例里有六条是“正常流程”三条是“必填项为空”这种输出测试经理看了会直接摇头。其次是角色设定。这里有个常见的误区不是把AI设定成“你是资深测试工程师”就完事了。你要设定的是“你是熟悉当前项目的测试工程师”核心还是上下文而不是头衔。我通常的写法是你是一名负责XX系统的资深测试工程师熟悉该系统的业务背景、技术架构和历史缺陷分布。请基于以下需求和已知约束按团队标准输出测试用例。这句话的信息量比单纯“你是测试专家”大得多。它暗示了AI要调用“资深工程师”的严谨性也要利用“熟悉项目”的上下文双管齐下输出会更务实。最后是任务描述。任务描述要具体到可执行不能只说“写一些测试用例”。我在实际项目中会这样写任务针对登录接口编写接口测试用例。 覆盖维度正常场景、参数异常、边界值、安全鉴权、并发重复提交。 输出数量每类不少于3条不多于8条。任务的颗粒度决定AI输出是“能直接用”还是“只能当草稿”。说“写一些测试用例”的生成结果大概率没法用说清楚覆盖什么维度、输出多少条的结果基本可以直接评审。2.2 输入物料、输出格式与约束条件把用例写进可执行轨道任务说清楚了接下来三个要素决定AI能不能把任务“落地”。输入物料就是AI必须参考的内容。我一般会在提示词里分块列出一句话系统背景、本功能点的业务规则列表、接口路径和入参出参示例、以及一个“已确认功能点清单”。这里要特别强调的是“已确认功能点清单”AI非常容易瞎编需求你列一个清单相当于画了圈它在圈里发挥出圈的内容视为无效。这里分享一个实测有效的做法哪怕你没有现成功能点清单也可以让AI先根据需求文本自己归纳一份“需求理解清单”你人工确认后再让它基于清单生成用例。多了一轮交互但准确性提升非常明显。很多人觉得让AI生成用例必须一步到位这是不对的——在测试工程里分步确认反而效率更高。输出格式。我最开始用AI生成用例时输出是一大段散文读起来很费劲。后来改成“强输出格式”质量立刻上了一个台阶。目前我用得最顺手的格式是Markdown表格字段固定为用例ID、所属功能点、测试类型、前置条件、操作步骤、测试数据、预期结果、断言建议、优先级。不要小看输出格式这一步它其实是给AI下了一个“结构化思维”的指令要求它把模糊的想法拆成字段很多不严谨的内容在这个过程里自然被过滤掉了。约束条件。这是把AI输出从“可用”推向“合格”的关键。我会明确写“不许出现”清单效果非常直接。比如约束条件预期结果必须具体可验证禁止出现“系统正常”“页面展示正确”“处理成功”等模糊描述。禁止新增未在需求中明确的功能点。每条用例必须有唯一编号且编号不可重复。涉及金额、时间、状态等字段必须给出具体示例值。这样的负向约束比正向要求管用得多。正面的“请确保质量”模型会觉得是在夸它反向的“禁止出现模糊断言”会真正触发它的纠错机制。3. 一套可直接复用的测试用例生成提示词模板3.1 模板结构详解把六要素组装起来就得到了一套我目前在项目里反复使用的模板。你可以直接复制替换掉“方括号”里的内容就能用# 背景 你是一名负责XX系统的资深测试工程师熟悉该系统的业务规则、接口规范和常见缺陷模式。 # 被测系统 系统名称XX商城 功能模块订单提交 模块概况支持商品校验、库存扣减、优惠计算、订单生成、支付单创建。 # 输入物料 1. 需求规则显式规则 - 下单时校验商品是否上架、是否在售时间范围内。 - 库存不足时提示“库存不足”不生成订单。 - 优惠券仅限本账号使用每个订单最多使用一张。 - 订单提交后进入“待支付”状态30分钟内未支付自动关闭。 2. 已确认功能点清单 - 正常下单、未上架商品拦截、库存不足拦截、优惠券使用、余额不足、重复提交拦截、超时关单。 3. 接口定义 - POST /api/order/create - 入参userId, skuId, quantity, couponId, payType - 出参orderId, status, totalAmount, couponAmount # 任务 为“订单提交”功能编写接口测试用例。 覆盖维度正常场景、异常拦截、边界值、鉴权、重复提交。 输出数量每类3-8条。 # 输出格式 使用Markdown表格字段如下 | 用例ID | 功能点 | 测试类型 | 前置条件 | 操作步骤 | 测试数据 | 预期结果 | 断言建议 | 优先级 | # 约束条件 1. 所有用例必须对应“已确认功能点清单”不得新增未列出的功能。 2. 预期结果必须给出具体的状态码、返回字段或数据库变化禁止模糊描述。 3. 测试数据必须具体例如明确的userId、skuId、数量、金额。 4. 边界值用例必须写明边界数值及设计依据。这套模板看起来挺长但实际效果远好于那种“帮我写测试用例”的短提示词。为什么模板长反而好用因为大模型的输出质量受“输出前信息量”影响很大你把背景、输入、约束都塞进去它在生成时就不需要靠“猜”来补全信息自然更少出现错误。3.2 模板参数与使用要点模板不是写完了就能一劳永逸有几个参数我建议你每次根据项目情况调整**“覆盖维度”**是模板里最灵活的地方。接口测试和Web UI测试要覆盖的维度完全不同接口测试我会写“参数校验、鉴权、并发、幂等”Web UI测试我会写“页面交互、响应式布局、异常提示、权限控制、数据回显”。维度写得好不好直接决定用例价值所以每次动手前花五分钟想清楚维度比写提示词本身更重要。**“输出数量”**要结合用例粒度来设。如果一条用例覆盖一个核心场景10条以内就够了如果一条用例只覆盖一个极小分支那可能得30条以上。我给团队的建议是第一轮先少生成几批你评估一下粒度再调整数量要求不要一上来就“越多越好”否则很容易生成一堆同质化用例浪费评审精力。**“断言建议”**字段是我近几个月新加进去的。AI生成的“预期结果”往往是业务层面的描述比如“订单创建成功”但测试工程师真正执行用例时需要的是可操作断言比如“接口返回status0数据库orders表中新增记录且statusPENDING”。加了“断言建议”这一个字段等于强制AI多思考一层输出价值高很多。这个模板同样适用于自动化测试脚本生成的场景只需把输出格式改成“Python pytest代码包含断言”把约束条件改成“禁止使用sleep固定等待统一使用显式等待”。基础协议不变换层皮而已。4. 从单条提示词到测试资产体系4.1 提示词资产库该怎么分类与维护当你手里有七八条好用的提示词模板后下一个问题就来了这些模板散落在每个人的聊天记录里没法复用也没法保证团队一致性。解决这个问题就是要把提示词当成和测试用例一样的项目资产来管理。我目前的做法是在代码仓库里建了一个prompts/目录和测试用例、测试数据放在一起纳入版本管理。里面的结构大概是这样的prompts/ ├── test-case/ │ ├── api_test_case.md │ ├── web_ui_test_case.md │ └── regression_case.md ├── test-data/ │ ├── boundary_data_generator.md │ └── login_user_factory.md ├── bug-analysis/ │ ├── bug_triage.md │ └── root_cause_analysis.md └── automation/ ├── pytest_script_generator.md └── selenium_step_converter.md分类的原则不是按“AI的功能”而是按“测试工作流里的环节”。用例生成、数据构造、缺陷分析、脚本生成这些恰好是测试日常工作中最消耗人力的环节也是AI最能提效的地方。这样分类的好处是团队遇到对应任务时能快速找到模板而不用在聊天记录里翻半天。维护提示词资产时最重要的是版本管理。你的需求文档会变系统架构会变提示词当然也要跟着变。我要求团队每修改一个模板必须记录修改原因和修改人就像改代码一样走评审。别看这是个流水账工作它能避免一个很常见的问题某条模板本来很靠谱某人为了一个特殊项目临时改了改完以后没人记得三个月后大家还在用那条被魔改过的模板效果自然变差。4.2 用“提示词评测集”控制质量有了资产库你还需要一套质检机制否则你根本不知道哪条模板是真好用哪条是“看起来能用的幻觉”。我做了个很简单但很有效的东西叫“提示词评测集”。思路是这样的从历史需求中挑出10到15个有代表性的、有标准答案的功能点作为固定评测任务。每次改模板都拿这套评测集去跑一轮人工给输出打分。打分维度我固定了四个维度说明评分标准1-5分覆盖率是否能覆盖需求中的所有功能点5分全覆盖3分覆盖80%1分明显缺失可执行性用例是否能直接被测试人员执行5分步骤和数据完整3分需少量补充1分只有标题断言明确度预期结果和断言建议是否具体可验证5分全部具体3分部分模糊1分大量“正常”表述需求可追踪性用例能否追踪到具体需求规则5分全部有对应1分大量凭空生成评测集跑完后把平均分记到模板文件的头部作为基线值。新改的模板如果分数低于基线基本不通过评审。这个方法听着不复杂但它把“AI生成质量”从一个主观感受变成了一个可衡量的数字。我强烈建议做提示词工程超过一个月的团队都建一个属于自己的评测集哪怕只有五条任务都比拍脑袋说“感觉还行”强得多。有一件事要提醒评测集的任务不能一直不变。每季度至少要换掉两三条旧任务加入最近遇到的新需求类型比如AI大模型相关的测试、数据一致性测试。不然评测集本身会慢慢和实际工作脱节分数虚高。5. 提示词工程向测试平台与Agent集成的工程化路径5.1 参数化调用与平台接入资产库在仓库里跑通了再往前走一步就是把提示词工程接进测试平台让更多测试人员在这个“协议”里高效工作而不是复制粘贴到聊天框。我做过一轮“把提示词模板参数化”的工程改造核心逻辑不复杂提示词里会变的部分需求文本、功能点清单、接口定义、覆盖维度做成参数固定部分结构、格式、约束条件保持不变。接进平台后测试人员只需要在界面上填几个下拉框和文本框比如选择“接口测试模板”粘贴一段需求文本勾选“覆盖维度”点生成系统自动把参数和模板拼装成完整提示词再调用大模型API把结果回填到测试用例管理页面。这个改造上线后团队里写用例的效率提升了大概一倍而且大家不用再关心提示词怎么写只需要关注需求本身——这才是提示词工程该有的最终形态。这里有个值得注意的细节参数化后模板的“约束条件”里最好加上一条“所有输入参数必须原样保留不得擅自修改或遗漏”。因为有人可能在平台界面漏填某个参数AI就会自己脑补一个脑补出来的东西往往和真实系统对不上。加了这条约束AI至少会提示“参数缺失”而不是默默编一个。另一个比较实用的接入场景是回归测试的分类和筛选。以前跑完一轮回归几百条用例没执行的、执行失败的、疑似环境问题的全靠人工一条条看。现在我让AI按照“失败原因分类”的提示词去读测试报告自动归纳出“断言失败”“超时”“环境异常”“数据问题”几类我只处理真正需要关注的类别。别小看这个分类动作它是我认为提示词工程在测试领域除了用例生成之外性价比最高的应用。5.2 AI Agent能做与不能做的边界聊到集成就绕不开“AI Agent”这个词。很多团队一上来就想搞“AI自动写用例、自动执行、自动定位Bug”的完全自动化。我的建议是先搞清楚边界再谈自动化。我目前见到的比较务实的AI Agent在测试工程里的角色是“测试助理”不是“测试替代”。它能做的有三件事一是根据需求生成候选用例替换掉从空白开始写用例的过程二是从一堆失败用例里做初步分类定位给人工缩小排查范围三是把人工确认过的用例转成自动化脚本框架减少造轮子的机械劳动。但有几件事现阶段我不建议放给Agent全自动做比如没有人工评审就直接把AI生成的用例加进回归套件比如让AI直接改生产环境的数据来做测试再比如用AI代替测试工程师做最终的缺陷判定。原因很简单AI生成内容天然带有概率性测试工程偏偏是一个要求确定性的环境。用例错了最多浪费一轮执行断言错了可能把线上问题漏过去这个风险不是提示词能完全对冲掉的。所以我在团队里坚持做“人在回路”模式AI生成候选人工评审确认确认后纳入资产执行结果再反馈给AI用于下一步优化。这套流程既利用了AI的效率也保住了测试工程的质量底线。这应该成为测试团队落地AI的一个常识性共识。6. 测试中AI提示词的常见踩坑与排查实录6.1 高频问题速查表真正跑起来之后问题比想象中多。我把团队这半年遇到的典型问题整理成一个速查表你以后遇到现象可以直接对号入座现象根因解决办法AI编造根本不存在的功能提示词里没给“已确认功能点清单”增加功能点清单并加约束“不得新增未列功能”用例数量爆炸全是相似场景输出数量约束缺失明确“每类3-8条”并要求“先列覆盖维度再生成”预期结果全是“系统正常”没有负向约束增加“禁止模糊断言”增设“断言建议”字段生成长文被截断输入需求文档太长超出上下文窗口先让AI归纳需求要点再基于要点生成用例同一个需求两次生成结果差异大温度/随机性参数过高或提示词缺少固定结构接入平台调用时固定温度参数保留模板固定框架用例和需求规则对不上需求文本和功能点未明确对应规则在输入物料中逐条列出“显式规则”要求用例标注依据让AI优化提示词后效果反而变差优化方向不明确AI“自作主张”加内容优化时只允许改指定部分其余框架保持不变这个表里的问题我基本都亲身踩过最典型的就是第一条“编造不存在的功能”。最开始我们生成订单模块用例时AI“发明”了一个“订单可以被用户主动拆分”的功能看起来还挺合理要不是人工评审认真核对需求差点就混进用例库了。从那以后“已确认功能点清单”就成了我们所有测试提示词模板里雷打不动的一项。6.2 几个值得长期坚持的工程习惯最后分享几个我坚持了很久的工程习惯算是对整个提示词工程体系的一个补完。第一任何AI生成的用例都必须经过“可执行性检查”。我会随机抽三到五条生成结果假装自己是一个第一次执行用例的初级测试员照着步骤走一遍看能不能走通断言能不能查到。这个检查不用全量做抽查就足以暴露模板的整体质量水平。第二AI生成完不要急着拿去用先让它自己“审一遍”。我有个小技巧在提示词里追加一句“生成完成后请检查所有用例是否满足约束条件并指出现有输出中的潜在问题”。很多大模型具备一定的自我纠错能力让它自己审一遍能筛掉一部分明显问题比如断言不具体、测试数据缺字段。这个操作零成本效果却很实在。第三提示词模板要定期“清洗”。AI项目变化快、实验多模板里很容易混入过时的约束条件比如某个自动化框架的旧版本写法。我每两个月会进行一次模板评审把和当前项目状态不一致的部分清掉。提示词模板是测试资产的一部分资产是会长“过期内容”的不及时清理就会变成负资产。还有一条特别重要的经验不要在关键时刻完全依赖AI生成的内容。测试工程关乎质量质量的底线永远是人的判断。AI可以把测试工程师从机械重复的劳动中解放出来但前提是工程师还在而且还在做判断还在承担责任。我做完这套体系之后最大的感受是AI提示词工程在测试领域本质上不是“怎么让AI更聪明”而是“怎么把测试方法论变成AI能执行的协议”。两者的区别在于前者依赖模型的灵光一现后者依赖你对自己测试流程的深度理解。你在提示词里写的每一个约束条件都是你测试经验的沉淀你建的那套资产库和评测集才是让AI真正稳定服务于测试工程的关键。先把流程理清楚再让AI跑起来这个顺序不能反。