如果你的自动化测试脚本已经跑了两三个版本每次修改都像在拆一个陈年盲盒——改完不知道哪段会崩、哪段会失效——那这篇文章应该能帮你减少一点痛苦。我用 ChatGPT 优化过一批“能跑但没人敢动”的回归脚本最终沉淀下来的并不是什么万能提问话术而是一套针对测试脚本优化场景的 10 个提示词模板。这套模板我大概花了三个迭代周期才固定下来。最开始我也试过直接把脚本丢给 ChatGPT说一句“帮我优化一下”结果它要么把业务断言改得面目全非要么给我生成一堆“看起来很专业但根本不符合项目现状”的抽象代码。后来我把任务拆细、把约束写清楚、把输出格式限定好效果才开始稳定。这篇文章会把每个模板的思路、提示词原文、适用场景和坑都拆开讲适合想真正把 ChatGPT 用进日常软件测试工作的人尤其是自动化测试脚本维护量比较大、迭代节奏又快的团队。1. 从“让它改脚本”到“让它按模板干活”我经历了什么先说一个我自己的真实经历。去年年中我接手了一套订单流程的自动化测试脚本全跑一遍大约 40 分钟里面有大量重复的等待逻辑和硬编码数据而且好几个用例之间还有共享状态。第一次想用 ChatGPT 帮我清理我给的指令是“这个脚本太乱了能不能重构一下”。它给出来的版本确实清爽了很多但一跑直接挂了因为我把业务端的登录态依赖和公共数据清理部分拆错了顺序导致后置用例全部失败。那次之后我意识到一件事大模型不是不能干测试脚本优化的活而是我给它定义的“工作边界”太模糊了。优化脚本背后其实包含了好几类完全不同的任务比如理解旧逻辑、拆分函数、改造数据、加固断言、调整等待策略、迁移测试框架、补回归用例。这些任务对上下文的需求、对输出的要求、对出错风险的容忍度都完全不同。把它们混在一个提示词里ChatGPT 只能自己猜重点猜对了算运气好猜错了就是脚本崩溃。所以后来我再也不用一句“帮我优化”了而是先会问自己一个问题这个脚本现在最痛的点到底是什么是读不懂是跑得慢是经常 flaky是数据写死导致没法复用还是公司要求从 unittest 迁到 pytest把痛点拆出来之后再从十个模板里选具体的那一个。宁可一次只解决一个问题也不要让模型一次性全改。还有一个让我改变使用方式的原因测试脚本和普通源代码不太一样它有很强的“业务耦合性”。普通代码重构只要保证输入输出不变基本不会出大问题。但测试脚本一旦拆错了公共步骤或者把某个 setUp 的调用顺序改了后面几十个用例的执行结果都会被污染。这种污染不是因为代码逻辑错了而是因为测试脚本天生依赖“执行顺序”和“外部状态”。ChatGPT 自己不会知道这些依赖它只会按你给的文本推断。所以在提示词里我会强制要求它在输出之前把“不能动的部分”列出来并且每次只修改我指定的范围。经过几轮调整我把整套工作方式沉淀成了一套模板库。有人问我模板是不是越多越好我的体验恰恰相反真正高频用到的就是十来个再往上就开始重复了。模板多了以后反而会增加决策成本。下面这十个模板是我按照“读脚本、改结构、换数据、补断言、稳运行”这几个层次收敛出来的每一个我都标注了最适用的场景和必须注意的副作用。2. 拆模板之前先明确三个约束条件在我共享具体模板之前想先把底层设计逻辑说清楚。否则你照着模板复制走遇到问题还是不会调整。第一个约束叫“先解释后修改”。ChatGPT 和传统编译器不一样它没有真正的“代码理解”机制它只是在做概率预测。但如果你让它先用自己的话说一遍这段脚本是干什么的风险点在哪儿它后面给出修改建议时就会明显更谨慎也更不容易把关键断言改坏。用不用这个前置步骤在实测里差别很大。不加这一步直接让它改代码它经常会把某个 assertEqual 悄悄换成 assertIn因为它觉得这样“更合理”。但测试脚本的断言是业务规则的具象化绝不能让它自由发挥。第二个约束叫“把不可变更的规则写进提示词”。我在第一条里提到必须在提示词中明确告诉模型哪些东西不允许动。比如接口地址、数据库连接字符串、错误码映射表、页面元素的定位方式甚至某些用例的注释风格都可能是“不可谈条件”。如果你不写ChatGPT 很可能顺手就把你的 CSS selector“优化”成了 XPath表面上提升了可读性结果页面元素一变全挂。更麻烦的是它可能把功能性数据改成随机生成的值导致测试断言失去可重复性。好的提示词模板本质上是一种“可执行的合同”把允许修改的范围和禁止修改的范围都写死。第三个约束叫“输出格式必须可控”。测试工程师用 ChatGPT 不是为了聊天而是要拿到能直接放进 IDE、能评审、能归档的内容。所以在我的模板里几乎每个都要求模型输出“改动点清单 代码 diff 测试建议”这样的结构。输出格式可控才能真正提高效率而不是让我去大段的模型生成内容里翻找我想看的重点。有些模板我还会明确要求它返回 JSON 或者表格方便我复制到 Excel 或测试管理平台上做后续跟踪。这三个约束也是我在下面十个模板里反复出现的底层设计。你先记住这三条看具体模板的时候会更有章法一点。底层约束解决的问题在模板中的体现先解释后修改防止模型不理解业务就乱改多数模板要求第一步输出流程说明不可变更规则防止模型改动业务断言、定位符、数据模板中明确写出禁止修改的范围输出格式可控防止结果不可归档、不可评审要求输出 diff、清单、JSON另外再提醒一句如果你的脚本本身连编译或导入都过不了那别用 ChatGPT。先把语法错误修好再让它做优化。模型对“坏味道代码”的容忍度很高它会默认你贴过去的代码是可运行的并基于这个假设生成修改结果。如果你自己都没跑过一次通过的基线那它给的优化方案只会让情况更复杂。这也是我每次用模板前的硬性检查项。3. 模板1-5先把脚本读明白再谈怎么优化这五个模板主要针对“脚本理解、结构重构、参数化、测试数据、断言”这几个基础层。它们适合你刚接手一个旧脚本或者脚本里已经开始出现明显重复代码和脆弱断言的时候。3.1 模板1让 ChatGPT 当一次“代码翻译官”这个模板专门解决“读不懂一段老脚本”的问题。很多项目里都有那种没有注释、函数命名随意、全靠全局变量传参的旧测试脚本。直接拿给新人看一天可能都看不明白。这时候千万不要让它直接重写先让它当翻译官把原脚本翻译成一段有逻辑结构的中文说明。你现在是一位资深的软件测试开发工程师。请阅读下面这段测试脚本不要修改代码只需要分三段解释 1. 从整体说明这段脚本的执行流程和测试目标 2. 从每个关键函数或方法的角度说明输入参数、依赖条件、副作用 3. 列出你在这个脚本里发现的潜在风险点包括资源未释放、隐式等待、断言过弱、数据硬编码、依赖执行顺序等。 约束 - 不要改写任何代码 - 如果脚本中有明显的 bug只指出来不要自动修复 - 使用中文回答并按照“流程说明”、“函数说明”、“风险清单”三个标题组织内容。这个模板在实际用的时候非常稳。因为它把任务限定为“读代码并输出说明”模型不会产生强烈的“改代码”倾向反而能识别出很多人类容易忽略的隐患。我记得有一次用这个模板读一个数据清洗脚本ChatGPT 很快就指出了某个函数里正则表达式没有做空值判断导致后来生成的测试用例全都依赖了一个不必要的临时文件。这种问题在实际脚本里藏得很深人工 review 的时候往往要花不少时间。适用场景一句话总结刚接手旧脚本、准备重构但心里没底、需要快速向团队同步脚本现状时优先用这个模板。3.2 模板2把超大函数拆成可测试的小单元测试脚本里的超大函数基本都是由“不断追加测试场景”导致的。一开始你只测一个登录成功场景后面所有分支都要往同一个函数里塞最后它就会变成一个几百行甚至上千行的巨型方法。这种函数可读性差、维护困难而且改动一处就影响大片。这时候我用这个模板做“行为不变的拆分”。下面这段测试脚本中的某个函数承担了过多职责。请在保持测试步骤顺序和断言结果不变的前提下把这个函数拆成多个职责单一的内部函数。 约束清单 - 外部接口和函数签名不允许变 - 断言值与断言顺序不允许变 - 公共步骤如果被多个场景复用请拆成一个独立的私有方法并加上参数和返回值的说明 - 不要引入 pytest 以外的第三方库 - 先输出拆分后的代码再输出一张“原函数行号 → 新函数归属”的映射表。 待拆分脚本如下我特别在乎“先输出拆分后的代码再输出映射表”这个要求。因为传统上我们做重构迁移的难点在于不知道哪些行去了哪里。有了映射表code review 的时候可以直接对照很快能确认业务逻辑没有丢失。还有一个额外的效果这个模板要求模型“不要引入 pytest 以外的第三方库”这个约束能防止 ChatGPT 在重构时顺手给你安装一堆明明没必要的依赖比如它很喜欢用deepdiff、pytest-parallel这类包装库行为看起来很合理但放在企业内部网络环境下很容易因为依赖下载不通而翻车。3.3 模板3用数据驱动改造重复的“脚本复制粘贴”很多测试脚本里最严重的问题不是代码丑而是同一个用例被复制粘贴了十几遍只是参数不同。例如需要测试订单在不同金额条件下的折扣逻辑原始代码可能是这么写的def test_discount_100(self): result apply_discount(100) assert result 90 def test_discount_200(self): result apply_discount(200) assert result 170这种写法功能没问题但一旦折扣规则变了你得同时改十几处。这时候该上参数化但手工改又很机械我把这个任务交给模板3。请将下面这段测试脚本中重复的测试函数改造成参数化测试。 要求 - 把所有表示同一场景的重复函数合并成一个测试函数名 - 测试参数从数据列表或外部 fixture 中读取 - 保留原来的关键业务字段名例如订单金额、折扣比例、预期结果 - 不要改变任何边界值条件 - 输出改造后的完整代码和参数表。 原始脚本如下结合 ChatGPT 的经验它会自动把相同模式的用例归纳成pytest.mark.parametrize里的参数数组。我看到有些同事会直接把脚本里出现的全部“魔法数字”都盲目参数化那也不对。参数化是为了减少重复和覆盖边界不是为了参数化而参数化。建议你给它限一个范围比如只处理“函数名相似、断言模式相同、数据不同”的用例这样改动范围可控review 的时候也轻松些。3.4 模板4按边界值设计测试数据少靠拍脑袋测试脚本里的数据质量问题往往比代码质量问题更隐蔽。有些脚本表面上在跑全量回归但实际上测试数据全是等价类内的安全值边界值一个都没覆盖到。真让产品上线后出了边界问题测试脚本根本拦不住。这个模板是我平时用得最多的一个因为我接手的脚本类型很多每次去补测试数据都要先查接口定义再推算边界值和异常值时间成本很高。让 ChatGPT 自己生成一版合理的数据全集给我做参考已经足够节省大量时间。我正在写关于“用户积分兑换”功能的自动化测试用例。下面是这个接口/功能相关字段和校验规则 - 用户积分余额非负整数范围 0-10000 - 兑换商品所需积分正整数50、100、200 - 用户是否会员布尔值 - 单日兑换次数限制最多 3 次 请按照等价类划分和边界值分析的方法生成一组适合做自动化测试的测试数据。 要求 - 每个用例要覆盖正常、边界、异常三种场景 - 输出格式为 Python 字典列表每个字典包含字段名、字段值、场景描述、预期结果 - 至少包含 12 个用例 - 不要生成与上述规则无关的额外字段。这样做出来的数据比手工设计覆盖得全。但这里有个坑模型生成的业务规则可能是基于它自己的常识推断出来的如果你内部的实际校验规则和常识不一样就得在提示词里把规则写得更细。比如有的系统里积分是允许为负数的有的系统不允许有的会员是分等级的不是布尔值。提示词里必须真实反映你项目里的规则别让 ChatGPT 用“通用电商逻辑”帮你填空。把规则条数写清楚效果会比让模型自由发挥稳定得多。3.5 模板5让模型找出你的断言薄弱点并补强测试脚本最怕的不是没跑而是测了等于没测。常见场景是后置断言过弱比如页面只是弹了一个“操作成功”的 toast代码就断言成功了但实际的数据库记录根本没变化或者多账户之间的信息没有校验。我让 ChatGPT 补断言时不会让它“自由地增加断言”那样它可能会加一堆依赖执行速度的校验比如去判断某个动画元素是否在某毫秒内出现结果反而把脚本搞得不稳定。我的模板里会强制它只补和业务规则相关的断言。下面是某个测试脚本中对“订单提交成功”场景的断言。请检查当前断言是否足以证明测试目标达成并帮我补充缺失的关键断言。 补充原则 - 只增加与业务结果相关的断言不增加与页面渲染速度、CSS样式、动画效果相关的断言 - 如果某个结果只能通过查询数据库或调用接口验证请直接给出对应的验证代码 - 不要删除原始断言只允许追加 - 最后输出“原始脚本风险点列表”和“补充后的完整用例代码”。 当前脚本断言如下我一般会把这个脚本的输出结果当成“断言 review 建议”而不是直接替代我自己的 review。因为 ChatGPT 并不知道你的系统里哪个 API 才是真正的后置状态入口它只知道“应该要查一下”。我拿到它的建议后会自己补上具体的 API 或 SQL 查询代码但不会再为“该不该验这个”而发愁。这就是补差式提效。4. 模板6-10断言、数据、框架迁移与整体可维护性下面这五个模板更偏向中后期优化阶段适合脚本已经能稳定运行、但你希望进一步提升可维护性和可靠性的场景。它们处理的问题更聚焦比如框架迁移、稳定性加固、回归用例生成和代码审查。4.1 模板6把 unittest 脚本迁移到 pytest别手工改我见过不少团队还停留在 unittest 时代的旧脚本上不是不想迁到 pytest而是迁移工作量太大。几百个测试函数要改构造函数、改 setUp/tearDown、改断言方式看起来不是高难度活但特别费时间而且很容易在迁完以后发现用例收集不全。这个模板我设计的思路是“一次性迁移不保留旧骨架”但同时在提示词里显式要求模型保留测试逻辑和断言语义。请将下面的 unittest 测试脚本迁移为 pytest 风格。 要求 - setUp 和 tearDown 逻辑要转换为 pytest fixture - 断言方法 assertEqual、assertTrue 等保留语义不改变原判断条件 - 测试类中如果只有方法组织作用不依赖类内共享状态可以去掉类结构 - 所有的函数名保留原名不要为了美观改名 - 迁移完成后给我一份简短的“迁移改动对照表”说明每个旧函数对应新代码的哪个位置。 原始脚本这个模板用起来要注意文件级别的 fixture 和类级 setUp 的执行次数差异。unittest 里如果 setUp 是在类级别被调用迁移后如果不小心把 fixture 写成了 module 级别会导致用例之间的隔离性被破坏。实际跑的时候用例顺序一变某些共享数据就会被污染。所以我建议迁完以后至少要跑一遍乱序执行比如用pytest-randomly强制改变用例顺序验证隔离性是否真正没问题。4.2 模板7给动态页面脚本加显式等待和更稳的定位自动化测试 flaky 的原因Top1 就是等待方式不科学。很多人还在用固定sleep(3)本地能过到 CI 环境就挂。用隐式等待虽然好了点但它没法解决“元素已经出现在 DOM 里但不可点击”这种问题。ChatGPT 擅长改进这部分代码所以我的模板7是个纯粹的“代码加固模板”。下面是测试脚本中一段针对 Web 页面元素的等待逻辑。请将它改造成基于 Selenium 显式等待的模式。 要求 - 将固定的 time.sleep 全部移除 - 根据场景使用 visibility_of_element_located、element_to_be_clickable、presence_of_element_located 等不同条件 - 等待超时时间设置为 10 秒轮询间隔 500 毫秒 - 不要吞掉超时异常超时后应输出包含页面 URL 和当前页面标题的错误信息 - 如果你发现元素定位表达式不够稳定可以建议更优的定位策略但不能直接修改页面对象的值。 原始代码这个模板里有一个默认很关键的举动不允许它吞异常。为什么因为在测试脚本里超时是一种重要的失败信号它说明页面在某些条件下没有按预期渲染。如果模型把超时异常 catch 住然后返回 None测试就会变成假通过。很多“全绿但线上还有 bug”的测试脚本就是因为把异常吞得太干净了。加显式等待的同时保留失败信息的可观测性才是真正的稳定性修复。4.3 模板8从一个 bug 描述反向补齐回归测试用例测试团队比较忙的时候修 bug 很容易只修当前那一条路相关的回归测试却没有补齐。过了几天同一个模块里相似的 bug 又被用户发现才发现上次根本没把关联场景覆盖到。ChatGPT 可以帮你从一份 bug 描述出发生成一份相对完整的回归测试设计稿。这是一个线上 bug 的描述 “用户在积分兑换过程中如果连续点击两次兑换按钮系统会生成两笔兑换记录。期望结果同一用户、同一商品、同一时刻的重复点击只能生成一笔订单。” 请基于这个 bug 生成回归测试用例和对应测试脚本。 要求 - 测试用例要覆盖正常提交、重复点击、接口重放、按钮置灰等场景 - 脚本中需要体现前置数据的准备例如用户需要先登录并拥有足够积分 - 脚本要包含必要的断言至少要验证数据库中的订单数量不超过 1 - 输出分两部分用例表格和 pytest 脚本代码。这种模板的产出并不一定可以 100% 直接跑通因为有些前置数据需要你自己 mock但它能帮你把一个 bug 联想到的场景全部列全。比如上面这个 bugChatGPT 会顺带想到“如果同一用户在不同浏览器里同时点击呢”“如果后端接口被直接重放呢”这些边角场景。这些想法就算最终实现起来很复杂至少能帮你在需求评审或排期阶段把风险点暴露出来。4.4 模板9把脚本中的硬编码改成外部配置和常量测试脚本写久了代码里会飘着一堆硬编码。URL、用户名、数据库连接串、页面元素路径、超时时间全被塞在代码字段里。到了多环境跑测试的时候就得临时改代码改完还可能忘记改回来。模板9的思路很简单让 ChatGPT 把硬编码抽到独立配置区而不再散落在各个用例方法里。下面这段自动化测试脚本中包含许多硬编码值。请把它改造成可配置的风格。 要求 - 环境相关变量例如 URL、数据库地址、用户名密码统一提取到一个 config 对象中 - 页面元素定位器如果有重复出现提取为页面对象级常量 - 测试业务数据不允许被提取为全局配置必须保留在用例内部保证每个用例数据独立 - 输出改造后的完整代码并标注出哪些变量只适合放在生产配置里、哪些适合放在测试代码目录下。 原始脚本这个模板有一个容易被忽略的好处它会把“环境相关变量”和“业务变量”分成两类。以前我们做配置化改造时容易把业务输入值也一股脑地塞进全局配置里结果多个用例之间互相影响改了一个全局配置值所有用例的行为都被带偏。ChatGPT 如果没被提示也会犯这个错误。我把“业务测试数据不提取为全局配置”写进提示词就是希望配置化改造之后每个用例的可读性和隔离性都还在而不是只管代码干净。4.5 模板10让 ChatGPT 以代码审查者身份挑问题这个模板适合放在每个优化迭代的收尾阶段。你的脚本已经经过了前九个模板的优化但你还担心有没有遗漏那就让 ChatGPT 扮演一个严格但专业的老测试开发来挑刺。请以一位资深测试开发工程师的身份对下面这段自动化测试脚本做一次代码审查。 审查方向包括 - 测试用例之间是否存在状态污染或执行顺序依赖 - 是否有未释放的资源例如浏览器实例、临时文件、mock server - 断言是否针对业务结果而不是中间过程 - 是否有不必要的复杂逻辑例如过度封装、无意义抽象 - 是否有潜在的维护陷阱例如定位方式不稳定、接口变更影响面大。 输出格式 - 按严重程度从高到低列出问题 - 每个问题标注代码行号和修改建议 - 最后给出整体评价并列出适合做自动化测试的用例场景。 待审查代码这个模板的价值不在于替代人工审查而在于它能在你提交代码之前先帮你扫一遍“常规坏味道”。实测下来它对“资源未释放”和“隐式依赖全局变量”这类问题的命中率相当高。有个同事用这个模板检查过一段后端自动化脚本发现某个用例虽然用with正确打开了 mock server但异常分支里 server 根本没关。这个 bug 人工看很难发现但模型因为是纯文本分析不会受“看似正常的代码缩进”干扰反而更容易注意到逻辑分支的缺口。如果你们团队已经有代码规范文档也可以把文档里的核心章节贴到当前提示词后面。这会让 ChatGPT 的审查标准更贴近团队内部约定而不是只停留在通用层面。5. 在真实项目里反复测试后这几个场景建议慎重使用模板不是万能钥匙。我用这套模板跑了差不多 200 多次测试脚本优化任务后也找到了一些 ChatGPT 目前并不擅长的边界。这里把我觉得最容易翻车的几种情况列出来省得你重复踩坑。第一个慎重使用的场景是“跨文件重构”。模板在单文件或者单函数级的表现非常好但一旦你要重构的是一个跨越多个测试文件、多个 fixture 文件、甚至有共享 conftest 的完整测试工程时ChatGPT 的输出经常会出现自相矛盾。它会改完 A 文件后忽略了 B 文件里还在引用旧函数名。我在用模板2和模板6时都遇到过类似问题解决办法是先把文件调用关系整理成一张依赖图并且把相关的核心接口签名贴进提示词而不是把整个目录一股脑抛给它。如果你期望它自己意识到“这里改了之后别的文件里还有三个调用点”那大概率会失望。第二个慎重使用的场景是“性能调优”。如果脚本跑得慢是因为存在大量不合理的 I/O 请求、浏览器无谓跳转、或者测试数据量过大ChatGPT 能帮你分析出表面原因但它并不了解你的被测系统内部到底哪一步响应慢。它很可能只会建议你“减少日志输出、用 headless 模式、加大并行度”这些通用手段。对运行时性能瓶颈这类问题我还是倾向于先做 profiling定位到具体阻塞点再让模型针对那一小段进行优化。不要一上来就让它做全局提速。第三个要谨慎的场景是“自动化生成整套 UI 自动化脚本”。ChatGPT 很擅长生成精美的页面定位代码但它没有真正打开过你的页面不知道哪个按钮在哪个层级下。拿它生成的 XPath 到了真实环境里经常失效。我的建议是让它只生成“步骤骨架”或“辅助函数”页面元素定位这类工作还是要基于你实际调试过的数据。如果你希望它参与 UI 脚本编写那就把页面的 HTML 关键片段、元素属性、期望交互流程先喂给它这样它写出来的脚本才有一点可跑的成功率。最后说一个“不是模板问题而是流程问题”的点。整个优化流程里最不该省的那一步是改了脚本之后立刻跑一次全量回归。别因为 ChatGPT 给了你看起来很稳的代码就省略执行和 review。它输出的是“基于文本统计的最优解”而不是“基于你系统真实行为的验证结果”。我团队里现在有两条硬规矩。第一条所有由 ChatGPT 生成或大幅修改的测试代码提交前必须由项目里另一个同事做代码评审不允许把模型输出直接合入主干。第二条任何一个模板生成的代码第一次合入时必须跑最小回归集确认测试环境本身没被改动破坏。这两条规矩执行了大半年几乎没有因为 AI 辅助而引入过严重的线上回归事故。 ChatGPT测试脚本优化实战：10个提示词模板
如果你的自动化测试脚本已经跑了两三个版本每次修改都像在拆一个陈年盲盒——改完不知道哪段会崩、哪段会失效——那这篇文章应该能帮你减少一点痛苦。我用 ChatGPT 优化过一批“能跑但没人敢动”的回归脚本最终沉淀下来的并不是什么万能提问话术而是一套针对测试脚本优化场景的 10 个提示词模板。这套模板我大概花了三个迭代周期才固定下来。最开始我也试过直接把脚本丢给 ChatGPT说一句“帮我优化一下”结果它要么把业务断言改得面目全非要么给我生成一堆“看起来很专业但根本不符合项目现状”的抽象代码。后来我把任务拆细、把约束写清楚、把输出格式限定好效果才开始稳定。这篇文章会把每个模板的思路、提示词原文、适用场景和坑都拆开讲适合想真正把 ChatGPT 用进日常软件测试工作的人尤其是自动化测试脚本维护量比较大、迭代节奏又快的团队。1. 从“让它改脚本”到“让它按模板干活”我经历了什么先说一个我自己的真实经历。去年年中我接手了一套订单流程的自动化测试脚本全跑一遍大约 40 分钟里面有大量重复的等待逻辑和硬编码数据而且好几个用例之间还有共享状态。第一次想用 ChatGPT 帮我清理我给的指令是“这个脚本太乱了能不能重构一下”。它给出来的版本确实清爽了很多但一跑直接挂了因为我把业务端的登录态依赖和公共数据清理部分拆错了顺序导致后置用例全部失败。那次之后我意识到一件事大模型不是不能干测试脚本优化的活而是我给它定义的“工作边界”太模糊了。优化脚本背后其实包含了好几类完全不同的任务比如理解旧逻辑、拆分函数、改造数据、加固断言、调整等待策略、迁移测试框架、补回归用例。这些任务对上下文的需求、对输出的要求、对出错风险的容忍度都完全不同。把它们混在一个提示词里ChatGPT 只能自己猜重点猜对了算运气好猜错了就是脚本崩溃。所以后来我再也不用一句“帮我优化”了而是先会问自己一个问题这个脚本现在最痛的点到底是什么是读不懂是跑得慢是经常 flaky是数据写死导致没法复用还是公司要求从 unittest 迁到 pytest把痛点拆出来之后再从十个模板里选具体的那一个。宁可一次只解决一个问题也不要让模型一次性全改。还有一个让我改变使用方式的原因测试脚本和普通源代码不太一样它有很强的“业务耦合性”。普通代码重构只要保证输入输出不变基本不会出大问题。但测试脚本一旦拆错了公共步骤或者把某个 setUp 的调用顺序改了后面几十个用例的执行结果都会被污染。这种污染不是因为代码逻辑错了而是因为测试脚本天生依赖“执行顺序”和“外部状态”。ChatGPT 自己不会知道这些依赖它只会按你给的文本推断。所以在提示词里我会强制要求它在输出之前把“不能动的部分”列出来并且每次只修改我指定的范围。经过几轮调整我把整套工作方式沉淀成了一套模板库。有人问我模板是不是越多越好我的体验恰恰相反真正高频用到的就是十来个再往上就开始重复了。模板多了以后反而会增加决策成本。下面这十个模板是我按照“读脚本、改结构、换数据、补断言、稳运行”这几个层次收敛出来的每一个我都标注了最适用的场景和必须注意的副作用。2. 拆模板之前先明确三个约束条件在我共享具体模板之前想先把底层设计逻辑说清楚。否则你照着模板复制走遇到问题还是不会调整。第一个约束叫“先解释后修改”。ChatGPT 和传统编译器不一样它没有真正的“代码理解”机制它只是在做概率预测。但如果你让它先用自己的话说一遍这段脚本是干什么的风险点在哪儿它后面给出修改建议时就会明显更谨慎也更不容易把关键断言改坏。用不用这个前置步骤在实测里差别很大。不加这一步直接让它改代码它经常会把某个 assertEqual 悄悄换成 assertIn因为它觉得这样“更合理”。但测试脚本的断言是业务规则的具象化绝不能让它自由发挥。第二个约束叫“把不可变更的规则写进提示词”。我在第一条里提到必须在提示词中明确告诉模型哪些东西不允许动。比如接口地址、数据库连接字符串、错误码映射表、页面元素的定位方式甚至某些用例的注释风格都可能是“不可谈条件”。如果你不写ChatGPT 很可能顺手就把你的 CSS selector“优化”成了 XPath表面上提升了可读性结果页面元素一变全挂。更麻烦的是它可能把功能性数据改成随机生成的值导致测试断言失去可重复性。好的提示词模板本质上是一种“可执行的合同”把允许修改的范围和禁止修改的范围都写死。第三个约束叫“输出格式必须可控”。测试工程师用 ChatGPT 不是为了聊天而是要拿到能直接放进 IDE、能评审、能归档的内容。所以在我的模板里几乎每个都要求模型输出“改动点清单 代码 diff 测试建议”这样的结构。输出格式可控才能真正提高效率而不是让我去大段的模型生成内容里翻找我想看的重点。有些模板我还会明确要求它返回 JSON 或者表格方便我复制到 Excel 或测试管理平台上做后续跟踪。这三个约束也是我在下面十个模板里反复出现的底层设计。你先记住这三条看具体模板的时候会更有章法一点。底层约束解决的问题在模板中的体现先解释后修改防止模型不理解业务就乱改多数模板要求第一步输出流程说明不可变更规则防止模型改动业务断言、定位符、数据模板中明确写出禁止修改的范围输出格式可控防止结果不可归档、不可评审要求输出 diff、清单、JSON另外再提醒一句如果你的脚本本身连编译或导入都过不了那别用 ChatGPT。先把语法错误修好再让它做优化。模型对“坏味道代码”的容忍度很高它会默认你贴过去的代码是可运行的并基于这个假设生成修改结果。如果你自己都没跑过一次通过的基线那它给的优化方案只会让情况更复杂。这也是我每次用模板前的硬性检查项。3. 模板1-5先把脚本读明白再谈怎么优化这五个模板主要针对“脚本理解、结构重构、参数化、测试数据、断言”这几个基础层。它们适合你刚接手一个旧脚本或者脚本里已经开始出现明显重复代码和脆弱断言的时候。3.1 模板1让 ChatGPT 当一次“代码翻译官”这个模板专门解决“读不懂一段老脚本”的问题。很多项目里都有那种没有注释、函数命名随意、全靠全局变量传参的旧测试脚本。直接拿给新人看一天可能都看不明白。这时候千万不要让它直接重写先让它当翻译官把原脚本翻译成一段有逻辑结构的中文说明。你现在是一位资深的软件测试开发工程师。请阅读下面这段测试脚本不要修改代码只需要分三段解释 1. 从整体说明这段脚本的执行流程和测试目标 2. 从每个关键函数或方法的角度说明输入参数、依赖条件、副作用 3. 列出你在这个脚本里发现的潜在风险点包括资源未释放、隐式等待、断言过弱、数据硬编码、依赖执行顺序等。 约束 - 不要改写任何代码 - 如果脚本中有明显的 bug只指出来不要自动修复 - 使用中文回答并按照“流程说明”、“函数说明”、“风险清单”三个标题组织内容。这个模板在实际用的时候非常稳。因为它把任务限定为“读代码并输出说明”模型不会产生强烈的“改代码”倾向反而能识别出很多人类容易忽略的隐患。我记得有一次用这个模板读一个数据清洗脚本ChatGPT 很快就指出了某个函数里正则表达式没有做空值判断导致后来生成的测试用例全都依赖了一个不必要的临时文件。这种问题在实际脚本里藏得很深人工 review 的时候往往要花不少时间。适用场景一句话总结刚接手旧脚本、准备重构但心里没底、需要快速向团队同步脚本现状时优先用这个模板。3.2 模板2把超大函数拆成可测试的小单元测试脚本里的超大函数基本都是由“不断追加测试场景”导致的。一开始你只测一个登录成功场景后面所有分支都要往同一个函数里塞最后它就会变成一个几百行甚至上千行的巨型方法。这种函数可读性差、维护困难而且改动一处就影响大片。这时候我用这个模板做“行为不变的拆分”。下面这段测试脚本中的某个函数承担了过多职责。请在保持测试步骤顺序和断言结果不变的前提下把这个函数拆成多个职责单一的内部函数。 约束清单 - 外部接口和函数签名不允许变 - 断言值与断言顺序不允许变 - 公共步骤如果被多个场景复用请拆成一个独立的私有方法并加上参数和返回值的说明 - 不要引入 pytest 以外的第三方库 - 先输出拆分后的代码再输出一张“原函数行号 → 新函数归属”的映射表。 待拆分脚本如下我特别在乎“先输出拆分后的代码再输出映射表”这个要求。因为传统上我们做重构迁移的难点在于不知道哪些行去了哪里。有了映射表code review 的时候可以直接对照很快能确认业务逻辑没有丢失。还有一个额外的效果这个模板要求模型“不要引入 pytest 以外的第三方库”这个约束能防止 ChatGPT 在重构时顺手给你安装一堆明明没必要的依赖比如它很喜欢用deepdiff、pytest-parallel这类包装库行为看起来很合理但放在企业内部网络环境下很容易因为依赖下载不通而翻车。3.3 模板3用数据驱动改造重复的“脚本复制粘贴”很多测试脚本里最严重的问题不是代码丑而是同一个用例被复制粘贴了十几遍只是参数不同。例如需要测试订单在不同金额条件下的折扣逻辑原始代码可能是这么写的def test_discount_100(self): result apply_discount(100) assert result 90 def test_discount_200(self): result apply_discount(200) assert result 170这种写法功能没问题但一旦折扣规则变了你得同时改十几处。这时候该上参数化但手工改又很机械我把这个任务交给模板3。请将下面这段测试脚本中重复的测试函数改造成参数化测试。 要求 - 把所有表示同一场景的重复函数合并成一个测试函数名 - 测试参数从数据列表或外部 fixture 中读取 - 保留原来的关键业务字段名例如订单金额、折扣比例、预期结果 - 不要改变任何边界值条件 - 输出改造后的完整代码和参数表。 原始脚本如下结合 ChatGPT 的经验它会自动把相同模式的用例归纳成pytest.mark.parametrize里的参数数组。我看到有些同事会直接把脚本里出现的全部“魔法数字”都盲目参数化那也不对。参数化是为了减少重复和覆盖边界不是为了参数化而参数化。建议你给它限一个范围比如只处理“函数名相似、断言模式相同、数据不同”的用例这样改动范围可控review 的时候也轻松些。3.4 模板4按边界值设计测试数据少靠拍脑袋测试脚本里的数据质量问题往往比代码质量问题更隐蔽。有些脚本表面上在跑全量回归但实际上测试数据全是等价类内的安全值边界值一个都没覆盖到。真让产品上线后出了边界问题测试脚本根本拦不住。这个模板是我平时用得最多的一个因为我接手的脚本类型很多每次去补测试数据都要先查接口定义再推算边界值和异常值时间成本很高。让 ChatGPT 自己生成一版合理的数据全集给我做参考已经足够节省大量时间。我正在写关于“用户积分兑换”功能的自动化测试用例。下面是这个接口/功能相关字段和校验规则 - 用户积分余额非负整数范围 0-10000 - 兑换商品所需积分正整数50、100、200 - 用户是否会员布尔值 - 单日兑换次数限制最多 3 次 请按照等价类划分和边界值分析的方法生成一组适合做自动化测试的测试数据。 要求 - 每个用例要覆盖正常、边界、异常三种场景 - 输出格式为 Python 字典列表每个字典包含字段名、字段值、场景描述、预期结果 - 至少包含 12 个用例 - 不要生成与上述规则无关的额外字段。这样做出来的数据比手工设计覆盖得全。但这里有个坑模型生成的业务规则可能是基于它自己的常识推断出来的如果你内部的实际校验规则和常识不一样就得在提示词里把规则写得更细。比如有的系统里积分是允许为负数的有的系统不允许有的会员是分等级的不是布尔值。提示词里必须真实反映你项目里的规则别让 ChatGPT 用“通用电商逻辑”帮你填空。把规则条数写清楚效果会比让模型自由发挥稳定得多。3.5 模板5让模型找出你的断言薄弱点并补强测试脚本最怕的不是没跑而是测了等于没测。常见场景是后置断言过弱比如页面只是弹了一个“操作成功”的 toast代码就断言成功了但实际的数据库记录根本没变化或者多账户之间的信息没有校验。我让 ChatGPT 补断言时不会让它“自由地增加断言”那样它可能会加一堆依赖执行速度的校验比如去判断某个动画元素是否在某毫秒内出现结果反而把脚本搞得不稳定。我的模板里会强制它只补和业务规则相关的断言。下面是某个测试脚本中对“订单提交成功”场景的断言。请检查当前断言是否足以证明测试目标达成并帮我补充缺失的关键断言。 补充原则 - 只增加与业务结果相关的断言不增加与页面渲染速度、CSS样式、动画效果相关的断言 - 如果某个结果只能通过查询数据库或调用接口验证请直接给出对应的验证代码 - 不要删除原始断言只允许追加 - 最后输出“原始脚本风险点列表”和“补充后的完整用例代码”。 当前脚本断言如下我一般会把这个脚本的输出结果当成“断言 review 建议”而不是直接替代我自己的 review。因为 ChatGPT 并不知道你的系统里哪个 API 才是真正的后置状态入口它只知道“应该要查一下”。我拿到它的建议后会自己补上具体的 API 或 SQL 查询代码但不会再为“该不该验这个”而发愁。这就是补差式提效。4. 模板6-10断言、数据、框架迁移与整体可维护性下面这五个模板更偏向中后期优化阶段适合脚本已经能稳定运行、但你希望进一步提升可维护性和可靠性的场景。它们处理的问题更聚焦比如框架迁移、稳定性加固、回归用例生成和代码审查。4.1 模板6把 unittest 脚本迁移到 pytest别手工改我见过不少团队还停留在 unittest 时代的旧脚本上不是不想迁到 pytest而是迁移工作量太大。几百个测试函数要改构造函数、改 setUp/tearDown、改断言方式看起来不是高难度活但特别费时间而且很容易在迁完以后发现用例收集不全。这个模板我设计的思路是“一次性迁移不保留旧骨架”但同时在提示词里显式要求模型保留测试逻辑和断言语义。请将下面的 unittest 测试脚本迁移为 pytest 风格。 要求 - setUp 和 tearDown 逻辑要转换为 pytest fixture - 断言方法 assertEqual、assertTrue 等保留语义不改变原判断条件 - 测试类中如果只有方法组织作用不依赖类内共享状态可以去掉类结构 - 所有的函数名保留原名不要为了美观改名 - 迁移完成后给我一份简短的“迁移改动对照表”说明每个旧函数对应新代码的哪个位置。 原始脚本这个模板用起来要注意文件级别的 fixture 和类级 setUp 的执行次数差异。unittest 里如果 setUp 是在类级别被调用迁移后如果不小心把 fixture 写成了 module 级别会导致用例之间的隔离性被破坏。实际跑的时候用例顺序一变某些共享数据就会被污染。所以我建议迁完以后至少要跑一遍乱序执行比如用pytest-randomly强制改变用例顺序验证隔离性是否真正没问题。4.2 模板7给动态页面脚本加显式等待和更稳的定位自动化测试 flaky 的原因Top1 就是等待方式不科学。很多人还在用固定sleep(3)本地能过到 CI 环境就挂。用隐式等待虽然好了点但它没法解决“元素已经出现在 DOM 里但不可点击”这种问题。ChatGPT 擅长改进这部分代码所以我的模板7是个纯粹的“代码加固模板”。下面是测试脚本中一段针对 Web 页面元素的等待逻辑。请将它改造成基于 Selenium 显式等待的模式。 要求 - 将固定的 time.sleep 全部移除 - 根据场景使用 visibility_of_element_located、element_to_be_clickable、presence_of_element_located 等不同条件 - 等待超时时间设置为 10 秒轮询间隔 500 毫秒 - 不要吞掉超时异常超时后应输出包含页面 URL 和当前页面标题的错误信息 - 如果你发现元素定位表达式不够稳定可以建议更优的定位策略但不能直接修改页面对象的值。 原始代码这个模板里有一个默认很关键的举动不允许它吞异常。为什么因为在测试脚本里超时是一种重要的失败信号它说明页面在某些条件下没有按预期渲染。如果模型把超时异常 catch 住然后返回 None测试就会变成假通过。很多“全绿但线上还有 bug”的测试脚本就是因为把异常吞得太干净了。加显式等待的同时保留失败信息的可观测性才是真正的稳定性修复。4.3 模板8从一个 bug 描述反向补齐回归测试用例测试团队比较忙的时候修 bug 很容易只修当前那一条路相关的回归测试却没有补齐。过了几天同一个模块里相似的 bug 又被用户发现才发现上次根本没把关联场景覆盖到。ChatGPT 可以帮你从一份 bug 描述出发生成一份相对完整的回归测试设计稿。这是一个线上 bug 的描述 “用户在积分兑换过程中如果连续点击两次兑换按钮系统会生成两笔兑换记录。期望结果同一用户、同一商品、同一时刻的重复点击只能生成一笔订单。” 请基于这个 bug 生成回归测试用例和对应测试脚本。 要求 - 测试用例要覆盖正常提交、重复点击、接口重放、按钮置灰等场景 - 脚本中需要体现前置数据的准备例如用户需要先登录并拥有足够积分 - 脚本要包含必要的断言至少要验证数据库中的订单数量不超过 1 - 输出分两部分用例表格和 pytest 脚本代码。这种模板的产出并不一定可以 100% 直接跑通因为有些前置数据需要你自己 mock但它能帮你把一个 bug 联想到的场景全部列全。比如上面这个 bugChatGPT 会顺带想到“如果同一用户在不同浏览器里同时点击呢”“如果后端接口被直接重放呢”这些边角场景。这些想法就算最终实现起来很复杂至少能帮你在需求评审或排期阶段把风险点暴露出来。4.4 模板9把脚本中的硬编码改成外部配置和常量测试脚本写久了代码里会飘着一堆硬编码。URL、用户名、数据库连接串、页面元素路径、超时时间全被塞在代码字段里。到了多环境跑测试的时候就得临时改代码改完还可能忘记改回来。模板9的思路很简单让 ChatGPT 把硬编码抽到独立配置区而不再散落在各个用例方法里。下面这段自动化测试脚本中包含许多硬编码值。请把它改造成可配置的风格。 要求 - 环境相关变量例如 URL、数据库地址、用户名密码统一提取到一个 config 对象中 - 页面元素定位器如果有重复出现提取为页面对象级常量 - 测试业务数据不允许被提取为全局配置必须保留在用例内部保证每个用例数据独立 - 输出改造后的完整代码并标注出哪些变量只适合放在生产配置里、哪些适合放在测试代码目录下。 原始脚本这个模板有一个容易被忽略的好处它会把“环境相关变量”和“业务变量”分成两类。以前我们做配置化改造时容易把业务输入值也一股脑地塞进全局配置里结果多个用例之间互相影响改了一个全局配置值所有用例的行为都被带偏。ChatGPT 如果没被提示也会犯这个错误。我把“业务测试数据不提取为全局配置”写进提示词就是希望配置化改造之后每个用例的可读性和隔离性都还在而不是只管代码干净。4.5 模板10让 ChatGPT 以代码审查者身份挑问题这个模板适合放在每个优化迭代的收尾阶段。你的脚本已经经过了前九个模板的优化但你还担心有没有遗漏那就让 ChatGPT 扮演一个严格但专业的老测试开发来挑刺。请以一位资深测试开发工程师的身份对下面这段自动化测试脚本做一次代码审查。 审查方向包括 - 测试用例之间是否存在状态污染或执行顺序依赖 - 是否有未释放的资源例如浏览器实例、临时文件、mock server - 断言是否针对业务结果而不是中间过程 - 是否有不必要的复杂逻辑例如过度封装、无意义抽象 - 是否有潜在的维护陷阱例如定位方式不稳定、接口变更影响面大。 输出格式 - 按严重程度从高到低列出问题 - 每个问题标注代码行号和修改建议 - 最后给出整体评价并列出适合做自动化测试的用例场景。 待审查代码这个模板的价值不在于替代人工审查而在于它能在你提交代码之前先帮你扫一遍“常规坏味道”。实测下来它对“资源未释放”和“隐式依赖全局变量”这类问题的命中率相当高。有个同事用这个模板检查过一段后端自动化脚本发现某个用例虽然用with正确打开了 mock server但异常分支里 server 根本没关。这个 bug 人工看很难发现但模型因为是纯文本分析不会受“看似正常的代码缩进”干扰反而更容易注意到逻辑分支的缺口。如果你们团队已经有代码规范文档也可以把文档里的核心章节贴到当前提示词后面。这会让 ChatGPT 的审查标准更贴近团队内部约定而不是只停留在通用层面。5. 在真实项目里反复测试后这几个场景建议慎重使用模板不是万能钥匙。我用这套模板跑了差不多 200 多次测试脚本优化任务后也找到了一些 ChatGPT 目前并不擅长的边界。这里把我觉得最容易翻车的几种情况列出来省得你重复踩坑。第一个慎重使用的场景是“跨文件重构”。模板在单文件或者单函数级的表现非常好但一旦你要重构的是一个跨越多个测试文件、多个 fixture 文件、甚至有共享 conftest 的完整测试工程时ChatGPT 的输出经常会出现自相矛盾。它会改完 A 文件后忽略了 B 文件里还在引用旧函数名。我在用模板2和模板6时都遇到过类似问题解决办法是先把文件调用关系整理成一张依赖图并且把相关的核心接口签名贴进提示词而不是把整个目录一股脑抛给它。如果你期望它自己意识到“这里改了之后别的文件里还有三个调用点”那大概率会失望。第二个慎重使用的场景是“性能调优”。如果脚本跑得慢是因为存在大量不合理的 I/O 请求、浏览器无谓跳转、或者测试数据量过大ChatGPT 能帮你分析出表面原因但它并不了解你的被测系统内部到底哪一步响应慢。它很可能只会建议你“减少日志输出、用 headless 模式、加大并行度”这些通用手段。对运行时性能瓶颈这类问题我还是倾向于先做 profiling定位到具体阻塞点再让模型针对那一小段进行优化。不要一上来就让它做全局提速。第三个要谨慎的场景是“自动化生成整套 UI 自动化脚本”。ChatGPT 很擅长生成精美的页面定位代码但它没有真正打开过你的页面不知道哪个按钮在哪个层级下。拿它生成的 XPath 到了真实环境里经常失效。我的建议是让它只生成“步骤骨架”或“辅助函数”页面元素定位这类工作还是要基于你实际调试过的数据。如果你希望它参与 UI 脚本编写那就把页面的 HTML 关键片段、元素属性、期望交互流程先喂给它这样它写出来的脚本才有一点可跑的成功率。最后说一个“不是模板问题而是流程问题”的点。整个优化流程里最不该省的那一步是改了脚本之后立刻跑一次全量回归。别因为 ChatGPT 给了你看起来很稳的代码就省略执行和 review。它输出的是“基于文本统计的最优解”而不是“基于你系统真实行为的验证结果”。我团队里现在有两条硬规矩。第一条所有由 ChatGPT 生成或大幅修改的测试代码提交前必须由项目里另一个同事做代码评审不允许把模型输出直接合入主干。第二条任何一个模板生成的代码第一次合入时必须跑最小回归集确认测试环境本身没被改动破坏。这两条规矩执行了大半年几乎没有因为 AI 辅助而引入过严重的线上回归事故。