干了十几年测试，我见过太多测试用例写了上千条、执行到崩溃的团队。每次版本迭代，光回归就占用一大半时间，用例集越来越臃肿，真正能发现缺陷的却寥寥无几。很多人觉得测试用例数量多等于覆盖全面，其实这是个误区——用例越多，维护成本越高，执行效率越低，最后大家为了“跑完用例”而跑，反而忽略了测试本身的目标。
这篇文章我就把自己这些年做用例“瘦身”的经验整理出来，一共9个可以直接落地的技巧。不需要什么高深理论，都是我在实际项目中反复验证过的做法。不管你是刚入行的功能测试，还是带团队的测试负责人，只要按着这些思路把现有用例过一遍，基本都能在一个迭代周期内看到明显效果。
1. 先搞清楚测试用例为什么会“胖”
动手瘦身之前，得先弄清楚用例是怎么一点点胖起来的。我见过的团队里，用例膨胀的原因高度集中在这几类：
- 覆盖恐惧症：怕漏测，所以每个输入框都要写上十几条用例，每个下拉框把每个选项都单独列一条。
- 需求没锁定就开写：需求评审还没结束，用例已经在写了，等需求改了三四轮，用例也跟着加了三四轮，旧的又不敢删。
- 历史包袱：从项目启动到现在积累的老用例，很多功能早就下线了，用例还在回归集里躺着。
- 为了“数量达标”写的废话用例：比如“打开页面验证标题正确”“点击按钮验证跳转正常”这种一条顶一万条的空话。
- 流程驱动而非风险驱动：只看“要覆盖的功能点列表”，不看“哪里最容易出问题”，结果低风险区域堆满了用例，高风险区域反而不够。
这几类问题叠加在一起，用例集想不胖都难。
1.1 一个典型的臃肿用例长什么样
我以前接手过一个商城的回归测试集，光登录模块就有300多条用例。我当时就觉得很离谱，一个登录功能，无非就是账号密码校验、验证码、第三方登录、异常场景，怎么可能需要300条？翻了一下发现，里面大量用例长这样：
- 用正确的用户名和密码登录，验证登录成功
- 用正确的用户名和错误的密码登录，验证提示密码错误
- 用错误的用户名和正确的密码登录，验证提示用户名不存在
- 用不存在的用户名和密码登录，验证提示用户名不存在
- 用空用户名和正确密码登录，验证提示用户名不能为空
- 用正确用户名和空密码登录，验证提示密码不能为空
这些用例单看都对，但问题在于它们只是把同一种处理逻辑重复了无数遍。登录失败时，前端提示什么、后端返回什么，本质上是同一段代码在跑，你测十条和测一条，发现缺陷的概率几乎一样。真正需要单独验证的，只有那些会走向不同代码分支的输入。
1.2 瘦身不等于偷工减料，而是把功夫花在刀刃上
很多人一听“用例瘦身”就紧张，觉得是不是要把用例删没了，漏测了算谁的？这里要先统一认知：精简用例的目标是提升缺陷检出率，不是降低它。你用10条精心设计的用例覆盖了一个模块的主要逻辑，比用100条重复用例堆出来的“伪覆盖”要有效得多。
判断一条用例该不该留，就一个问题：如果把它删掉，有没有可能漏掉一个真实的缺陷？如果答案是否定的，那它大概率就是冗余用例。反过来，如果一条用例覆盖了多条路径、多个断言，那它不仅不该删，还应该继续加厚。
2. 9大瘦身技巧逐一拆解
下面进入正题。这些技巧没有严格的顺序依赖，你可以从最痛的地方开始改起，也可以按模块逐个过。每个技巧我都会配一个真实场景来说明，方便你对照自己的项目判断。
2.1 技巧一：需求阶段做减法，砍掉“不存在”的需求
这一条看着像废话，但恰恰是最多人忽略的。很多用例冗余的根源，是需求本身就不清晰的时候就开始写用例了，等需求改了，用例忘记同步更新，一堆测不存在的功能的用例就留在了集子里。
我建议把用例设计前置到需求评审阶段。接到需求之后，先别急着打开用例管理工具，先和产品经理过一遍这几个问题：
- 这个功能要解决用户什么问题？主要使用路径是什么？
- 哪些场景是本次版本必须支持的，哪些是后续迭代才支持的？
- 有没有被砍掉的需求、被替换的方案？对应的旧用例是否要标记废弃？
我实操时会在PRD评审会上直接拉一份“用例范围清单”，把需求里的功能点对应到主干用例、扩展用例和异常用例三个级别。凡是需求里没有明确提到的功能，一律先不写用例。等开发进入测试阶段，如果发现确实有遗漏场景，再补也不迟，但要记录原因，这会反哺下一次需求评审。
注意：这里要区分“需求没写但代码实现了”的情况。我的建议仍然是先以需求文档为准，测试阶段如果发现实际行为与需求不符，第一时间提缺陷，而不是默默加用例去覆盖“代码实际有但需求没说”的行为——那会让用例库越来越偏离产品定义。
2.2 技巧二：等价类划分法，每个集合只留一条代表用例
等价类划分是测试设计的基础方法，但很多人用着用着就变形了。我见过有人把账号长度从1到20每个数字都写一条用例，这就是没搞懂等价类的真正价值——它要的不是穷举，而是把无限输入划分成有限集合，每个集合里选一条代表用例，验证“这一类输入会被同样的逻辑处理”。
实操上，我在设计用例时会把输入域划成有效等价类和无效等价类，然后在每个类里挑一个典型值、一个临界值去覆盖。比如注册页的密码长度规则是6到20位：
- 有效等价类：长度6位、长度20位、长度8位（中间值）
- 无效等价类：长度5位、长度21位、长度0位（空值）
这样设计下来，密码长度这个字段只需要5条用例，而不是15条。同样的逻辑应用到账号、邮箱、手机号等所有输入字段，用例数量直接腰斩。
实操心得：等价类用例的断言一定要覆盖到“这一类输入被执行后系统给出的反馈”，比如提示文案、页面跳转、接口返回值。别只验证“能输入”或“不能输入”，要验证“输入之后发生了预期的处理”。
2.3 技巧三：边界值分析，把相邻边界合并成一条用例
边界值分析和等价类经常配合使用，但很多人在边界值这里也犯了“过度设计”的毛病。我见过一份测试用例，对一个“数量输入框允许范围1到99”的字段，写了100条用例，从0、1、2一直写到99、100，每个整数都来一遍。
边界值分析的精髓是测“边界两侧”和“边界本身”，不是测“整个范围里的所有值”。还是拿1到99举例，真正需要测的只有四个值：
- 0（下边界外）
- 1（下边界本身）
- 99（上边界本身）
- 100（上边界外）
如果逻辑里涉及临界条件判断，最多再加一个中间值。这5条用例就能覆盖这个输入框的全部边界逻辑，剩下的95条都是在消耗时间。
遇到那种“边界内外行为一致，或者边界内外走向同一个处理分支”的情况，还可以继续压缩。比如某个字段对非法输入统一弹同一个提示，那0和100这两条用例的预期结果完全一样，就可以合并成一条“输入边界外的任意值，验证统一错误提示”。边界值本身仍然要单独测，因为等于边界值时代码走的是合法逻辑分支。
2.4 技巧四：从“一条用例一个功能”切换到“一条用例一条链路”
我发现很多人的用例设计习惯是“一个功能点配一条用例”，登录配一条，加购物车配一条，下单配一条，支付再配一条。这种设计方式执行起来非常机械，而且在回归测试时效率极低——你得连续登录好几次、加好几次购物车，才能把一条完整的用户路径走完。
更好的做法是站在用户视角设计“场景用例”，把多个功能点串成一条端到端的链路。比如一条用例可以写成：
- 用户登录商城，搜索商品，将商品加入购物车，进入结算页，提交订单，完成支付，验证订单状态变更为“已支付”，同时验证库存扣减、优惠券状态变更、积分增加等多个业务状态。
这样一条用例就覆盖了登录、搜索、购物车、订单、支付、库存、营销七个模块的联动逻辑。你执行一条用例，相当于跑了以前七条用例的量，而且它是按真实用户的路径来测的，更容易发现模块之间的接口兼容问题。
实操心得：链路用例的关键在于断言写在哪。我的习惯是在每个里程碑节点（下单成功、支付成功、订单状态流转）都设置一个轻量断言，在最终节点设置一个重量级断言（校验所有关联状态）。这样万一链路中间断了，你一眼就能看出是哪个节点出的问题。
2.5 技巧五：用探索式测试吸收大量“正向用例”
探索式测试这个词很多人听过但不知道怎么用。我的理解很简单：对于稳定模块的正向功能，与其写20条“点击按钮A，页面跳到B”这种机械用例，不如直接让测试人员在固定时间内自由探索，把发现的问题记录成缺陷报告，把有价值的路径沉淀成后续的自动化脚本。
我在团队里推行过一个做法：每个迭代，把用例评审时判定为“低风险但不测又不放心”的正向用例全部标记为“探索测试候选”。版本提测之后，安排测试人员用半天时间专门走这些路径，不按脚本执行，而是带问题去操作，比如“如果我在支付成功那一刻断网会怎样”“如果我在下单后又去改了收货地址会怎样”。这个过程中发现的问题，大概率是写用例时想不到的，价值比机械执行20条正向用例高得多。
当然，探索式测试的记录不能太随意。我给团队的模板是：探索路径、前置条件、实际结果、发现的问题、对应的需求点。每次探索结束之后，有价值的路径会补录成正式用例，没发现问题的路径直接丢弃，不让它们沉淀成冗余资产。
2.6 技巧六：UI用例和接口用例分层，砍掉重复覆盖
同一个业务逻辑，UI层测一遍、接口层测一遍、单元层再测一遍，这是最常见的人力浪费。很多人在设计用例时没有分层意识，同一个校验逻辑在UI、接口、数据库三个层面各写一组用例，看起来覆盖得挺全，其实大部分是在重复劳动。
我的分层原则是这样的：
- 接口层覆盖业务规则和异常分支，比如参数校验、权限校验、状态流转、超时重试，因为接口直接面对逻辑，发现问题更快、定位更准。
- UI层只覆盖用户可感知的交互反馈，比如页面加载、按钮置灰、错误提示展示、跳转路径，不重复验证接口已经验证过的业务规则。
- 数据库层只做关键数据的抽查，比如订单金额、库存数量、状态字段，不必每条用例都查一次库。
举一个我实际处理的例子：一个“修改密码”的功能，接口层验证了“旧密码错误时返回错误码”“新旧密码相同时返回错误码”“新密码不满足复杂度规则时返回错误码”这三条用例。UI层对应的用例就只需要覆盖“修改成功时页面提示与跳转”“修改失败时错误码映射到页面提示文案”这两条。以前很多团队会在这里写八九条UI用例，每条都是重复输入密码再验证提示，时间就这么浪费掉了。
注意：UI自动化用例尤其容易变成冗余重灾区。我见过一些团队，接口已经在断言返回码了，UI脚本还要一层层点进去看提示文案，执行一次慢得要命，稳定性还差。建议UI自动化的断言只卡“结果状态”，别每一层都做全文断言。
2.7 技巧七：测试数据先行，用参数化合并“重复步骤”用例
有一类典型的冗余用例长这样：同样的操作步骤，只是测试数据不同，其他完全一样。比如“商品列表页按价格升序排列”，有人会写三条用例——商品价格分别为100元、200元、300元时验证升序逻辑。这种用例三大痛点：难维护、难执行、难定位问题。
正确的做法是参数化。把测试数据从用例步骤里抽出来，单独放到数据源里，用例本身只保留操作步骤和预期结果，用一组参数去驱动执行。
还是拿商城系统举例。我在写购物车结算用例时，会把商品类型、数量、优惠券类型、运费模板这些参数全部外置成一张数据表格（Excel、CSV或测试平台的参数化列表都行）。执行用例时，一行行读取数据去跑，用例的步骤部分只有一条：初始化参数，加入购物车，结算，断言金额。用十万个数据组合跑完，用例文件里只有一条用例，而不是十万条。
参数化能帮你从物理上减少用例编写量，这个道理很多人能想通，但真正落地时有个坎：参数化之后用例的可读性变差了。我的解决办法是给参数化用例写清晰的“数据说明”注释，并把数据表按业务场景分组命名，比如order_normal.csv、order_boundary.csv、order_abnormal.csv，在用例的摘要里写明“由数据表驱动，覆盖XX场景”，这样审查用例时也不会一头雾水。
2.8 技巧八：定期评审用例，删除超过3个月未执行的“僵尸用例”
这条是我在带团队时立的规矩，很多人刚开始不接受，但执行两个迭代之后都真香了。
具体做法是每两个迭代做一次用例评审，把用例管理工具里“最近3个月没有执行记录”的用例全部拉出来过一遍。分成三种处理：
- 确实没用了，标记废弃（功能下线、需求变更、重复覆盖）
- 功能还在，但执行优先级低，降级到探索测试候选池
- 功能自动化了，把手工执行这条用例改为“自动化脚本执行”，用例状态标记为自动化维护
我统计过，第一轮评审通常能清理掉25%到40%的用例。很多用例大家平时根本想不起来有它们，等到评审时一看，功能早就不存在了，或者已经被其他用例覆盖了。这种评审还有一个隐藏收益：它能逼着整个团队重新思考“我们到底在测什么”，而不是按惯性维护一个越来越大的“僵尸文件”。
实操心得：评审容易陷入“谁的用例谁护短”的局面。我建议定一个硬性标准：说不清这条用例覆盖什么需求的，直接标废弃；没有人能解释预期结果的，直接标废弃；和执行过的高优先级用例存在重复覆盖的，直接标废弃。把标准定在前面，评审就不会变成拉锯战。
2.9 技巧九：AI辅助生成用例初稿，把精力留给高价值设计
最近AI写测试用例已经是非常成熟的应用了，我用过不少工具，豆包、ChatGPT、还有一些测试平台自带的功能都有试过。客观讲，AI写的初稿质量能到60分，重点是它能快速铺出覆盖框架，省掉你从头列功能点的时间。但AI生成的内容有一个普遍问题：它会把“应该覆盖的点”全部列上来，没有取舍意识，直接拿去用，用例量反而会膨胀。
所以我的用法是“AI生成初稿 + 人工按等价类/边界值/优先级做第二轮裁剪”。具体流程是这样的：
- 把需求文档的主要功能点、核心规则、异常场景描述粘贴给AI，让它生成一份功能测试用例初稿
- 把初稿导入自己的用例模板，先用等价类划分把同质用例合并，再用边界值分析把无效穷举砍掉，最后用优先级标签把低风险用例降级
举个例子，有一次我让AI帮一个“商品评价”功能生成用例，它一口气列出了60多条。我过了一遍，合并了同类校验、删掉了纯空话用例、把重复的UI交互合并成链路场景，最后保留了22条，但覆盖度一点没降。
这里特别说一句，AI还有一个特别好用的场景是配合代码Review做补充。团队在评审代码时发现某个方法有特殊的分支逻辑，可以直接把这个方法的代码或注释丢给AI，让它设计针对这个分支的测试用例，这样用例设计就自然地和编码实现对齐了，不会出现“代码都改成新逻辑了，用例还在测旧逻辑”这种脱节。
3. 用例瘦身后的团队协作与流程落地
上面9条技巧主要聚焦在“怎么写好每一条用例”和“怎么删掉多余的用例”，但要让瘦身效果长期保持，团队层面的流程机制也得跟上。不然这次清完，下个迭代又会慢慢胖回去。
3.1 建立用例质量的三道过滤防线
我在团队里建立了三道过滤防线，分别卡在用例提交、用例评审、用例执行三个阶段。
第一道防线是“用例编写规范检查”。我自己写了一套简易的用例编写Checklist，列了十几条硬性指标，比如“是否标注了对应的需求编号”“是否明确了前置条件”“预期结果是否包含具体校验点”“是否通过等价类/边界值方法设计输入数据”。用例写好之后提交评审前，先自查一遍Checklist，不合格的直接打回。
第二道防线是“用例评审的覆盖率反推”。评审用例时不允许只看“有没有覆盖需求”，必须反向问一个问题：如果执行完这套用例，哪些逻辑分支我们仍然不清楚？哪些错误输入可能导致未预期的行为？答不上来的地方就是要补用例的地方。
第三道防线是“执行中的动态淘汰”。我要求测试人员执行用例时，关注点不只是Pass/Fail，也要记录“这条用例执行时，我有没有发现额外的风险点”“这条用例有没有实际价值”。每次版本结束后汇总一条“低价值用例清单”，反馈给用例负责人做二次评审。这三道防线配合起来，用例库的质量才能维持在一个稳定的高位。
3.2 用例编号与标签规范，方便定期清理
很多团队的用例膨胀还有一个技术层面的原因：没有一套合理的编号和标签体系，导致靠人眼去判断“哪些用例重复、哪些用例废弃”非常困难。我建议在用例管理工具里做两件事：
- 每条用例必须带需求编号标签，需求下线时就按编号把用例全部捞出来，统一清理。
- 每条用例必须带优先级标签（P0/P1/P2），P0是核心路径，P1是重要扩展，P2是边缘异常。回归测试只执行P0和P1，P2用例在探索测试中覆盖。
有了这套标签，做“3个月未执行清理”就很简单了。直接按优先级筛出P2且长期未执行的用例，先拉到测试计划里跑一轮，能发现问题就升级，发现问题就删除，整个流程非常清爽。
注意：优先级标签不是固定的。每次大版本变更后，我建议花半小时统一过一遍P0/P1/P2的划分，因为业务优先级会变，用例优先级也必须跟着变，否则用例会慢慢变成“全是P0”的失控状态。
3.3 把瘦身指标纳入迭代复盘
用例瘦身这件事，如果不放进复盘议程，通常坚持不了多久。我们团队在每次迭代复盘时，会固定看三个数字：
- 用例总数变化（净新增/净删除）
- 用例执行时长（每轮回归从X小时降到Y小时）
- 线上/发布后缺陷率（瘦身后是否仍然稳定）
这三个数字放在一起看，很有说服力。有一次我们花了两个迭代把回归用例从1200条压缩到700条，执行时间从3天降到1.5天，发布后缺陷率没有上升，反而因为精力更集中在高风险区域而略有下降。这个结果拿出来，团队里再也没人质疑“删用例会漏测”了。
这里想特别提醒一点：别用“单轮执行发现缺陷数”来做瘦身后的评估指标。因为用例变少之后，单轮发现的缺陷数大概率会下降，但很多缺陷本来就不是靠回归用例发现的。真正能说明问题的是“回归集有没有漏掉高风险缺陷”，这个只能通过统计发布后的线上缺陷来源来验证，周期要拉长至少两个版本。
4. 常见误区与避坑指南
用例瘦身是一个长期迭代的过程，过程中很容易走偏。我在做这件事的几年里，踩过一些坑，也见过团队走弯路，把下面这几个典型误区列出来，给大家提个醒。
| 误区 | 典型表现 | 正确做法 |
|---|---|---|
| 砍过头 | 把异常场景、边界场景全删了，只留正向链路 | 优先砍“重复覆盖”和“低风险冗余”，保留异常和边界用例 |
| 只删不补 | 清理完用例后不做覆盖度复核 | 每次清理后做一轮“逻辑覆盖复核”，确认高风险路径仍有对应用例 |
| 用例瘦身变成追KPI | 为了数字好看，盲目合并、删除，甚至把本来清晰的用例改得晦涩难懂 | 瘦身的目标是“用更少用例覆盖更多风险”，不是单纯追求数量少 |
| 只有测试人员参与 | 用例评审和清理变成测试团队内部的事，开发、产品都不参与 | 邀请开发和产品一起评审，需求变更信息能第一时间同步到用例调整 |
| 从不对自动化用例瘦身 | 手工用例精简了，自动化脚本越堆越多，执行时间越来越长 | 自动化用例同样执行定期评审，长期失败的、断言无效的脚本要及时修复或删除 |
4.1 用心得：失败过的用例瘦身怎么救
有一年我们团队做了一次比较激进的用例清理，一个核心交易模块的用例从400多条直接砍到120条。清理完看起来特别清爽，但下一个迭代就在预发环境漏了一个严重缺陷，是一个二级页面在特定数据类型下的展示异常，当时测试团队被运营和产品连环追问，过程相当痛苦。
复盘后发现问题的根源不在于删错了用例，而是删除时没有保留“覆盖度记录”。当时只关注了“删了多少条”，没有把每条已删除用例对应的需求点、逻辑分支记录下来，结果事后想去验证“这个场景原先有没有用例覆盖”时，根本查不到。
从那以后我养成了一个习惯：每次批量删除用例前，先导出一份“待删用例清单”，把每条用例覆盖的需求点、验证的规则、删除原因写清楚，在PR中附上这份清单。这样即使后来发现覆盖缺口，也能快速回溯。这个习惯我一直用到现在，强烈推荐。
实操心得：如果你接手的是一个已经严重肥胖的用例库，别想着“一次性清理到位”，那太容易出事故了。我的建议是分三步走：第一轮只清理“功能已下线或需求已变更”的确定废弃用例；第二轮清理“与其他用例完全重复”的用例；第三轮才动“低风险但还在功能范围内”的用例。每一轮间隔一个迭代，边清理边观察线上质量，稳扎稳打。
4.2 用心得：怎么让团队甘愿做减法
做用例瘦身最难的地方，其实不是方法论，而是人心。很多测试同学对删用例非常抵触，总觉得“万一测出了问题，是不是因为我删了这条用例？”这种情绪完全能理解，强行推只会让团队更保守。
我的做法是先把“瘦身”定性成“测试设计优化”，让团队看到删掉的用例换来了什么。比如把回归时间缩短后省下来的时间，拿去探索性测试或者补自动化，这两个方向对测试人员的成长价值远大于机械执行用例。团队有了实实在在的正向反馈，再去推动用例清理，阻力就小了。
还有一个比较实际的手段：用例评审时把“用例总数”和“缺陷检出数”的比值作为一个参考指标。同样的缺陷检出效果下，用例数越少，测试设计能力越强。这个比值我会在周会或者迭代复盘里带上，让团队成员直观感受到“少而精”的力量。
结尾：一条我用得最久也最省心的“瘦身习惯”
如果这9个技巧只能留一条，我会留“定期评审+淘汰机制”这条。因为它不依赖某个人的设计能力，不依赖工具的智能化程度，只需要一个稳定的节奏和一点敢删的勇气。就算其他技巧暂时用不上，你只要坚持每个迭代都问一次“这些用例还有没有存在价值”，用例库就很难发胖。
我自己现在管项目，最省心的状态就是打开回归集，里面每一条用例都能说清楚“为什么要写它”“它覆盖了什么风险”。遇到版本变更，能在半小时内判断哪些用例受影响、哪些用例要废弃。这种可控感，比任何花哨的测试技术都让人踏实。
最后分享一个小技巧：清理完用例之后，记得把“瘦身的过程和理由”写在测试总结里，发给团队和项目组。不只是留个记录，更是让所有人意识到——用例不是越多越好，测试的价值从来都不取决于数量，而取决于它是否在最关键的地方守住了质量底线。
