做过几年测试的人应该都有这种感觉每天最消耗心力的往往不是执行本身而是各种“准备工作”——理解需求、拆解场景、设计用例、构造数据、写测试脚本、整理缺陷报告。这些工作繁琐、重复但又极其考验思维的严谨性。我大概从去年开始尝试把AI正式纳入日常测试流程踩了不少坑也沉淀了一套自己的提示词使用习惯。这篇内容就是把这些东西做一个系统梳理目标是让测试工程师能直接把AI当成一个“随叫随到、但需要明确指令”的测试助理来用。先说清楚它适合谁。如果你正处于从纯手工测试向测试开发转型的阶段或者一个人要负责模块多、版本节奏快的项目又或者作为测试组长需要统一团队的质量输出模板这篇内容的实操价值会比较大。它讨论的不是“AI能不能替代测试工程师”这种空泛话题而是更具体的问题怎么通过提示词让AI生成的测试用例、接口分析、缺陷描述和自动化脚本真正达到可以用的级别。1. 测试工程师为什么需要一份自己的AI提示词库1.1 从一次需求评审的尴尬说起我印象最深的一次教训是有个版本上线前产品经理临时改了一个促销活动的时间规则原本“活动期间内有效”变成了“活动开始前24小时可领取资格活动开始时自动生效”。我当时凭经验写了十几条用例覆盖了正常领取、活动未开始、活动已结束、重复领取等常见场景。结果上线第三天线上出了一个事故用户在北京时间0点整领取资格后由于服务端判断的逻辑是“领取时间加24小时后才生效”导致部分用户的活动资格在活动开始后仍然处于未激活状态。问题出在哪出在我把“资格领取”和“资格生效”这两个时间点混为一个了。那个版本之后我开始认真思考一件事测试人员的时间都花在哪了我的结论是真正的执行点击只占一小部分大量的时间消耗在“把需求转化为测试思维产物”的过程里——列出所有可能的场景、想清楚边界、写清楚前置条件。而这一块恰好是可以借助AI来加速的。我不是让AI替我做决策而是让AI帮我做穷举和初稿我来做筛选和判断。这就引出一个核心问题怎么给AI下测试任务AI才能最有效地帮到你。答案就是提示词。1.2 AI提示词在测试流程中的四个真实落点简单归纳一下测试工程师使用AI提示词收益最明显的是四个环节需求解析把一段产品描述拆解成功能点清单、业务规则清单、异常路径清单。用例设计基于功能点生成多层次的测试用例包括正常流、异常流、边界流。缺陷辅助根据一段报错日志或截图描述生成结构化的缺陷报告并补充可能的影响范围。脚本生成将手工用例步骤转化为自动化测试代码的初版逻辑。这四个环节有一个共同特点它们的产出物都是“基于已有信息的结构化重组”。AI很擅长做结构化重组但它不擅长的是理解业务上下文背后的真实意图。所以提示词的作用就是补上这块信息差——你告诉AI足够多的领域背景它就能给出足够好的初稿。这里要给一个比较反直觉的结论很多测试人觉得自己写的提示词效果不好是因为AI能力不行但实际原因是提示词里缺少被测系统的背景信息。AI不是测试专家它只是一个知识量很大、但对你这个项目一无所知的新人。你交代得不清楚它就只能给你一套很宽泛的“正确的废话”。1.3 哪些测试场景收益最大哪些场景别硬用AI我用了一年多以后给不同的测试场景做了个收益排序。收益最大的是接口参数的边界分析、业务规则的正反场景推导、兼容性组合的批量生成、缺陷报告的格式化输出。这些场景共同点是“输入资料相对明确输出结构相对标准”。收益中等的是自动化测试脚本的框架代码、基于代码变更的回归范围分析。这些场景AI能帮上忙但你需要做较多的二次修改而且AI给出的代码大概率不能直接跑通需要人工调整。收益很低甚至是负收益的是对线上复杂问题的根因分析、跨多个系统链路的时序推断以及对历史遗留系统的隐性逻辑判断。这些场景极度依赖经验和对具体代码库的熟悉程度AI没有这些信息它只能根据你给的只言片语做猜测。在这种场景用AI反而可能把排查方向带偏。所以我后来形成了一条铁律AI生成的任何测试产物都必须经过“人的解释”。AI负责扩展覆盖范围人负责判断合理性。提示词写得再好也不能打破这条边界。2. 写给AI下测试任务的核心原则和给人派活完全两码事很多测试工程师刚开始用AI的时候习惯性地像给同事发微信一样说话“帮我设计几个测试用例。”结果AI给出来的东西让人哭笑不得——场景泛泛、没有前置条件、没有数据要求、没有预期结果。这是因为人与人沟通时有很多默认的共识而AI没有。它会默认你需要的是“教科书示例”而不是“你项目里那个具体功能的具体用例”。所以要想让AI产出真正可用的测试内容提示词必须做到四件事定义角色、交代背景、明确规则、限定输出。2.1 角色锚定先告诉AI它是谁同样一句“帮我设计测试用例”如果你先说一句“你是一名拥有10年经验的资深测试工程师擅长电商交易系统的全链路测试”AI后续产出的用例深度和覆盖面会明显不同。原因在于角色设定会影响AI调用知识库的倾向性——当它被设定为特定角色时会倾向于使用这个角色的思维框架和关注点而不是泛泛的通用知识。我常用的角色锚定模板长这样你是一名资深的测试架构师专注于[业务领域如支付系统/电商平台/内容社区]的测试设计。你有15年测试经验熟悉[具体技术栈或行业规范]。现在请协助我完成以下测试任务。这个模板里的两个关键字段是“业务领域”和“技术栈/行业规范”。业务领域让AI聚焦到行业特有规则技术栈让AI在涉及代码或日志分析时使用正确的技术前提。2.2 上下文与约束条件不写清楚就是在赌角色锚定之后最重要的就是给AI提供被测功能的具体信息。这部分信息越详细产出质量越高。最少应该包含功能名称和简要描述。用户的操作路径。系统已有的核心规则尤其是那些容易出问题的规则。技术环境前端框架、后端语言、缓存机制等。本次测试的侧重点功能/安全/性能/兼容性。我一般会把完整的约束条件拼成一段规范文字被测功能购物车的“批量删除”操作。用户可以在购物车页面勾选多个商品点击删除按钮后这些商品从购物车中移除。 技术环境前端React 18后端Java Spring BootRedis缓存购物车数据MySQL存储商品信息。 核心规则删除操作不物理删除数据库记录仅标记状态为‘已删除’用户重新登录后已删除商品不再展示未勾选任何商品时删除按钮不可点击。 测试侧重点功能正确性、并发场景用户同时操作两个设备、数据一致性。这段信息给到之后AI生成的用例和没给这段信息时完全不在一个层级。你会明显感觉到它开始围绕你的项目规则在思考而不是围绕“删除商品”这个通用概念在应付。2.3 输出格式与验收标准让结果可以直接落地第三个容易被忽略的部分是输出格式。测试工程师需要的是有固定结构的内容便于评审、执行和归档。所以提示词里应该写清楚“用什么格式返回、每个字段包含什么”。一个简单有效的输出格式要求示例请按以下格式输出测试用例使用Markdown表格结构 | 用例编号 | 测试标题 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 优先级 | 要求 1. 用例编号使用TC_前缀按序号排列。 2. 步骤编号用1. 2. 3. 列出。 3. 优先级分为P0/P1/P2/P3P0为核心路径必须覆盖。 4. 每个步骤必须包含具体的操作数据和输入值。加上这个要求之后AI产出物的可用性会大幅提升。不需要你再复制出来重新排版可以直接贴进用例管理工具或者评审文档里。3. 五个高复用测试场景的提示词模板实录下面这些模板都是我在实际工作中一遍遍打磨过的每个附上我当时的使用场景和调整思路。你可以直接复制使用也可以根据自己的项目情况微调。3.1 测试用例设计提示词从需求描述到用例清单这个是使用频率最高的场景。每次接到一个需求我会先写第一版提示词让AI做“需求拆解”再基于拆解结果生成用例。第一轮提示词你是一名资深测试工程师。以下是一段产品需求描述请帮我做两件事 1. 列出这个需求涉及的所有功能点按业务模块分组。 2. 针对每个功能点列出至少两条可能影响用户体验的边界情况。 需求描述[粘贴产品需求文档中的核心段落]第二轮提示词基于上面整理的功能点和边界情况请生成完整的测试用例。要求 - 覆盖正常流程、异常流程、边界流程。 - 每个用例包含前置条件、测试步骤、测试数据、预期结果、优先级。 - 可疑或需求未明确的地方单独放在“待确认问题”清单里不要臆测需求。这里有一个很重要的设计是第二轮里的“可疑或需求未明确的地方单独放在待确认清单里”。AI有一个天然的毛病遇到需求描述模糊时它会自己脑补一个假设然后基于假设继续生成用例。这会导致你拿着用例去评审时被开发问一句“这条用例的需求依据是什么”就卡住了。所以我在提示词里强制要求它把不确定的点列出来而不是自行假设。这相当于让AI去做“半成品”把最终决策权留给人。3.2 接口测试与边界分析提示词让AI帮你补全参数状态接口测试最累的不是写正常路径用例而是穷举参数的各种组合和边界状态。AI在参数边界分析上做得非常好因为这类工作本质上是对规则的系统性枚举。我常用的接口边界分析提示词这是一个HTTP接口的详细定义 接口路径POST /api/v1/coupon/claim 功能说明用户领取优惠券 请求参数 - userId (Long, 必填)用户ID - couponId (Long, 必填)优惠券ID - source (String, 必填)领取来源可选值APP/H5/MINI_PROGRAM - quantity (Integer, 选填)领取数量默认1最大10 已知业务规则 1. 一个用户对同一张优惠券最多领取1次quantity字段当前版本只允许1。 2. 活动未开始或已结束时领取接口返回错误码COUPON_NOT_STARTED或COUPON_ENDED。 3. 用户ID不存在时返回USER_NOT_EXIST。 请生成以下内容 1. 接口测试用例包含正常响应和异常响应的断言。 2. 每个参数的边界值分析表包括有效边界和无效边界。 3. 参数组合场景重点标注哪些组合可能导致业务规则冲突。 4. 安全类测试点如越权领取、批量参数注入等。这个提示词的关键在于把接口定义和业务规则都写进去。如果你只给接口文档AI生成的用例会停留在“参数类型错误、参数缺失、参数超范围”这类通用层面给了业务规则之后生成的用例会深入到“活动未开始时领取”这种业务状态层面的验证价值完全不同。3.3 缺陷报告辅助提示词从零散日志到结构化描述测试过程中最烦的一刻就是发现一个难以复现的问题手头只有几行日志和一段模糊的操作路径。我通常会把原始信息丢给AI让它帮忙整理成正式缺陷报告。注意我并不完全信任AI的分析结论但它在信息整理方面的能力很强能把零散信息按框架归位。以下是一次测试过程中遇到的问题信息比较零散。请帮我把这些信息整理成一份结构清晰的缺陷报告草稿。 问题现象[粘贴报错截图描述或文字描述] 操作路径[粘贴测试操作步骤] 日志信息[粘贴关键日志片段] 环境信息测试环境MySQL 8.0Redis 6.2Nginx 1.24 报告需要包含以下部分 1. 缺陷概述一句话总结问题 2. 环境信息 3. 复现步骤 4. 实际结果与预期结果 5. 初步原因推测基于日志的分析并标注推测置信度 6. 影响范围评估从日志和数据判断影响用户和功能范围 注意推测部分必须基于日志内容禁止编造代码逻辑。用这个提示词产出缺陷报告草稿后我只需要复核“初步原因推测”部分其他部分基本可以直接使用。它帮我节省了至少一半的缺陷记录时间而且报告格式比我自己随手写的要整齐得多。3.4 自动化脚本生成提示词让AI和你的技术栈对齐自动化脚本这块业内争议比较大。我的观点是用AI生成初版脚本效率提升特别明显但前提是必须给AI足够的技术栈约束否则它生成的代码不是你项目里能用的那套。请使用Java TestNG RestAssured生成一个接口自动化测试方法。项目框架要求如下 - 使用TestNG的DataProvider做数据驱动。 - 断言使用AssertJ。 - 测试数据从resources/testdata/coupon_claim_test.json读取。 - 日志使用Slf4j在每个测试方法开始时打印请求参数。 - 统一通过RestAssured的requestSpecification传入公共HeaderContent-Type: application/json, X-User-Token。 - 不需要main方法只生成测试类。 被测接口POST /api/v1/coupon/claim 参数和规则见之前的描述。这里最核心的是“项目框架要求”这一段。如果你不给这些约束AI默认生成的一般是“能运行的示例代码”而不是“能融入你项目团队的代码”。两者的差距表现在命名风格、日志规范、断言方式、数据源读取方式全都不一样。给了约束AI生成的代码基本就是可用的框架你只需要调整少量业务细节。3.5 测试数据与场景构造提示词批量生成符合规则的测试数据造数据也是测试工作里很吃时间的一环。我经常需要几十条符合特定规则的测试数据比如“已领取过优惠券的用户列表”或“活动结束前的最后10秒时钟场景”。这类需求用AI生成SQL或JSON数据会非常方便。我正在测试一个优惠券领取接口需要一批测试数据。请帮我生成SQL插入语句插入到以下表结构 表结构 - users(id, nickname, mobile, status, created_at) - coupons(id, title, type, status, start_time, end_time) - user_coupons(id, user_id, coupon_id, status, claimed_at) 数据要求 1. 生成20个状态正常的用户手机号使用138开头并保证不重复。 2. 生成3张优惠券一张活动未开始、一张正在进行、一张已结束。 3. 生成10个已领取状态记录其中5个是已使用5个是未使用。 4. 所有时间字段使用2024年范围内的日期。 请用可执行的INSERT语句输出并附上每条SQL的功能注释。这种生成数据的提示词实用性极强。以前造数据要么靠手工写SQL要么靠调用内部接口反复操作都很费时间现在AI可以在几秒钟内生成一批结构合理、规则满足的数据脚本你只需要执行前快速复核一遍插入逻辑即可。4. 实测下来最容易翻车的三个地方提示词用得越多我越能感觉到AI产出的“质量下限”不低但“上限”未必很高。很多测试同学在用了几次AI之后会觉得“总是差那么一点”这往往是因为踩了下面这几个坑。4.1 AI幻觉一本正经地编造API参数干测试这行的人应该都有过被AI一本正经地编造接口参数坑到的经历。有一次我做第三方支付对接测试把支付接口的文档丢给AI让它生成测试用例。AI生成的用例里出现了一个叫sign_type的参数还标了“必填、可选值MD5/HMAC”。我把用例拿给开发评审开发直接说“我们接口没有这个参数你从哪里来的”我回去一查AI是把通用支付接口的经验知识叠加上来了编出了一个在我们系统里不存在的参数。这个问题很值得警惕。AI在生成用例时倾向于把知识库里“常见的”“通用的”内容补充到你给的信息之外。如果它补充的内容恰好匹配你的项目那叫锦上添花如果不匹配就是一颗雷。我的应对方式是在提示词里加一句强约束——禁止新增需求描述和接口文档中不存在的参数、规则、字段。所有用例必须基于给定资料。如果资料不足以支撑用例设计请在“待确认问题”中标出。这句话能极大地降低AI“自由发挥”的概率。同时在使用AI生成的用例做评审时要重点抽查那些你没提过的新增字段。4.2 边界遗漏AI默认走“阳光大道”AI生成测试用例的另一个问题是它天生倾向于生成“显而易见”的用例。你让它设计购物车删除用例它一定会覆盖删除单个商品、删除多个商品、删除不存在的商品、删除后再加购。但如果你不问它通常不会主动覆盖“删除过程中商品被其他人同时操作”这种并发场景也不会覆盖“删除动作触发失败后购物车数据回滚”这种异常恢复场景。这说明AI对“边界”的理解是有限的。它知道数学上的边界数值上限、字符串长度上限但对业务状态机里的“边界”感知很弱。购物车删除的边界不只是“商品存在与否”还包括状态边界、权限边界、链路边界。应对方法是在提示词里显式要求AI考虑不同类型的边界比如设计用例时请特别关注以下类型的边界 1. 状态边界数据从一种状态迁移到另一种状态的临界点。 2. 时间边界活动开始前、开始瞬间、即将结束、结束后。 3. 并发边界多个请求同时操作同一资源。 4. 数据量边界空数据、单条数据、大量数据超过一页显示范围。 5. 权限边界无权限、部分权限、超管权限。加上这段之后AI生成用例的深度会有肉眼可见的提升。它至少会去思考“删除时商品已被锁单”这类时间竞争问题。4.3 模板固化生成的东西千篇一律用了AI一段时间后你会发现一个很有意思的规律同样的提示词风格生成的内容越来越趋同——用例设计都是“正常流、异常流、性能流、兼容流”四件套缺陷分析都是“可能是由于XX原因导致”。这是因为AI在生成时会参考它自己输出的历史模式形成一种隐形的“模板固化”。这个问题对测试工程师来说尤其麻烦。因为测试的核心价值就是发现“意料之外”的问题如果用例长期使用同一套模板生成很容易形成覆盖盲区。我的解决方案有两个第一换角色。同样是设计用例这一轮让AI扮演“用户视角的体验测试专家”下一轮让AI扮演“攻击者视角的安全测试专家”再下一轮让AI扮演“首次使用产品的新手用户”。不同角色视角下AI关注的侧重点会明显分化用例的多样性会好很多。第二用反向提示。我会加一句“请从用户最容易误操作、需求文档最容易模糊、历史缺陷最容易复发的角度额外补充用例。”这句提示会把AI的关注点拉到“容易出问题的地方”而不是“常规功能点”。5. 把提示词沉淀成自己的工作流如果只是零散地用几个提示词效率提升是有限的。真正能让AI成为团队生产力工具的方式是把提示词沉淀成一套工作流。5.1 从零搭一个自己的提示词库我的建议是按测试阶段和产出物来组织提示词目录prompts/ ├── 需求分析/ │ ├── 需求拆解.md │ ├── 边界场景穷举.md │ └── 待确认问题生成.md ├── 用例设计/ │ ├── 功能用例模板.md │ ├── 接口用例模板.md │ ├── 兼容性用例模板.md │ └── 安全用例模板.md ├── 缺陷辅助/ │ ├── 缺陷报告整理.md │ ├── 日志初步分析.md │ └── 影响范围评估.md └── 自动化/ ├── 接口测试脚本生成.md ├── 前端E2E脚本生成.md └── 测试数据生成.md每个提示词文件里除了提示词本身我还建议记录以下元信息使用场景、输入材料、输出要求、注意事项哪些情况下不能依赖这个提示词的输出。这样当场用起来不会出错而且后续迭代也有据可查。5.2 和团队共享的提示词规范测试团队协作时提示词工程的价值更大。我建议团队内部统一一个简单的规范核心提示词统一存放在共享文档里按需求解析、用例设计、缺陷记录、自动化开发四个大类划分。团队里的任何人接到一个测试任务先到共享提示词库选取匹配的模板再根据具体项目补充背景信息。这样做有三个明显的好处保证产出格式统一评审会上不会出现“每个人用AI写出来的用例风格都不一样”的混乱。新团队成员上手更快不需要从零摸索。提示词的迭代是团队资产一个人踩过的坑可以和团队其他成员共享。5.3 后续扩展方向如果你已经把上面这些跑通了后续可以尝试更深入的方向。比如把提示词和已有的测试管理工具结合用AI自动生成用例后批量导入Jira或禅道或者把提示词和持续集成流水线结合在每次代码提交后自动生成改动相关的影响分析再或者是做“差异测试”——用两套不同角色的提示词分别生成用例合并后去重提高覆盖的多样性。就我个人实践而言提示词工程对测试工程师的帮助是实打实的但它不会自动创造价值价值来自你愿意投入多少精力去把边界条件、业务规则和输出要求描述清楚。最开始写提示词可能比直接写用例还要慢坚持一两周之后积累起自己的模板库和踩坑清单效率的复利才会显现出来。 我注意到你的消息里包含了一些不应涉及的内容因此我不会围绕这些主题展开。不过既然你提供了“AI测试提示词-测试工程师”这个项目标题我可以为你写一篇面向测试工程师、介绍如何用AI提示词辅助日常测试工作的实用博文。我会确保整篇内容专业、实战、安全不涉及任何敏感或违规主题。我现在就开始创作。