分类：大模型
大模型测试落地的工程账：窄任务、硬预算和失败后人工介入
当企业团队评估大模型参与软件测试时，最常被问到的不是模型能否生成用例，而是成本能否预测、人工何时介入、哪些环节必须保持确定。掘金上一篇技术总结文章回顾了此前 13 个测试项目验证结果，把大模型自动化测试的落地问题归纳为三件事：测试场景的 Token 成本量级、人工确认门应该放在哪一步，以及哪些场景明确不适合使用 LLM。
文章给出的判断并不在于“测试天生比代码生成便宜”。相反，它强调测试场景之所以更容易算清成本，是因为已验证的落地项目几乎都把 LLM 限制在一个很窄的环节里，并配套了明确的预算上限。
Token 账单差异来自任务边界，而不是模型价格
文章首先对比了两组数字。一组来自代码生成场景：一套企业级 Bug 修复端到端工作流包含 12 个全 AI 驱动节点，从 Jira 取单到 Gerrit 提交，调试阶段消耗了数千美金 Token。其中一个失败案例显示，单个 Turn 在执行 117 个 tool calls 后，准备继续进入下一步时被服务端中止。原因并不是 Agent 不知道下一步做什么，而是整轮上下文已经过大，最终被服务端拒绝。
这背后是典型的长链路上下文问题：读 Jira、下载和解压日志、分析日志文本、读取多个源码文件、查看 Code Review 结果、处理 Sonar 扫描报告，这些信息都堆在同一个 Turn 里线性累积。
另一组数字来自测试场景。文章引用 AutoRestTest README 中的说明：使用 GPT-4o-mini 测试一个约 15 个 operations 的 API，成本约为 $0.1。另一个项目 pytest-triage 的默认配置是 –ai-budget=10，即一次测试运行无论有多少失败用例，最多触发 10 次模型调用。同时，它对每次调用的 prompt 大小设置了硬上限：4 KB 的 traceback、每个输出尾部 2 KB、异常信息 1 KB，典型 prompt 通常远低于 2 KB。
两组成本相差很大，但文章认为原因不是测试场景使用了更便宜的模型，而是任务边界完全不同。Bug 修复是端到端任务：读日志、定位根因、改代码、理解 Code Review 反馈、再修改、再看 CI 报错，每一步输出都会成为下一步输入，且没有天然调用次数上限。
测试场景则不同。AutoRestTest 只让 LLM 生成“看起来真实”的字段取值，顺序决策和依赖推断交给强化学习和向量相似度；pytest-triage 只在测试已经失败后追加一段诊断文字，并且从架构上设置了预算上限和防御式包装。窄任务边界意味着最坏成本可以提前估算，而端到端任务很难做到这一点。
人工确认门：不是每次生成后审批，而是失败升级时介入
围绕人工确认门应该放在哪里，文章比较了三种方案：生成后 review、执行前 review、只 review 失败案例。结论明显偏向第三种。
在企业级 Bug 修复工作流中，三个人工确认门都不是在 AI 生成代码后立即出现，也不是在 AI 开始执行前等待批准。确认门 A 和 B 在 Code Review 自动重试跑满 3 轮仍未通过后触发，系统会展示对比报告，并给出“接受当前代码”或“人工修复剩余问题”两个选项。确认门 C 则在 Gerrit 收到 CI 流水线的失败投票后触发。
也就是说，人工被引入的前提是自动化路径已经走到尽头，或者外部系统给出了明确失败信号，而不是每一次 AI 输出都要求人工查看。
测试项目也采用了类似思路。pytest-triage 的设计更保守：AI 只在测试已经失败后追加诊断信息，人是否查看、是否采纳都可以选择，而且 AI 从架构上不允许影响测试运行结果。vlmkit 的两阶段管线同样如此，Stage 2 产出的是 FIX: 建议行，是供人参考的修复提案，不是自动应用的补丁；只有在检测到视觉差异后，AI 判断才会触发。
这种设计之所以更合理，是因为“生成后全部人工审核”会让人力成本随调用频次线性增长，削弱自动化价值；“执行前全部审批”则会因等待审批产生延迟，抵消自动化节省的时间。只 review 失败案例，则把人力投入绑定在两个信号上：系统自己判断不了，以及自动化路径已经走到尽头。
三类不建议引入 LLM 的测试场景
文章还结合已验证的项目，列出了三类不适合使用 LLM 的测试场景。
- 高频回归测试：这是成本结构问题。文章提到，Schemathesis 这类基于 Hypothesis 的属性测试引擎可以通过 schema 驱动进行边界值枚举，不依赖外部 API 调用，结果确定，可无限重跑，回归测试多次执行的边际成本为零。如果换成 LLM，每次回归都会产生 API 调用费用和延迟；一旦与每次 commit、每次 PR 的 CI 频率绑定，成本可能随团队规模和提交频率增长。
- 纯逻辑单元测试：这是任务结构问题。排序函数、状态机转换等纯逻辑代码的判断标准明确、可形式化，不存在需要常识判断的模糊地带。schema 和类型系统就能推导边界值、极端值、类型不匹配等经典缺陷类别，LLM 在这类场景中的增量价值较薄。
- 对确定性要求极高的场景：这是风险容忍度问题。如果一个判断结果需要 100% 可复现，就不能让 LLM 输出直接进入判断链路。pytest-triage 的做法是让 AI 始终作为旁路建议存在，不允许影响测试通过或失败结果。即便模型报错、超时或返回无效内容，整次运行结果也保持与未安装插件时一致。
行业意义：可控性优先于自动化范围
从这组对比看，LLM 在测试领域的落地重点正在从“能不能自动完成更多步骤”转向“能否被工程系统稳定约束”。测试场景的 Token 成本之所以可预算，并不是因为测试本身享有特殊优势，而是因为项目设计普遍选择了窄任务、低触发频率和硬性预算上限。
这也解释了为什么简单的“端到端 AI 测试工作流”并不一定更先进。如果让模型连续完成读需求、写测试、跑测试、分析失败、改测试、再执行，链路越长，上下文越容易膨胀，成本和延迟也更难预测。
对工程团队而言，更现实的路径是把确定性工具继续放在高频回归、纯逻辑验证和最终判断链路中，把 LLM 放在生成测试数据、解释失败、提出修复建议等局部辅助环节，并让人工只在失败升级时介入。这样的分工不追求模型覆盖所有流程，但能让成本、结果和人工责任都更容易被提前计算。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/da-mo-xing-ce-shi-luo-di-de-gong-cheng-zhang-zhai-ren-wu
