按等价类划分设计用例后仍然漏测，通常说明覆盖在某个环节断了：类清单本身不完整、边界值与条件组合没有单独设计、划分依据存在歧义，或者用例虽已设计但执行时的环境与数据并未真正覆盖。本文按“症状分类—原因假设与证据—排查处置—验证防复发”的顺序展开，聚焦用例设计与内容质量，不涉及脚本实现和跨项目资产复用。
要点总览（TL;DR）
- 按等价类划分仍漏测，先看缺陷落在哪里：已划分类内部、类边界附近、多条件组合处、未识别的新类，四类位置对应不同失效环节。
- 常见原因有五类：类清单不完整、边界值未单独覆盖、缺少条件组合与场景串联、划分依据有歧义、执行环境与数据未真实覆盖；每类都要用证据验证后再定性。
- 排查按先设计后执行的顺序：复核类清单、补边界值、补组合与场景、核对追溯关系、抽查执行记录；划分依据有根本歧义时先澄清再补用例。
- 补漏效果用已漏测缺陷回放验证，并在用例评审和缺陷关闭环节设置检查点；单次回放通过不等于长期有效，需按周期和样本量观察。
漏测的表现与排查范围
先看缺陷落在哪里，能快速缩小排查方向。按等价类划分后仍漏测，缺陷位置通常集中在四类区域，每类对应的失效环节不同。
| 缺陷位置 | 典型表现 | 优先怀疑的环节 |
|---|---|---|
| 已划分的类内部 | 缺陷输入落在某个有效类中，但该类只有代表值用例，代表值恰好绕开了缺陷触发条件 | 类内取值代表性不足，或类划分粒度过粗 |
| 类边界附近 | 缺陷出现在临界值、空值、最大值、最小值、长度临界点 | 边界值未单独设计用例 |
| 多条件组合处 | 单字段单独测试均正常，两个及以上条件同时取特定值时出错 | 只做单条件划分，缺少组合覆盖 |
| 未识别的新类 | 缺陷输入属于需求中未描述、类清单中不存在的输入域 | 划分依据不完整或需求理解有偏差 |
在此基础上还要区分两类症状。设计遗漏表现为类清单或用例本身缺失，翻遍用例库也找不到能命中该缺陷的条目；执行遗漏表现为用例存在，但执行时的环境、数据或前置状态与设计不一致，覆盖没有真实发生。两类症状的排查入口不同：前者回到需求和类清单，后者回到执行记录和环境配置。
本文的排查边界限定在用例设计与内容质量，包括类清单完整性、边界与组合覆盖、用例与需求的可追溯性、执行记录的真实性。测试脚本的编写缺陷、自动化框架问题，以及跨项目的用例资产复用策略，属于其他环节，本文不展开。
常见原因假设与逐项排除证据
下面五类原因在排查中出现的频率较高，但在拿到证据之前都只能作为假设。每类假设都配有验证动作和判定标准，验证通过才升级为确定原因。
| 原因假设 | 验证动作 | 判定为真的证据 |
|---|---|---|
| 假设一：等价类清单不完整，有效类或无效类有遗漏 | 重走需求文档，逐条比对输入域与类清单 | 存在需求中明确描述、类清单中却没有对应条目的输入域 |
| 假设二：边界值未单独覆盖，只取了类内代表值 | 检查每个类的边界点、临界值是否有独立用例 | 边界附近有缺陷，但用例集中找不到针对该临界值的条目 |
| 假设三：只做单条件划分，未考虑条件组合与场景串联 | 列出条件交互矩阵，核对组合用例 | 缺陷由两个及以上条件同时触发，而用例均为单条件设计 |
| 假设四：划分依据本身有歧义或缺失 | 与需求方逐条确认规格、接口文档中的模糊表述 | 同一输入域存在两种合理解读，类清单只按其中一种划分 |
| 假设五：执行侧环境、数据、前置状态与设计不一致 | 比对执行记录与实际数据、环境配置 | 用例标记为通过，但执行时的数据或状态与用例前置条件不符 |
假设一的验证重点是“逐条比对”而不是“整体浏览”。实际操作中，把需求中的每个输入域、每个状态迁移单独列出来，与类清单做一对一勾对，遗漏往往出现在异常输入、权限差异、空值与特殊字符这类容易被一笔带过的区域。无效类的遗漏尤其常见，因为设计时注意力更多放在正常流程上。
假设二的验证要区分“类内代表值”和“边界值”两个概念。等价类划分保证类内一个代表值可以代表整类，但缺陷恰恰高频出现在类的边缘：数值的上下限、字符串的长度临界、集合的空与非空、时间的起止点。如果用例集中每个类只有一个中间值用例，边界基本处于未覆盖状态。
假设三需要借助条件交互矩阵来验证。把影响同一业务结果的多个输入条件列为行与列，标出两两组合中哪些已被用例覆盖。缺陷常出现在“单个条件都合法、组合起来触发异常”的位置，例如金额与折扣同时取边界、状态与角色交叉。场景串联则是另一层：多个步骤按业务顺序执行时，中间状态是否被验证。
假设四容易被忽略，因为划分依据错了，后面所有用例看起来都“有据可依”。验证方式是把需求、规格、接口文档中表述模糊的地方逐条列出，与需求方确认唯一解释。若确认后发现原划分基于错误理解，需要重做类清单，而不是在旧清单上打补丁。
假设五属于执行侧问题，验证时抽查执行记录：用例标注通过的时间点，实际环境版本、测试数据、账号权限是否与用例前置条件一致。常见情形是数据被复用后状态已改变，或用例在简化环境下执行，覆盖并未真实发生。
按排查顺序的处置步骤
排查按“先设计、后执行”的顺序推进，每一步有明确的产出和停止点。修改既有用例集之前，先备份或保留版本记录，避免覆盖历史执行结果，影响后续回溯。
第一步：复核需求与类清单。以需求文档为基准，逐条列出输入域、状态和异常路径，与现有类清单勾对，补齐遗漏的有效类和无效类。完成标志是每个需求条目都能在类清单中找到对应类，或明确标注不适用及理由。
第二步：为每个类补充边界值与临界值用例。对数值、长度、数量、时间等可度量输入，取上界、下界及其相邻值；对集合类输入，覆盖空、单元素、满员等状态。完成标志是每个类的边界点都有独立可执行的用例条目。
第三步：梳理多条件交互，补充组合与场景级用例。先列出影响同一结果的条件，用两两组合矩阵找出未覆盖的组合，再针对核心业务链路补充端到端场景用例，验证中间状态和步骤衔接。完成标志是高风险组合均有对应用例，核心链路有场景级覆盖。
第四步：核对用例与需求的可追溯关系。逐条检查用例是否挂接到对应需求或任务，标记无需求依据的用例和无用例覆盖的需求条目。前者需要确认来源或清理，后者需要补设计。完成标志是追溯关系完整，悬空条目有处理结论。
第五步：抽查执行记录与环境数据。抽取标记通过的用例，核对执行时的环境版本、测试数据和前置状态是否与设计一致。发现不一致的，重新执行并记录真实结果。完成标志是抽查样本中执行条件与设计一致，或已识别出需重跑的用例清单。
处置过程中有两个停止点需要交代。其一，若第一步发现划分依据本身存在根本性歧义，应先与需求方澄清并重做类清单，暂停在旧清单上继续补用例，否则补得越多返工越大。其二，若第五步抽查发现大面积执行条件不符，应先修复执行流程和环境管理，再评估已通过用例的可信度，避免把不可信的执行结果当作覆盖证据。
在用例评审和缺陷回溯环节，工具承载的是追溯与流转动作。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，便于在第四步核对追溯关系时直接查看用例挂接情况；用例模块支持树状结构与拖拽排序，可按输入域或业务模块分层组织类清单与用例；自定义用例属性可用于标记边界用例、组合用例等设计类型，方便评审时按类型检查覆盖。缺陷回溯时，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，便于把“该缺陷对应哪个类缺失”的记录随缺陷一起闭环。
验证补漏效果与防止复发
补漏完成后，最直接的验证方式是用已漏测的缺陷回放：把触发该缺陷的输入、条件组合或操作序列，对照新补充的类或用例，确认存在能命中它的条目，并在对应环境执行一次，观察是否能够暴露该缺陷。回放命中的条目应记录在缺陷回溯信息中，作为该类已补齐的证据。
缺陷回溯是防止复发的入口。对每个漏测缺陷追问三个问题：它属于哪个输入域，该输入域在类清单中是否存在，若存在为何没有对应用例。答案会指向具体失效环节——类缺失、边界未设计、组合未覆盖、依据有误或执行失真。把结论记录在缺陷关闭信息里，形成可检索的回溯记录。
机制层面可以设置三个检查点。其一，在用例评审中把“类清单完整性、边界值覆盖、条件组合覆盖”列为固定评审项，评审时逐项确认而非凭印象判断。其二，在缺陷关闭环节增加“是否需补充等价类或用例”的判断项，要求关闭人明确回答，避免同类缺陷再次出现时仍无对应用例。其三，定期抽样比对类清单与需求变更记录，需求新增或修改后同步更新类清单，防止清单随需求演进而滞后。
需要说明验证的局限：单次缺陷回放通过，只证明这一个缺陷对应的类已补齐，不能证明整体覆盖充分。补漏效果需要一定周期和样本量观察，例如连续几个迭代中同类输入域的漏测缺陷是否下降、评审中发现的类缺失是否减少。把回放结果、回溯记录和评审发现放在一起看，才能判断补漏是否真正生效，以及下一轮排查应从哪个环节加强。
常见问题
等价类划分和边界值分析是什么关系，只做等价类够不够？
等价类划分解决的是“类内取一个代表值即可代表整类”，它保证的是类内覆盖，不自动覆盖类的边缘。边界值分析针对的正是类的上下限、临界值、空值、长度临界点这些位置，而缺陷高频出现在边缘而非类中部。
因此只做等价类划分、每个类只放一个中间值用例，边界基本处于未覆盖状态。实践中两者配合使用：先划分有效类与无效类，再为每个类补充边界点及其相邻值的独立用例。
无效等价类的用例经常被跳过，这会直接导致漏测吗？
会提高漏测概率，尤其是异常输入、权限差异、空值与特殊字符这类区域。设计时注意力通常集中在正常流程，无效类容易被一笔带过，类清单里没有对应条目，用例集自然也没有能命中异常输入的条目。
排查时把需求中的每个输入域单独列出，与类清单做一对一勾对，重点检查无效类是否有独立条目。补齐无效类后，建议为每个无效类至少设计一条可执行的异常路径用例。
用例都标记通过了，怎么判断是设计遗漏还是执行遗漏？
看用例库里是否存在能命中该缺陷的条目。翻遍用例库找不到对应条目，属于设计遗漏，排查入口回到需求和类清单；条目存在但执行时的环境版本、测试数据或前置状态与用例设计不一致，属于执行遗漏，排查入口回到执行记录和环境配置。
执行遗漏的常见情形是数据被复用后状态已改变，或用例在简化环境下执行。抽查标记通过的用例，核对执行条件与设计是否一致，可以识别出需要重跑的用例清单。
补完用例后，怎么确认补漏真的有效？
最直接的方式是用已漏测的缺陷回放：把触发该缺陷的输入、条件组合或操作序列，对照新补充的类或用例，确认存在能命中它的条目，并在对应环境执行一次，观察是否暴露该缺陷。命中条目记录在缺陷回溯信息中，作为该类已补齐的证据。
回放通过只证明这一个缺陷对应的类已补齐，不能证明整体覆盖充分。还需要按周期观察同类输入域的漏测缺陷是否下降、评审中发现的类缺失是否减少，把回放结果、回溯记录和评审发现放在一起判断。
需求频繁变更时，类清单怎么维护才不滞后？
把类清单与需求变更记录定期抽样比对，需求新增或修改后同步更新类清单，而不是等下一轮漏测再回头补。用例与需求保持关联关系，需求变更时能快速定位受影响的用例条目。
ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，便于在需求变更后核对用例挂接情况；用例模块支持树状结构与拖拽排序，可按输入域或业务模块分层组织类清单与用例；自定义用例属性可用于标记边界用例、组合用例等设计类型，方便评审时按类型检查覆盖。
