做AI测试大半年我最大的一个感受是大部分测试用例不是大模型写不好而是我们压根没问对。同一个模型有人拿到的接口测试用例十条有八条能直接进用例库有人拿到的十条里有九条是“正确的废话”。差别不在模型选型不在算力而在提示词怎么写。如果你正在用大模型辅助测试或者准备面试AI测试工程师岗位这篇内容值得慢慢读。我会把自己反复打磨出来的“提示词工程四步法则”完整拆开配合接口自动化测试、小程序AI自动化测试、智能体测试数据集设计这些真实场景讲清楚每一步背后的逻辑、具体的写法和踩过的坑尽量让不同基础的读者都能照着落地。1. 为什么做AI测试绕不开提示词工程1.1 一次让我警醒的对比实验上个月我组织团队做了一次内部练习任务很简单用同一个大模型给同一个登录接口设计测试用例。我把人分成两组一组直接甩了一句话“帮我设计这个接口的测试用例”另一组按照四步法则来写提示词。结果非常悬殊。第一组拿到的用例翻来覆去就是“验证用户名密码是否正确”“检查返回状态码”这类谁都能想到的东西第二组拿到的用例里有token过期、并发登录、参数边界、安全风险、验证码错误次数锁定这类真正有测试价值的内容。这个实验不是想证明谁聪明而是想说明一个事实大模型的输出质量很大程度上取决于输入提示词的质量。提示词写得模糊输出必然模糊提示词写得具体、专业、有约束输出才会像一份能用的测试资产。1.2 提示词工程到底是什么很多人一听到“提示词工程”就觉得是高深的技术其实它内核特别朴素不断雕琢提示词使大模型能给出最理想的答案这个过程就叫做提示词工程Prompt Engineering。它不只是一句话怎么写而是一套系统方法包括角色设定、上下文组织、输出约束、错误反馈与迭代优化。你可以把它理解成“给模型做需求分析”。需求分析做得越清楚交付的东西越接近预期。我们做测试的平时最擅长挑需求的毛病到了提示词这里同样要把“需求”给模型讲明白。模型没有读心术你不说清楚测试目标、被测环境、边界数据它就只能用训练语料里的普遍经验来补补出来的东西自然不贴你的项目。1.3 AI测试工程师的新基本功现在AI测试这个岗位越来越热面试题也开始从“会不会用Postman/JMeter”转向“怎么用大模型提效”。我自己面试候选人的时候一定会问一道题“给你一个接口你怎么让大模型帮你生成高质量的测试用例”大部分人的回答停留在“把接口文档贴进去”少数人会提到“告诉模型角色、给出边界条件、要求输出格式”。差距一下就拉开了。所以不管你是测试开发、功能测试、自动化测试还是正在转型AI测试工程师提示词工程都已经不是可选项而是基本功。它决定了你用AI是“提效”还是“增加返工”。用得好的人一天的用例设计工作半小时完成用不好的人花在挑错和返工上的时间比手工写用例还长。2. 四步法则的整体设计思路先搭骨架再填肉2.1 四步法则一句话版我日常用的这套方法总结下来就是四步角色设定、上下文构建、输出规范、迭代反馈。每一步解决一类具体问题步骤解决什么问题对应测试场景角色设定回答风格与立场不明确让模型像资深测试一样思考上下文构建信息缺失导致漏测与编造补充需求、接口文档、代码、测试数据输出规范结果不可解析、不可断言结构化输出JSON、用例字段、优先级、预期结果迭代反馈一次不准次次不准用失败样本反向优化提示词建立回归集2.2 为什么顺序不能乱这四步的顺序是有讲究的。先定角色是让模型进入“测试工程师”的工作状态后续所有推理都基于这个立场展开再给上下文是提供推理依据防止模型凭空编造然后约束输出格式是让结果能被自动化流程直接消费最后迭代反馈是让提示词从“偶尔准”变成“稳定准”。我见过不少人一上来就写“请用JSON格式输出”结果没有角色也没有上下文模型确实输出了JSON但内容全是空话。就好比你让一个新人写测试报告不告诉他测什么、怎么测只跟他说“用表格写”他交上来的表格当然没法看。格式是外壳角色和上下文才是血肉。2.3 一条完整的提示词长什么样先给大家看一条我经常用的模板后面每一节会拆开讲解你是一位有10年经验的测试架构师擅长接口自动化测试和边界分析。 请根据以下接口文档设计测试用例。 接口文档 POST /api/v1/login 请求参数username(string, 必填), password(string, 必填), captcha(string, 可选) 成功响应{code:0,message:success,data:{token:xxx,expires_in:7200}} 失败响应{code:1001,message:invalid credentials} 测试要求 1. 覆盖正常流程、参数异常、安全风险、并发场景 2. 关注username与password的边界值长度、类型、特殊字符 3. 每个用例包含用例编号、前置条件、操作步骤、预期结果、优先级 请以JSON数组格式输出测试用例。这条提示词看着不长但它同时包含了角色、上下文、任务目标、覆盖要求、输出格式五类信息。模型拿到它就知道自己是资深测试、被测对象是什么、要覆盖哪几类场景、最后交什么格式的成果。3. 第一步锁定角色与测试目标别让模型瞎猜3.1 角色设定为什么有效角色设定的本质是给模型一个“领域视角”。大模型在训练时见过海量语料不同的语料背后有不同的立场和表达方式。你告诉它“你是资深测试工程师”它就会偏向调用测试领域的知识体系比如等价类划分、边界值分析、场景法、错误推测法。你不说它就默认用“通用语言助手”的口吻回答写出来的东西自然四平八稳、没有测试味。有个很直观的例子。我让模型“帮我看看这个登录功能有哪些问题”它列了三条密码不能为空、用户名不能为空、验证码要正确。但我把角色改成“你是资深安全测试工程师专门做Web应用渗透测试”它就列出了撞库风险、验证码可绕过、登录接口未做频率限制、token过期策略不合理这些真正有价值的问题。同一个模型同一段输入差别只在角色那一句话。角色给模型画了一个专业边界边界内的推理会明显更聚焦。3.2 测试目标要写到什么颗粒度光有角色还不够目标也得说清楚。我建议把测试目标拆成三个层次写进提示词范围层测什么不测什么。比如“只设计登录接口的接口层用例不做UI层”。覆盖层必须覆盖哪几类。比如“正常流程、参数异常、权限异常、并发与性能、安全风险”。验收层什么样算通过。比如“每个用例必须包含明确的预期结果不能出现‘验证功能正常’这类模糊表述”。这三个层次写明白模型的输出就会有边界感不会跑偏到无关方向。比如你不写“不测UI层”模型可能会顺手给你生成一套Selenium脚本看着挺全但根本不是你要的东西。3.3 实操示例从模糊到精准模糊版提示词帮我测试一下用户注册功能。四步法优化后的提示词你是一位资深测试工程师专注Web端功能测试与安全性测试。 请对用户注册接口 POST /api/v1/register 进行用例设计。 覆盖范围手机号、密码、验证码三个字段的正常与异常组合。 重点关注手机号格式校验、密码强度规则、验证码错误次数限制、重复注册返回码。 输出要求每个用例包含用例编号、字段组合、操作步骤、预期结果、优先级高/中/低。 请用Markdown表格输出。前后对比一目了然。前者模型只能给泛泛的流程后者模型能给出可以落地的用例设计而且“重复注册返回码”这种细节恰恰是很多手工设计容易漏掉的点。3.4 这一步最容易踩的坑角色设定最常犯的错就是“角色太多、互相打架”。我见过一个提示词里写了“你既是测试工程师又是产品经理还是运维”模型到最后不知道以谁的身份说话输出夹杂着需求建议、线上监控方案和测试用例三不像。我的建议是一个提示词只保留一个主导角色最多加一个辅助视角比如“你是资深测试工程师同时有3年性能测试经验”不要贪多。角色一旦混乱后面几步做得再好都会白费。4. 第二步构建上下文把测试素材喂到位4.1 上下文的三层结构角色设定解决了“模型站在什么立场思考”的问题上下文则解决“模型根据什么信息推理”的问题。我在实战中把测试类提示词的上下文分成三层需求层被测功能要解决什么问题、业务规则是什么。技术层接口文档、数据结构、代码片段、技术栈约束。数据层测试数据、边界值样例、已有测试数据分布。三层信息越完整模型越不容易编造需求。很多人说大模型会“一本正经地胡说八道”其实很多时候是因为你只给了它问题没给素材它只能根据训练语料里的常识补补错了就是幻觉。做测试的人最忌讳需求来源不明喂给模型的素材也一样必须来源明确、口径统一。4.2 接口自动化测试场景的上下文组织以接口自动化测试为例我的习惯是把信息按下面结构拼进提示词被测接口POST /api/v1/order/create 功能说明用户下单接口需要登录态。 请求头Authorization: Bearer tokenContent-Type: application/json 请求体示例 {sku_id:SKU12345,quantity:2,address_id:ADDR001,coupon_id:CPN001} 业务规则 1. 库存不足时返回 code5001 2. 优惠券过期时返回 code5002 3. 下单成功后扣减库存和优惠券 4. quantity 取值范围 1-999超过返回 code4001 已有测试数据 - 有效用户user01 - 库存不足的skuSKU_BAD - 过期优惠券CPN_EXPIRED 请基于以上信息设计覆盖正常、异常、边界、并发场景的测试用例。这样组织之后模型拿到的是一份“被测对象全景图”它只需要在这个框架里做推理不会天马行空。实际跑下来生成的用例覆盖度明显高于只给一个接口路径的情况。尤其是“已有测试数据”这一块模型可以直接把具体数据值写进用例而不是写“传入一个不存在的sku”这种还要人工补数据的空话。4.3 小程序AI自动化测试的上下文设计很多同学问小程序怎么用AI做自动化测试。我的经验是小程序测试的提示词上下文和接口测试不太一样除了接口信息还得补上页面结构和交互约束。你是一位小程序自动化测试专家擅长编写自动化测试脚本。 被测小程序XX商城微信小程序 技术栈uni-app自动化框架miniprogram-automator 核心页面及路径 - pages/index/index首页 - pages/cart/cart购物车 - pages/order/confirm确认订单 被测流程首页 - 商品详情 - 加入购物车 - 结算 - 支付 支付环节使用测试环境mock支付不要调用真实支付。 请为上述主流程生成自动化测试脚本脚本需包含 1. 页面元素定位方式 2. 关键步骤的操作代码 3. 每一步的断言 4. 异常场景如商品已下架的处理这个提示词里最重要的两条信息是“路径结构”和“mock支付”没有这两条模型生成的脚本要么找不到页面元素要么在支付环节卡住。我一开始没写mock支付生成的脚本真的尝试调用了真实支付环境差点酿成事故。这是血泪教训。做自动化测试的上下文凡是涉及外部依赖、环境限制、安全边界的必须在提示词里显式写死不要指望模型自己意识到。4.4 上下文不是越多越好上下文给得不够模型会瞎编给得太多模型会“迷失重点”。我总结了一个经验上下文总量控制在模型输入窗口的20%-30%以内优先放与本次测试目标直接相关的信息。比如测登录接口就只放登录相关的业务规则不要把整个项目文档都贴进去。信息过载时模型的注意力会被无关内容稀释反而影响关键点的覆盖率。上下文组织的本质是“做减法”只保留能帮助模型做对事的信息。5. 第三步定义输出规范让结果可解析、可断言5.1 为什么必须要求结构化输出测试场景里AI的产出通常不是给人看一眼就完事的而是要喂给自动化流程的。如果模型输出的是散文式的描述后续脚本没法解析还得人工整理等于白干。所以第三步的核心就是把输出格式卡死。我自己最常用的是JSON格式因为解析成本最低。以下是我让模型生成接口测试用例时常用的输出结构{ test_cases: [ { case_id: LOGIN_001, title: 正确用户名和密码登录成功, preconditions: 已注册用户user01密码正确, steps: [ 调用POST /api/v1/login传入usernameuser01passwordpass123, 校验响应code0且data.token非空 ], expected_result: 登录成功返回有效token, priority: high, category: normal } ] }有了这个结构自动化脚本拿到结果后可以直接遍历填充到用例管理平台或者转成pytest参数化数据源。我自己写过一个小工具把模型输出的JSON直接转成YAML测试数据文件整个链路是通的。如果你做接口自动化测试这一步能帮你省掉大量手工整理用例的时间。5.2 输出约束的写法技巧要求结构化输出时光说“请用JSON”是不够的还要把字段的含义、枚举值范围、必填项写清楚。比如输出要求 - 输出JSON对象包含字段 test_cases - test_cases为数组每个元素包含case_id、title、preconditions、steps、expected_result、priority、category - case_id格式为“模块名_编号”如LOGIN_001 - priority取值只能是 high、medium、low - category取值只能是 normal、boundary、security、concurrency、error - 不要输出任何JSON以外的说明文字最后一条“不要输出任何JSON以外的说明文字”特别关键。不加这句很多模型会好心在JSON外面包一层“好的以下是生成的测试用例”解析脚本直接报错。我一开始没写这条解析脚本每次都要先做字符串清洗麻烦得很。加了之后基本零清洗成本。5.3 断言标准怎么写进提示词除了格式断言标准也要写进提示词。测试用例里的“预期结果”如果写得太虚自动化执行时没法断言。比如“验证功能正常”这种预期结果脚本根本不知道要断言什么。我要求模型写预期结果时必须包含可校验的维度状态码如code0或HTTP 200响应字段如data.token非空、message为固定文案时间维度如响应时间小于500ms数据一致性如库存扣减1、订单状态变为paid我常跟团队说一句话如果预期结果里没有数字、没有字段名、没有状态码那这条用例就不算写完。这句话完全可以用来评价模型生成的用例质量。你把这条标准写进提示词模型输出的预期结果立即可用自动化脚本的断言逻辑也能直接套用。6. 第四步迭代反馈把“一次准”变成“次次准”6.1 从失败用例反推提示词问题没有任何一条提示词第一版就能完美。我自己的命中率大概是这样第一版提示词生成的用例能直接用的大概只有六成剩下四成要么少了关键场景要么输出格式不达标。第二版修正之后能到八成再往后就靠持续迭代。最常见的三种失败模式和对策漏场景模型只覆盖正常流程没覆盖异常。对策在提示词里把覆盖维度显式枚举出来比如“必须覆盖normal、boundary、security、concurrency、error五类”。格式跑偏模型没按JSON输出。对策补充输出示例few-shot把一段合格的JSON样例直接贴在提示词里比写一百句“请按格式输出”都管用。照抄需求模型把需求文档里的描述原样搬到用例里没有测试视角。对策强化角色和任务要求比如“对以下需求进行批判性分析找出需求中未明确定义的边界条件”。这三个问题我基本每周都会遇到每次都是靠迭代提示词而不是靠换模型解决。换模型是最后手段多数情况下问题出在提示词不在模型。6.2 提示词版本管理与回归集很多人优化提示词靠感觉改一版就换个新提示词完全没有版本概念。我自己现在会维护一个提示词回归集。每次调整提示词先跑一遍回归集里的老问题确认已修复的问题没有复发再上线到新场景。我的做法很简单在项目里建一个prompts目录按场景分文件prompts/ ├── login_interface_test.md ├── order_interface_test.md ├── miniprogram_e2e_test.md ├── test_data_generation.md └── change_log.mdchange_log里记录每个版本的修改原因和效果版本修改点效果v1.0初版用例覆盖率60%v1.1增加安全测试维度覆盖率提升到75%v1.2增加JSON输出示例输出格式达标率100%v1.3修正角色描述去掉多余副角色用例质量明显提升这套做法听着土但特别有用。提示词和代码一样是会被不断改动的东西如果没有版本管理出了问题根本不知道是哪次改动引起的。我见过同学改完提示词效果变差想回滚却找不回旧版只能重新回忆浪费时间。用Git或者简单的change_log都能解决这个问题。7. 高频问题与排查速查7.1 典型问题速查表我把平时被问到最多的几个问题整理成了一张表方便大家遇到问题直接对照现象可能原因解决办法生成的用例全是正常流程提示词没显式要求异常覆盖在提示词中枚举覆盖维度normal/boundary/error/security输出格式总是不合规只说了“用JSON”没给示例在提示词里贴一段完整的JSON输出示例用例内容像复读需求角色设定太弱强化角色要求“以批判性视角分析需求”模型编造不存在的接口字段上下文里接口文档不完整把接口文档原文、字段类型、枚举值全部贴入上下文并发场景设计得离谱缺少业务规则约束补充业务规则如库存扣减、唯一约束、锁机制预期结果无法断言没有约束预期结果的写法要求预期结果必须包含状态码、字段名、数值条件这张表是我实践沉淀的直接结果每次碰到输出不对先查表再调提示词基本十分钟内能定位问题。建议你把这张表存下来或者根据自己的项目补充成自己的速查手册。7.2 我的一些习惯性动作除了上面这张表我还有几个固定习惯。第一写提示词之前先自己列一遍测试点。你脑子里得有一个“标准答案”才能判断模型输出好不好。很多同学让AI写用例自己根本不知道好用例长什么样那优化提示词就是盲人摸象。第二让模型给出多个候选版本。需要探索测试思路时我会在提示词末尾加一句“请给出三个不同思路的用例设计方向”然后从中选最优的而不是只让模型给一个答案。第三定期清理提示词里的“废话”。我每次迭代都会删掉一些不再起作用的长句因为提示词越长模型推理的负担越重出错的概率也会增加。能用10个字说清楚的事绝不用20个字。7.3 一个真实排查案例有一次我用AI生成一批订单接口的测试数据发现生成的数据里金额全是整数没有小数。我检查了提示词里面确实写了“amount为金额”但没写“amount可取小数、负数、极大值”。模型默认金额就是正整数这就是典型的上下文不足。我在提示词里补了一句“amount取值范围建议覆盖0、负数、小数、极大值、字符串类型”再跑就正常了。这个案例说明做AI测试数据生成提示词里的枚举示例比抽象描述重要得多。“金额”这个抽象词给模型的想象力太有限你必须把测试需要的具体形态摆出来它才知道往哪个方向用力。8. 场景延伸面试问什么智能体数据集怎么设计8.1 AI测试工程师面试中的提示词问题最近面试AI测试岗位几乎必考两件事一是怎么用提示词让大模型生成高质量测试用例二是怎么评估和优化模型在测试场景的表现。我建议面试准备者至少能现场说出这套四步法则并且能随手写出一条角色清晰、上下文完整、输出格式明确、带迭代思路的提示词。面试官真正想看的不是你背了多少提示词模板而是你有没有“把模型当测试工具来调优”的意识。能说出“我先给模型设定测试工程师角色再给它接口文档和边界数据要求它输出结构化用例最后根据漏测场景反推提示词”的人基本就过关了。8.2 智能体测试数据集怎么用提示词设计智能体测试的数据集设计和传统测试数据不太一样传统测试数据追求确定性智能体测试数据追求多样性和边界覆盖。我现在的做法是用提示词分层生成数据集每一层解决一类问题你是一位智能体测试数据专家。请为“航班查询智能体”生成测试数据集。 要求按以下维度生成 1. 正常查询出发地、目的地、日期齐全 2. 边界查询日期为今天、日期为一年后、往返日期倒置 3. 模糊输入如“明天飞北京”“帮我订个便宜票” 4. 多轮对话只有“我想去北京”这样的不完整表达等待追问 5. 对抗场景用户故意输入不存在的城市、特殊符号、超长文本 每个样本输出JSON格式包含 user_input、expected_behavior、difficulty_level。这样生成的测试集比从生产日志里捞出来的数据覆盖度更高更适合用来评估智能体在异常输入和模糊表达下的表现。尤其在多轮对话场景传统测试数据往往只覆盖完整表达而真实用户很少一次把信息说全这些不完整表达的样本必须靠提示词主动构造。8.3 给测试同行的最后一句话提示词工程不是什么玄学它就是一个把需求讲清楚的过程。我们测试工程师天天干的就是跟需求较真到了跟大模型打交道的时候把这份较真用上就行。先把角色定清楚再把上下文喂足然后要求结构化输出最后根据失败用例反推迭代。四步走完你会发现大模型做测试的质量比想象中高得多。根据我个人的经验这个能力花两周就能上手但带来的提效是长期的。建议你今天就拿手上一个现成接口试试第一步先给模型设定“资深测试工程师”的角色对比一下和之前直接提问的差别。差距出来了你就会明白为什么说提示词工程是AI测试的必修课。 提示词工程四步法则：让大模型生成高质量测试用例
做AI测试大半年我最大的一个感受是大部分测试用例不是大模型写不好而是我们压根没问对。同一个模型有人拿到的接口测试用例十条有八条能直接进用例库有人拿到的十条里有九条是“正确的废话”。差别不在模型选型不在算力而在提示词怎么写。如果你正在用大模型辅助测试或者准备面试AI测试工程师岗位这篇内容值得慢慢读。我会把自己反复打磨出来的“提示词工程四步法则”完整拆开配合接口自动化测试、小程序AI自动化测试、智能体测试数据集设计这些真实场景讲清楚每一步背后的逻辑、具体的写法和踩过的坑尽量让不同基础的读者都能照着落地。1. 为什么做AI测试绕不开提示词工程1.1 一次让我警醒的对比实验上个月我组织团队做了一次内部练习任务很简单用同一个大模型给同一个登录接口设计测试用例。我把人分成两组一组直接甩了一句话“帮我设计这个接口的测试用例”另一组按照四步法则来写提示词。结果非常悬殊。第一组拿到的用例翻来覆去就是“验证用户名密码是否正确”“检查返回状态码”这类谁都能想到的东西第二组拿到的用例里有token过期、并发登录、参数边界、安全风险、验证码错误次数锁定这类真正有测试价值的内容。这个实验不是想证明谁聪明而是想说明一个事实大模型的输出质量很大程度上取决于输入提示词的质量。提示词写得模糊输出必然模糊提示词写得具体、专业、有约束输出才会像一份能用的测试资产。1.2 提示词工程到底是什么很多人一听到“提示词工程”就觉得是高深的技术其实它内核特别朴素不断雕琢提示词使大模型能给出最理想的答案这个过程就叫做提示词工程Prompt Engineering。它不只是一句话怎么写而是一套系统方法包括角色设定、上下文组织、输出约束、错误反馈与迭代优化。你可以把它理解成“给模型做需求分析”。需求分析做得越清楚交付的东西越接近预期。我们做测试的平时最擅长挑需求的毛病到了提示词这里同样要把“需求”给模型讲明白。模型没有读心术你不说清楚测试目标、被测环境、边界数据它就只能用训练语料里的普遍经验来补补出来的东西自然不贴你的项目。1.3 AI测试工程师的新基本功现在AI测试这个岗位越来越热面试题也开始从“会不会用Postman/JMeter”转向“怎么用大模型提效”。我自己面试候选人的时候一定会问一道题“给你一个接口你怎么让大模型帮你生成高质量的测试用例”大部分人的回答停留在“把接口文档贴进去”少数人会提到“告诉模型角色、给出边界条件、要求输出格式”。差距一下就拉开了。所以不管你是测试开发、功能测试、自动化测试还是正在转型AI测试工程师提示词工程都已经不是可选项而是基本功。它决定了你用AI是“提效”还是“增加返工”。用得好的人一天的用例设计工作半小时完成用不好的人花在挑错和返工上的时间比手工写用例还长。2. 四步法则的整体设计思路先搭骨架再填肉2.1 四步法则一句话版我日常用的这套方法总结下来就是四步角色设定、上下文构建、输出规范、迭代反馈。每一步解决一类具体问题步骤解决什么问题对应测试场景角色设定回答风格与立场不明确让模型像资深测试一样思考上下文构建信息缺失导致漏测与编造补充需求、接口文档、代码、测试数据输出规范结果不可解析、不可断言结构化输出JSON、用例字段、优先级、预期结果迭代反馈一次不准次次不准用失败样本反向优化提示词建立回归集2.2 为什么顺序不能乱这四步的顺序是有讲究的。先定角色是让模型进入“测试工程师”的工作状态后续所有推理都基于这个立场展开再给上下文是提供推理依据防止模型凭空编造然后约束输出格式是让结果能被自动化流程直接消费最后迭代反馈是让提示词从“偶尔准”变成“稳定准”。我见过不少人一上来就写“请用JSON格式输出”结果没有角色也没有上下文模型确实输出了JSON但内容全是空话。就好比你让一个新人写测试报告不告诉他测什么、怎么测只跟他说“用表格写”他交上来的表格当然没法看。格式是外壳角色和上下文才是血肉。2.3 一条完整的提示词长什么样先给大家看一条我经常用的模板后面每一节会拆开讲解你是一位有10年经验的测试架构师擅长接口自动化测试和边界分析。 请根据以下接口文档设计测试用例。 接口文档 POST /api/v1/login 请求参数username(string, 必填), password(string, 必填), captcha(string, 可选) 成功响应{code:0,message:success,data:{token:xxx,expires_in:7200}} 失败响应{code:1001,message:invalid credentials} 测试要求 1. 覆盖正常流程、参数异常、安全风险、并发场景 2. 关注username与password的边界值长度、类型、特殊字符 3. 每个用例包含用例编号、前置条件、操作步骤、预期结果、优先级 请以JSON数组格式输出测试用例。这条提示词看着不长但它同时包含了角色、上下文、任务目标、覆盖要求、输出格式五类信息。模型拿到它就知道自己是资深测试、被测对象是什么、要覆盖哪几类场景、最后交什么格式的成果。3. 第一步锁定角色与测试目标别让模型瞎猜3.1 角色设定为什么有效角色设定的本质是给模型一个“领域视角”。大模型在训练时见过海量语料不同的语料背后有不同的立场和表达方式。你告诉它“你是资深测试工程师”它就会偏向调用测试领域的知识体系比如等价类划分、边界值分析、场景法、错误推测法。你不说它就默认用“通用语言助手”的口吻回答写出来的东西自然四平八稳、没有测试味。有个很直观的例子。我让模型“帮我看看这个登录功能有哪些问题”它列了三条密码不能为空、用户名不能为空、验证码要正确。但我把角色改成“你是资深安全测试工程师专门做Web应用渗透测试”它就列出了撞库风险、验证码可绕过、登录接口未做频率限制、token过期策略不合理这些真正有价值的问题。同一个模型同一段输入差别只在角色那一句话。角色给模型画了一个专业边界边界内的推理会明显更聚焦。3.2 测试目标要写到什么颗粒度光有角色还不够目标也得说清楚。我建议把测试目标拆成三个层次写进提示词范围层测什么不测什么。比如“只设计登录接口的接口层用例不做UI层”。覆盖层必须覆盖哪几类。比如“正常流程、参数异常、权限异常、并发与性能、安全风险”。验收层什么样算通过。比如“每个用例必须包含明确的预期结果不能出现‘验证功能正常’这类模糊表述”。这三个层次写明白模型的输出就会有边界感不会跑偏到无关方向。比如你不写“不测UI层”模型可能会顺手给你生成一套Selenium脚本看着挺全但根本不是你要的东西。3.3 实操示例从模糊到精准模糊版提示词帮我测试一下用户注册功能。四步法优化后的提示词你是一位资深测试工程师专注Web端功能测试与安全性测试。 请对用户注册接口 POST /api/v1/register 进行用例设计。 覆盖范围手机号、密码、验证码三个字段的正常与异常组合。 重点关注手机号格式校验、密码强度规则、验证码错误次数限制、重复注册返回码。 输出要求每个用例包含用例编号、字段组合、操作步骤、预期结果、优先级高/中/低。 请用Markdown表格输出。前后对比一目了然。前者模型只能给泛泛的流程后者模型能给出可以落地的用例设计而且“重复注册返回码”这种细节恰恰是很多手工设计容易漏掉的点。3.4 这一步最容易踩的坑角色设定最常犯的错就是“角色太多、互相打架”。我见过一个提示词里写了“你既是测试工程师又是产品经理还是运维”模型到最后不知道以谁的身份说话输出夹杂着需求建议、线上监控方案和测试用例三不像。我的建议是一个提示词只保留一个主导角色最多加一个辅助视角比如“你是资深测试工程师同时有3年性能测试经验”不要贪多。角色一旦混乱后面几步做得再好都会白费。4. 第二步构建上下文把测试素材喂到位4.1 上下文的三层结构角色设定解决了“模型站在什么立场思考”的问题上下文则解决“模型根据什么信息推理”的问题。我在实战中把测试类提示词的上下文分成三层需求层被测功能要解决什么问题、业务规则是什么。技术层接口文档、数据结构、代码片段、技术栈约束。数据层测试数据、边界值样例、已有测试数据分布。三层信息越完整模型越不容易编造需求。很多人说大模型会“一本正经地胡说八道”其实很多时候是因为你只给了它问题没给素材它只能根据训练语料里的常识补补错了就是幻觉。做测试的人最忌讳需求来源不明喂给模型的素材也一样必须来源明确、口径统一。4.2 接口自动化测试场景的上下文组织以接口自动化测试为例我的习惯是把信息按下面结构拼进提示词被测接口POST /api/v1/order/create 功能说明用户下单接口需要登录态。 请求头Authorization: Bearer tokenContent-Type: application/json 请求体示例 {sku_id:SKU12345,quantity:2,address_id:ADDR001,coupon_id:CPN001} 业务规则 1. 库存不足时返回 code5001 2. 优惠券过期时返回 code5002 3. 下单成功后扣减库存和优惠券 4. quantity 取值范围 1-999超过返回 code4001 已有测试数据 - 有效用户user01 - 库存不足的skuSKU_BAD - 过期优惠券CPN_EXPIRED 请基于以上信息设计覆盖正常、异常、边界、并发场景的测试用例。这样组织之后模型拿到的是一份“被测对象全景图”它只需要在这个框架里做推理不会天马行空。实际跑下来生成的用例覆盖度明显高于只给一个接口路径的情况。尤其是“已有测试数据”这一块模型可以直接把具体数据值写进用例而不是写“传入一个不存在的sku”这种还要人工补数据的空话。4.3 小程序AI自动化测试的上下文设计很多同学问小程序怎么用AI做自动化测试。我的经验是小程序测试的提示词上下文和接口测试不太一样除了接口信息还得补上页面结构和交互约束。你是一位小程序自动化测试专家擅长编写自动化测试脚本。 被测小程序XX商城微信小程序 技术栈uni-app自动化框架miniprogram-automator 核心页面及路径 - pages/index/index首页 - pages/cart/cart购物车 - pages/order/confirm确认订单 被测流程首页 - 商品详情 - 加入购物车 - 结算 - 支付 支付环节使用测试环境mock支付不要调用真实支付。 请为上述主流程生成自动化测试脚本脚本需包含 1. 页面元素定位方式 2. 关键步骤的操作代码 3. 每一步的断言 4. 异常场景如商品已下架的处理这个提示词里最重要的两条信息是“路径结构”和“mock支付”没有这两条模型生成的脚本要么找不到页面元素要么在支付环节卡住。我一开始没写mock支付生成的脚本真的尝试调用了真实支付环境差点酿成事故。这是血泪教训。做自动化测试的上下文凡是涉及外部依赖、环境限制、安全边界的必须在提示词里显式写死不要指望模型自己意识到。4.4 上下文不是越多越好上下文给得不够模型会瞎编给得太多模型会“迷失重点”。我总结了一个经验上下文总量控制在模型输入窗口的20%-30%以内优先放与本次测试目标直接相关的信息。比如测登录接口就只放登录相关的业务规则不要把整个项目文档都贴进去。信息过载时模型的注意力会被无关内容稀释反而影响关键点的覆盖率。上下文组织的本质是“做减法”只保留能帮助模型做对事的信息。5. 第三步定义输出规范让结果可解析、可断言5.1 为什么必须要求结构化输出测试场景里AI的产出通常不是给人看一眼就完事的而是要喂给自动化流程的。如果模型输出的是散文式的描述后续脚本没法解析还得人工整理等于白干。所以第三步的核心就是把输出格式卡死。我自己最常用的是JSON格式因为解析成本最低。以下是我让模型生成接口测试用例时常用的输出结构{ test_cases: [ { case_id: LOGIN_001, title: 正确用户名和密码登录成功, preconditions: 已注册用户user01密码正确, steps: [ 调用POST /api/v1/login传入usernameuser01passwordpass123, 校验响应code0且data.token非空 ], expected_result: 登录成功返回有效token, priority: high, category: normal } ] }有了这个结构自动化脚本拿到结果后可以直接遍历填充到用例管理平台或者转成pytest参数化数据源。我自己写过一个小工具把模型输出的JSON直接转成YAML测试数据文件整个链路是通的。如果你做接口自动化测试这一步能帮你省掉大量手工整理用例的时间。5.2 输出约束的写法技巧要求结构化输出时光说“请用JSON”是不够的还要把字段的含义、枚举值范围、必填项写清楚。比如输出要求 - 输出JSON对象包含字段 test_cases - test_cases为数组每个元素包含case_id、title、preconditions、steps、expected_result、priority、category - case_id格式为“模块名_编号”如LOGIN_001 - priority取值只能是 high、medium、low - category取值只能是 normal、boundary、security、concurrency、error - 不要输出任何JSON以外的说明文字最后一条“不要输出任何JSON以外的说明文字”特别关键。不加这句很多模型会好心在JSON外面包一层“好的以下是生成的测试用例”解析脚本直接报错。我一开始没写这条解析脚本每次都要先做字符串清洗麻烦得很。加了之后基本零清洗成本。5.3 断言标准怎么写进提示词除了格式断言标准也要写进提示词。测试用例里的“预期结果”如果写得太虚自动化执行时没法断言。比如“验证功能正常”这种预期结果脚本根本不知道要断言什么。我要求模型写预期结果时必须包含可校验的维度状态码如code0或HTTP 200响应字段如data.token非空、message为固定文案时间维度如响应时间小于500ms数据一致性如库存扣减1、订单状态变为paid我常跟团队说一句话如果预期结果里没有数字、没有字段名、没有状态码那这条用例就不算写完。这句话完全可以用来评价模型生成的用例质量。你把这条标准写进提示词模型输出的预期结果立即可用自动化脚本的断言逻辑也能直接套用。6. 第四步迭代反馈把“一次准”变成“次次准”6.1 从失败用例反推提示词问题没有任何一条提示词第一版就能完美。我自己的命中率大概是这样第一版提示词生成的用例能直接用的大概只有六成剩下四成要么少了关键场景要么输出格式不达标。第二版修正之后能到八成再往后就靠持续迭代。最常见的三种失败模式和对策漏场景模型只覆盖正常流程没覆盖异常。对策在提示词里把覆盖维度显式枚举出来比如“必须覆盖normal、boundary、security、concurrency、error五类”。格式跑偏模型没按JSON输出。对策补充输出示例few-shot把一段合格的JSON样例直接贴在提示词里比写一百句“请按格式输出”都管用。照抄需求模型把需求文档里的描述原样搬到用例里没有测试视角。对策强化角色和任务要求比如“对以下需求进行批判性分析找出需求中未明确定义的边界条件”。这三个问题我基本每周都会遇到每次都是靠迭代提示词而不是靠换模型解决。换模型是最后手段多数情况下问题出在提示词不在模型。6.2 提示词版本管理与回归集很多人优化提示词靠感觉改一版就换个新提示词完全没有版本概念。我自己现在会维护一个提示词回归集。每次调整提示词先跑一遍回归集里的老问题确认已修复的问题没有复发再上线到新场景。我的做法很简单在项目里建一个prompts目录按场景分文件prompts/ ├── login_interface_test.md ├── order_interface_test.md ├── miniprogram_e2e_test.md ├── test_data_generation.md └── change_log.mdchange_log里记录每个版本的修改原因和效果版本修改点效果v1.0初版用例覆盖率60%v1.1增加安全测试维度覆盖率提升到75%v1.2增加JSON输出示例输出格式达标率100%v1.3修正角色描述去掉多余副角色用例质量明显提升这套做法听着土但特别有用。提示词和代码一样是会被不断改动的东西如果没有版本管理出了问题根本不知道是哪次改动引起的。我见过同学改完提示词效果变差想回滚却找不回旧版只能重新回忆浪费时间。用Git或者简单的change_log都能解决这个问题。7. 高频问题与排查速查7.1 典型问题速查表我把平时被问到最多的几个问题整理成了一张表方便大家遇到问题直接对照现象可能原因解决办法生成的用例全是正常流程提示词没显式要求异常覆盖在提示词中枚举覆盖维度normal/boundary/error/security输出格式总是不合规只说了“用JSON”没给示例在提示词里贴一段完整的JSON输出示例用例内容像复读需求角色设定太弱强化角色要求“以批判性视角分析需求”模型编造不存在的接口字段上下文里接口文档不完整把接口文档原文、字段类型、枚举值全部贴入上下文并发场景设计得离谱缺少业务规则约束补充业务规则如库存扣减、唯一约束、锁机制预期结果无法断言没有约束预期结果的写法要求预期结果必须包含状态码、字段名、数值条件这张表是我实践沉淀的直接结果每次碰到输出不对先查表再调提示词基本十分钟内能定位问题。建议你把这张表存下来或者根据自己的项目补充成自己的速查手册。7.2 我的一些习惯性动作除了上面这张表我还有几个固定习惯。第一写提示词之前先自己列一遍测试点。你脑子里得有一个“标准答案”才能判断模型输出好不好。很多同学让AI写用例自己根本不知道好用例长什么样那优化提示词就是盲人摸象。第二让模型给出多个候选版本。需要探索测试思路时我会在提示词末尾加一句“请给出三个不同思路的用例设计方向”然后从中选最优的而不是只让模型给一个答案。第三定期清理提示词里的“废话”。我每次迭代都会删掉一些不再起作用的长句因为提示词越长模型推理的负担越重出错的概率也会增加。能用10个字说清楚的事绝不用20个字。7.3 一个真实排查案例有一次我用AI生成一批订单接口的测试数据发现生成的数据里金额全是整数没有小数。我检查了提示词里面确实写了“amount为金额”但没写“amount可取小数、负数、极大值”。模型默认金额就是正整数这就是典型的上下文不足。我在提示词里补了一句“amount取值范围建议覆盖0、负数、小数、极大值、字符串类型”再跑就正常了。这个案例说明做AI测试数据生成提示词里的枚举示例比抽象描述重要得多。“金额”这个抽象词给模型的想象力太有限你必须把测试需要的具体形态摆出来它才知道往哪个方向用力。8. 场景延伸面试问什么智能体数据集怎么设计8.1 AI测试工程师面试中的提示词问题最近面试AI测试岗位几乎必考两件事一是怎么用提示词让大模型生成高质量测试用例二是怎么评估和优化模型在测试场景的表现。我建议面试准备者至少能现场说出这套四步法则并且能随手写出一条角色清晰、上下文完整、输出格式明确、带迭代思路的提示词。面试官真正想看的不是你背了多少提示词模板而是你有没有“把模型当测试工具来调优”的意识。能说出“我先给模型设定测试工程师角色再给它接口文档和边界数据要求它输出结构化用例最后根据漏测场景反推提示词”的人基本就过关了。8.2 智能体测试数据集怎么用提示词设计智能体测试的数据集设计和传统测试数据不太一样传统测试数据追求确定性智能体测试数据追求多样性和边界覆盖。我现在的做法是用提示词分层生成数据集每一层解决一类问题你是一位智能体测试数据专家。请为“航班查询智能体”生成测试数据集。 要求按以下维度生成 1. 正常查询出发地、目的地、日期齐全 2. 边界查询日期为今天、日期为一年后、往返日期倒置 3. 模糊输入如“明天飞北京”“帮我订个便宜票” 4. 多轮对话只有“我想去北京”这样的不完整表达等待追问 5. 对抗场景用户故意输入不存在的城市、特殊符号、超长文本 每个样本输出JSON格式包含 user_input、expected_behavior、difficulty_level。这样生成的测试集比从生产日志里捞出来的数据覆盖度更高更适合用来评估智能体在异常输入和模糊表达下的表现。尤其在多轮对话场景传统测试数据往往只覆盖完整表达而真实用户很少一次把信息说全这些不完整表达的样本必须靠提示词主动构造。8.3 给测试同行的最后一句话提示词工程不是什么玄学它就是一个把需求讲清楚的过程。我们测试工程师天天干的就是跟需求较真到了跟大模型打交道的时候把这份较真用上就行。先把角色定清楚再把上下文喂足然后要求结构化输出最后根据失败用例反推迭代。四步走完你会发现大模型做测试的质量比想象中高得多。根据我个人的经验这个能力花两周就能上手但带来的提效是长期的。建议你今天就拿手上一个现成接口试试第一步先给模型设定“资深测试工程师”的角色对比一下和之前直接提问的差别。差距出来了你就会明白为什么说提示词工程是AI测试的必修课。