用AI提示词把回归测试从3天压缩到3小时

把回归测试从3天压到3小时不是靠买机器不是靠换更快的CI靠的是一套能稳定复用的AI提示词。你可能觉得这个标题有点夸张先交代一下背景我们有个核心业务系统单次发版前要跑四百多条回归用例涉及三个服务、两组数据库、十几个定时任务。以前测试同事每次发版前都要提前三天手工筛用例、造数据、对着日志猜原因真正花在“执行”上的时间其实很短耗掉时间的是大量重复的筛选、准备和定位。这次我把整个链路改造了一遍筛选、数据准备、失败分析这三块全部交给大模型配合原来已有的执行平台保留人工复核。文里会先拆一下三天的时间到底花在哪接着讲提示词的设计逻辑把三套可以直接抄走的提示词全贴出来再说落地链路和踩过的坑。如果你是测试、开发或者带测试团队这套东西基本可以迁移过去对照使用。1. 回归测试的“3天”到底消耗在哪1.1 400条用例背后的三类重复劳动我第一次看到这个系统的回归排期时心里是有点发怵的三百多个接口四百多条回归用例每次都要动库存、订单、支付状态。这类数据一旦造错后面所有断言全部作废测试等于白跑。真正让我决定引入AI的不是用例数量多而是有三个环节几乎完全靠人肉硬扛。第一是用例筛选。产品需求写得很粗测试同学每次都要靠记忆把“这次改了哪段逻辑”映射到“哪些用例可能受影响”。老测试能凭感觉圈出范围新同事就只能把整个用例库跑一遍图个安心。你要知道四百条用例全跑和跑两百条执行时间能差出一倍更不用说环境资源的占用。第二是测试数据准备。库存要对应不同状态订单要有不同生命周期退款要凑出边界金额。人工补数很容易出现两种情况要么漏了某个关联字段导致用例跑到一半断言失败要么数据跟历史数据重复把环境搞脏。数据一旦脏了后面所有用例都会跟着误报排查成本成倍增加。第三是失败定位。晚上十点冒出一条失败用例真正熟悉这块业务的人可能已经下班了。值班的人要么把日志截图发到群里等第二天要么凭经验试着调两个接口猜不出来就重跑重跑过了就当没发生。问题在于重跑通过不等于缺陷不存在这个动作反而会把真正的回归问题掩盖掉。这三件事有一个共同特点大量信息检索、比对、判断但几乎没有复杂的创造性设计。大模型在处理文本归纳、分类、生成模板化内容这些事上恰好落在这个能力区间里。所以我当时的判断是不动业务代码不加测试框架就把这三个重复劳动环节用AI接管。1.2 把三天拆成一张工时账单先给一张我在改造前记录的工时分布表方便你对“3天”有一个更具体的概念。环节改造前大约耗时主要动作AI介入后耗时回归用例筛选6小时左右人工比对代码变更与用例库10到15分钟测试数据准备6小时左右SQL补数、环境校准、数据清理20到30分钟执行与排队等待4小时左右串行排队、环境重启、重试1小时左右失败日志分析8小时左右翻日志、找人确认、反复重试1.5小时左右回归报告汇总2小时左右复制结果、整理截图、发邮件20分钟左右这还是在一切顺利的前提下。遇到环境挂掉、半夜失败、回归区的数据被另一条任务污染每出现一次都会额外吃掉半天。所以三天这个数字一点也不夸张甚至有时候还不止三天。拆开以后你会发现真正的用例执行时间可能只占一天不到剩下两天多都耗在了“等”和“查”上。压缩时间的核心不是把用例跑得更快而是把这两天的“等”和“查”砍掉。2. 压缩的核心逻辑不给AI写代码的机会只让它做判断与组织2.1 为什么把边界划在“判断”而不划在“执行”最开始我也踩过“让AI写用例代码”这个坑。直接让模型生成一套完整的测试脚本看起来特别爽但实际上一旦业务逻辑复杂有深循环、有回调、有异步处理它生成的代码比手写的还难维护。更麻烦的是你很难判断它生成的代码到底对不对最后还是要人一行一行读省的功夫又还回去了。后来我想明白一件事回归测试这个场景里AI最适合做的事情是把“人来回翻文档、翻代码、翻日志”的过程压缩掉而不是直接替代执行动作。换句话说我只让AI产出中间结论——用例清单、数据参数、可疑日志位置最终是否采纳由测试人员做决定。这样即便AI判断错了一两个点人工复核成本也非常低不会造成破坏性后果。这里有一个我到现在还在用的原则凡是允许出错的环节交给AI凡是不能出错的环节留给人。用例筛选错了最多是多跑几条或者漏跑一条风险可控测试环境被AI改错了全组都要跟着遭殃这种事不能让它碰修复方案写错了上线直接崩更不能让它自己决定。所以这套提示词全部围绕“分析”和“建议”设计没有一个提示词是做环境变更或代码热修复的。2.2 提示词的四个信息块角色、上下文、输入、约束很多人写提示词喜欢把需求揉在一句话里比如“你是一个测试专家请帮我筛选用例这是代码差异下面是用例列表”。模型不是不能处理但输出质量很不稳定。我后来把提示词固定成四个信息块效果明显稳定很多。第一块是角色定义。每个提示词只让模型承担一个职能筛选就是筛选造数就是造数分析就是分析。不要让它同时做三件事多职能输出会让结果互相干扰。第二块是上下文。系统背景、变更内容、目标规则都写在前面相当于给模型一个明确的知识背景。第三块是输入数据。用分隔线把测试用例列表、日志片段括起来告诉它“以下是输入内容”避免它把输入内容当成要执行的指令。第四块是输出约束。规定输出格式、禁止行为、遇到未知情况时如何处理。这四块结构就像是给模型设路标。尤其当上下文特别长的时候结构化输入比无序文本可靠得多。模型很容易被中间某段无关内容带偏有了分隔线它才知道哪些是背景哪些是真实要处理的数据。3. 三套提示词全公开3.1 第一套回归用例筛选提示词这是整个改造里最核心的一套提示词。它要做的事情是从四百条用例里筛出本次发版真正需要回归的范围。你是资深回归测试负责人负责对一次常规发版进行回归用例筛选。 下面是本次变更的代码文件、变更说明和现有回归用例库索引。 本次变更 {变更内容包括涉及服务、接口、数据表} 代码文件 {文件列表} 回归用例库 {用例编号 一句话描述 涉及模块} 请完成以下任务 1. 分析变更影响到的业务链路 2. 从用例库中选出必须回归的用例 3. 标出潜在的风险点和对应用例 4. 给出不需要跑的用例及其原因。 输出格式 | 用例编号 | 是否必跑 | 关联链路 | 原因 | 约束 - 只允许减少明确与本次变更无关的用例 - 没有把握的用例一律保留 - 不要输出模型推理过程直接给结论 - 如果变更信息不足直接说“信息不足”并列出需要补充的信息。这套提示词有三个设计点很关键。第一是“没有把握的用例一律保留”这直接解决模型漏筛的问题。第二是“只允许减少明确与本次变更无关的用例”让模型从保守角度做减法而不是激进地做加法。第三是“直接说信息不足”让它在信息不完整的时候敢于承认而不是硬编一个结论出来。实际跑下来模型给出的必跑用例范围基本能压到原用例集的六到七成漏筛率在人工复核后可接受。3.2 第二套测试数据生成提示词数据准备是最容易被人忽略但实际最耗时的事。这套提示词用来生成参数化数据配合已有的测试数据工厂工具落地。你是一个测试数据构造器按约束生成可用于回归测试的参数化数据。 字段约束 {例如订单状态、金额、库存、时间范围} 业务规则 {例如退款金额不能超过订单金额时间字段随当前时间动态生成} 请生成{n}组数据要求 1. 覆盖正常值、边界值、异常值 2. 同组数据之间的字段要保持业务关系一致 3. 不同组之间不要重复 4. 不要包含真实的身份证、手机号、地址等个人信息。 输出格式 | 用例编号 | 字段1 | 字段2 | 字段3 | ... | 只输出表格不要输出解释。若某条规则有矛盾请说明矛盾点不要自行假设。注意这里我没有让AI直接去改数据库只是让它生成数据参数表。真实的数据写入动作还是走我们已有的数据工厂这样即使AI生成的数据有问题也不会污染环境。关于“不要包含真实个人信息”这一条不仅是合规要求也是为了避免测试数据流入日志系统造成不必要的麻烦。业务规则冲突时要求它说明矛盾点而不是自行假设这一点能帮你提前发现测试设计本身的问题。3.3 第三套失败日志分析提示词失败分析是回归测试中最消耗人工的部分。这套提示词的作用是把一条失败用例的日志和代码片段喂给模型让它输出一个带嫌疑等级的分析结论。你是测试失败分析助手。下面是某条回归用例执行后的日志片段和对应代码片段。 日志 {最近500到1000行日志} 代码片段 {与失败相关的代码} 请输出 1. 嫌疑等级P0阻断发布/ P1高概率根因/ P2值得排查/ P3噪音 2. 关键报错摘要从日志原文中摘抄不允许改写或补充 3. 与本次变更的关系有关/无关/不确定 4. 建议下一步动作例如“检查XX服务的连接池配置”“重跑该用例”“联系XX模块负责人”。 约束 - 禁止引用日志和代码片段之外的信息 - 禁止为了凑结论而凭空补充错误 - 如果信息不足直接写“信息不足”并列出还需要哪些日志或数据。这里最关键的是两条约束“关键报错摘要必须从原文摘抄”和“禁止引用日志之外的信息”。模型在训练语料里见过大量相似错误很容易把常见报错模式套到你这条用例上然后给你编一个看起来合理、实际上日志里根本不存在的错误。加了这两条约束以后它的输出质量稳定很多。另外我给每个嫌疑等级定义了明确的标准P0就是阻断发布P1就是高概率根因这样测试同事拿到结论后能直接做决策不需要再追问“这个错到底有多严重”。4. 从3天到3小时的落地链路4.1 实际执行流程六个环节有了三套提示词之后下一步就是把它们串成一条可执行的流程。我在项目里最终跑的链路是这样先从CI系统拉取本次变更的代码差异和用例库索引喂给第一套筛选提示词生成“必跑清单”。人工花10分钟扫一遍把明显不对的去掉确认后锁定本次回归范围。用第二套数据生成提示词生成参数表导入已有的测试数据工厂。导入之前先备份环境初始状态方便跑完以后回滚。把必跑用例推入执行队列多台执行机并行跑。原来串行要花四小时的用例分到三台机器之后大约一小时能完成。执行过程中失败用例自动抓取日志截取最近500到1000行再喂给第三套失败分析提示词。P0级别的失败自动推到IM群里不用等第二天。全部跑完后把各模块的通过率、失败原因、AI分析结论汇总成一张表。人工确认那些P1级别的失败项其他级别的交给对应模块负责人跟进。最后做一次复盘把AI漏筛或误判的用例记录下来反馈到提示词模板里沉淀成历史回归记录。这个流程不是全自动的但它把人的注意力从“所有事情”收窄到“少数关键判断”。前两步人工确认只花十分钟第四步只处理P0和P1级别的问题其他时间不用人盯。整体算下来三小时是真实可复现的。4.2 为什么输入可以临时变提示词框架必须固定这里有一个很容易忽略的细节AI的输入每次都会变比如这次的日志不同、下次的用例不同但提示词框架不要轻易改。我见过有人每次都重新写一遍提示词结果模型的输出风格也跟着来回变脚本解析经常出问题。我现在把三套提示词维护在测试知识库里和测试用例一样纳入版本管理每次改动都走评审。固定模板还有一个好处就是方便积累历史数据。比如第一套筛选提示词里我会把过去三次发版中“AI判断不需要跑、但实际上出了问题”的用例记录追加进去。模型每次筛选用例时看到这些反例就会更谨慎。这个不是靠模型自己记住而是靠你把经验固化到提示词里。从成本角度看这套模板也不怕重复使用。固定模板的token消耗很低真正贵的是每次变化很大的输入数据但即便加上这些跑一轮回归的整体模型调用成本也远低于人工干三天的成本。关键是结果可控输出风格稳定才能让脚本稳定解析。5. 踩过的坑幻觉、漏筛与格式漂移5.1 模型会一本正经地补充日志里没有的错误印象最深的一次一条数据库锁等待超时的用例模型给出的分析结论是“可能是缓存策略导致的”。但日志里根本没有缓存相关的任何报错它只是在训练资料里见过大量类似的锁等待案例就把常见根因套过来了。我们几个同事照着这个方向查了半小时最后才发现是并发线程没有释放连接。这次之后我给所有分析类提示词都加了同一个硬性要求禁止引用日志和代码片段之外的信息否则就回答“信息不足”。加了这条之后模型在缺失信息时会更容易承认自己不知道而不是强行给一个看起来合理的答案。但也要明白加了约束只能降低幻觉概率不能完全消除所以失败分析必须保留人工复核环节不能全信。5.2 筛选阈值调得太高丢掉了一条支付边界用例第一次用AI筛完必跑用例只有原来的60%看着很高效。但我对照本次变更点仔细看了一遍发现一个跨模块的支付边界用例被漏掉了。原因是我在提示词里加了“去掉低频、本轮影响较小的用例”这句话。模型的判断逻辑是“这段代码没改相关用例影响小”但它忽略了那条边界用例虽然本轮没改代码却会受到另一个服务传参变化的影响属于隐性回归风险。后来我把规则改成“只允许减少明确与本次变更无关的用例”和“没有把握的用例一律保留”。从那以后漏筛的情况少了很多。一个经验是AI筛选的目标是让你从四百条减到两百五十条而不是从四百条减到一百五十条。宁可多跑一点也别把风险漏掉。5.3 输出格式漂移比答错更可怕用了一段时间后模型有一次升级同样一段提示词它开始把表格输出成非表格结构或者偶尔在表格后面补一句解释性的话。我的解析脚本直接崩了。这个问题比答错更麻烦因为答错只是单个结论有问题格式崩掉意味着整条链路断掉所有后续处理都得停下来。我做了两件事。第一在所有提示词的输出约束里都写明“只输出表格不要输出任何解释”。第二解析脚本加了一个兜底逻辑一旦解析失败自动把这次请求重新排队并记录当时的输入和输出方便定位。这样跑了一段时间后整体解析稳定率保持在比较高的水平。另外提醒一句不要依赖模型记住之前的对话每次提问都把上下文带全。模型记性不可靠一旦对话历史被截断它就可能给出前后矛盾的结果。6. 实际效果、成本与适用边界6.1 三小时里的时间构成改完以后我记录了一轮典型发版的完整耗时环节耗时说明用例筛选约10分钟AI产出清单人工扫一遍确认数据准备约20分钟AI生成参数表数据工厂导入并行执行约30分钟到1小时多机并行已有执行平台承担失败分析约1.5小时AI先分析人只处理P0和P1报告汇总约20分钟AI生成表格人工签名合计约三小时。需要说明的是这三小时不是模型单独完成的而是“AI输出加人工复核加原有执行平台”的总时长。不要把它理解成完全无人值守。人工复核虽然还在但时间成本已经大幅减少。过去人工要把每个失败都翻一遍日志现在只需要看AI标注的P0和P1级问题效率自然不一样。6.2 这套东西能适配什么样的团队先讲限制。这套玩法最适用的场景是几百条用例、测试数据有规律、日志结构清晰的中型业务系统。如果你的用例只有二三十条手工筛用例和准备数据本来就不慢没必要上AI。如果你的系统是几万条用例的微服务全链路建议先从单个模块开始试点不要在第一天就铺到全量。团队方面至少要有一个人能读懂模型的输出内容并且能判断它是不是在胡说。如果团队里完全没有人对AI产出的质量负责更快的筛选只会更快放大错误漏一条关键用例的后果比跑三天更严重。我见过完全没有代码背景的测试同学把模型当搜索引擎来用配合固定的提示词模板也有不错的效果但前提是模板由懂业务的人维护而不是临时拼凑。成本方面大模型调用费用其实很可控。一轮回归涉及的数据量三套提示词并发跑下来按主流几家大模型服务的公开价格算也就几杯咖啡的钱对比三个人干三天的成本可以忽略不计。7. 如果你也想复刻我的三点建议7.1 先拿三个小样本跑一周别急着全量替换我强烈建议从一个小模块开始比如只拿三十条用例跑一周试点。每天把AI结论和人工结论放在一起对比记录它们分歧在哪里。一周之后你自然会知道模型在你这个系统里最容易在哪种场景下犯傻然后再决定要不要铺开。前面说过这套方案失败的人多数是第一天就全量接入结果遇到一次事故就退回老路。小范围试运行本质上是为了让你提前摸清模型的脾性。7.2 提示词也做版本管理和用例一起评审我现在把三套提示词放在测试知识库目录里和测试用例放在同一个仓库。每次改提示词就是一次代码提交。这样做的好处是当模型升级导致输出风格变化时你可以直接通过diff找出是哪一条规则引起的。我也把每次失败的典型案例追加到提示词尾部作为少样本示例。实际证明给模型一两个具体例子比反复强调“你要认真分析”要管用得多。7.3 永远保留一个人工审核岗这个“人审岗”不一定是专职但一定要有明确的人来承担。他的工作不是重复AI的活不是把四百条用例再看一遍而是专门盯那些AI给出的“说法”是否符合业务逻辑。我在实际使用中发现有一个人专门做最终复核比让团队所有人都信任AI、但没人收敛结果要可靠得多。这个人不需要多一个就够但他必须熟悉业务链路能够在AI给出错误结论时及时踩刹车。这套方法最打动我的地方不是省了多长时间的排序问题而是把测试团队从低水平重复劳动里解放出来了。以前大家下班前都在盯日志、刷状态、等重跑结果现在更多时间在讨论业务逻辑和梳理链路。跑通第一轮的时候测试同事还不太敢信三小时的结果连续跑了两三个版本以后才慢慢接受。如果你也准备用这套东西建议你从最小范围开始先让AI在你的系统上证明一次再谈扩大边界。