📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

很多团队在做大模型项目时，最容易犯的错误是：

拿着传统软件测试计划模板，简单改几个字段，就直接套用到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 回流机制写进计划，而不是写进复盘

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

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

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

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

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​​

​