第2章：测试策略制定——基于风险的测试策略，如何平衡成本与质量
做测试最怕什么？
怕测不全，也怕测太多。
测不全，上线出事故，背锅的是你。测太多，项目延期，挨骂的还是你。说白了，这就是成本与质量的博弈。我做了这么多年大模型测试，踩过的坑不少，慢慢摸索出一套方法——基于风险的测试策略。今天就跟大家聊聊，怎么用这套策略在有限的资源下，把质量守住。
2.1 为什么需要基于风险的测试策略？
先讲个真实案例。
我之前负责一个智能客服大模型的上线测试。团队只有3个人，时间只有两周。如果按传统思路，把所有功能、所有场景都测一遍，别说两周，两个月都不够。
怎么办？
我当时的做法是：先做风险分析。把可能出问题的地方列出来，按严重程度和发生概率排个序。结果发现，最核心的「意图识别」模块占了80%的用户流量，但代码改动却最小。反而是「多轮对话」模块，改动频繁，逻辑复杂，虽然用户用得少，但一旦出错，用户体验极差。
于是我把测试资源做了倾斜：70%的精力放在多轮对话上，20%放在意图识别，剩下10%覆盖其他模块。最后上线效果不错，核心问题都堵住了。
这就是基于风险的测试策略——把好钢用在刀刃上。
2.2 风险分析的四个维度
做风险分析，我习惯从四个维度入手：
| 维度 | 说明 | 示例（大模型场景） |
|---|---|---|
| 业务影响 | 出问题后对用户/业务的影响程度 | 支付相关对话出错 → 高；闲聊功能出错 → 低 |
| 发生概率 | 该模块出问题的可能性 | 新开发的RAG检索 → 高；稳定运行半年的摘要生成 → 低 |
| 可检测性 | 问题是否容易被发现 | 模型输出明显错误 → 高；逻辑漏洞但表面正常 → 低 |
| 修复成本 | 出问题后修复的难度和代价 | Prompt调优 → 低；重新训练模型 → 高 |
你想想看，这四个维度一组合，就能给每个模块打个风险分。分数高的，优先测、重点测。分数低的，可以少测甚至不测。
核心公式：风险等级 = 业务影响 × 发生概率 × (1 / 可检测性) × 修复成本
注意：可检测性越高，风险越低，所以用倒数。
2.3 如何平衡成本与质量？
有了风险等级，接下来就是分配资源了。我一般按「三七原则」来分：
- 高风险模块（占30%）：投入70%的测试资源。做全量测试，包括功能、性能、安全、边界值、异常场景等。
- 中风险模块（占50%）：投入20%的测试资源。做核心功能测试，加上一些关键边界场景。
- 低风险模块（占20%）：投入10%的测试资源。做冒烟测试，确保基本功能可用即可。
举个例子。我之前测一个文档问答大模型，风险分析后：
- 高风险：文档解析模块（业务影响大，新开发，容易出错）→ 全量测试，包括各种格式的文档、超大文件、乱码文件等。
- 中风险：答案生成模块（业务影响大，但模型相对稳定）→ 测试常见问题，加上一些刁钻问题。
- 低风险：用户登录模块（复用已有组件，几乎不出问题）→ 只测登录、登出两个场景。
这样下来，测试时间从预估的3周压缩到了1周半，而且上线后没有出现严重事故。成本省了，质量也没丢。
我的小技巧：每次测试前，先花半天时间做风险分析。这半天看起来是「浪费」，实际上能帮你省下后面几天的无用功。我曾经因为跳过这一步，结果在低风险模块上浪费了整整两天——嗯，后来再也不敢偷懒了。
2.4 动态调整：风险不是一成不变的
这里要特别提醒一点：风险是会变的。
我记得有一次，一个模块在前期风险分析时被评为「低风险」，因为代码没怎么改。但测试到一半，开发突然提交了一个大改动，修复了一个看似无关紧要的bug。我立刻警觉起来，重新评估了这个模块的风险——果然，改动涉及了核心逻辑，风险等级直接升到了「高」。
所以，我建议在测试过程中，每隔两三天就重新审视一下风险矩阵。特别是遇到以下情况时，必须重新评估：
- 代码有重大变更
- 发现了新的严重bug
- 需求发生变化
- 测试资源出现变动（比如有人请假）
说白了，基于风险的测试策略不是「一锤子买卖」，而是一个动态调整的过程。你想想看，如果风险变了你还按原计划测，那跟闭着眼睛开车有什么区别？
2.5 避坑指南：我曾经踩过的三个坑
做这行久了，谁还没踩过几个坑呢？我分享三个典型的，希望能帮你少走弯路。
坑一：过度依赖历史数据
我曾经接手一个项目，前任测试同学留下了一份风险分析报告。我偷了个懒，直接拿来用了。结果呢？上线后出了个大事故——因为那个报告是半年前的，期间模型迭代了好几次，风险早就变了。从那以后，我坚持每次测试都重新做风险分析，哪怕看起来跟上次差不多。
坑二：忽略「低概率高影响」的风险
有些风险，发生概率很低，但一旦发生，后果极其严重。比如大模型输出涉政内容，概率可能只有0.01%，但出了就是大事。我建议对这类风险单独列出来，即使概率低，也要安排专项测试。别问我怎么知道的——问就是吃过亏。
坑三：只关注功能风险，忽略非功能风险
很多人做风险分析时，只盯着功能模块。但大模型应用里，性能、安全、合规这些非功能风险往往更致命。我见过一个案例，模型功能全对，但响应时间超过10秒，用户直接流失了。所以，记得把性能、安全、合规也纳入风险矩阵。
2.6 实战：一个完整的风险测试计划示例
最后，我给大家展示一个简化版的风险测试计划，供参考：
# 风险测试计划（示例）
# 项目：智能客服大模型 v2.0
## 风险矩阵
| 模块 | 业务影响 | 发生概率 | 可检测性 | 修复成本 | 风险等级 |
|------|---------|---------|---------|---------|---------|
| 意图识别 | 高 | 低 | 高 | 低 | 中 |
| 多轮对话 | 高 | 高 | 中 | 中 | 高 |
| 情感分析 | 低 | 中 | 高 | 低 | 低 |
| 知识库检索 | 高 | 中 | 低 | 高 | 高 |
## 测试资源分配
- 高风险模块（多轮对话、知识库检索）：70% 资源
- 中风险模块（意图识别）：20% 资源
- 低风险模块（情感分析）：10% 资源
## 测试策略
- 高风险：全量测试 + 压力测试 + 安全测试
- 中风险：核心功能测试 + 边界场景
- 低风险：冒烟测试
## 动态调整机制
- 每两天重新评估一次风险矩阵
- 代码变更后立即重新评估
- 发现严重bug后重新评估相关模块
这个模板你可以直接拿去用，根据自己的项目情况调整。记住，没有放之四海而皆准的测试策略，只有最适合当前项目的策略。
小结
基于风险的测试策略，说白了就是一句话：把有限的测试资源，投入到最可能出问题、出问题后果最严重的地方。它不是让你偷工减料，而是让你聪明地工作。
我做了这么多年测试，最大的感悟就是：测试不是「越多越好」，而是「越准越好」。你想想看，与其花三天测一个几乎不出错的模块，不如花一天测透一个高风险模块，剩下两天去补其他短板。这才是真正的成本与质量平衡。
下一章，我们会聊聊具体的测试用例设计方法。到时候见。