最近朋友圈被三个消息刷了屏GLM-5 正式发布、MiniMax M2.5 进入内测、DeepSeek 把上下文窗口灰度放到了 1M token。做软件测试的朋友跑来问我说这些大模型动态看着挺热闹可跟我们天天写用例、提 bug、跑回归到底有什么关系我的回答是关系比你想象的大得多而且这次不是AI 辅助写用例这种小打小闹是测试的整个工作方式要换一批新工具的问题。这篇文章不聊模型榜单也不做厂商夸夸就站在软件测试从业者的角度把这几个消息拆开看它们到底改了什么、测试工作流里哪些环节会最先变、现在能落地的实操路径是什么、以及有哪些坑是我实际踩过之后想提醒你的。无论你现在是手工测试为主还是已经在搞自动化平台这篇内容都值得花十分钟读完。1. 三个大模型动态到底在释放什么信号1.1 GLM-5 发布和 MiniMax M2.5 内测不只是又出新模型先说 GLM-5。这几年国产大模型的迭代节奏基本是半年一个大版本GLM-5 这次发布最核心的变化不是参数规模又大了多少而是推理能力和指令遵循的稳定性上了一个台阶。对测试行业来说这意味着什么意味着你让它按照指定格式输出测试用例、缺陷报告、接口测试数据的时候它的配合度变高了。以前你可能要反复调 prompt 才能让它稳定输出 JSON现在一次给对格式规范基本就能直接拿结果去灌进自动化框架里跑。MiniMax M2.5 内测一般关注 AI 应用的人会把它理解成又多了一个对话模型。但如果你从工程视角看它的看点在于多模态能力和长文本处理上的侧重。软件测试的物料远不止代码和需求文档还有页面截图、接口返回报文、日志堆栈、录屏回放。过去这些信息是割裂的你要靠人肉去把截图现象 日志报错 接口返回拼成一条完整缺陷链路。如果模型本身具备更强的多模态理解能力那么给它一张报错截图加一段日志让它直接给出初步定位结论这类场景就会变得非常实用。这对测试的价值是实打实的效率提升。1.2 1M 上下文是什么意思它解决的是测试人的老难题1M 上下文是什么意思这个问题我最近被问了很多次。通俗解释1M token 的上下文窗口意味着模型在单次对话里能记住的信息量大约是一百万个 token折算成中文大概是几十万到上百万字换算成代码文件大约是几万到十几万行。你可以一次性把一个中型项目的核心代码目录、全套接口文档、甚至一批历史缺陷报告全部塞给模型而不需要做切片、摘要、分段喂入这些繁琐操作。为什么要专门说这个因为软件测试恰恰是需要同时看大量上下文的工种。你分析一个线上问题的时候要同时看需求文档、代码实现、测试用例、历史 bug、当前日志这些材料加起来经常超过普通模型的记忆上限。以前做大模型辅助测试最大的尴尬是单个文件太长模型记不住你只能拆碎了分批问结果就是模型总是丢前忘后。1M 上下文灰度放量等于把这个最大的限制往前推了一大步。注意DeepSeek 这次是灰度不是全量开放但方向已经确定了——长上下文不再是大模型的稀缺资源。1.3 三个信号叠加在一起为什么要警惕的不是失业而是落后把这三件事放在一起看你会发现一个共同点大模型正在从搜索式问答工具转向可嵌入工作流的工程组件。GLM-5 提升的是执行稳定性MiniMax M2.5 补的是多模态感知能力DeepSeek 1M 上下文解决的是大规模信息处理问题。这三个能力单看都是自然语言处理范畴的升级但合在一起它们恰好覆盖了软件测试工作流里最耗费人力的三件事写文档、看现象、翻历史。我见过很多测试朋友现在的态度是AI 再强也替代不了我点点点。这话放在两年前没毛病但放在现在我更愿意换个说法AI 确实不会一夜之间替代测试工程师但会用 AI 的测试工程师会替代不用 AI 的测试工程师。因为这三个能力组合起来已经足够把测试环节里 70% 以上的信息搬运类工作自动化掉剩下需要人做的是对业务的判断和对质量风险的权衡。这不是焦虑贩卖是我最近半年在真实项目里反复验证过的结论。2. 软件测试工作流里最先被改写的四个环节2.1 需求分析和测试设计的输入方式彻底变了传统测试流程里需求分析靠的是人肉读文档。一个大型迭代PRD 几十页交互稿几十张测试要自己抽取出功能点列表—正常路径—异常路径—边界条件再转写成测试用例。这个过程非常慢而且非常依赖个人经验。现在有了长上下文和多模态模型做法可以完全不一样。我最近在项目里试过把一份 40 多页的 PRD 和十几张原型图直接丢给模型让它输出三样东西功能点清单、风险点清单、按优先级排列的测试设计建议。实测下来的效果是功能点提取的完整度能达到老测试工程师人工梳理的 80% 以上而耗时从一两天压缩到半小时以内。剩下的时间不是省下来摸鱼而是去补模型漏掉的那些业务潜规则和历史包袱。2.2 用例生成从模板复用进化到场景推理以前用 AI 生成测试用例基本是套模板你给我一个登录功能我还你一套用户名空、密码空、格式错误、账号锁定的标准八股。这种生成的用例有用但价值天花板很低因为它不懂你的业务。现在的情况不一样了。模型能读你完整的接口文档、数据库表结构、上下游调用关系生成的用例会更接近场景推理。比如你让它针对订单超时未支付自动关闭这个需求生成用例它能结合你给的完整业务代码逻辑推演出支付回调与超时任务并发库存释放与优惠券回滚关闭通知发送失败这类真正容易出问题的场景。这才是测试设计该有的样子。我自己实际跑下来模型生成的边界场景里有大概三到四成是团队里 Junior 测试想不到的这已经很有参考价值了。2.3 缺陷分析和问题定位从看日志猜变成给材料出结论软件测试里最耗时的事情不是发现 bug而是把 bug 描述清楚并推动开发修对。一个高质量的缺陷报告需要把前置条件、操作步骤、实际结果、期望结果、影响范围、可能的根因方向都写清楚。过去写一份这样的报告要来回切换截图工具、日志平台、接口测试工具收集齐材料再组织语言半小时起步。大模型在这里的用法是信息汇聚和初判。我现在的习惯是遇到一个疑似缺陷先把接口返回、前端截图、后端异常堆栈分别丢给模型让它做一次交叉分析。它能很快指出从断言看是 status 字段与文档定义不一致具体到代码层面可能出现在 xx 模块的序列化逻辑里。开发拿到这种报告不需要再从零开始问你当时怎么操作的直接进入排查状态。单条缺陷的处理时长实测缩短了差不多一半。2.4 回归测试和测试数据准备长上下文的用武之地回归测试最烦的是什么是你不知道这次改动到底会影响哪些模块。传统的做法是让资深测试凭经验圈定回归范围或者干脆全量回归——耗时且浪费。现在可以把本次代码变更 diff 全量接口文档 历史用例库一次性丢给模型让它基于变更内容推断受影响的接口和用例范围。我试过一次模型圈定的范围跟人工评估结果的重合度很高而且它还能指出一些容易被忽略的间接影响面比如公共工具类的改动可能影响到的下游模块。测试数据准备也一样。造数据以前靠 SQL 脚本硬怼现在跟模型对话告诉它表结构、字段含义、想要的业务状态它直接给你生成可执行的造数脚本。几个晚上加班造数据的活儿变成一个小时的对话和微调。3. 实操把大模型接进测试工作流的三个落地场景3.1 落地场景一用模型 API 做缺陷报告的自动分类和标签化先给一个最简单、最容易见效的场景缺陷报告自动分类。很多团队的缺陷管理系统里堆了几万条历史 bug但标签混乱、模块归属不清想做数据统计分析根本没法下手。用大模型的 API 做一次历史数据清洗是最低成本的切入点。操作步骤很简单。把缺陷标题、描述、复现步骤拼成文本调用模型接口让它输出 JSON 格式的分类结果包含所属模块、缺陷类型、优先级建议、可能根因。注意这里的关键是让模型输出结构化内容方便后续处理。以下是我在项目里实际用过的 Python 脚本骨架基于 OpenAI 兼容接口封装DeepSeek 的 API 也走同样的协议改一下 base_url 和 key 就能跑import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1 # DeepSeek 兼容 OpenAI 协议 ) def classify_bug(title, desc, steps): prompt f 你是一名资深的软件测试工程师。请对以下缺陷报告进行分类。 要求只输出 JSON不要输出任何解释性文字。 JSON 格式如下 {{ module: 模块名称, type: 功能缺陷/接口异常/性能问题/兼容性问题/其他, priority: P0/P1/P2/P3, root_cause_hint: 可能的根因方向 }} 缺陷标题{title} 缺陷描述{desc} 复现步骤{steps} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object} # 强制结构化输出 ) return json.loads(resp.choices[0].message.content) # 读取缺陷列表批量处理结果写回 CSV 或数据库这段代码的思路是先定义好输出格式约束然后用低温参数保证输出稳定性。实测下来几万条历史缺陷的分类准确率在人工抽检里能达到 85% 以上剩下的 15% 基本是模块边界模糊导致的误判人工快速复核一下即可。它的收益不只是标签好看了而是你终于可以回答老板那个经典问题我们这个季度最常见的缺陷类型到底是什么3.2 落地场景二利用长上下文做变更影响分析和回归范围圈定这个场景是 1M 上下文带来的新玩法。以前模型记不住整个项目代码现在可以试试放进去。我刚在团队里实践过的流程是这样的先把核心代码仓库的目录结构和关键模块的代码抽出来加上最近的 git diff组合成一次分析的输入。这里有个实操要点1M 上下文虽然很大但也不是无限大而且输入越长响应越慢、费用越高。所以不是真的把整个仓库几十万行代码全部塞进去而是做一次有损压缩——保留与本次变更直接相关的模块代码、接口定义、公共依赖再配上 dev 环境可访问的接口文档。用代码仓库根目录的执行命令生成变更范围git diff --name-only HEAD~1 HEAD changed_files.txt拿到变更文件清单后配合代码目录结构构造 prompt 让模型输出三部分内容受影响的接口列表、受影响的业务流程、建议回归的测试范围。注意提示词里要明确要求它给出推理依据不要只给结论。这样人工复核时能快速判断模型圈定的范围是否合理。实测效果一次涉及 40 个文件的迭代模型输出的影响范围分析大约 2000 字人工复核耗时十几分钟圈定结果与原来资深测试花半天做出的回归方案高度一致还额外指出了两个被遗漏的关联模块。对于没有资深测试坐镇的团队这个能力等于把经验变成了可调用的服务。3.3 落地场景三用模型批量生成接口测试数据和断言逻辑第三个场景偏向接口自动化。很多团队的接口自动化脚本卡在数据准备太费劲上要测一个订单状态的流转需要先造出各种前置状态的订单数据手工写 SQL 至少十分钟一条。现在可以直接让模型读表结构生成造数 SQL 和对应的接口调用脚本。我自己的实践是把核心业务表的建表语句整理成一份文本让模型针对指定业务状态生成数据构造方案。例如要构造订单已支付待发货的数据模型会根据表结构判断需要插入订单主表、订单商品表、支付流水表并处理好状态字段和关联外键。然后它会输出-- 构造订单已支付待发货状态 INSERT INTO t_order (order_id, user_id, order_status, pay_status, total_amount, create_time) VALUES (TEST20250101001, 10001, 2, 1, 99.00, NOW()); INSERT INTO t_order_item (order_id, sku_id, sku_name, price, qty) VALUES (TEST20250101001, SKU001, 测试商品, 99.00, 1); INSERT INTO t_pay_record (order_id, pay_channel, pay_amount, pay_status, pay_time) VALUES (TEST20250101001, WECHAT, 99.00, SUCCESS, NOW()); -- 注意事项需同步更新 t_order 的 pay_time 字段否则部分查询逻辑会查不到支付记录这个场景的诀窍不是让模型写 SQL而是让模型理解业务状态背后的数据约束。生成完 SQL 后我建议先在一个独立的测试库里跑一遍验证确认状态流转正常再收进自动化用例。因为模型偶尔会漏掉某个业务表的更新时间戳或冗余字段直接在流程里才发现就晚了。4. 测试人必须知道的常见坑和应对策略4.1 模型输出不稳定别让它自由发挥给它框架很多测试朋友第一次用大模型辅助工作最崩溃的就是它上次这么回答这次换个说法。这个问题的根源不是你运气不好而是你没有给模型加约束。处理办法有四个一是要求输出 JSON 并锁定 schema二是给 few-shot 示例在 prompt 里直接放一个你期望的输入输出对三是把 temperature 降到 0牺牲一点创造性换取稳定性四是做一层代码校验解析失败就重试一次。不要嫌这些步骤麻烦。在一个工程化的工作流里模型的输出不应该被当成人话来看而应该被当成可能需要清洗的数据源。你花十分钟把这些校验逻辑写好后面每次调用都省心。我见过太多团队卡在这一步就放弃了其实多写十行代码就能解决。4.2 长上下文的两大隐形问题幻觉放大和成本失控1M 上下文是一把双刃剑。输入的信息越多模型就越容易在某个细节上一本正经地胡说八道。尤其是当你的代码仓库里本身存在一些历史遗留的、已经不生效的逻辑时模型会把它们当成有效逻辑来分析得出一个看起来很有道理、实际上错误的结论。这就是长上下文的幻觉被放大问题。应对策略永远要求模型在关键结论后面标注依据并限定它只依据提供的材料回答不要引入外部知识。另外对于影响范围这种重要结论建议让模型输出置信度打分低置信度的部分人工重点复核。成本问题更直接。1M 上下文的输入费用远高于普通对话把几十万 token 的代码整包灌进去跑一次分析的成本可能是日常对话的几十倍。我的做法是先浓缩再分析先用普通模型对代码目录做一轮摘要把每个模块的核心职责压缩成几百字再把摘要作为上下文。这样既能利用长上下文带来的全局视角又不会让账单爆炸。这个方案适合预算有限的团队。4.3 别把所有测试都交给模型这四类任务必须保留人工我踩过最大的坑是有一段时间为了追求效率把线上问题定性这类高风险分析也交给模型判断。结果它给了个看起来很专业的结论实际上完全跑偏幸亏在推给开发之前被资深同事拦下来确认了一次。从那之后我给自己定了一条规矩模型可以给建议但凡是影响发布决策、客户赔偿、安全合规的结论必须有测试专家复核签字。具体来说这几类任务不要迷信模型第一线上紧急故障的根因判断时间窗口太短你来不及验证模型的推理依据第二涉及法规合规的测试结论比如支付、隐私数据相关的必须人工确认第三需要主观体验判断的测试比如 UI 美观度、交互手感模型给不了可信的结论第四测试用例的最终审核确认模型生成的用例永远是草稿而不是基线。4.4 工具链选型API 直调还是用编排框架我的真实建议现在社区里很多人讨论要不要引入deepseek harness这类工具链来编排模型调用流程。我个人的看法是小步快跑别过度工程化。如果你的团队只是想在测试工作流里尝鲜直接用 API 写几十行脚本就够用。等确认了场景价值、积累了稳定可复用的 prompt 模板之后再考虑引入外部编排框架来管理多步骤任务。原因是测试团队的核心痛点从来不是没有工具而是没有想清楚自己要什么。工具链能帮你管理 prompt、串联多轮调用、做缓存和重试但它也带来了新的维护成本和学习成本。一开始就把流程叠得太重很容易让整个团队陷入工具本身的调试里反而耽误了真正的业务分析。我的建议始终是先用最简单的脚本验证一个场景的 ROI再逐步加大投入。还有一点一定要提醒的是不要忽视私密数据的合规边界。测试环境里往往有大量业务敏感数据把代码、数据库 schema、真实用户信息直接传给第三方模型接口存在不小的合规风险。团队在接入前最好先确认数据脱敏方案和接口调用层面的权限隔离。对于一些严格要求数据不出内网的企业建议评估私有化部署或本地模型方案不要为了图省事走公网 API。另外在工程侧新入职的测试同学如果会 Python、了解模型 API 调用的基础写法在团队里的定位会明显不一样。这不是让你转行做开发而是让你有能力把模型当测试工具链的一环来使用。未来半年到一年我认为懂业务 会测试设计 能调模型的复合能力会是测试行业最值钱的组合。如果你还停留在只会点点点那确实应该有一点危机感——但危机感的方向不是AI 抢我工作而是我还没开始用 AI 改进我的工作。我这半年把这三个模型能力陆续接入到测试流程之后最大的体感变化就是机械重复的活变少了需要脑子的活变多了。以前每天要花大量时间在信息搬运和格式整理上现在这部分时间被压缩到很小更多精力可以投入到真正影响质量的风险判断上。这才是软件测试工作该有的样子。所以回到标题的提问——软件测试要变天了吗我的答案是天确实在变但变出来的不是末日而是一套新的工作方式。早一步接住它的人后面会走得更轻松。
大模型新能力如何重塑软件测试工作流：从GLM-5到1M上下文
最近朋友圈被三个消息刷了屏GLM-5 正式发布、MiniMax M2.5 进入内测、DeepSeek 把上下文窗口灰度放到了 1M token。做软件测试的朋友跑来问我说这些大模型动态看着挺热闹可跟我们天天写用例、提 bug、跑回归到底有什么关系我的回答是关系比你想象的大得多而且这次不是AI 辅助写用例这种小打小闹是测试的整个工作方式要换一批新工具的问题。这篇文章不聊模型榜单也不做厂商夸夸就站在软件测试从业者的角度把这几个消息拆开看它们到底改了什么、测试工作流里哪些环节会最先变、现在能落地的实操路径是什么、以及有哪些坑是我实际踩过之后想提醒你的。无论你现在是手工测试为主还是已经在搞自动化平台这篇内容都值得花十分钟读完。1. 三个大模型动态到底在释放什么信号1.1 GLM-5 发布和 MiniMax M2.5 内测不只是又出新模型先说 GLM-5。这几年国产大模型的迭代节奏基本是半年一个大版本GLM-5 这次发布最核心的变化不是参数规模又大了多少而是推理能力和指令遵循的稳定性上了一个台阶。对测试行业来说这意味着什么意味着你让它按照指定格式输出测试用例、缺陷报告、接口测试数据的时候它的配合度变高了。以前你可能要反复调 prompt 才能让它稳定输出 JSON现在一次给对格式规范基本就能直接拿结果去灌进自动化框架里跑。MiniMax M2.5 内测一般关注 AI 应用的人会把它理解成又多了一个对话模型。但如果你从工程视角看它的看点在于多模态能力和长文本处理上的侧重。软件测试的物料远不止代码和需求文档还有页面截图、接口返回报文、日志堆栈、录屏回放。过去这些信息是割裂的你要靠人肉去把截图现象 日志报错 接口返回拼成一条完整缺陷链路。如果模型本身具备更强的多模态理解能力那么给它一张报错截图加一段日志让它直接给出初步定位结论这类场景就会变得非常实用。这对测试的价值是实打实的效率提升。1.2 1M 上下文是什么意思它解决的是测试人的老难题1M 上下文是什么意思这个问题我最近被问了很多次。通俗解释1M token 的上下文窗口意味着模型在单次对话里能记住的信息量大约是一百万个 token折算成中文大概是几十万到上百万字换算成代码文件大约是几万到十几万行。你可以一次性把一个中型项目的核心代码目录、全套接口文档、甚至一批历史缺陷报告全部塞给模型而不需要做切片、摘要、分段喂入这些繁琐操作。为什么要专门说这个因为软件测试恰恰是需要同时看大量上下文的工种。你分析一个线上问题的时候要同时看需求文档、代码实现、测试用例、历史 bug、当前日志这些材料加起来经常超过普通模型的记忆上限。以前做大模型辅助测试最大的尴尬是单个文件太长模型记不住你只能拆碎了分批问结果就是模型总是丢前忘后。1M 上下文灰度放量等于把这个最大的限制往前推了一大步。注意DeepSeek 这次是灰度不是全量开放但方向已经确定了——长上下文不再是大模型的稀缺资源。1.3 三个信号叠加在一起为什么要警惕的不是失业而是落后把这三件事放在一起看你会发现一个共同点大模型正在从搜索式问答工具转向可嵌入工作流的工程组件。GLM-5 提升的是执行稳定性MiniMax M2.5 补的是多模态感知能力DeepSeek 1M 上下文解决的是大规模信息处理问题。这三个能力单看都是自然语言处理范畴的升级但合在一起它们恰好覆盖了软件测试工作流里最耗费人力的三件事写文档、看现象、翻历史。我见过很多测试朋友现在的态度是AI 再强也替代不了我点点点。这话放在两年前没毛病但放在现在我更愿意换个说法AI 确实不会一夜之间替代测试工程师但会用 AI 的测试工程师会替代不用 AI 的测试工程师。因为这三个能力组合起来已经足够把测试环节里 70% 以上的信息搬运类工作自动化掉剩下需要人做的是对业务的判断和对质量风险的权衡。这不是焦虑贩卖是我最近半年在真实项目里反复验证过的结论。2. 软件测试工作流里最先被改写的四个环节2.1 需求分析和测试设计的输入方式彻底变了传统测试流程里需求分析靠的是人肉读文档。一个大型迭代PRD 几十页交互稿几十张测试要自己抽取出功能点列表—正常路径—异常路径—边界条件再转写成测试用例。这个过程非常慢而且非常依赖个人经验。现在有了长上下文和多模态模型做法可以完全不一样。我最近在项目里试过把一份 40 多页的 PRD 和十几张原型图直接丢给模型让它输出三样东西功能点清单、风险点清单、按优先级排列的测试设计建议。实测下来的效果是功能点提取的完整度能达到老测试工程师人工梳理的 80% 以上而耗时从一两天压缩到半小时以内。剩下的时间不是省下来摸鱼而是去补模型漏掉的那些业务潜规则和历史包袱。2.2 用例生成从模板复用进化到场景推理以前用 AI 生成测试用例基本是套模板你给我一个登录功能我还你一套用户名空、密码空、格式错误、账号锁定的标准八股。这种生成的用例有用但价值天花板很低因为它不懂你的业务。现在的情况不一样了。模型能读你完整的接口文档、数据库表结构、上下游调用关系生成的用例会更接近场景推理。比如你让它针对订单超时未支付自动关闭这个需求生成用例它能结合你给的完整业务代码逻辑推演出支付回调与超时任务并发库存释放与优惠券回滚关闭通知发送失败这类真正容易出问题的场景。这才是测试设计该有的样子。我自己实际跑下来模型生成的边界场景里有大概三到四成是团队里 Junior 测试想不到的这已经很有参考价值了。2.3 缺陷分析和问题定位从看日志猜变成给材料出结论软件测试里最耗时的事情不是发现 bug而是把 bug 描述清楚并推动开发修对。一个高质量的缺陷报告需要把前置条件、操作步骤、实际结果、期望结果、影响范围、可能的根因方向都写清楚。过去写一份这样的报告要来回切换截图工具、日志平台、接口测试工具收集齐材料再组织语言半小时起步。大模型在这里的用法是信息汇聚和初判。我现在的习惯是遇到一个疑似缺陷先把接口返回、前端截图、后端异常堆栈分别丢给模型让它做一次交叉分析。它能很快指出从断言看是 status 字段与文档定义不一致具体到代码层面可能出现在 xx 模块的序列化逻辑里。开发拿到这种报告不需要再从零开始问你当时怎么操作的直接进入排查状态。单条缺陷的处理时长实测缩短了差不多一半。2.4 回归测试和测试数据准备长上下文的用武之地回归测试最烦的是什么是你不知道这次改动到底会影响哪些模块。传统的做法是让资深测试凭经验圈定回归范围或者干脆全量回归——耗时且浪费。现在可以把本次代码变更 diff 全量接口文档 历史用例库一次性丢给模型让它基于变更内容推断受影响的接口和用例范围。我试过一次模型圈定的范围跟人工评估结果的重合度很高而且它还能指出一些容易被忽略的间接影响面比如公共工具类的改动可能影响到的下游模块。测试数据准备也一样。造数据以前靠 SQL 脚本硬怼现在跟模型对话告诉它表结构、字段含义、想要的业务状态它直接给你生成可执行的造数脚本。几个晚上加班造数据的活儿变成一个小时的对话和微调。3. 实操把大模型接进测试工作流的三个落地场景3.1 落地场景一用模型 API 做缺陷报告的自动分类和标签化先给一个最简单、最容易见效的场景缺陷报告自动分类。很多团队的缺陷管理系统里堆了几万条历史 bug但标签混乱、模块归属不清想做数据统计分析根本没法下手。用大模型的 API 做一次历史数据清洗是最低成本的切入点。操作步骤很简单。把缺陷标题、描述、复现步骤拼成文本调用模型接口让它输出 JSON 格式的分类结果包含所属模块、缺陷类型、优先级建议、可能根因。注意这里的关键是让模型输出结构化内容方便后续处理。以下是我在项目里实际用过的 Python 脚本骨架基于 OpenAI 兼容接口封装DeepSeek 的 API 也走同样的协议改一下 base_url 和 key 就能跑import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1 # DeepSeek 兼容 OpenAI 协议 ) def classify_bug(title, desc, steps): prompt f 你是一名资深的软件测试工程师。请对以下缺陷报告进行分类。 要求只输出 JSON不要输出任何解释性文字。 JSON 格式如下 {{ module: 模块名称, type: 功能缺陷/接口异常/性能问题/兼容性问题/其他, priority: P0/P1/P2/P3, root_cause_hint: 可能的根因方向 }} 缺陷标题{title} 缺陷描述{desc} 复现步骤{steps} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object} # 强制结构化输出 ) return json.loads(resp.choices[0].message.content) # 读取缺陷列表批量处理结果写回 CSV 或数据库这段代码的思路是先定义好输出格式约束然后用低温参数保证输出稳定性。实测下来几万条历史缺陷的分类准确率在人工抽检里能达到 85% 以上剩下的 15% 基本是模块边界模糊导致的误判人工快速复核一下即可。它的收益不只是标签好看了而是你终于可以回答老板那个经典问题我们这个季度最常见的缺陷类型到底是什么3.2 落地场景二利用长上下文做变更影响分析和回归范围圈定这个场景是 1M 上下文带来的新玩法。以前模型记不住整个项目代码现在可以试试放进去。我刚在团队里实践过的流程是这样的先把核心代码仓库的目录结构和关键模块的代码抽出来加上最近的 git diff组合成一次分析的输入。这里有个实操要点1M 上下文虽然很大但也不是无限大而且输入越长响应越慢、费用越高。所以不是真的把整个仓库几十万行代码全部塞进去而是做一次有损压缩——保留与本次变更直接相关的模块代码、接口定义、公共依赖再配上 dev 环境可访问的接口文档。用代码仓库根目录的执行命令生成变更范围git diff --name-only HEAD~1 HEAD changed_files.txt拿到变更文件清单后配合代码目录结构构造 prompt 让模型输出三部分内容受影响的接口列表、受影响的业务流程、建议回归的测试范围。注意提示词里要明确要求它给出推理依据不要只给结论。这样人工复核时能快速判断模型圈定的范围是否合理。实测效果一次涉及 40 个文件的迭代模型输出的影响范围分析大约 2000 字人工复核耗时十几分钟圈定结果与原来资深测试花半天做出的回归方案高度一致还额外指出了两个被遗漏的关联模块。对于没有资深测试坐镇的团队这个能力等于把经验变成了可调用的服务。3.3 落地场景三用模型批量生成接口测试数据和断言逻辑第三个场景偏向接口自动化。很多团队的接口自动化脚本卡在数据准备太费劲上要测一个订单状态的流转需要先造出各种前置状态的订单数据手工写 SQL 至少十分钟一条。现在可以直接让模型读表结构生成造数 SQL 和对应的接口调用脚本。我自己的实践是把核心业务表的建表语句整理成一份文本让模型针对指定业务状态生成数据构造方案。例如要构造订单已支付待发货的数据模型会根据表结构判断需要插入订单主表、订单商品表、支付流水表并处理好状态字段和关联外键。然后它会输出-- 构造订单已支付待发货状态 INSERT INTO t_order (order_id, user_id, order_status, pay_status, total_amount, create_time) VALUES (TEST20250101001, 10001, 2, 1, 99.00, NOW()); INSERT INTO t_order_item (order_id, sku_id, sku_name, price, qty) VALUES (TEST20250101001, SKU001, 测试商品, 99.00, 1); INSERT INTO t_pay_record (order_id, pay_channel, pay_amount, pay_status, pay_time) VALUES (TEST20250101001, WECHAT, 99.00, SUCCESS, NOW()); -- 注意事项需同步更新 t_order 的 pay_time 字段否则部分查询逻辑会查不到支付记录这个场景的诀窍不是让模型写 SQL而是让模型理解业务状态背后的数据约束。生成完 SQL 后我建议先在一个独立的测试库里跑一遍验证确认状态流转正常再收进自动化用例。因为模型偶尔会漏掉某个业务表的更新时间戳或冗余字段直接在流程里才发现就晚了。4. 测试人必须知道的常见坑和应对策略4.1 模型输出不稳定别让它自由发挥给它框架很多测试朋友第一次用大模型辅助工作最崩溃的就是它上次这么回答这次换个说法。这个问题的根源不是你运气不好而是你没有给模型加约束。处理办法有四个一是要求输出 JSON 并锁定 schema二是给 few-shot 示例在 prompt 里直接放一个你期望的输入输出对三是把 temperature 降到 0牺牲一点创造性换取稳定性四是做一层代码校验解析失败就重试一次。不要嫌这些步骤麻烦。在一个工程化的工作流里模型的输出不应该被当成人话来看而应该被当成可能需要清洗的数据源。你花十分钟把这些校验逻辑写好后面每次调用都省心。我见过太多团队卡在这一步就放弃了其实多写十行代码就能解决。4.2 长上下文的两大隐形问题幻觉放大和成本失控1M 上下文是一把双刃剑。输入的信息越多模型就越容易在某个细节上一本正经地胡说八道。尤其是当你的代码仓库里本身存在一些历史遗留的、已经不生效的逻辑时模型会把它们当成有效逻辑来分析得出一个看起来很有道理、实际上错误的结论。这就是长上下文的幻觉被放大问题。应对策略永远要求模型在关键结论后面标注依据并限定它只依据提供的材料回答不要引入外部知识。另外对于影响范围这种重要结论建议让模型输出置信度打分低置信度的部分人工重点复核。成本问题更直接。1M 上下文的输入费用远高于普通对话把几十万 token 的代码整包灌进去跑一次分析的成本可能是日常对话的几十倍。我的做法是先浓缩再分析先用普通模型对代码目录做一轮摘要把每个模块的核心职责压缩成几百字再把摘要作为上下文。这样既能利用长上下文带来的全局视角又不会让账单爆炸。这个方案适合预算有限的团队。4.3 别把所有测试都交给模型这四类任务必须保留人工我踩过最大的坑是有一段时间为了追求效率把线上问题定性这类高风险分析也交给模型判断。结果它给了个看起来很专业的结论实际上完全跑偏幸亏在推给开发之前被资深同事拦下来确认了一次。从那之后我给自己定了一条规矩模型可以给建议但凡是影响发布决策、客户赔偿、安全合规的结论必须有测试专家复核签字。具体来说这几类任务不要迷信模型第一线上紧急故障的根因判断时间窗口太短你来不及验证模型的推理依据第二涉及法规合规的测试结论比如支付、隐私数据相关的必须人工确认第三需要主观体验判断的测试比如 UI 美观度、交互手感模型给不了可信的结论第四测试用例的最终审核确认模型生成的用例永远是草稿而不是基线。4.4 工具链选型API 直调还是用编排框架我的真实建议现在社区里很多人讨论要不要引入deepseek harness这类工具链来编排模型调用流程。我个人的看法是小步快跑别过度工程化。如果你的团队只是想在测试工作流里尝鲜直接用 API 写几十行脚本就够用。等确认了场景价值、积累了稳定可复用的 prompt 模板之后再考虑引入外部编排框架来管理多步骤任务。原因是测试团队的核心痛点从来不是没有工具而是没有想清楚自己要什么。工具链能帮你管理 prompt、串联多轮调用、做缓存和重试但它也带来了新的维护成本和学习成本。一开始就把流程叠得太重很容易让整个团队陷入工具本身的调试里反而耽误了真正的业务分析。我的建议始终是先用最简单的脚本验证一个场景的 ROI再逐步加大投入。还有一点一定要提醒的是不要忽视私密数据的合规边界。测试环境里往往有大量业务敏感数据把代码、数据库 schema、真实用户信息直接传给第三方模型接口存在不小的合规风险。团队在接入前最好先确认数据脱敏方案和接口调用层面的权限隔离。对于一些严格要求数据不出内网的企业建议评估私有化部署或本地模型方案不要为了图省事走公网 API。另外在工程侧新入职的测试同学如果会 Python、了解模型 API 调用的基础写法在团队里的定位会明显不一样。这不是让你转行做开发而是让你有能力把模型当测试工具链的一环来使用。未来半年到一年我认为懂业务 会测试设计 能调模型的复合能力会是测试行业最值钱的组合。如果你还停留在只会点点点那确实应该有一点危机感——但危机感的方向不是AI 抢我工作而是我还没开始用 AI 改进我的工作。我这半年把这三个模型能力陆续接入到测试流程之后最大的体感变化就是机械重复的活变少了需要脑子的活变多了。以前每天要花大量时间在信息搬运和格式整理上现在这部分时间被压缩到很小更多精力可以投入到真正影响质量的风险判断上。这才是软件测试工作该有的样子。所以回到标题的提问——软件测试要变天了吗我的答案是天确实在变但变出来的不是末日而是一套新的工作方式。早一步接住它的人后面会走得更轻松。