提示词工程在智能测试中的实践-设计方法

文章作者: “TesterHome 社区”
发布平台: “微信公众平台”
发布时间: 2026-05-19 12:00:00
原文链接: “https://mp.weixin.qq.com/s/GCVKJbffH0YJcuOZkRvueQ“

智能测试进阶｜提示词工程在智能测试中的实践：核心设计方法与通用模板

**整理编辑｜**TesterHome 社区

前言

2026 年，AI Agent、云原生重构软件研发全流程，软件测试行业迈入人机协同智能化新阶段。传统测试脚本失效率高、维护成本偏高，AI 智能测试已成为多行业核心质量保障方案，测试从业者亟需一套聚焦 AI 大模型、国产化工具、复杂场景等方向，兼具前沿性与实操性的系统化内容。

此前，TesterHome 社区推出的《测试质量进阶》系列文章（点击查看）已完结，围绕测试底层逻辑、全流程管控等搭建了完整的基础进阶体系，助力从业者夯实核心能力，收获广泛认可。

承接往期干货调性，TesterHome 社区继续推出《智能测试进阶篇》系列文章。本系列以 “ 技术进阶 + 场景落地 + 体系升级 “ 为核心，覆盖 AI 大模型融合、国产化工具、车载/IoT 等复杂场景、效能优化与体系治理，以 “ 前沿性、实操性、深度性 “ 为导向，拆解实战案例、落地实操方案，助力测试人向高端智能测试工程师进阶。

文章将持续更新，敬请关注！

智能测试进阶篇 (3)——提示词工程在智能测试中的实践：核心设计方法与通用模板

在 AI 大模型与智能测试深度融合的进阶路径中，提示词（Prompt）是连接测试人员专业意图与大模型能力的 “ 核心桥梁 “。相较于传统 AI 测试工具的固定指令，大模型的输出质量高度依赖提示词的设计水平——很多测试团队在落地大模型测试时，之所以出现 “ 输出偏离需求、用例覆盖不全、故障分析流于表面 “ 等问题，核心并非大模型能力不足，而是缺乏系统的提示词设计方法，未能将测试领域知识、业务场景要求精准传递给大模型。

本文聚焦提示词工程的 “ 基础核心 “——设计方法与通用模板，摒弃复杂的理论堆砌，立足测试实操场景，先明确提示词设计的核心原则（筑牢基础），再拆解 4 大核心测试场景（需求分析、用例生成、故障根因、脚本修复）的通用提示词模板，每个模板均标注使用场景、核心要素和使用说明，确保测试人员无需深厚的 AI 技术功底，即可直接套用、快速上手，为后续提示词优化、场景化落地奠定基础，衔接前文大模型进阶应用的核心逻辑，延续 “ 实操为先、深度适配 “ 的系列调性。

本文核心目标：掌握智能测试场景提示词的核心设计逻辑，获取可直接复用的通用模板，解决 “ 提示词怎么写、写得准 “ 的核心痛点，让大模型精准理解测试需求，发挥其在智能测试中的核心辅助作用。

一、智能测试场景提示词的核心设计原则（必守基础）

测试场景的提示词，区别于普通聊天、文案生成的提示词，核心要求是 “ 精准、专业、规范、可落地 “，结合提示工程的科学逻辑与测试领域的特殊性，总结 5 大核心设计原则，贯穿所有模板的设计与使用全过程，也是避免提示词设计误区的关键。

1.1 角色锚定原则：让大模型 “ 化身 “ 专业测试人员

核心逻辑：明确指定大模型的 “ 测试角色 “，限定其专业领域、工作经验，让大模型以对应角色的专业视角输出结果，避免泛泛而谈。角色越具体，大模型的输出越贴合测试场景、越具专业性。

示例：避免使用 “ 作为测试工程师，生成测试用例 “，应使用 “ 作为一名拥有 5 年功能测试经验的工程师，专注于 Web 应用测试，熟悉需求分析与用例设计规范 “。

例如：某电商测试团队需生成 “ 商品搜索功能 “ 测试用例，初始提示词为 “ 作为测试工程师，生成商品搜索功能测试用例 “，大模型输出仅包含 “ 输入关键词搜索 “” 清空关键词 “2 个基础场景；优化角色描述为 “ 作为一名拥有 4 年电商测试经验的功能测试工程师，专注于电商 Web 端商品模块，熟悉商品搜索、筛选、排序的业务逻辑与用例设计规范 “，大模型输出覆盖了关键词精准搜索、模糊搜索、无结果搜索、筛选条件组合搜索等 10+ 场景，贴合电商实际业务，专业性显著提升。

关键要点：角色描述需包含 “ 经验年限、专注领域、核心能力 “，贴合具体测试场景（如车载、IoT、接口测试），让大模型快速对齐专业认知。

1.2 需求明确原则：杜绝模糊表述，降低理解成本

核心逻辑：清晰传递 “ 测试目标、测试范围、业务背景 “，避免模糊、笼统的表述，让大模型明确 “ 要做什么、做哪些、不做什么 “，减少理解偏差。

示例：避免使用 “ 生成接口测试用例 “，应使用 “ 生成电商平台支付接口的接口测试用例，覆盖正常请求、参数异常、权限异常 3 类场景，聚焦支付金额、订单号两个核心参数 “。

例如：某金融测试团队测试 “ 用户提现接口 “，初始提示词为 “ 生成用户提现接口测试用例 “，大模型输出未明确提现金额范围、用户权限等核心要求，用例缺乏针对性；优化后提示词为 “ 生成金融平台用户提现接口的接口测试用例，覆盖正常提现、金额异常（低于最低提现额、高于余额）、权限异常（普通用户提现超额）3 类场景，聚焦提现金额、用户 ID、提现方式 3 个核心参数 “，大模型输出的用例精准贴合金融提现业务规则，无冗余场景。

关键要点：需求描述需具体到 “ 场景、范围、核心对象 “，可补充简单业务背景（如 “ 该接口用于用户下单后支付，支持微信、支付宝两种方式 “），帮助大模型精准定位需求。

1.3 输出规范原则：明确格式，实现 “ 即输即用 “

核心逻辑：明确提示词的输出格式、字段、排版要求，让大模型的输出符合测试工作规范，无需人工二次整理，可直接对接测试流程（如用例格式贴合 TestRail、根因分析报告可同步至 Jira）。

示例：生成测试用例时，明确格式为 “ 用例名称、前置条件、操作步骤、预期结果、优先级 “；生成根因分析报告时，明确格式为 “ 故障现象、影响范围、根因定位、解决建议 “。

例如：某车载测试团队需生成 “ 座舱导航启动功能 “ 测试用例，未明确输出格式时，大模型输出为大段文字描述，需人工整理成用例格式；优化提示词，明确 “ 用例格式严格遵循：用例名称、前置条件、操作步骤、预期结果、优先级（高/中/低），操作步骤需贴合中控屏触摸操作场景 “，大模型直接输出结构化用例，可直接复制至测试管理工具，无需人工二次整理。

关键要点：输出格式需贴合企业实际测试规范，可提前约定字段顺序、排版方式，甚至给出简单示例，确保输出一致性。

1.4 约束清晰原则：划定边界，避免无效输出

核心逻辑：明确 “ 禁止做什么、需要注意什么 “，划定测试边界，避免大模型输出冗余、无效或不符合要求的内容（如编造测试数据、遗漏核心场景、偏离业务逻辑）。

示例：添加约束条件 “ 严格基于提供的需求文档生成用例，不编造未提及的测试场景；不生成重复用例，核心场景不可遗漏；测试数据需符合业务规范（如手机号为 11 位数字）”。

例如：某 IoT 测试团队测试 “ 智能门锁开锁功能 “，未添加约束条件时，大模型生成了 “ 指纹开锁、密码开锁 “ 等核心场景，但同时编造了 “ 人脸识别开锁 “（需求中未提及）的无效场景；添加约束条件 “ 严格基于提供的需求文档生成用例，不编造未提及的开锁方式，测试数据需符合门锁密码规范（6 位数字）” 后，大模型仅输出需求中明确的指纹、密码、刷卡 3 种开锁场景，无无效内容。

关键要点：约束条件需贴合场景需求，重点规避 “ 编造内容、冗余重复、偏离规范 “ 三大问题，确保输出质量。

1.5 上下文完整原则：补充关键信息，提升针对性

核心逻辑：补充必要的上下文信息（如需求文档片段、接口参数、故障日志、测试环境），尤其是复杂测试场景，上下文越完整，大模型输出的针对性越强，避免 “ 无依据输出 “。

示例：生成接口测试用例时，补充接口文档核心信息（接口地址、请求方法、必填参数、正常响应格式）；分析故障根因时，补充故障现象、相关日志片段。

例如：某 Serverless 架构测试团队分析 “ 接口调用超时 “ 故障，仅提供提示词 “ 分析接口调用超时故障根因 “，大模型输出泛泛而谈，无法定位具体原因；补充上下文 “ 故障现象：用户调用/user/getInfo 接口时，响应超时超过 3 秒，持续 5 分钟；日志片段：[2024-05-10 14:30:00] ERROR: 数据库连接超时，连接池已满；环境信息：Serverless 架构，数据库 MySQL 8.0，连接池最大连接数 10”，大模型快速定位根因为 “ 数据库连接池配置不足，高峰期连接耗尽 “，并给出针对性解决建议。

关键要点：上下文信息无需冗长，提取核心内容即可，重点补充 “ 影响大模型判断 “ 的关键信息，平衡简洁性与完整性。

二、4 大核心测试场景通用提示词模板（可直接复用）

结合智能测试最常用的 4 大核心场景——需求分析与质量前置、测试用例生成、故障根因分析、测试脚本修复，基于上述 5 大设计原则，设计通用提示词模板，每个模板均标注 “ 适用场景、核心要素、使用说明 “，测试人员可根据自身业务场景，替换模板中的 “[ ]” 内容，快速生成精准提示词，降低设计成本。

场景 1：需求分析与质量前置（左移测试）

适用场景

产品经理输出 PRD 文档、业务描述后，需快速解析需求、识别需求中的模糊点、不可测试点、逻辑矛盾，生成结构化需求质量报告或验收标准，提前规避需求缺陷，支撑左移质量管控。

通用提示词模板

“ 作为一名拥有 [X 年] 测试经验的需求分析专家，专注于 [行业/场景，如金融支付/车载座舱/Web 应用] 领域，负责需求质量校验与分析。请你基于以下提供的需求文档（或业务描述），完成以下任务：

梳理核心业务流程、核心需求点、异常场景、边界条件，简洁明了呈现；
精准识别需求中的模糊点、不可测试点、逻辑矛盾、遗漏点，标注每个问题的类型（模糊/不可测试/矛盾/遗漏），并对应需求中的具体内容；
针对识别的每个问题，给出具体、可落地的优化建议；
生成结构化的需求质量检查报告，输出格式严格遵循：核心需求梳理→问题清单→优化建议→可测试的验收标准。

约束条件：

严格基于提供的需求文档（或业务描述）分析，不编造任何未提及的需求或业务逻辑；
问题标注需精准，不泛泛而谈，验收标准需符合可测试性原则，可直接用于后续测试用例设计；
语言简洁、专业，符合企业需求分析规范，避免冗余表述。

上下文（需求文档/业务描述）：[粘贴具体的 PRD 文档片段或业务描述内容]”

实践示例

某电商团队使用该模板分析 “ 商品加入购物车 “ 需求，替换模板内容后提示词如下：” 作为一名拥有 3 年电商测试经验的需求分析专家，专注于电商 Web 应用领域，负责需求质量校验与分析。请你基于以下提供的业务描述，完成以下任务：

梳理核心业务流程、核心需求点、异常场景、边界条件，简洁明了呈现；
精准识别需求中的模糊点、不可测试点、逻辑矛盾、遗漏点，标注每个问题的类型（模糊/不可测试/矛盾/遗漏），并对应需求中的具体内容；
针对识别的每个问题，给出具体、可落地的优化建议；
生成结构化的需求质量检查报告，输出格式严格遵循：核心需求梳理→问题清单→优化建议→可测试的验收标准。

约束条件：

严格基于提供的业务描述分析，不编造任何未提及的需求或业务逻辑；
问题标注需精准，不泛泛而谈，验收标准需符合可测试性原则，可直接用于后续测试用例设计；
语言简洁、专业，符合企业需求分析规范，避免冗余表述。

上下文（业务描述）：

用户可将商品加入购物车，支持单个商品加入、批量加入，购物车商品可修改数量，单个商品数量不超过 10 件，未登录用户可加入购物车，登录后同步至账号。” 大模型输出的需求质量报告，精准识别出 “ 批量加入商品的数量限制未明确 “ 这一模糊点，并给出 “ 明确批量加入商品总数量不超过 50 件 “ 的优化建议，验收标准可直接用于后续用例设计。

使用说明

替换 [X 年] 为实际测试经验（如 3 年、5 年），[行业/场景] 贴合自身业务（如金融、车载、IoT），增强角色专业性；
上下文部分建议粘贴核心需求片段（无需全文），重点包含业务流程、核心功能描述，提升分析针对性；
若仅需生成验收标准，可删除 “ 问题清单、优化建议 “ 相关任务，调整输出格式即可。

场景 2：测试用例生成（核心实操场景）

适用场景

基于需求文档、接口文档或业务流程，快速生成符合企业测试规范、高覆盖率的测试用例，覆盖正常场景、异常场景、边界场景，减少人工用例设计成本，适配功能测试、接口测试等常见场景。

通用提示词模板（分 2 类，按需选用）

模板 1：功能测试用例通用模板

“ 作为一名拥有 [X 年] 功能测试经验的专家，专注于 [行业/场景，如车载座舱/电商 Web/移动端 APP]，请根据以下需求（或业务流程），生成功能测试用例。

核心要求：

覆盖范围：必须包含正常场景、异常场景、边界场景，不遗漏核心业务逻辑，重点覆盖用户高频操作场景；
用例格式：严格遵循 “ 用例名称、前置条件、操作步骤、预期结果、优先级（高/中/低）”，每个字段表述清晰、无模糊性；
优先级划分标准：核心功能（用户高频使用、影响业务正常运行）设为高优先级，次要功能设为中优先级，边缘功能设为低优先级；
用例可执行：操作步骤清晰可落地，预期结果明确可验证，无歧义表述。

约束条件：

严格基于提供的需求（或业务流程）生成，不编造测试场景、测试数据和业务逻辑；
避免用例冗余，相同测试场景不重复生成，用例语言简洁、专业，符合企业功能测试用例规范；
边界场景需重点覆盖（如输入参数的最大值、最小值、临界值，操作流程的异常中断等）。

上下文（需求/业务流程）：[粘贴具体的需求描述、业务流程步骤或 PRD 片段]”

实践示例

某车载团队使用该模板生成 “ 座舱蓝牙连接手机 “ 功能测试用例，替换模板内容后提示词如下：” 作为一名拥有 5 年功能测试经验的专家，专注于车载座舱场景，请根据以下需求，生成功能测试用例。

核心要求：

覆盖范围：必须包含正常场景、异常场景、边界场景，不遗漏核心业务逻辑，重点覆盖用户高频操作场景；
用例格式：严格遵循 “ 用例名称、前置条件、操作步骤、预期结果、优先级（高/中/低）”，每个字段表述清晰、无模糊性；
优先级划分标准：核心功能（用户高频使用、影响业务正常运行）设为高优先级，次要功能设为中优先级，边缘功能设为低优先级；
用例可执行：操作步骤清晰可落地，预期结果明确可验证，无歧义表述。

约束条件：

严格基于提供的需求生成，不编造测试场景、测试数据和业务逻辑；
避免用例冗余，相同测试场景不重复生成，用例语言简洁、专业，符合企业功能测试用例规范；
边界场景需重点覆盖（如输入参数的最大值、最小值、临界值，操作流程的异常中断等）。

上下文（需求）：车载座舱支持蓝牙连接手机，支持同时连接 2 台手机，可切换连接设备，断开连接后再次进入蓝牙范围可自动重连，支持 iOS 和 Android 系统手机。” 大模型输出 12 条结构化用例，覆盖正常连接、异常连接（设备数量超限、不支持系统）、边界场景（自动重连、切换设备），优先级划分清晰，可直接执行。

模板 2：接口测试用例通用模板

“ 作为一名拥有 [X 年] 接口测试经验的专家，熟悉 RESTful API、HTTP 协议，擅长接口测试用例设计与异常场景覆盖，请根据以下接口文档，生成接口测试用例。

核心要求：

覆盖范围：包含正常请求、参数异常（缺失、错误、格式错误、类型错误）、权限异常、边界值异常、依赖接口异常 5 类场景；
用例格式：严格遵循 “ 用例名称、接口地址、请求方法、请求参数（正确/异常）、前置条件、预期响应（状态码、响应体、响应时间）、优先级 “；
响应要求：正常请求响应时间≤[X]ms（根据企业实际要求填写），异常场景需明确对应的错误提示信息，符合接口文档规范；
用例可执行：请求参数格式正确，可直接复制至 Postman、JMeter 等接口测试工具执行。

约束条件：

严格按照接口文档的参数要求、返回规范生成用例，不编造接口参数、返回字段和错误提示；
异常场景需贴合接口实际逻辑，避免生成不符合接口设计的无效场景；
明确标注每个用例的优先级，核心接口的正常请求、关键异常场景设为高优先级。

上下文（接口文档）：[粘贴接口地址、请求方法、参数说明（必填/可选、类型、格式）、正常响应格式、异常响应说明等核心内容]”

实践示例

某金融团队使用该模板生成 “ 用户充值接口 “ 测试用例，替换模板内容后提示词如下：” 作为一名拥有 4 年接口测试经验的专家，熟悉 RESTful API、HTTP 协议，擅长接口测试用例设计与异常场景覆盖，请根据以下接口文档，生成接口测试用例。

核心要求：

覆盖范围：包含正常请求、参数异常（缺失、错误、格式错误、类型错误）、权限异常、边界值异常、依赖接口异常 5 类场景；
用例格式：严格遵循 “ 用例名称、接口地址、请求方法、请求参数（正确/异常）、前置条件、预期响应（状态码、响应体、响应时间）、优先级 “；
响应要求：正常请求响应时间≤500ms，异常场景需明确对应的错误提示信息，符合接口文档规范；
用例可执行：请求参数格式正确，可直接复制至 Postman、JMeter 等接口测试工具执行。

约束条件：

严格按照接口文档的参数要求、返回规范生成用例，不编造接口参数、返回字段和错误提示；
异常场景需贴合接口实际逻辑，避免生成不符合接口设计的无效场景；
明确标注每个用例的优先级，核心接口的正常请求、关键异常场景设为高优先级。

上下文（接口文档）：接口地址：/api/user/recharge；请求方法：POST；必填参数：userId（用户 ID，字符串，长度 10-20 位）、amount（充值金额，数字，≥10 元，≤5000 元）；正常响应：状态码 200，响应体{“code”:200,”msg”:” 充值成功 “,”data”:{“balance”:1000}}；异常响应：400（参数缺失，msg：” 用户 ID/充值金额不能为空 “）、400（格式错误，msg：” 用户 ID 需为 10-20 位字符串 “）、403（权限异常，msg：” 该用户无充值权限 “）。” 大模型输出的用例可直接复制至 Postman 执行，异常场景的错误提示与接口文档完全一致。

使用说明

功能测试模板可适配 Web、移动端、车载等多场景，替换 [行业/场景] 即可，若需聚焦某一细分场景（如车载座舱触摸操作），可在上下文补充场景细节；
接口测试模板中，[X]ms 需替换为企业实际接口响应要求（如 500ms、1000ms），上下文需提取接口文档核心信息，避免粘贴全文；
若需生成性能测试、安全测试用例，可在核心要求中补充对应场景（如性能测试补充 “ 并发量、响应时间阈值 “）。

场景 3：故障根因分析（右移测试）

适用场景

测试环境或生产环境出现故障（如接口调用失败、功能异常、系统崩溃），需结合故障现象、日志数据、链路信息，快速定位故障根因，区分故障类型（代码 bug、环境异常、接口依赖、配置错误等），并给出具体解决建议，缩短故障排查时间。

通用提示词模板

“ 作为一名拥有 [X 年] 测试运维和故障排查经验的专家，熟悉 [技术栈，如 Java、Kubernetes、微服务、车载协议]，擅长各类测试/生产环境故障定位与分析，请根据以下故障现象、日志数据和链路信息，完成故障根因分析。

核心要求：

先梳理故障现象，明确故障发生时间、影响范围（涉及的业务模块、用户群体、设备范围）；
结合提供的日志数据、链路信息，逐一步骤分析故障原因，精准定位核心根因，明确故障类型（代码 bug/环境异常/接口依赖/配置错误/其他）；
针对核心根因，给出具体、可落地的解决建议（分步骤说明操作流程），明确每个步骤的责任人（可选）和操作时长（可选）；
输出格式严格遵循：故障现象→影响范围→日志/链路分析→根因定位→解决建议→预防措施（1-2 条，避免故障重复发生）。

约束条件：

严格基于提供的故障现象、日志、链路信息分析，不主观臆断、不编造根因和解决建议；
根因分析需逻辑清晰、有数据支撑，每个分析结论均需对应日志或链路中的具体信息，避免泛泛而谈；
解决建议需具体可落地，避免 “ 优化代码 “” 检查环境 “ 等模糊表述，步骤清晰、可直接执行。

上下文：

故障现象：[粘贴具体故障描述，如 “ 用户点击支付按钮后提示 ‘ 系统异常 ‘，无法完成支付，持续时间 15 分钟，涉及 iOS 端所有用户 “]；
日志数据：[粘贴相关错误日志、接口调用日志、系统日志片段，重点标注错误信息、时间戳]；
链路信息（可选）：[粘贴链路调用关系、接口响应状态、服务依赖关系等信息]；
测试/生产环境信息（可选）：[粘贴环境配置、技术栈、部署架构等信息，如 “ 生产环境，微服务架构，Java 版本 1.8，数据库 MySQL 8.0”]。”

实践示例

某微服务团队使用该模板分析 “ 订单查询接口调用失败 “ 故障，替换模板内容后提示词如下：” 作为一名拥有 5 年测试运维和故障排查经验的专家，熟悉 Java、微服务、MySQL，擅长各类生产环境故障定位与分析，请根据以下故障现象、日志数据和链路信息，完成故障根因分析。

核心要求：

先梳理故障现象，明确故障发生时间、影响范围（涉及的业务模块、用户群体、设备范围）；
结合提供的日志数据、链路信息，逐一步骤分析故障原因，精准定位核心根因，明确故障类型（代码 bug/环境异常/接口依赖/配置错误/其他）；
针对核心根因，给出具体、可落地的解决建议（分步骤说明操作流程），明确每个步骤的责任人（可选）和操作时长（可选）；
输出格式严格遵循：故障现象→影响范围→日志/链路分析→根因定位→解决建议→预防措施（1-2 条，避免故障重复发生）。

约束条件：

严格基于提供的故障现象、日志、链路信息分析，不主观臆断、不编造根因和解决建议；
根因分析需逻辑清晰、有数据支撑，每个分析结论均需对应日志或链路中的具体信息，避免泛泛而谈；
解决建议需具体可落地，避免 “ 优化代码 “” 检查环境 “ 等模糊表述，步骤清晰、可直接执行。

上下文：

故障现象：2024-05-12 10:00-10:15，用户调用/order/query 接口查询订单时，提示 “ 系统异常 “，调用失败率 100%，涉及所有 Web 端用户；
日志数据：[2024-05-12 10:05:00] ERROR: 调用订单数据库失败，Connection refused: connect，数据库地址：192.168.1.100:3306；
链路信息：order 服务→db 服务，db 服务响应超时；
生产环境信息：生产环境，微服务架构，Java 版本 1.8，数据库 MySQL 8.0，订单数据库部署在 192.168.1.100 服务器。” 大模型快速定位根因为 “ 订单数据库服务器宕机，导致 order 服务无法连接数据库 “，属于环境异常，给出 “1. 运维人员重启 192.168.1.100 服务器数据库服务（责任人：运维张三，时长 10 分钟）；2. 重启后验证接口调用情况 “ 的解决建议，预防措施为 “ 添加数据库服务器监控，当数据库宕机时及时告警 “。

使用说明

替换 [技术栈] 为企业实际使用的技术（如车载场景可填写 “ 车载以太网协议、QNX 系统 “），增强故障分析的专业性；
日志数据建议粘贴核心错误片段（无需全文），重点标注错误码、异常信息、时间戳，帮助大模型快速定位问题；
若无链路信息或环境信息，可删除对应上下文内容，不影响核心分析效果。

场景 4：测试脚本修复（自动化测试进阶）

适用场景

自动化测试脚本（如 UI 脚本、接口脚本）执行失败，需快速分析脚本失效原因（如元素定位失败、接口参数变更、语法错误、环境适配问题），并自动修复脚本，确保脚本可正常执行，减少人工修复成本。

通用提示词模板

“ 作为一名拥有 [X 年] 自动化测试经验的工程师，熟悉 [脚本语言/工具，如 Python+Selenium、JMeter、Appium、Pytest]，擅长自动化脚本设计与修复，请根据以下失效脚本、失效日志，分析失效原因，并修复脚本。

核心要求：

先分析脚本失效原因，明确失效点（如元素定位器变更、接口参数调整、语法错误、环境路径变更），详细说明失效原因；
修复脚本，确保修复后的脚本可直接执行，功能与原脚本一致，完全解决失效问题，不引入新的语法错误或功能偏差；
给出详细的修复说明，明确修复的内容、修复原因，以及后续维护注意事项（如环境依赖、参数调整、元素定位器维护）；
脚本语法需严格符合 [脚本语言/工具] 规范，适配原测试环境，无需额外调整环境配置。

约束条件：

严格基于失效脚本、失效日志分析，不随意修改原脚本的核心功能和执行逻辑；
修复后的脚本需兼容原测试环境和测试数据，可直接复制执行，无需人工二次调整；
修复说明需清晰易懂，便于其他测试人员后续维护脚本、排查问题。

上下文：

失效脚本：[粘贴失效的完整脚本，标注失效的具体行数（可选）]；
失效日志：[粘贴脚本执行失败的日志片段，重点标注错误信息、失效位置]；
变更信息（可选）：[粘贴相关变更说明，如 UI 元素变更、接口参数调整、环境配置变更等]。”

实践示例

某自动化测试团队使用该模板修复 Selenium UI 脚本，替换模板内容后提示词如下：” 作为一名拥有 3 年自动化测试经验的工程师，熟悉 Python+Selenium、Pytest，擅长自动化脚本设计与修复，请根据以下失效脚本、失效日志，分析失效原因，并修复脚本。

核心要求：

先分析脚本失效原因，明确失效点（如元素定位器变更、接口参数调整、语法错误、环境路径变更），详细说明失效原因；
修复脚本，确保修复后的脚本可直接执行，功能与原脚本一致，完全解决失效问题，不引入新的语法错误或功能偏差；
给出详细的修复说明，明确修复的内容、修复原因，以及后续维护注意事项（如环境依赖、参数调整、元素定位器维护）；
脚本语法需严格符合 Python+Selenium 规范，适配原测试环境，无需额外调整环境配置。

约束条件：

严格基于失效脚本、失效日志分析，不随意修改原脚本的核心功能和执行逻辑；
修复后的脚本需兼容原测试环境和测试数据，可直接复制执行，无需人工二次调整；
修复说明需清晰易懂，便于其他测试人员后续维护脚本、排查问题。

上下文：

失效脚本：from selenium import webdriver; driver = webdriver.Chrome(); driver.get(“https://www.test.com/login“); driver.find_element(By.ID, “loginBtn1”).click();
失效日志：selenium.common.exceptions.NoSuchElementException: Message: no such element: Unable to locate element: {“method”:”css selector”,”selector”:”[id=”loginBtn1”]”}；
变更信息：登录按钮 UI 元素 ID 由 “loginBtn1” 变更为 “loginBtn”。” 大模型分析失效原因为 “ 登录按钮元素 ID 变更，脚本中定位器未同步修改 “，修复后的脚本将 “loginBtn1” 改为 “loginBtn”，并给出修复说明，修复后脚本可正常执行。

使用说明

替换 [脚本语言/工具] 为企业实际使用的技术（如 “Python+Selenium、JMeter”），确保脚本修复符合语法规范；
失效脚本需粘贴完整内容，失效日志重点标注错误信息（如 “ 元素未找到 “” 参数错误 “），帮助大模型快速定位失效点；
若有变更信息（如 UI 元素 ID 变更），补充后可大幅提升脚本修复的精准度，减少修复后的验证成本。

三、模板使用注意事项（避坑关键）

模板适配性调整：通用模板需结合企业实际业务场景、测试规范，替换 [ ] 中的内容，若企业有特殊要求（如用例格式、报告规范），可在模板中补充对应约束，提升适配性；
上下文精准提炼：上下文内容无需冗长，提取核心信息即可（如需求片段、接口核心参数、日志错误片段），过多冗余信息会增加大模型理解成本，降低输出精准度；
角色与场景匹配：角色描述需贴合具体测试场景（如车载场景用 “ 车载测试专家 “，接口测试用 “ 接口测试专家 “），避免角色与场景脱节，导致输出偏离需求；
约束条件不可缺失：约束条件是避免大模型无效输出的关键，尤其是 “ 不编造内容、不遗漏核心场景 “ 等约束，需根据场景补充，不可省略；
灵活调整输出格式：若企业有固定的用例模板、报告模板，可在提示词中明确输出格式（如 “ 用例格式需符合 TestRail 规范，包含用例 ID、模块、优先级等字段 “），确保输出可直接对接现有流程。

四、小结

提示词工程的核心并非 “ 复杂的指令设计 “，而是 “ 精准传递测试意图 “——本文提出的 5 大设计原则，是确保提示词精准度的基础；4 大核心场景的通用模板，是降低提示词设计成本、实现快速落地的关键。测试人员无需掌握 AI 技术、提示词工程的深层理论，只需套用模板、结合自身业务场景调整，即可让大模型精准理解测试需求，输出符合预期的结果。

后续文章将聚焦提示词的优化技巧与企业落地案例，结合不同规模企业的实操经验，讲解如何通过提示词优化，进一步提升大模型输出质量，解决模板使用过程中出现的 “ 输出偏差、覆盖不全 “ 等问题，让提示词工程真正服务于智能测试效能提升，衔接本系列 “ 技术进阶 + 场景落地 “ 的核心逻辑。

《智能测试进阶》系列文章（陆续更新中）