检查等价类划分是否覆盖有效类、无效类和异常类，核心是把每个输入条件的输入域拆成三类清单，再与用例标注做双向核对：从类清单查用例，从用例反查类清单。判断依据是类清单与用例标注能否互相对应，用例条数只作参考。有效类、无效类、异常类需要分开统计，避免合并后的总数掩盖某一类遗漏。
要点总览（TL;DR）
- 检查等价类覆盖的核心是双向核对：从类清单查用例、从用例反查类清单，两者能对上才算覆盖。
- 有效类、无效类、异常类要按输入条件分别列清单，类编号统一格式，作为后续核对和统计的基准。
- 覆盖率按三类分别计算，分母是类数而不是用例条数；未标注类编号的用例单独列出，不计入已覆盖。
- 覆盖率100%只说明每个类至少有一条用例，充分性还要看代表值选取、预期结果完整性和遗漏清单的处理结论。
- 输入条件多时按条件分组统计，避免总数掩盖某个条件的遗漏。
检查覆盖前先明确评估目标
等价类覆盖检查容易滑向“数用例”的误区：用例看起来不少，却说不清哪些输入条件已被覆盖、哪些类还没有对应用例。开始核对前，先把这次检查要回答的问题写清楚，后续统计口径和结论才有落点。
检查对象是等价类划分结果与用例之间的对应关系，包含两个层次。第一层是“类是否齐全”：针对每个输入条件，有效类、无效类、异常类是否都已列出，有没有整类缺失。第二层是“类是否被用例覆盖”：已列出的每个类，是否存在至少一条标注了该类编号的用例。两层要分开检查，类本身缺失时，覆盖率再高也说明不了问题。
检查结论的用途也要提前说明。用于用例评审时，重点是遗漏清单和补充建议，结论可以带“待补充”状态；用于测试准出时，需要给出三类覆盖率数字、未覆盖类清单及风险说明，并明确哪些遗漏可以接受、哪些必须补齐。建议在评估目标说明中列出2–3个具体问题，例如“手机号输入条件的无效类是否全部有用例”“异常类覆盖率是否达到本阶段要求”“未标注类编号的用例有多少条”，并注明这份结论提交给谁、在哪个环节使用。
有效类、无效类、异常类的划分口径
三类等价类的界定标准是后续所有核对的基准。口径不统一，覆盖率就算得再精确，结论也不可靠。划分时按每个输入条件分别建表，一个条件一张清单，避免多个条件混在一张表里导致编号和统计串行。
| 类型 | 界定标准 | 典型取值 | 预期处理结果 |
|---|---|---|---|
| 有效类 | 输入域内合法、应被系统正常处理的取值集合 | 符合格式与范围的常规值 | 正常受理并返回预期结果 |
| 无效类 | 格式或范围不合规、应被拒绝的取值集合 | 格式错误、超出允许范围、类型不符 | 明确拒绝并给出提示 |
| 异常类 | 边界外、空值、超长、特殊字符、并发或依赖异常等需要单独处理的输入 | 空输入、超长字符串、特殊字符、依赖服务不可用 | 异常被捕获并妥善处理，不产生错误数据 |
清单表建议包含五列：输入条件、类编号、类描述、代表值、类型。类编号采用“条件缩写-类型-序号”的格式，例如“手机号-有效-01”“手机号-无效-02”“手机号-异常-01”，便于用例标注和统计时直接引用。代表值一列填写该类中用于设计用例的具体取值，同一类可以填多个代表值，但统计时按类计数。
有效类与无效类的边界要写清楚依据，例如长度范围、格式规则、取值范围来自哪份需求或接口文档。异常类容易被合并进无效类，建议单独成列：无效类回答“不合规输入是否被拒绝”，异常类回答“异常输入是否被安全处理”，两者的预期结果和证据形式不同，混在一起会削弱检查的针对性。
覆盖检查的数据口径与证据
覆盖判断需要可复核的证据，证据来自用例上的类标注。每条用例应标注所属输入条件和类编号，一条用例覆盖多个类时逐一标注，标注信息与类清单使用同一套编号。没有标注的用例无法证明覆盖了哪个类，在统计中单独列出，不计入已覆盖。
统计口径以“类”为分母，不以用例条数为分母。用例条数多，可能集中在少数几个类上反复设计，遗漏的类依然存在；以类计数才能直接暴露空白。缺失值处理规则同样要写进口径说明：未标注类编号的用例进入“待标注清单”，既不算覆盖，也不从用例总数中删除，便于后续补标。
异常类的覆盖需要独立证据，例如用例中写明预期错误提示、异常处理结果或系统状态保持正常的检查点。仅有“输入异常值”的操作步骤，没有对应的预期结果，不能算作异常类已覆盖。评审时可以把这类用例标为“证据不足”，与“未覆盖”分开管理。
输入条件较多时，按条件分组维护清单和统计表，每个条件单独一行汇总，再汇总到整体。分组统计是防止遗漏的主要手段：总数看起来不错，某个条件的异常类可能一条用例都没有。
覆盖率的计算与核对步骤
覆盖率按三类分别计算，公式统一：
- 有效类覆盖率 = 已覆盖有效类数 ÷ 有效类总数 × 100%
- 无效类覆盖率 = 已覆盖无效类数 ÷ 无效类总数 × 100%
- 异常类覆盖率 = 已覆盖异常类数 ÷ 异常类总数 × 100%
分子是至少有一条已标注用例对应的类数，分母是该类清单中的类总数。三类分别计算、分别报告，不合并成一个总覆盖率。某个输入条件没有异常类时，分母为零，应记录“该条件未划分异常类”并说明原因，不能写成100%。
核对按以下顺序进行：
- 从类清单查用例：逐条读取类编号，在用例标注中检索是否存在对应用例，找不到的记入遗漏清单。
- 从用例反查类清单：逐条读取用例的类标注，核对编号是否存在于类清单，找不到的记为“标注无效”，可能是编号写错或类清单漏列。
- 单独整理未标注类编号的用例，形成待标注清单。
- 按输入条件分组统计三类覆盖率，再汇总整体数字。
- 输出遗漏清单，注明每个遗漏类的类型、所属条件和建议补充的用例方向。
双向核对的价值在于两个方向会暴露不同问题：从类查用例发现覆盖空白，从用例查类清单发现标注错误和清单缺项。只做一个方向，容易把标注混乱误判为覆盖充分。
用一个输入条件走完检查过程
以“手机号”输入条件为例演示完整过程。假设需求规定手机号为11位数字、以1开头，系统需校验格式并处理空值和超长输入。
| 类编号 | 类描述 | 代表值 | 类型 | 对应用例 |
|---|---|---|---|---|
| 手机-有效-01 | 11位、以1开头的合法号码 | 13800000000 | 有效类 | TC-101 |
| 手机-无效-01 | 位数不足 | 1380000 | 无效类 | TC-102 |
| 手机-无效-02 | 含非数字字符 | 138abc00000 | 无效类 | TC-103 |
| 手机-无效-03 | 首位不为1 | 23800000000 | 无效类 | 无 |
| 手机-异常-01 | 空值 | 空字符串 | 异常类 | TC-104 |
| 手机-异常-02 | 超长输入 | 20位数字 | 异常类 | 无 |
初次核对结果：有效类1个、已覆盖1个，覆盖率100%；无效类3个、已覆盖2个，覆盖率约66.7%；异常类2个、已覆盖1个，覆盖率50%。遗漏清单包括“手机-无效-03”和“手机-异常-02”。同时发现TC-104只写了输入空值，未写预期提示，证据不足，需补充预期结果后才计入异常类覆盖。
补充用例后：新增TC-105覆盖首位不为1的号码，预期提示格式错误；新增TC-106覆盖超长输入，预期提示长度超限且系统不写入数据；TC-104补写预期提示。复核后无效类覆盖率100%，异常类覆盖率100%。前后对比说明，覆盖率提升来自补齐遗漏类和补足证据，用例总数只增加了两条。
这个例子也说明按条件分组的意义：如果只看整体数字，手机号条件的两个遗漏很容易被其他条件的覆盖情况稀释。输入条件多时，每个条件都按同样流程走一遍，遗漏清单按条件归档。
当类清单和用例标注需要在团队间共享和追溯时，可以把类编号作为用例属性维护在测试用例管理工具中。ONES TestCase 支持自定义用例属性，用例库中的属性支持筛选，便于按类编号检索对应用例；用例与需求、任务关联，测试计划与迭代关联，检查结论可以沿着需求到用例的链路回溯。用例模块的树状结构可以按输入条件组织用例，清单与用例的对应关系更直观。
如何解读覆盖率并判断是否充分
覆盖率100%的含义是每个类至少有一条用例，它证明的是覆盖动作已完成，不证明代表值选得合理，也不证明用例能发现缺陷。判断充分性需要把覆盖率与代表值质量、预期结果完整性一起看。
三类覆盖率应分开解读。有效类覆盖率高，说明正常路径的输入组合有基本保障；无效类和异常类覆盖率低，意味着拒绝逻辑和异常处理缺少验证，这类遗漏在联调和上线阶段往往代价更高。把三类合并成一个总数，会掩盖无效类和异常类的薄弱环节。
充分性判断可以参考以下条件：
- 三类覆盖率分别达到本阶段约定要求，且没有未说明原因的零分母项；
- 每个已覆盖类都有明确的代表值和预期结果，异常类有可核验的处理证据；
- 未标注类编号的用例已清零或已列入补标计划；
- 高风险输入条件的无效类和异常类优先补齐，组合场景按风险决定是否补充；
- 遗漏清单中的每一项都有处理结论：补充用例、说明可接受理由或转入后续迭代。
常见误读有三种：把用例条数当作覆盖证据；用总覆盖率替代分类覆盖率；认为覆盖率达标就可以停止设计。覆盖率是覆盖证据，缺陷发现能力还取决于代表值选取、预期结果设计和执行质量。输入条件复杂度高、业务风险大的模块，即使三类覆盖率都达到要求，也建议针对关键条件补充组合场景，并在结论中注明补充范围和理由。
常见问题
用例没有标注等价类编号，还能算覆盖吗？
不能直接算作覆盖。没有类编号标注的用例，无法证明它对应的是哪个类，在统计中应单独列入待标注清单，既不计入已覆盖，也不从用例总数中删除。处理方式有两种：一是补标类编号后重新核对，二是确认该用例确实对应某个遗漏类后补入覆盖统计。如果团队用例量大，建议在用例设计阶段就把类编号作为必填属性，减少事后补标的工作量。
某个输入条件没有划分异常类，覆盖率应该怎么记？
分母为零时不能写成100%，应记录“该条件未划分异常类”并说明原因。常见原因包括该输入条件不存在并发或依赖异常场景，或异常处理由上游系统统一承担。无论哪种原因，都要在结论中写明依据，便于评审时判断这个零分母是否合理。如果评审认为该条件实际存在异常场景，则应回到类清单补充异常类，再重新统计。
三类覆盖率都达到100%，还需要继续补充用例吗？
是否补充取决于风险判断，覆盖率达标不是停止设计的唯一依据。三类覆盖率100%说明每个类至少有一条用例，但代表值是否选在类内典型位置、预期结果是否写全、异常类是否有可核验的处理证据，都需要单独检查。输入条件复杂、业务风险高的模块，建议针对关键条件补充组合场景，并在结论中注明补充范围和理由。风险较低的模块可以在遗漏清单全部有处理结论后结束本轮检查。
输入条件很多时，怎样避免某个条件的等价类被整体遗漏？
关键是把清单和统计都按输入条件分组，一个条件一行汇总，再汇总到整体。分组后每个条件的有效类、无效类、异常类数量都单独可见，某个条件整类缺失会直接暴露在分组表里，不会被其他条件的覆盖情况稀释。核对时按条件逐个走完“列类—标注—统计—遗漏清单”的流程，遗漏清单也按条件归档，便于分工补充。
等价类编号和用例标注在工具里怎么维护更方便追溯？
可以把类编号作为用例属性维护，与类清单使用同一套编号规则。ONES TestCase 支持自定义用例属性，用例库中的属性支持筛选，便于按类编号检索对应用例；用例与需求、任务关联，测试计划与迭代关联，检查结论可以沿着需求到用例的链路回溯。用例模块的树状结构可以按输入条件组织用例，清单与用例的对应关系更直观。
