回归测试这件事做过的人都知道它有多磨人。功能没改几行测试用例却要全量跑一遍三天时间搭进去人还累得够呛。我所在的团队维护着一套中等规模的Web应用前端用React后端是Java微服务测试框架是Playwright加pytest。每次发版前的回归测试光是等待CI流水线跑完就要大半天加上人工核对失败用例、排查环境问题、补写遗漏场景三天是常态。直到我把AI引入到回归测试的各个环节用提示词驱动用例生成、脚本修复和结果分析硬是把周期压到了三个小时。这篇文章不讲虚的直接把我用的提示词、踩过的坑、以及每一步为什么这么设计全部摊开来说。1. 回归测试为什么这么慢先找到瓶颈再谈优化1.1 三天时间到底花在了哪里很多人一提到回归测试慢第一反应是机器不够快或者用例太多。但我实际记录了两周的时间开销后发现真正跑测试的时间只占不到20%。剩下的时间分布在几个隐蔽的环节用例维护、失败排查、环境准备、数据构造。这四个环节才是真正的吞金兽。我拿一个具体版本举例。那次发版涉及用户权限模块的重构回归用例集有480条。CI流水线并行跑完所有用例用了大约4小时但其中有62条失败。这62条里面真正因为代码缺陷导致的只有7条其余55条全是用例本身的问题——选择器失效、断言过时、测试数据被污染。排查这55条假失败花了整整一天半。剩下的时间用来补写新功能的回归用例、协调测试环境、以及等待后端服务部署。所以问题的本质不是跑得慢而是维护成本高和排查效率低。AI能帮上忙的地方恰恰就在这两个环节。1.2 哪些环节适合交给AI哪些必须人工把关在动手之前我先划了一条线。AI擅长的是模式识别、代码生成、文本理解和批量处理不擅长的是业务逻辑判断、需求意图理解和最终质量决策。基于这个判断我把回归测试的环节做了分类环节是否适合AI介入理由用例脚本生成适合有明确的页面结构和操作描述AI能快速产出骨架选择器修复适合属于模式匹配和替换AI准确率高失败原因初筛适合能快速分类失败类型减少人工逐条看日志测试数据构造部分适合结构化数据可以生成业务语义数据需人工确认缺陷定级不适合需要业务上下文和风险评估回归范围决策不适合依赖对代码变更影响面的理解这条线划清楚之后我就知道该把精力投在哪里了。后面所有的提示词设计都是围绕让AI做它擅长的事人工只做决策这个原则展开的。1.3 工具链选型为什么是Playwright加pytest市面上自动化测试工具不少Selenium、Cypress、Playwright各有拥趸。我选Playwright有几个实际原因。第一它对现代前端框架的支持更自然自动等待机制减少了大量flaky用例这对回归测试的稳定性至关重要。第二它的选择器策略更灵活支持文本选择器、角色选择器AI生成脚本时不容易写出脆弱的选择器。第三Playwright的trace功能在排查失败时非常好用截图、网络请求、控制台日志一应俱全这些信息喂给AI做分析特别高效。pytest作为测试运行器优势在于 fixture 机制成熟、参数化方便、插件生态丰富。pytest-playwright 这个插件把两者粘合得很顺滑。至于AI部分我用的是支持长上下文的大模型通过API调用把页面结构、用例描述、失败日志作为输入让它输出脚本或分析结果。整个链路不依赖任何特定平台本地就能跑通。2. 提示词设计的核心逻辑不是让AI写代码而是让AI理解意图2.1 为什么直接说帮我写测试用例效果很差我一开始也犯过这个错。把需求文档往AI面前一扔说帮我写Playwright测试用例结果出来的东西看着像那么回事实际跑起来一堆问题。选择器用的是脆弱的CSS路径断言写得太宽泛步骤顺序也不符合实际操作流程。问题出在哪里AI不知道你的页面长什么样不知道你的测试规范不知道哪些操作是前置条件。它只能根据通用知识猜。猜出来的东西你得花更多时间去改还不如自己写。后来我调整了策略把AI当成一个刚入职的测试工程师你需要给它足够的上下文它才能产出可用的东西。上下文包括页面DOM结构、现有用例的写法范例、测试规范约定、以及具体的测试意图描述。这四样东西给足了AI的输出质量会有质的飞跃。2.2 提示词的四层结构角色、上下文、任务、约束经过反复调试我总结出一套四层结构的提示词模板。这个结构不是拍脑袋想的而是对应了AI理解任务的四个必要条件。第一层是角色设定。告诉AI它现在是什么身份这会影响它的输出风格和专业深度。比如你是一名有五年经验的自动化测试工程师熟悉Playwright和pytest的最佳实践。第二层是上下文注入。把页面结构、现有代码范例、测试规范都塞进去。这一层最占token但效果最明显。我通常会把目标页面的关键DOM片段、两到三个现有用例的完整代码、以及一份简短的测试规范文档一起放进去。第三层是任务描述。具体要AI做什么越明确越好。不要说写测试用例要说为登录页面的记住我功能写三条回归用例分别覆盖勾选后关闭浏览器再打开、勾选后清除cookie、不勾选三种场景。第四层是约束条件。告诉AI什么能做、什么不能做。比如选择器优先使用getByRole和getByLabel禁止使用nth-child、断言必须包含具体的期望值禁止使用toBeTruthy这种模糊断言、每个用例必须独立不依赖其他用例的执行结果。这四层缺一不可。我试过省掉约束条件结果AI用了大量脆弱的XPath省掉上下文AI写的选择器和实际页面对不上。只有四层都给足输出才稳定可用。2.3 一个完整的提示词长什么样下面是我实际在用的用例生成提示词模板直接贴出来你是一名有五年经验的自动化测试工程师精通Playwright和pytest 熟悉Page Object模式和测试用例设计方法。 ## 项目背景 - 测试框架pytest playwright-python - 页面对象存放在 pages/ 目录测试用例存放在 tests/ 目录 - 所有页面对象继承 BasePage 类该类封装了 wait_for_load 和 safe_click 方法 - 断言使用 pytest 的 assert 语句配合 playwright 的 expect ## 现有用例范例 [这里粘贴2-3个现有用例的完整代码] ## 目标页面结构 [这里粘贴目标页面的关键DOM片段或者用 accessibility tree 的描述] ## 测试任务 为[具体功能]编写[N]条回归测试用例覆盖以下场景 1. [场景一描述] 2. [场景二描述] 3. [场景三描述] ## 约束条件 - 选择器优先级getByRole getByLabel getByText getByTestId CSS - 禁止使用 nth-child、nth-of-type 等位置选择器 - 每个用例必须有明确的断言断言要包含期望的具体值 - 用例之间必须独立不共享状态 - 涉及网络请求的场景使用 page.route 进行拦截和mock - 输出格式完整的Python代码包含必要的import这个模板我用了几个月生成用例的可用率从最初的30%提升到了80%左右。剩下的20%主要是业务语义上的偏差需要人工微调。3. 从用例生成到脚本修复AI在回归测试中的三个实战场景3.1 场景一根据需求描述批量生成回归用例新功能开发完成后测试用例往往来不及写。以前的做法是测试工程师对着需求文档一条条手写一个中等复杂度的功能要写大半天。现在我把需求描述整理成结构化文本喂给AI让它先生成用例骨架我再做审核和补充。具体操作是这样的先从需求文档里提取出功能点、操作路径、预期结果整理成一个简单的列表。然后把这个列表和页面结构一起放进提示词让AI输出pytest格式的测试代码。生成之后我会跑一遍看哪些用例能通过、哪些失败。失败的用例分两种情况一种是用例本身写错了一种是发现了真实的缺陷。前者让AI根据报错信息修复后者直接提bug。这里有个经验需求描述越具体AI生成的用例越准确。如果需求文档写的是用户可以修改个人信息AI只能猜出修改姓名、修改邮箱这些通用场景。但如果写成用户可以在个人中心页面修改昵称昵称长度限制2-20个字符支持中英文和数字修改后立即生效并在页面顶部显示成功提示AI就能生成覆盖边界值、特殊字符、成功提示的完整用例。3.2 场景二选择器失效后的批量修复前端改版是回归测试的头号杀手。一个class名改了几十条用例跟着挂。以前只能一条条看报错、一个个改选择器枯燥且容易出错。现在我把失败的用例代码和新的页面DOM一起喂给AI让它批量替换选择器。这个场景的提示词相对简单核心是提供准确的映射关系。我会把旧的选择器和新的DOM结构放在一起让AI找出对应的新选择器。比如旧的.login-btn变成了button rolebutton aria-label登录AI会自动替换成page.getByRole(button, { name: 登录 })。实测下来这种批量修复的准确率很高尤其是当页面结构变化有规律的时候。但有一个坑要注意如果新旧页面不只是选择器变了交互流程也变了那AI替换出来的代码虽然能跑但测试意图可能已经不对了。这种情况必须人工介入重新设计用例。3.3 场景三失败日志的智能分类与初筛回归测试跑完面对几十条失败最耗时的不是修复而是判断哪些是真失败、哪些是假失败。我把失败日志、截图描述、以及用例代码一起喂给AI让它做初步分类。提示词的核心是让AI按照预设的分类标准输出结果。我的分类标准是这样的环境问题超时、连接拒绝、服务未启动数据问题测试数据不存在、数据被其他用例污染用例问题选择器失效、断言过时、步骤顺序错误疑似缺陷页面行为与预期不符且不属于以上三类AI分类之后我只需要重点看疑似缺陷这一类其余三类按对应方案批量处理。这一步把失败排查的时间从一天半压缩到了两小时左右。不过要提醒一句AI的分类不是100%准确尤其是疑似缺陷和用例问题之间的边界有时候需要人工复核。我的做法是让AI给出分类理由我根据理由判断是否可信。如果理由牵强就人工介入。4. 把3天压到3小时的完整流水线每个环节的配置与衔接4.1 流水线的整体架构单点用AI提效还不够真正把时间压下来需要把AI嵌入到整个回归测试流程中形成一条自动化流水线。我的流水线大致分为五个阶段变更分析、用例筛选、脚本生成与修复、并行执行、结果分析。每个阶段都有AI的参与但参与程度不同。变更分析阶段我用AI读取代码diff判断哪些模块受影响从而确定回归范围。这一步AI只做建议最终范围由人工确认。用例筛选阶段根据变更范围从用例库中挑选相关用例AI辅助打标签。脚本生成与修复阶段是AI介入最深的环节前面讲的三个场景都在这里。并行执行阶段是纯工程问题用pytest-xdist做分布式执行。结果分析阶段AI做失败分类和报告生成。整条流水线跑下来从代码提交到回归报告产出稳定在3小时左右。其中AI相关的处理时间大约占40分钟其余是实际的测试执行时间。4.2 变更分析与回归范围确定这一步的提示词设计要点是让AI理解代码变更的影响面。我会把git diff的内容、项目的模块依赖图、以及用例与模块的映射关系一起提供给AI让它输出受影响的模块列表和建议的回归范围。你是一名资深测试架构师擅长根据代码变更评估测试影响范围。 ## 代码变更 [粘贴 git diff 内容] ## 模块依赖关系 [粘贴模块依赖图可以用简单的文本描述] ## 用例与模块映射 [粘贴用例标签与模块的对应关系] ## 任务 分析本次代码变更可能影响的模块输出 1. 直接受影响模块列表 2. 间接受影响模块列表通过依赖关系推导 3. 建议的回归用例范围按优先级排序 4. 分析理由这个提示词的关键在于依赖关系的准确性。如果依赖图不全AI的推导就会漏掉一些模块。我的做法是维护一份手工校准过的依赖关系文档每次架构调整时同步更新。4.3 用例筛选与优先级排序回归用例不是越多越好全量跑三天精选跑三小时效果可能差不多。关键是选对用例。我用AI给用例打标签标签维度包括关联模块、业务重要性、历史失败率、执行耗时。然后根据变更范围优先选择高关联、高重要性、高失败率的用例。标签的初始化可以借助AI批量完成。把用例代码和用例名称喂给AI让它输出模块标签和业务重要性评估。历史失败率和执行耗时从测试报告里自动提取。这套标签体系建起来之后用例筛选就从凭感觉变成了看数据。4.4 并行执行与资源调度执行阶段本身没有太多AI的戏份但有几个工程细节直接影响总耗时。第一是并行度设置pytest-xdist的-n参数不是越大越好要结合CI机器的CPU核数和内存来定。我的经验值是CPU核数的1.5倍再高反而因为上下文切换导致效率下降。第二是用例分组把耗时长的用例和耗时短的用例混编避免出现长尾——所有短用例跑完了还在等最后几条长用例。第三是失败重试策略对flaky用例设置一次重试但重试次数不能多否则会掩盖真实问题。4.5 结果分析与报告生成最后一步是把执行结果整理成可读的报告。AI在这里的作用是汇总失败原因、生成修复建议、以及输出回归结论。我会把失败用例的日志、截图描述、以及AI之前的分类结果一起喂给它让它生成一份结构化的报告。报告包含几个部分执行概况总数、通过数、失败数、跳过数、失败分类统计、疑似缺陷列表附日志摘要、用例问题列表附修复建议、以及回归结论。这份报告直接发给团队省去了人工整理的时间。5. 踩过的坑与实战心得那些文档里不会写的东西5.1 提示词不是越长越好关键是信息密度我一开始以为提示词写得越详细越好把整个项目的文档都往里塞。结果AI的输出反而变差了因为它抓不住重点。后来我学会了做减法只放和目标直接相关的信息无关的背景一律删掉。比如生成登录页用例就不需要把订单模块的代码放进去。信息密度的另一个体现是范例的质量。放两个写得好的现有用例比放十个写得一般的用例效果好得多。AI会模仿范例的风格和结构范例质量直接决定输出质量。5.2 AI生成的用例必须跑一遍再入库这一点我吃过亏。有一次批量生成了80条用例看着都挺像样直接入库了。结果下次回归时发现其中20多条根本跑不通有的是选择器写错了有的是断言逻辑有问题。从那以后我定了个规矩AI生成的用例必须实际执行通过才能入库跑不通的要么修复要么丢弃。这个规矩看起来增加了工作量但实际上避免了更大的麻烦。一条坏用例混在用例库里每次回归都要浪费时间去排查长期成本远高于入库前的一次验证。5.3 选择器策略决定了用例的寿命Playwright支持多种选择器但它们的稳定性差异很大。我总结了一个优先级getByRole最稳因为它基于无障碍角色前端改样式不会影响它getByLabel和getByText次之只要文案不变就没事getByTestId需要开发配合加属性但一旦加上就很稳定CSS选择器和XPath最脆弱能不用就不用。在提示词里明确这个优先级AI生成的选择器质量会好很多。我还会在代码审查阶段检查选择器类型发现用了位置选择器的直接打回重写。5.4 不要让AI碰业务逻辑判断我试过让AI判断一个失败用例到底是缺陷还是用例问题。结果它经常把业务逻辑上的差异误判为用例问题。比如某个按钮在特定权限下应该隐藏AI看到按钮不可见就认为是选择器问题实际上这是正确的业务行为。后来我把这类判断收回来自己做AI只负责提供日志摘要和分类建议。业务逻辑判断必须由了解需求的人来做这一点AI替代不了。5.5 提示词需要版本管理提示词是会迭代的。随着项目变化、AI模型更新、团队规范调整提示词也要跟着改。我建议把提示词当成代码一样管理放在git仓库里每次修改记录变更原因。这样当输出质量下降时可以回溯是哪个版本的提示词、配合哪个模型效果最好。我现在的做法是每个提示词文件头部写清楚适用场景、最后更新日期、以及已知的局限性。团队里其他人用的时候能快速判断是否适合自己的场景。5.6 成本控制不是所有环节都值得用AIAI调用是有成本的包括token费用和时间开销。我算过一笔账用例生成环节用AI每条用例平均节省15分钟人工时间非常划算但简单的选择器替换用sed命令批量处理可能比调AI更快。所以我把AI用在那些需要理解语义的环节纯机械的替换用脚本解决。另外大模型的响应时间也要考虑。如果一条提示词要等30秒才返回结果那批量处理100条用例就是50分钟这个时间成本要算进去。我的做法是把能批量的任务合并成一次调用减少往返次数。6. 回归测试提效的边界与后续演进方向6.1 三个小时的构成与进一步压缩的空间现在的三小时里实际测试执行占了大约两小时AI处理占40分钟人工审核占20分钟。要进一步压缩执行时间是大头。我目前在尝试的方向是用例分片和增量执行——只跑受变更影响的用例而不是全量回归。这需要更精准的变更影响分析也是AI可以继续发力的地方。另一个方向是失败重试的智能化。现在flaky用例的重试是盲目的重试一次不行就标记失败。如果能让AI根据失败日志判断是否值得重试可以节省不少时间。6.2 什么情况下AI提效会打折扣AI不是万能的。在几种情况下提效效果会明显下降。一是页面结构极度不稳定选择器天天变AI修复的速度赶不上变化的速度。二是业务逻辑极其复杂AI生成的用例覆盖不到关键路径需要大量人工补充。三是测试环境本身不可靠失败原因大多是环境问题AI分类也帮不上忙。遇到这些情况我的建议是先解决根本问题。页面不稳定就先推动前端加testid环境不可靠就先修环境。AI是放大器不是万能药。6.3 从回归测试延伸到更广的测试自动化这套提示词驱动的方法其实不限于回归测试。冒烟测试、接口测试、甚至性能测试的脚本生成都可以用类似的思路。核心逻辑是一样的给AI足够的上下文和明确的约束让它产出可用的测试资产人工做最终把关。我最近在尝试把这套方法用到接口自动化测试上用OpenAPI文档作为上下文让AI生成pytest的接口测试用例。初步效果不错生成效率比手写高很多准确率也在可接受范围内。6.4 团队协作中的提示词共享与规范统一一个人用AI提效不难难的是让整个团队都用起来并且效果一致。我的做法是建了一个提示词库按场景分类存放每个提示词都有使用说明和效果评价。新成员入职时先学提示词库再上手写用例。这样能保证团队输出的用例风格统一、质量稳定。另外我们每周会做一次提示词复盘把本周遇到的新场景、新问题、以及对应的提示词调整记录下来。这个习惯坚持了几个月提示词库越来越丰富覆盖的场景也越来越全。说到底AI在回归测试里的价值不是替代测试工程师而是把测试工程师从重复劳动里解放出来让他们有精力去做更有价值的事——设计更好的测试策略、发现更深层的缺陷、推动质量内建。工具在变但测试的核心目标没变用最小的成本给产品质量提供最大的信心。 
长河君 · 2026/11/3 8:51:51 · 阅读 1.2k AI驱动回归测试提效：从3天到3小时的提示词实战
回归测试这件事做过的人都知道它有多磨人。功能没改几行测试用例却要全量跑一遍三天时间搭进去人还累得够呛。我所在的团队维护着一套中等规模的Web应用前端用React后端是Java微服务测试框架是Playwright加pytest。每次发版前的回归测试光是等待CI流水线跑完就要大半天加上人工核对失败用例、排查环境问题、补写遗漏场景三天是常态。直到我把AI引入到回归测试的各个环节用提示词驱动用例生成、脚本修复和结果分析硬是把周期压到了三个小时。这篇文章不讲虚的直接把我用的提示词、踩过的坑、以及每一步为什么这么设计全部摊开来说。1. 回归测试为什么这么慢先找到瓶颈再谈优化1.1 三天时间到底花在了哪里很多人一提到回归测试慢第一反应是机器不够快或者用例太多。但我实际记录了两周的时间开销后发现真正跑测试的时间只占不到20%。剩下的时间分布在几个隐蔽的环节用例维护、失败排查、环境准备、数据构造。这四个环节才是真正的吞金兽。我拿一个具体版本举例。那次发版涉及用户权限模块的重构回归用例集有480条。CI流水线并行跑完所有用例用了大约4小时但其中有62条失败。这62条里面真正因为代码缺陷导致的只有7条其余55条全是用例本身的问题——选择器失效、断言过时、测试数据被污染。排查这55条假失败花了整整一天半。剩下的时间用来补写新功能的回归用例、协调测试环境、以及等待后端服务部署。所以问题的本质不是跑得慢而是维护成本高和排查效率低。AI能帮上忙的地方恰恰就在这两个环节。1.2 哪些环节适合交给AI哪些必须人工把关在动手之前我先划了一条线。AI擅长的是模式识别、代码生成、文本理解和批量处理不擅长的是业务逻辑判断、需求意图理解和最终质量决策。基于这个判断我把回归测试的环节做了分类环节是否适合AI介入理由用例脚本生成适合有明确的页面结构和操作描述AI能快速产出骨架选择器修复适合属于模式匹配和替换AI准确率高失败原因初筛适合能快速分类失败类型减少人工逐条看日志测试数据构造部分适合结构化数据可以生成业务语义数据需人工确认缺陷定级不适合需要业务上下文和风险评估回归范围决策不适合依赖对代码变更影响面的理解这条线划清楚之后我就知道该把精力投在哪里了。后面所有的提示词设计都是围绕让AI做它擅长的事人工只做决策这个原则展开的。1.3 工具链选型为什么是Playwright加pytest市面上自动化测试工具不少Selenium、Cypress、Playwright各有拥趸。我选Playwright有几个实际原因。第一它对现代前端框架的支持更自然自动等待机制减少了大量flaky用例这对回归测试的稳定性至关重要。第二它的选择器策略更灵活支持文本选择器、角色选择器AI生成脚本时不容易写出脆弱的选择器。第三Playwright的trace功能在排查失败时非常好用截图、网络请求、控制台日志一应俱全这些信息喂给AI做分析特别高效。pytest作为测试运行器优势在于 fixture 机制成熟、参数化方便、插件生态丰富。pytest-playwright 这个插件把两者粘合得很顺滑。至于AI部分我用的是支持长上下文的大模型通过API调用把页面结构、用例描述、失败日志作为输入让它输出脚本或分析结果。整个链路不依赖任何特定平台本地就能跑通。2. 提示词设计的核心逻辑不是让AI写代码而是让AI理解意图2.1 为什么直接说帮我写测试用例效果很差我一开始也犯过这个错。把需求文档往AI面前一扔说帮我写Playwright测试用例结果出来的东西看着像那么回事实际跑起来一堆问题。选择器用的是脆弱的CSS路径断言写得太宽泛步骤顺序也不符合实际操作流程。问题出在哪里AI不知道你的页面长什么样不知道你的测试规范不知道哪些操作是前置条件。它只能根据通用知识猜。猜出来的东西你得花更多时间去改还不如自己写。后来我调整了策略把AI当成一个刚入职的测试工程师你需要给它足够的上下文它才能产出可用的东西。上下文包括页面DOM结构、现有用例的写法范例、测试规范约定、以及具体的测试意图描述。这四样东西给足了AI的输出质量会有质的飞跃。2.2 提示词的四层结构角色、上下文、任务、约束经过反复调试我总结出一套四层结构的提示词模板。这个结构不是拍脑袋想的而是对应了AI理解任务的四个必要条件。第一层是角色设定。告诉AI它现在是什么身份这会影响它的输出风格和专业深度。比如你是一名有五年经验的自动化测试工程师熟悉Playwright和pytest的最佳实践。第二层是上下文注入。把页面结构、现有代码范例、测试规范都塞进去。这一层最占token但效果最明显。我通常会把目标页面的关键DOM片段、两到三个现有用例的完整代码、以及一份简短的测试规范文档一起放进去。第三层是任务描述。具体要AI做什么越明确越好。不要说写测试用例要说为登录页面的记住我功能写三条回归用例分别覆盖勾选后关闭浏览器再打开、勾选后清除cookie、不勾选三种场景。第四层是约束条件。告诉AI什么能做、什么不能做。比如选择器优先使用getByRole和getByLabel禁止使用nth-child、断言必须包含具体的期望值禁止使用toBeTruthy这种模糊断言、每个用例必须独立不依赖其他用例的执行结果。这四层缺一不可。我试过省掉约束条件结果AI用了大量脆弱的XPath省掉上下文AI写的选择器和实际页面对不上。只有四层都给足输出才稳定可用。2.3 一个完整的提示词长什么样下面是我实际在用的用例生成提示词模板直接贴出来你是一名有五年经验的自动化测试工程师精通Playwright和pytest 熟悉Page Object模式和测试用例设计方法。 ## 项目背景 - 测试框架pytest playwright-python - 页面对象存放在 pages/ 目录测试用例存放在 tests/ 目录 - 所有页面对象继承 BasePage 类该类封装了 wait_for_load 和 safe_click 方法 - 断言使用 pytest 的 assert 语句配合 playwright 的 expect ## 现有用例范例 [这里粘贴2-3个现有用例的完整代码] ## 目标页面结构 [这里粘贴目标页面的关键DOM片段或者用 accessibility tree 的描述] ## 测试任务 为[具体功能]编写[N]条回归测试用例覆盖以下场景 1. [场景一描述] 2. [场景二描述] 3. [场景三描述] ## 约束条件 - 选择器优先级getByRole getByLabel getByText getByTestId CSS - 禁止使用 nth-child、nth-of-type 等位置选择器 - 每个用例必须有明确的断言断言要包含期望的具体值 - 用例之间必须独立不共享状态 - 涉及网络请求的场景使用 page.route 进行拦截和mock - 输出格式完整的Python代码包含必要的import这个模板我用了几个月生成用例的可用率从最初的30%提升到了80%左右。剩下的20%主要是业务语义上的偏差需要人工微调。3. 从用例生成到脚本修复AI在回归测试中的三个实战场景3.1 场景一根据需求描述批量生成回归用例新功能开发完成后测试用例往往来不及写。以前的做法是测试工程师对着需求文档一条条手写一个中等复杂度的功能要写大半天。现在我把需求描述整理成结构化文本喂给AI让它先生成用例骨架我再做审核和补充。具体操作是这样的先从需求文档里提取出功能点、操作路径、预期结果整理成一个简单的列表。然后把这个列表和页面结构一起放进提示词让AI输出pytest格式的测试代码。生成之后我会跑一遍看哪些用例能通过、哪些失败。失败的用例分两种情况一种是用例本身写错了一种是发现了真实的缺陷。前者让AI根据报错信息修复后者直接提bug。这里有个经验需求描述越具体AI生成的用例越准确。如果需求文档写的是用户可以修改个人信息AI只能猜出修改姓名、修改邮箱这些通用场景。但如果写成用户可以在个人中心页面修改昵称昵称长度限制2-20个字符支持中英文和数字修改后立即生效并在页面顶部显示成功提示AI就能生成覆盖边界值、特殊字符、成功提示的完整用例。3.2 场景二选择器失效后的批量修复前端改版是回归测试的头号杀手。一个class名改了几十条用例跟着挂。以前只能一条条看报错、一个个改选择器枯燥且容易出错。现在我把失败的用例代码和新的页面DOM一起喂给AI让它批量替换选择器。这个场景的提示词相对简单核心是提供准确的映射关系。我会把旧的选择器和新的DOM结构放在一起让AI找出对应的新选择器。比如旧的.login-btn变成了button rolebutton aria-label登录AI会自动替换成page.getByRole(button, { name: 登录 })。实测下来这种批量修复的准确率很高尤其是当页面结构变化有规律的时候。但有一个坑要注意如果新旧页面不只是选择器变了交互流程也变了那AI替换出来的代码虽然能跑但测试意图可能已经不对了。这种情况必须人工介入重新设计用例。3.3 场景三失败日志的智能分类与初筛回归测试跑完面对几十条失败最耗时的不是修复而是判断哪些是真失败、哪些是假失败。我把失败日志、截图描述、以及用例代码一起喂给AI让它做初步分类。提示词的核心是让AI按照预设的分类标准输出结果。我的分类标准是这样的环境问题超时、连接拒绝、服务未启动数据问题测试数据不存在、数据被其他用例污染用例问题选择器失效、断言过时、步骤顺序错误疑似缺陷页面行为与预期不符且不属于以上三类AI分类之后我只需要重点看疑似缺陷这一类其余三类按对应方案批量处理。这一步把失败排查的时间从一天半压缩到了两小时左右。不过要提醒一句AI的分类不是100%准确尤其是疑似缺陷和用例问题之间的边界有时候需要人工复核。我的做法是让AI给出分类理由我根据理由判断是否可信。如果理由牵强就人工介入。4. 把3天压到3小时的完整流水线每个环节的配置与衔接4.1 流水线的整体架构单点用AI提效还不够真正把时间压下来需要把AI嵌入到整个回归测试流程中形成一条自动化流水线。我的流水线大致分为五个阶段变更分析、用例筛选、脚本生成与修复、并行执行、结果分析。每个阶段都有AI的参与但参与程度不同。变更分析阶段我用AI读取代码diff判断哪些模块受影响从而确定回归范围。这一步AI只做建议最终范围由人工确认。用例筛选阶段根据变更范围从用例库中挑选相关用例AI辅助打标签。脚本生成与修复阶段是AI介入最深的环节前面讲的三个场景都在这里。并行执行阶段是纯工程问题用pytest-xdist做分布式执行。结果分析阶段AI做失败分类和报告生成。整条流水线跑下来从代码提交到回归报告产出稳定在3小时左右。其中AI相关的处理时间大约占40分钟其余是实际的测试执行时间。4.2 变更分析与回归范围确定这一步的提示词设计要点是让AI理解代码变更的影响面。我会把git diff的内容、项目的模块依赖图、以及用例与模块的映射关系一起提供给AI让它输出受影响的模块列表和建议的回归范围。你是一名资深测试架构师擅长根据代码变更评估测试影响范围。 ## 代码变更 [粘贴 git diff 内容] ## 模块依赖关系 [粘贴模块依赖图可以用简单的文本描述] ## 用例与模块映射 [粘贴用例标签与模块的对应关系] ## 任务 分析本次代码变更可能影响的模块输出 1. 直接受影响模块列表 2. 间接受影响模块列表通过依赖关系推导 3. 建议的回归用例范围按优先级排序 4. 分析理由这个提示词的关键在于依赖关系的准确性。如果依赖图不全AI的推导就会漏掉一些模块。我的做法是维护一份手工校准过的依赖关系文档每次架构调整时同步更新。4.3 用例筛选与优先级排序回归用例不是越多越好全量跑三天精选跑三小时效果可能差不多。关键是选对用例。我用AI给用例打标签标签维度包括关联模块、业务重要性、历史失败率、执行耗时。然后根据变更范围优先选择高关联、高重要性、高失败率的用例。标签的初始化可以借助AI批量完成。把用例代码和用例名称喂给AI让它输出模块标签和业务重要性评估。历史失败率和执行耗时从测试报告里自动提取。这套标签体系建起来之后用例筛选就从凭感觉变成了看数据。4.4 并行执行与资源调度执行阶段本身没有太多AI的戏份但有几个工程细节直接影响总耗时。第一是并行度设置pytest-xdist的-n参数不是越大越好要结合CI机器的CPU核数和内存来定。我的经验值是CPU核数的1.5倍再高反而因为上下文切换导致效率下降。第二是用例分组把耗时长的用例和耗时短的用例混编避免出现长尾——所有短用例跑完了还在等最后几条长用例。第三是失败重试策略对flaky用例设置一次重试但重试次数不能多否则会掩盖真实问题。4.5 结果分析与报告生成最后一步是把执行结果整理成可读的报告。AI在这里的作用是汇总失败原因、生成修复建议、以及输出回归结论。我会把失败用例的日志、截图描述、以及AI之前的分类结果一起喂给它让它生成一份结构化的报告。报告包含几个部分执行概况总数、通过数、失败数、跳过数、失败分类统计、疑似缺陷列表附日志摘要、用例问题列表附修复建议、以及回归结论。这份报告直接发给团队省去了人工整理的时间。5. 踩过的坑与实战心得那些文档里不会写的东西5.1 提示词不是越长越好关键是信息密度我一开始以为提示词写得越详细越好把整个项目的文档都往里塞。结果AI的输出反而变差了因为它抓不住重点。后来我学会了做减法只放和目标直接相关的信息无关的背景一律删掉。比如生成登录页用例就不需要把订单模块的代码放进去。信息密度的另一个体现是范例的质量。放两个写得好的现有用例比放十个写得一般的用例效果好得多。AI会模仿范例的风格和结构范例质量直接决定输出质量。5.2 AI生成的用例必须跑一遍再入库这一点我吃过亏。有一次批量生成了80条用例看着都挺像样直接入库了。结果下次回归时发现其中20多条根本跑不通有的是选择器写错了有的是断言逻辑有问题。从那以后我定了个规矩AI生成的用例必须实际执行通过才能入库跑不通的要么修复要么丢弃。这个规矩看起来增加了工作量但实际上避免了更大的麻烦。一条坏用例混在用例库里每次回归都要浪费时间去排查长期成本远高于入库前的一次验证。5.3 选择器策略决定了用例的寿命Playwright支持多种选择器但它们的稳定性差异很大。我总结了一个优先级getByRole最稳因为它基于无障碍角色前端改样式不会影响它getByLabel和getByText次之只要文案不变就没事getByTestId需要开发配合加属性但一旦加上就很稳定CSS选择器和XPath最脆弱能不用就不用。在提示词里明确这个优先级AI生成的选择器质量会好很多。我还会在代码审查阶段检查选择器类型发现用了位置选择器的直接打回重写。5.4 不要让AI碰业务逻辑判断我试过让AI判断一个失败用例到底是缺陷还是用例问题。结果它经常把业务逻辑上的差异误判为用例问题。比如某个按钮在特定权限下应该隐藏AI看到按钮不可见就认为是选择器问题实际上这是正确的业务行为。后来我把这类判断收回来自己做AI只负责提供日志摘要和分类建议。业务逻辑判断必须由了解需求的人来做这一点AI替代不了。5.5 提示词需要版本管理提示词是会迭代的。随着项目变化、AI模型更新、团队规范调整提示词也要跟着改。我建议把提示词当成代码一样管理放在git仓库里每次修改记录变更原因。这样当输出质量下降时可以回溯是哪个版本的提示词、配合哪个模型效果最好。我现在的做法是每个提示词文件头部写清楚适用场景、最后更新日期、以及已知的局限性。团队里其他人用的时候能快速判断是否适合自己的场景。5.6 成本控制不是所有环节都值得用AIAI调用是有成本的包括token费用和时间开销。我算过一笔账用例生成环节用AI每条用例平均节省15分钟人工时间非常划算但简单的选择器替换用sed命令批量处理可能比调AI更快。所以我把AI用在那些需要理解语义的环节纯机械的替换用脚本解决。另外大模型的响应时间也要考虑。如果一条提示词要等30秒才返回结果那批量处理100条用例就是50分钟这个时间成本要算进去。我的做法是把能批量的任务合并成一次调用减少往返次数。6. 回归测试提效的边界与后续演进方向6.1 三个小时的构成与进一步压缩的空间现在的三小时里实际测试执行占了大约两小时AI处理占40分钟人工审核占20分钟。要进一步压缩执行时间是大头。我目前在尝试的方向是用例分片和增量执行——只跑受变更影响的用例而不是全量回归。这需要更精准的变更影响分析也是AI可以继续发力的地方。另一个方向是失败重试的智能化。现在flaky用例的重试是盲目的重试一次不行就标记失败。如果能让AI根据失败日志判断是否值得重试可以节省不少时间。6.2 什么情况下AI提效会打折扣AI不是万能的。在几种情况下提效效果会明显下降。一是页面结构极度不稳定选择器天天变AI修复的速度赶不上变化的速度。二是业务逻辑极其复杂AI生成的用例覆盖不到关键路径需要大量人工补充。三是测试环境本身不可靠失败原因大多是环境问题AI分类也帮不上忙。遇到这些情况我的建议是先解决根本问题。页面不稳定就先推动前端加testid环境不可靠就先修环境。AI是放大器不是万能药。6.3 从回归测试延伸到更广的测试自动化这套提示词驱动的方法其实不限于回归测试。冒烟测试、接口测试、甚至性能测试的脚本生成都可以用类似的思路。核心逻辑是一样的给AI足够的上下文和明确的约束让它产出可用的测试资产人工做最终把关。我最近在尝试把这套方法用到接口自动化测试上用OpenAPI文档作为上下文让AI生成pytest的接口测试用例。初步效果不错生成效率比手写高很多准确率也在可接受范围内。6.4 团队协作中的提示词共享与规范统一一个人用AI提效不难难的是让整个团队都用起来并且效果一致。我的做法是建了一个提示词库按场景分类存放每个提示词都有使用说明和效果评价。新成员入职时先学提示词库再上手写用例。这样能保证团队输出的用例风格统一、质量稳定。另外我们每周会做一次提示词复盘把本周遇到的新场景、新问题、以及对应的提示词调整记录下来。这个习惯坚持了几个月提示词库越来越丰富覆盖的场景也越来越全。说到底AI在回归测试里的价值不是替代测试工程师而是把测试工程师从重复劳动里解放出来让他们有精力去做更有价值的事——设计更好的测试策略、发现更深层的缺陷、推动质量内建。工具在变但测试的核心目标没变用最小的成本给产品质量提供最大的信心。