![](https://developer.qcloudimg.com/http-save/yehe-12060431/41b15adcafa099d0dd9454b3dc0e61ec.png)


事情是这样的。

前段时间有个测试负责人找我，说他团队花了两个月，写了 3000 多条 case，代码覆盖率干到 95%。老板看了很满意，团队也觉得稳了。

上线第二天，炸了。

线上冒出来一个极其严重的 bug，3000 条 case 全没拦住。不是什么极限边界场景，就是一个很普通的操作路径，测试团队压根没想到。

3000 条 case，没一条踩中。

他特别郁闷。该做的都做了，case 数量够多，覆盖率够高，但真到线上，该漏的还是漏了。

我听完只有一句话，你测了很多，但你没测到点子上。

这事太常见了。

我见过太多团队，把测试质量等同于测试数量。case 写了几千条，覆盖率拉到 90% 以上，就觉得心里有底了。

但覆盖率这个东西，测的是你的代码被跑过了没有，不测你的代码跑得对不对。

你写 100 条 case 把每一行代码都跑一遍，覆盖率 100%。但如果这 100 条 case 全是最理想的输入、最顺畅的路径，那你只是反复确认了一件事，正常情况下代码能跑。仅此而已。

真正翻车的地方，异常输入、并发冲突、边界条件、模块集成，一条没测。

## 覆盖率是个好指标，但别把它神化了

先说清楚，我不是否定覆盖率。

覆盖率是个有用的参考。它告诉你哪些代码完全没被测过，这是有价值的信号。一个核心模块覆盖率只有 20%，那确实该补。

但太多团队把覆盖率当成了目标，而不是参考。

经济学里有个古德哈特定律。简单来说就是，当一个指标变成目标，它就不再是个好指标了。

放到测试上一模一样。

你一旦把覆盖率设成 KPI，团队行为就会变形。为了把覆盖率从 85% 撑到 90%，开始大量写那种跑一下就过、没有实质断言的 case。一个测试函数调了一下目标函数，不检查返回值，不检查副作用，覆盖率贡献了，测试价值约等于零。

数字好看了，质量没变。

INRIA 有过一项大规模研究，分析了大量开源项目，结论很直接，在项目级别，覆盖率和发布后发现的 bug 数量之间，相关性微弱到可以忽略。

你没看错。覆盖率高的项目，不一定 bug 少。

还有一种更隐蔽的问题。覆盖率不区分代码的重要性。你把一个日志工具类测到 100%，和一个核心支付逻辑测到 100%，在覆盖率报告里权重是一样的。但前者出 bug 最多日志格式错一下，后者出 bug 就是资金事故。

盯着覆盖率干活，大量精力会被低风险代码占满，真正高风险的地方反而没时间好好测。

## 测得多，不如测得准

那什么才叫好的测试。

一句话，测该测的地方。

好的测试不是面面俱到，是精准命中高风险区域。你不需要测每一行代码，你需要测的是一旦出问题、后果最严重的那些路径。

这在测试方法论里叫风险驱动测试。**思路很简单，按「出 bug 的概率」乘以「出 bug 的后果」排优先级。概率高、后果严重的，重点测。概率低、后果也轻的，少花时间甚至不测**。

举个具体例子。

电商系统里，支付链路和日志清理脚本能一样对待吗。支付链路出 bug，用户付了钱没收到货，客诉、退款、信任崩塌。

日志清理脚本出 bug，最多磁盘满了告个警。前者你应该花大量精力写边界测试、异常测试、并发测试，后者跑个基本 smoke test 就够了。

但如果你盯着覆盖率干，这两块代码得到的关注可能是一样的。

这就是问题所在。

测试资源永远是有限的。你不可能什么都测，你需要做的是把有限的资源砸到最值钱的地方。

## 怎么找到该测的地方

道理讲完了，实操的问题来了。怎么知道哪些地方该测。

我自己的经验，按这几条线索去找。

**第一，盯真实故障。**

线上真正出过的 bug，是最高质量的测试需求来源。每一次线上事故，都应该沉淀出测试 case。不是泛泛地说「以后注意」，是实打实写一条 case，锁死这个场景，确保同样的 bug 不会再出现。

很多团队的事故复盘写得很好，改进措施列了一堆，但就是不落地成自动化测试。过两个月换个姿势，同一个坑再踩一次。

真实故障还有一个好处。它告诉你你以为安全的地方其实不安全。你测得最多的是核心功能，但线上炸的往往是那种你觉得「这么简单不可能出问题」的角落。真实数据帮你打脸，打完你就知道该补哪了。

**第二，盯改动频繁的地方。**

代码变更频率是个很好的风险信号。一个模块三个月改了 20 次，要么需求在反复变，要么这块逻辑本身就复杂不稳定。不管哪种，都是 bug 高发区。

每次改完代码手动跑一遍觉得没问题就提交，迟早翻车。改动频繁的模块，回归测试必须自动化，断言要细。

**第三，盯集成点。**

单个模块自己跑没问题，挂到系统里就出事。这种事天天都在发生。

服务之间的接口契约、数据格式传递、异步消息的时序、数据库事务的隔离级别，这些集成点的 bug 远比单元逻辑的 bug 多。但这些地方恰恰是很多人懒得测的，因为搭环境麻烦，造数据麻烦，跑起来慢。

嫌麻烦不测，上线了就轮到用户帮你测了。

**第四，用变异测试验一把。**

前面三条帮你找「该测哪些地方」，变异测试解决的是另一个问题，你写的那些测试到底有没有用。

原理很直白。在你的代码里主动注入一些 bug，比如把大于号改成小于号，把加号改成减号，删掉一行校验逻辑，然后跑你的测试套件。如果测试挂了，说明你的测试能抓到这个 bug，有效。如果测试全过了，说明你的测试根本没检查到这块逻辑，白写了。

这比看覆盖率诚实多了。覆盖率告诉你代码被跑过了，变异测试告诉你跑过了之后到底有没有真正检查。

主流的变异测试工具，Java 有 PIT，Python 有 mutmut，JS 有 Stryker。接进 CI 周期性跑一轮，你会惊讶地发现，覆盖率 90% 的测试套件，变异得分可能只有 40% 到 50%。说明一大半的测试在假装保护你。

## AI Agent 场景，精准测试更关键

前面聊的主要是传统软件测试的思路。如果你做的是 AI Agent，这事更极端。

传统软件你好歹还能算覆盖率，输入空间虽然大但好歹有限。Agent 的输入空间是无穷的。用户可能问出任何问题，可能用任何顺序操作，可能给任何格式的数据。你想穷举，不可能。

更麻烦的是 Agent 的非确定性。同一个输入，今天输出 A，明天输出 B。你写了一条 case 跑过了，不代表稳定通过。跑 10 次可能 7 次过 3 次挂，你按一次的结果来判断，跟抛硬币没区别。

这种情况下，精准测试不是优化项，是生存项。

怎么选，跟前面一样的思路。

从真实用户对话里捞失败 case。用户骂得最多的问题类型，就是最该建评估器的场景。与其花一周合成 1000 条测试数据，不如从线上捞 50 条真实失败 case，后者价值大十倍。

盯核心业务链路。你的 Agent 如果是做客服的，退换货流程比闲聊场景重要一百倍。把退换货的全链路测透，比面面俱到地测一百个边缘场景管用。

跑多次看概率。一个 case 至少跑 5 到 10 次，看通过率。一次通过不叫通过，十次通过八次以上才叫靠谱。

## 几条实操经验

道理和方向都有了，最后给几条我自己踩坑后总结的。

**第一，定期清理低价值测试。**

测试不是越多越好。那些跑一下就过、断言空泛、从来没抓到过 bug 的 case，是负债不是资产。它们拉慢 CI、增加维护成本、给你虚假的安全感。定期 review，该删的删，该重构的重构。好的测试套件是精炼的，不是臃肿的。

**第二，跟踪逃逸缺陷，别盯覆盖率。**

逃逸缺陷就是线上发现的 bug。这个数字比覆盖率诚实得多。覆盖率 95% 但每个版本线上都冒 bug，你的测试体系是有问题的。覆盖率 70% 但线上几乎不出事，说明你那 70% 全砸在了刀刃上。

真正该盯的指标是，你测过的东西，还有多少跑到线上炸了。

**第三，测试跟着业务风险走，不是跟着代码量走。**

代码多的地方不一定该多测，风险高的地方才该多测。每次新功能上线前，先做风险评估。哪些路径涉及钱、涉及数据安全、涉及用户体验的关键节点，先把这几个地方测透了，再考虑其他的。

**第四，Agent 评测，质量远比数量重要。**

50 条从真实业务场景里提取的评估 case，比 500 条合成数据有用得多。一条能抓到核心问题的 case，胜过一百条跑 happy path 的废 case。评测的价值不在于你有多少条数据，在于你的数据能不能反映真实的业务质量。

## 写在最后

回到开头那个测试负责人。

3000 条 case，覆盖率 95%，听上去很厉害。但如果这 3000 条 case 全在测代码有没有被跑过，而没测到真正的风险点，那这 3000 条 case 就是一堆好看的数字。

测试的价值，从来不在于数量。在于精准。

你测了 100 个地方，不如测准 10 个最关键的。你写了 1000 条 case，不如有 100 条能真正抓住 bug。

好的测试，不是测得多。是测得准。

知道哪里该测，哪里可以不测，哪里必须往死里测。这种判断力，比写 case 的能力重要一百倍。



前段时间有个测试负责人找我，说他团队花了两个月，写了 3000 多条 case，代码覆盖率干到 95%。老板看了很满意，团队也觉得稳了。

一个测试负责人的崩溃：该做的都做了，线上还是炸了

测试

测试质量不等于覆盖率数字，3000条case全跑理想路径，仍可能漏掉核心风险。真正有效的测试需风险驱动，聚焦故障历史、频繁改动与集成点，用变异测试验证有效性。线上逃逸缺陷才是更诚实的指标，精准命中要害远比堆量重要。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一个测试负责人的崩溃：该做的都做了，线上还是炸了-腾讯云开发者社区-腾讯云

一个测试负责人的崩溃：该做的都做了，线上还是炸了

一个测试负责人的崩溃：该做的都做了，线上还是炸了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐