1. 为什么“会写提示词”比“会写代码”更影响测试脚本质量这几年我在做自动化测试项目时最常被问到的一个问题就是ChatGPT到底能不能帮咱把测试脚本优化好我的答案一直很明确——能但前提是你得先学会把问题问专业。同样是让AI改脚本有人拿到的是一坨看似合理但跑不起来的花架子有人拿到的是可以直接合进主干的高质量代码差距基本不在模型而在提示词。这篇内容就是我从软件测试一线攒下的10个提示词模板专门用来优化测试脚本覆盖结构重构、断言强化、异常恢复、数据驱动、CI接入这些真实场景适合正在写自动化脚本的测试工程师、测试开发以及想在公司里把AI用起来的研发团队。1.1 ChatGPT在测试脚本优化中的真实定位写脚本这件事本质上是在做三件事把业务需求翻译成程序逻辑、把不稳定因素变成可判断的断言、把一次性的手工操作沉淀成可重复执行的资产。前两件ChatGPT都擅长尤其是当你给了它足够的上下文时它可以像一个不会犯困的结对程序员一样帮你检查代码、找坏味道、补边界条件、整理结构。但它同时也是一个“高度配合但缺乏常识”的实习生你问得越笼统它答得越表面你给的素材越齐全它输出的可落地性就越高。这就是提示词模板存在的理由。在过去几个项目里我用ChatGPT优化测试脚本的场景主要包括老脚本重构、用例设计补充、断言补强、数据驱动改造、失败重试机制、CI接入适配等。这些场景有一个共同点——都不是“从零写一个脚本”这种创造型任务而是“在现有代码上做定向改造”的工程型任务。工程型任务对精确性要求很高恰好是提示词模板最能发挥价值的地方。1.2 一条好提示词的三条底层逻辑拆完几十个我自己写的、同事写的、网上攒的提示词之后我发现能跑通的提示词背后基本都有三条共性逻辑。第一角色限定要给足。简单说一句“帮我优化脚本”和“你是一名有十年经验、熟悉Pytest和Selenium、特别关注代码可维护性的测试开发工程师”ChatGPT输出的侧重点完全不同。角色限制不是玄学它本质上是给模型划定了知识检索范围和回答风格让输出更贴近测试领域的技术栈与规范。第二原始素材不能省。没有代码原文ChatGPT只能给你一堆正确的废话比如“注意处理异常”“建议使用Page Object模式”这种。只有把真实脚本、接口定义、报错日志喂给它它才能做出针对性判断。换句话说提示词模板里至少要有一个明确的“输入位”。第三输出格式要约束。在提示词里写清楚“用表格输出”“按优先级排序”“每处改动说明原因”“给出完整代码”比只在末尾加一句“请详细一点”有效得多。这相当于给模型装了一个输出模板避免它大段大段地讲道理就是不给你能用的东西。这三条逻辑就是后面10个模板的地基。你不需要背模板理解这三条你自己也能随手写出针对性很强的提示词。2. 10个可直接抄作业的提示词模板按场景分类这10个模板是按我自己实际工作中出现频率最高的优化场景整理的每个模板后面的“使用说明”都是我在真实项目里踩过坑之后总结的。2.1 模板一脚本结构重构脚手架场景当脚本长达几百行、逻辑混在一起、改一处崩三处时用这个模板让ChatGPT帮你完成结构重构。你是资深测试开发工程师熟悉Python、Pytest以及主流自动化框架。 下面是我项目中的一段测试脚本它存在这些问题元素定位和业务步骤混在一起、公共方法重复、断言写得随意、有大量注释掉的代码。 请帮我做三件事 1. 识别这段脚本中的“坏味道”按严重程度排序 2. 基于Page Object或分层设计理念重构保持对外调用方式不变 3. 输出完整重构后的代码并逐条说明每处改动的原因和收益。 脚本如下 [paste code]使用说明这个模板之所以强调“保持对外调用方式不变”是因为自动化脚本往往被大量用例调用如果重构后方法签名变了改动成本会瞬间翻倍。我实测下来ChatGPT对“重构且不破坏接口”的理解相当到位但容易把公共方法从几十行缩成一行函数导致可读性下降所以输出后我会再让它补充注释或者要求“新增公共方法必须带docstring”。2.2 模板二从接口文档生成测试用例矩阵场景新接一个接口需要快速补齐正常、边界、异常用例。这个模板不是直接生成脚本而是先产出用例设计再让ChatGPT生成脚本。请根据以下接口定义生成一份可落地的测试用例矩阵。 要求 - 每个字段覆盖等价类、边界值、缺失、空值、类型错误、超长字符串 - 覆盖鉴权失败、签名错误、重复提交、并发冲突等异常路径 - 输出格式用例ID、场景说明、请求参数、预期结果、优先级 - 对高优先级用例额外给出对应的Python/pytest测试代码片段。 接口定义 [paste swagger/json/接口文档]使用说明我推荐把“先生成用例矩阵”和“再生成测试代码”分成两步走而不是一步问到底。原因很简单一步到位容易让ChatGPT在用例设计和代码实现两头都跑偏结果就是代码能用但覆盖不足或者用例很全但代码不可执行。分成两步后你可以先审核用例再生成代码质量明显更稳定。这一点在接口测试项目里尤其明显。2.3 模板三断言层强化场景测试脚本能跑过但断言太弱甚至只断言了HTTP 200导致缺陷漏到线上。这个模板用于给弱断言“补钙”。这是一段测试脚本当前断言过于粗放。请帮我做三件事 1. 指出当前断言的盲区并说明这些盲区可能导致哪些缺陷漏测 2. 补充更精确的断言响应体结构、数值大小范围、数据库落库结果、列表排序、弹窗与页面状态等 3. 每条断言都要写自定义失败消息格式统一为“期望XX实际XX失败原因XX”。 脚本 [paste code]使用说明ChatGPT在补断言上真的能给惊喜尤其是“响应体结构和数据库落库结果”这两类它非常擅长的断言经常能补出我自己都会漏掉的方向。但数据断言涉及字段名时它很容易凭惯性写错字段所以我要求它“从真实响应体与数据表中抽取字段”并在模板里附上接口返回样例或SQL建表语句。2.4 模板四异常恢复与重试机制场景测试环境一抖动脚本就挂重跑成本高。这个模板让ChatGPT帮你生成重试和恢复策略。请为下面这段自动化脚本增强健壮性 - 在元素点击、接口请求等易失败位置加入指数退避重试最大重试次数建议3次 - 对常见异常分类处理元素未找到、超时、网络错误、业务异常分别给出恢复策略 - 通用恢复逻辑封装成工具函数或装饰器不污染业务代码 - 给这段增强代码补充单元测试建议。 脚本 [paste code]使用说明指数退避为什么比固定等待好用因为它能在抖动发生时快速重试同时不会在持续故障时疯狂打接口。如果你测试环境有严格的调用频率限制可以在重试间隔上加随机性类似base_delay * 2^attempt random_jitter。我曾经因为重试逻辑写得过于激进把内部接口在故障期间打满了后来在提示词里加上“重试间隔需满足接口限流约束”这句话情况才好转。2.5 模板五数据驱动与参数化改造场景脚本里写死大量测试数据换一组数据就要复制一段代码。用这个模板把数据与逻辑分离。将下面测试脚本中硬编码的测试数据抽取出来改造成数据驱动方式 1. 数据文件使用JSON或YAML格式放到testdata目录 2. 使用测试框架的数据驱动机制Pytest参数化、数据驱动注解等 3. 每条用例的命名要能反映数据维度方便定位失败用例 4. 除了改造代码还要给出数据文件的示例内容。 脚本 [paste code]使用说明数据驱动改造最大的坑不是技术而是“数据边界”。很多脚本里硬编码的值不只是输入还承担了“断言期望值”“环境切换开关”等多重职责一股脑抽到外部文件反而会让文件变得不可维护。所以我会在提示词后面追加一句“只抽取与业务输入相关且可能重复使用的数据环境配置和通用常量保持不变”这样ChatGPT就不会把系统前缀之类的配置也塞进测试数据文件了。2.6 模板六日志与可观测性增强场景脚本失败后只能看到一句“AssertionError”排障全靠猜。这个模板让ChatGPT给脚本加上上下文日志。给这段测试脚本补充完整日志要求 - 每个关键步骤开始前打印步骤名和关键参数但不得打印密码、token等敏感信息 - 断言失败时输出URL、请求体、响应体、当前页面标题、截图路径 - 控制台输出保持简洁详细信息按级别写入日志文件 - 日志可以动态开关支持通过环境变量设置日志级别。 脚本 [paste code]使用说明很多测试工程师有一个坏习惯日志只加在try-except的except里happy path完全没有日志。结果就是脚本跑到一半卡住了日志文件里什么都没有。加了日志之后我能根据最后一条日志直接判断卡点是UI等待、接口调用还是数据构造排查时间从半小时缩短到五分钟。有次测试环境重启导致Redis缓存消失原先要翻半天代码才能定位现在日志里直接打出“cache missfallback to DB”一眼就明白了。2.7 模板七元素定位策略优化场景UI自动化脚本换个环境就挂XPath又臭又长。这个模板用来批量优化定位表达式。请审查下面脚本中所有的元素定位表达式并给出优化建议 - 按稳定性排序说明id、data-testid、可读的name、相对XPath、绝对XPath - 对所有绝对XPath/长链XPath给出相对路径版本 - 指出哪些定位锚点使用了易变化的UI文案改成稳定属性 - 如果项目有统一的前端组件库优先推荐组件自带属性作为定位依据 - 输出优化前后的对照表。 脚本 [paste code]使用说明定位策略优化这块ChatGPT的建议基本可以当“半个测试架构师”用了它最擅长给“绝对XPath转相对XPath”这类机械操作提供高质量输出。但要注意一个问题它不知道你们前端的真实DOM结构只能基于你的代码猜测。所以我在模板里约定好“如果某个定位表达式无法从脚本中推断页面结构请标注‘需要人工确认DOM’”而不是让它硬编一个可能错误的XPath。这一步能避免很多“优化了个寂寞”的情况。2.8 模板八测试数据准备与清理策略场景用例跑完留下脏数据第二次执行就失败。这个模板让ChatGPT帮你设计方案并生成代码。我在做自动化测试需要一套测试数据准备与清理方案环境是Pytest MySQL Redis被测系统是[业务系统]。 请输出 1. 直接调接口造数与走业务界面造数的取舍建议列出各自的优缺点 2. 每个用例结束后的清理策略数据库软删除、直接物理删除、Redis key过期、中间表清理等结合测试数据是否有跨用例依赖 3. 一个可复用的数据管理工具类支持Pytest fixture或上下文管理 4. 重点解决并发执行时不同用例之间的数据隔离避免互相覆盖的关键做法。使用说明这个模板更偏方案设计而不是代码生成。实战下来ChatGPT给出的“基于事务回滚造数”的思路特别有价值——即测试开始时开启事务结束时回滚数据不落库。但前提是数据库配置要允许且被测系统不能有异步任务把数据写到其他库。真正落地时我让它“输出事务型fixture的工厂函数”再根据项目环境微调连接串基本半天就能接入现有项目。2.9 模板九持续集成集成度改造场景脚本本地能跑到了CI就像个炸药包跑得慢、不稳定、报告难懂。这个模板用来做CI适配改造。我要把这段测试脚本接入CI流水线当前测试框架是Pytest。请帮我 1. 按冒烟、核心回归、全量回归分组用标记marker组织用例执行顺序 2. 给易失败用例增加自动重跑机制给出重试次数与间隔建议 3. 设置合理的全局超时与单用例超时并解释为什么这样设置 4. 输出一份最小可用的GitLab CI配置示例或Jenkins配置包含执行、报告、产物归档 5. 报告格式要能被CI系统直接解析。 脚本 [paste code]使用说明这里最容易踩的坑是“重跑会导致重复数据”。很多团队为了让CI变绿直接开“失败就重跑”结果用例里又带着造数逻辑重跑第二次必失败加数据翻倍。我会在模板里加一条铁律“重跑前需确保用例是幂等的或重跑时先执行清理函数”ChatGPT会据此自动生成含前置清理的包装层比自己拍脑袋加个retry装饰器靠谱得多。2.10 模板十测试脚本审查清单场景写完或改完脚本后想快速知道质量如何、哪些地方必须改。这个模板让ChatGPT扮演严格的Code Reviewer。作为资深测试开发请审查这段测试代码输出结构化审查报告 1. 按“必须修改/建议修改/可忽略”三级列出所有问题 2. 对每个问题说明它会在什么场景下引发什么代价 3. 重点检查同步/异步等待、数据库连接泄漏、全局共享状态、异常被吞、并发安全、硬编码 4. 最后给出一个0-100分的质量评分并指出最值得投入的三个优化点。 代码 [paste code]使用说明这个模板的核心价值在于“结构化”它强制ChatGPT从三级问题、代价分析、评分、优化优先级四个维度输出而不是笼统地说“代码写得不错”。我一般会在合并代码前跑一次审查把“必须修改”里我认可的条目直接生成待办再让ChatGPT按模板一重构形成“审查-重构-再审”的闭环。用下来最大的体会是ChatGPT对“数据库连接泄漏”和“异常被吞”这两类问题的敏感度很高而这恰恰是很多测试人自己写脚本时最容易忽视的。3. 实战对照三个模板从“提示词”到“可运行代码”的完整过程模板是静态的真正拿到项目里还要过一遍“提需求—改代码—验证—再迭代”的循环。这节我用三个真实案例展示从上面10个模板里挑模板经历完整闭环的过程。3.1 案例一接口回归脚本的健壮性改造模板四背景我们有个订单查询接口的回归脚本经常在测试环境偶发网络抖动时报ConnectionError每周回归最多一次挂了七条用例人工重跑一遍要十几分钟。我用模板四给ChatGPT喂了脚本原文它的输出直接生成了一个retry装饰器import functools import random import time import requests def retry_on_connection_error(max_attempts3, base_delay0.5, max_delay8.0): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): attempt 0 while attempt max_attempts: try: return func(*args, **kwargs) except (requests.ConnectionError, requests.Timeout) as exc: attempt 1 if attempt max_attempts: raise delay min(max_delay, base_delay * (2 ** (attempt - 1))) delay random.uniform(0, 0.1) print(f[retry] attempt {attempt}/{max_attempts}, ferror{exc}, next retry in {delay:.2f}s) time.sleep(delay) return wrapper return decorator这段代码基本可以直接用我唯一做的调整是把print改成logging并把重试异常从requests.ConnectionError扩展到了requests.ConnectTimeout。原脚本里查询接口的调用处加上retry_on_connection_error修饰符就完成了改造。经过两周观察网络抖动导致的失败率几乎清零。这里我想强调一个细节ChatGPT生成的退化函数中如果重试后仍然失败raise抛出的是最后一次异常这样测试报告里能保留真实失败原因而不是笼统的超时错误。这一点对排查非常关键。如果它没这么做我一般会补一句“重试耗尽后请重新抛出原始异常”。3.2 案例二UI自动化定位表达式批量优化模板七背景我们维护了一个老旧的Selenium项目脚本里大量使用绝对XPath比如/html/body/div[3]/div[2]/form/button。每次页面微调这串定位就全废。我把全部元素定位整理成一张表喂给ChatGPT让它按照模板七的要求给出优化对照。它输出了类似这样的建议原定位写法风险等级优化建议/html/body/div[3]/div[2]/form/input高给input加data-testid或读取现有name属性改用find_element(By.NAME, username)//*[idmain]/div[2]/div[3]/button[2]中检查button是否有稳定文案若有则用By.XPATH(//button[normalize-space()提交])文案易变则建议前端加data-testid这张表的价值不在于每一个建议都能直接用而在于它把最应该优先处理的“高风险”定位项挑出来了。我按表里“高”风险项逐一找前端同学协商加data-testid两周下来脚本稳定性从78%升到了94%。这组工作如果靠人工逐条审查估计得花两三个迭代才能完成。3.3 案例三给临时代码套上数据驱动骨架模板五背景我们的订单审核测试脚本里有三四个相同的函数块区别只是订单金额不同、审批人不同。每次要加一组新订单就得复制一大段代码改参数极容易漏改。我用模板五让ChatGPT把这段脚本改造成了Pytest参数化风格。它的输出中数据文件长这样[ {order_amount: 0, expected_status: REJECT, remark: 零金额订单直接拒绝}, {order_amount: 0.01, expected_status: PENDING, remark: 最小金额进入待审核}, {order_amount: 10000, expected_status: PENDING, remark: 正常金额}, {order_amount: 999999999, expected_status: MANUAL, remark: 超限额需要人工审批} ]测试函数则变成了pytest.mark.parametrize加载JSON数据。改造后加新用例只需要在JSON里加一行数据测试代码零改动。这个改动看起来不大但对我们这个每周都要在测试环境跑大量数据组合的项目来说维护成本下降非常明显。这里有几个细节值得注意一是数据文件名要用有业务含义的名字比如order_audit_cases.json别叫data.json二是参数化后用例ID会变成参数值的组合要在pytest配置里转成可读的用例ID不然报告里全是test_audit[0-REJECT-PENDING]反而看不太懂。ChatGPT在第一次输出里就没有处理用例ID可读性这块是我在提示词里追加“请将参数化用例的ID设置为业务场景名”后才补上的。4. 用提示词驱动测试脚本时的高频问题与排查思路就算模板用得再熟实战中还是会撞上一堆意想不到的问题。这一节我把这几年来最常碰到的问题和排查思路整理成速查表按类型归了三组。4.1 ChatGPT“理解偏差”类问题问题一它把“优化测试脚本”理解成了“重写整个脚本”。原因通常是提示词里没给约束条件模型默认你有改动范围自由。解决办法很直接——在模板开头写明“保持方法签名不变”“只改某一部分”“不改业务逻辑”这类边界条件。我早期吃过很多亏后来每条提示词都固定加一句“只针对我贴出的代码做修改不要发明新需求”。问题二它不知道自己不知道。比如让它补数据库断言它会想当然地按常见表结构补一个不存在的字段。应对办法是涉及外部系统的内容一定要在提示词里给出“事实版本”比如把SQL建表语句、接口返回样例放进去。如果放不进去就明确要求“遇到不确定的内容用TODO标注并询问不要编造字段名”。问题三使用私有组件库业务逻辑时模型给出的方案是业内通用做法但不是你们系统的做法。