乐于分享
好东西不私藏

传统软件测试 vs 大模型测评:测试计划该怎么做,才不“失焦”?

传统软件测试 vs 大模型测评:测试计划该怎么做,才不“失焦”?
很多团队在做大模型项目时,最容易犯的错误是:
拿着传统软件测试计划模板,简单改几个字段,就直接套用到LLM 测评里。

结果往往是:功能看起来“都测了”,上线后却被幻觉、安全、稳定性问题反复打脸。 

原因并不复杂:传统软件测试计划关注“确定性系统是否按预期工作”,而大模型测试计划关注“概率性系统在复杂输入下是否可控、可信、可持续优化”。

我将从从多个维度做对比,但重点放在“测试计划”本身如何设计。

一、测试对象不同,决定了计划方法论不同

传统软件(如订单系统、支付系统)本质是规则驱动:

输入 A,输出通常稳定等于 B。测试计划围绕“需求-用例-缺陷”闭环展开,强调功能覆盖率、路径覆盖率、回归通过率。

而大模型系统(LLM、RAG、Agent)是概率生成:  

同一意图在不同 prompt、参数、上下文下,可能出现不同输出。测试计划不再只关心“功能是否可用”,还必须纳入:

•一致性与指令遵循

•幻觉与事实准确性

•安全越狱与有害输出拦截

•多轮记忆稳定性

•生成性能(TTFT、吞吐等)

所以,LLM 的测试计划不是传统计划的“扩展版”,而是评测工程化计划。

二、测试计划目标:从“验功能”到“控风险 + 保质量”

结合规范内容,LLM 测试计划目标通常应包含四层:

•质量目标:核心场景综合评分达标(例如均分>=4)

•安全目标:高危场景拦截率 100%

•回归目标:模型升级后黄金集通过率下降不超过阈值(如 2%)

•性能目标:高负载下关键时延指标(如 TTFT P90)满足门槛

对比传统测试计划,传统目标更偏“功能正确率、接口可用性、性能 SLA”,而 LLM 计划会显著强化安全与行为稳定性目标,并明确“不可退化”的回归红线。

三、测试范围定义:从模块边界到能力边界

传统测试计划常按模块拆范围:用户、订单、库存、结算。

LLM 测试计划更适合按“能力维度 + 场景维度”双轴拆解:

•核心能力:指令遵循、语义理解、逻辑推理

•专项能力:安全性、鲁棒性、记忆一致性

•系统能力:API 协议与并发稳定、上下文窗口压力、多轮会话连续性

•业务能力:垂直领域专业表现(心理、金融、代码等)

这意味着测试计划里的“范围章节”不应只写“测哪些页面/接口”,还要明确“测哪些模型能力及其判定标准”。

四、测试资源规划:人机协同是刚需

传统计划中,资源分配以QA人力+自动化框架为主。  

LLM测试计划必须额外规划:

•Prompt 库建设资源:基础库、对抗库、长文本库

•自动化测评资源:批量执行脚本、LLM-as-a-Judge

•人工盲测资源:领域专家对模糊样本做二次判读

•数据与模型资源:模型版本、参数快照(Temperature、Top_p)记录机制

关键点:LLM 测试计划不是“全自动”能解决的,必须设计好自动化初筛 + 人工复核的分工。

五、测试流程编排:阶段化比“并行乱跑”更重要

从规范看,LLM 测试计划可明确三阶段:

1. 测试准备阶段

先做测评点提取,再建设 Prompt 库(基础/对抗/长文本)。

2. 测试执行阶段

API 测试、自动化测评、红队攻击并行推进。

3. 评估优化阶段

人工盲测复核、Bad Case 分类归因并回流优化。

相比传统流程,LLM 计划要特别强调“Bad Case 不是终点,而是下一轮优化的输入资产”。

六、缺陷策略:从“修 bug”到“追根因”

传统缺陷管理偏向代码或逻辑错误定位。

LLM 计划中的缺陷策略更像“多因子归因工程”,至少要在计划中预置:

•缺陷分级规则(P0-P3)

•必填记录项(Prompt、模型版本、参数配置)

•根因标签(底模能力、Prompt 诱导、RAG 检索数据等)

这能避免团队陷入“只改提示词、不改系统机制”或“只怪模型、不查检索链路”的低效循环。

七、测试计划交付物:从“报告”到“可复用资产”

传统计划交付常是计划文档、用例、报告。

LLM 计划应把交付物升级为长期资产,包括:

•《测试计划》(范围/资源/进度)

•Prompt 黄金用例库(可复用、可回归)

•自动化测评报告(含核心指标)

•人工盲测评估表

•Bad Case 分析与优化建议

真正成熟的 LLM 测试计划,不只是“完成一次项目测试”,而是能沉淀下一版本可直接复用的评测体系。

八、给传统测试团队的实操建议(测试计划重点)

如果你要快速把传统计划升级为 LLM 计划,建议优先改这 5 点:

•把“功能范围”改成“能力范围 + 业务场景范围”

•在计划首页写明安全、回归、性能三条准出红线

•增加 Prompt 库建设任务,并单独排期

•设计“自动化初筛 + 专家盲测”双轨评估流程

•把 Bad Case 回流机制写进计划,而不是写进复盘

传统软件测试计划追求“按需求验证系统正确性”;  

大模型测评计划追求“在不确定性中建立可控性”。

两者并不冲突,但不能混用。

当你的测试计划从“测没测完”转向“风险是否被量化、被拦截、被持续优化”,你才真正进入了大模型质量工程阶段。

我们最近会有一个《大模型测评与AI产品质量把控》专题的免费训练营。价值399,前200位免费,如果你也感兴趣。可以扫码下方的二维码联系老师,老师会邀请你进群。

(长按或者扫码识别)

 

相关学习资料