测试结果汇总表按“结论—统计—明细—风险”四层组织，先定口径再定列，让每个数字都能回溯到明细记录。本文给出一套可直接套用的展示结构、指标口径定义、字段清单、角色分工与交付前核对清单，适用于单个测试轮次或版本的汇总，不涉及组织级质量趋势与发布门禁设计。
要点总览（TL;DR）
- 汇总表按“结论—统计—明细—风险”四层组织：结论区先给版本判断和关键数字，统计区按模块汇总，明细区逐条可追溯，风险区集中交代遗留与后续动作。
- 先定口径再定列：通过率固定为“通过用例数÷执行用例数”，分母不含未执行用例；阻塞与未执行分别列示，口径说明放在独立说明区并注明统计时点。
- 统计区字段以模块/需求为行，含用例数、执行数、通过率、缺陷数、遗留数；明细区必填用例编号、关联需求、执行结果、缺陷编号、责任人、执行日期。
- 测试执行人即时更新明细，测试负责人核对后汇总统计与结论，开发确认缺陷状态，产品确认影响判断；按轮次和版本两个粒度出表。
- 交付前逐项核对：统计与明细加总一致、失败用例均关联缺陷、口径说明齐全、风险写明影响与责任人、表内标注版本轮次与出表日期。
汇总表先定四层结构：结论、统计、明细、风险
汇总表的读者通常分两类：需要快速判断版本状态的管理者，和需要核对具体执行情况的测试、开发人员。四层结构让两类读者各取所需——上层给判断，下层给证据。设计时先搭骨架，再往里填字段和口径。
四层职责与排列理由
| 层级 | 回答的问题 | 主要内容 | 位置 |
|---|---|---|---|
| 结论区 | 这个版本测试得怎么样，能不能进入下一环节 | 整体判断、关键数字（用例总数、通过率、未关闭缺陷数、阻塞项数） | 表格最上方，单页首屏可见 |
| 统计区 | 各模块的执行与缺陷分布如何 | 按模块或需求汇总的用例数、执行数、通过率、缺陷数、遗留数 | 结论区之下 |
| 明细区 | 每个数字由哪些记录构成 | 用例编号、关联需求、执行结果、缺陷编号、责任人、执行日期 | 统计区之下，或独立Sheet |
| 风险与遗留区 | 还有什么没解决，影响多大，下一步做什么 | 未关闭缺陷、阻塞原因、影响范围、后续动作与责任人 | 表格末尾或独立区块 |
排列顺序遵循“先结论后证据”的阅读习惯：管理者在结论区停留几十秒即可形成判断，需要追问时再向下查统计和明细。风险与遗留区放在最后，是因为它承接前三层的发现，把“数字背后的不确定性”集中交代，避免风险信息散落在各层被忽略。
单页与多页承载方式的选择
单页承载适合用例规模在几十到一两百条、模块数量少的轮次：结论、统计、风险三块放在同一页，明细区折叠或放在页面下方，读者滚动即可完成核对。多页（分Sheet）承载适合用例数百条以上、按模块或需求拆分明细的场景：第一页放结论、统计与风险，后续每页一个模块的明细，统计区的数字通过公式或引用与明细页对应。选择标准是用例规模与读者核对频率——需要频繁逐条核对时，分Sheet更清晰；只做整体判断时，单页更紧凑。
统计口径怎么定：用例、缺陷、通过率与阻塞
汇总表最常见的争议来自口径不一致：两个人报出的通过率不同，往往是因为分子分母定义不同。口径应在出表前书面固定，并在表内注明统计时点。
指标口径定义表
| 指标 | 计算方式 | 数据来源 | 统计时点 |
|---|---|---|---|
| 计划用例数 | 本轮测试范围内已评审通过的用例总数 | 用例库中标记为本轮范围的用例 | 测试开始前锁定 |
| 执行用例数 | 已有执行结果的用例数，含通过、失败、阻塞 | 用例执行记录 | 出表时刻 |
| 通过率 | 通过用例数 ÷ 执行用例数 | 用例执行记录 | 出表时刻 |
| 缺陷数 | 本轮测试发现并登记的有效缺陷数，按严重程度、状态、发现阶段分组 | 缺陷记录 | 出表时刻 |
| 遗留缺陷数 | 出表时刻仍未关闭的缺陷数，含已修复待验证 | 缺陷记录 | 出表时刻 |
| 阻塞用例数 | 因环境、依赖或前置缺陷无法执行的用例数 | 用例执行记录中标记为阻塞的记录 | 出表时刻 |
通过率的分子分母与常见歧义
通过率建议固定为“通过用例数 ÷ 执行用例数”，分母不含未执行用例。另一种做法是用“通过用例数 ÷ 计划用例数”，它反映的是整体覆盖进度，数值会因未执行用例多而偏低。两种算法各有用途，关键是同一份表内只用一个，并在表头注明。常见歧义有三处：失败后修复重测通过的用例算通过还是算失败（建议以最终执行结果为准，并在口径说明中写明）；阻塞用例是否计入分母（不计入，单独列示）；同一用例多轮执行时取哪一轮（取最新一轮）。
缺陷分组与阻塞、未执行的区别
缺陷数至少按三个维度分组：严重程度（致命、严重、一般、轻微）、状态（新建、处理中、待验证、已关闭）、发现阶段（冒烟、功能测试、回归）。分组口径固定后，不同轮次之间才可比较。阻塞与未执行是两种状态：阻塞指用例已开始执行但因环境或依赖中断，需要有人跟进解除；未执行指尚未开始，反映进度而非质量问题。两者对结论的影响不同——阻塞多说明测试推进受阻，未执行多说明覆盖不足，结论区应分别说明。
口径说明建议放在独立说明区，而不是塞进表头注释：指标多、定义长时，表头注释会挤占列宽且难以维护。独立说明区可随表附一页“口径与统计时点”，注明每个指标的计算方式、数据来源和出表时间。
字段与列设计：汇总表该有哪些列
字段设计以“统计区能汇总、明细区能追溯”为目标。统计区每行对应一个模块或需求，明细区每行对应一条用例执行记录。
统计区字段
| 字段 | 必填 | 填写示例 | 常见填错 |
|---|---|---|---|
| 模块/需求 | 必填 | 订单结算 | 模块名与需求名混用，导致跨表对不上 |
| 用例数 | 必填 | 48 | 把未评审用例计入 |
| 执行数 | 必填 | 45 | 把阻塞用例排除在执行数外 |
| 通过率 | 必填 | 86.7% | 分子分母口径与说明区不一致 |
| 缺陷数 | 必填 | 7 | 把重复缺陷或无效缺陷计入 |
| 遗留数 | 必填 | 2 | 把已修复待验证的缺陷算作已关闭 |
明细区字段
| 字段 | 必填 | 填写示例 | 常见填错 |
|---|---|---|---|
| 用例编号 | 必填 | TC-ORDER-012 | 手写编号与用例库不一致 |
| 关联需求 | 必填 | REQ-208 优惠券叠加 | 只填需求名不填编号，无法追溯 |
| 执行结果 | 必填 | 失败 | 结果用“OK/NG”等非标准写法 |
| 缺陷编号 | 失败时必填 | BUG-1043 | 失败用例未关联缺陷，统计区缺陷数对不上 |
| 责任人 | 必填 | 李敏 | 填团队名而非执行人 |
| 执行日期 | 必填 | 2025-03-12 | 只填轮次不填日期，无法判断时效 |
| 备注 | 选填 | 依赖支付沙箱，暂缓 | 把阻塞原因写在结果列 |
必填与选填的划分原则：凡参与统计计算的字段必填，凡用于解释异常的字段选填。明细区的执行结果建议使用固定枚举值（通过、失败、阻塞、未执行），避免自由文本导致汇总时无法归类。
角色分工与交付节奏
汇总表的质量取决于录入与审核的顺序：先有完整的明细，再有可信的统计，最后形成结论。角色分工按这个顺序安排。
| 角色 | 动作 | 产出 |
|---|---|---|
| 测试执行人 | 执行用例后即时更新执行结果，失败用例登记缺陷并回填缺陷编号 | 明细区记录 |
| 测试负责人 | 核对明细完整性，按口径汇总统计区，撰写结论与风险区，组织评审 | 统计区、结论区、风险区 |
| 开发 | 确认缺陷状态与修复情况，提供遗留缺陷的处理计划 | 缺陷状态更新、遗留说明 |
| 产品 | 确认需求范围与遗留问题的影响判断，参与结论评审 | 范围确认、风险影响意见 |
出表时点建议按轮次和版本两个粒度：每轮测试结束当天出轮次汇总，用于团队内部跟进；版本提测前出完整汇总，作为版本状态的书面记录。汇总表与缺陷记录、用例执行记录是引用关系——统计区数字来自明细区，明细区的缺陷编号指向缺陷记录，三者应能逐条对应。若团队使用ONES管理测试工作项，用例执行记录与缺陷可作为工作项关联到同一需求下，汇总时按需求或模块筛选即可得到统计区数据，减少手工搬运造成的对不上。
填写示例：一个版本的汇总表长什么样
以下为演示情景，数字仅用于说明结构，不代表真实项目数据。
结论区
本轮订单模块测试共计划用例 120 条，执行 112 条，通过率 85.7%（按执行用例计），发现有效缺陷 23 个，其中遗留 5 个（严重 1 个、一般 4 个），阻塞用例 3 条，阻塞原因为支付沙箱环境不稳定。整体判断：核心流程可用，遗留的 1 个严重缺陷需在提测前修复并回归，阻塞用例解除后需补测。
统计区
| 模块 | 用例数 | 执行数 | 通过率 | 缺陷数 | 遗留数 |
|---|---|---|---|---|---|
| 订单创建 | 40 | 40 | 90.0% | 6 | 1 |
| 订单结算 | 48 | 45 | 86.7% | 7 | 2 |
| 订单查询 | 32 | 27 | 77.8% | 10 | 2 |
明细区（节选）
| 用例编号 | 关联需求 | 执行结果 | 缺陷编号 | 责任人 | 执行日期 |
|---|---|---|---|---|---|
| TC-ORDER-012 | REQ-208 优惠券叠加 | 失败 | BUG-1043 | 李敏 | 2025-03-12 |
| TC-ORDER-015 | REQ-208 优惠券叠加 | 通过 | — | 李敏 | 2025-03-12 |
| TC-SETTLE-007 | REQ-215 结算金额校验 | 阻塞 | — | 王磊 | 2025-03-13 |
风险与遗留区
遗留缺陷 BUG-1043（严重）：优惠券叠加场景金额计算错误，影响下单结算，计划 3 月 14 日修复，修复后由李敏回归 TC-ORDER-012 及相关用例。阻塞用例 3 条集中在结算模块，依赖支付沙箱恢复，恢复后 1 个工作日内补测，责任人王磊。订单查询模块通过率偏低，主要因分页边界用例失败集中，已登记缺陷 4 个，需在下一轮重点回归。
完成检查：汇总表交付前的核对项
出表前按以下清单逐项核对，全部通过再交付：
- 统计区每个模块的用例数、执行数、缺陷数、遗留数，与明细区逐条加总一致；
- 失败用例均关联了缺陷编号，缺陷数与缺陷记录中的有效缺陷数一致；
- 口径说明区齐全，注明通过率算法、统计时点与数据来源；
- 阻塞与未执行用例分别列示，并写明阻塞原因与跟进人；
- 风险与遗留区每条都写明影响范围、后续动作和责任人；
- 结论区的判断与统计区数字一致，未出现结论说“通过”而统计区仍有严重遗留的情况；
- 表内标注版本号、测试轮次、出表日期与汇总人；
- 遗留缺陷的状态与开发确认一致，已修复待验证的缺陷未计入已关闭。
核对中发现数字对不上时，优先回到明细区定位差异记录，而不是直接调整统计区数字。汇总表的可信度来自每一行明细可查、每一个数字可算，这也是四层结构设计的出发点。
常见问题
用例数不多的小团队，也要按四层结构做汇总表吗？
四层结构可以按规模裁剪，但建议保留结论区和风险区。用例规模在几十条以内时，统计区可以只保留模块、用例数、执行数、通过率、遗留数几列，明细区折叠在页面下方或直接引用用例执行记录，风险区用两三句话说明遗留缺陷和阻塞项即可。结论区不能省，它是读者判断版本状态的入口；风险区也不能省，否则遗留问题容易在数字里被忽略。
同一用例多轮执行，通过率按哪一轮算？
建议取最新一轮执行结果，并在口径说明中写明“以出表时刻最新执行结果为准”。这样修复后重测通过的用例计为通过，反映当前真实状态。如果团队需要观察修复效果，可以在统计区旁另设一列“首轮通过率”作为对照，但两个指标要分别注明算法，避免混用。跨轮次比较时，确保各轮采用同一取数规则。
阻塞用例解除后，汇总表需要重新出一次吗？
视阻塞对结论的影响而定。如果阻塞用例集中在核心流程，解除后应补测并更新汇总表，至少更新统计区对应模块的执行数、通过率和结论区判断，同时在风险区记录补测结果。如果阻塞用例属于边缘场景且不影响版本判断，可在下一轮汇总中合并体现，但需在风险区注明补测计划与责任人，避免遗留项失去跟踪。
汇总表里的缺陷数和缺陷管理系统里的数字对不上，怎么处理？
先确认两边的统计范围是否一致：汇总表统计的是本轮测试范围内发现的有效缺陷，缺陷系统里可能包含其他轮次、其他模块或无效缺陷。核对时按缺陷编号逐条比对，重点检查失败用例是否都回填了缺陷编号、重复缺陷是否已合并、已修复待验证的缺陷是否被误计为已关闭。差异定位到具体记录后再调整，不要直接改统计区数字。若团队在ONES中管理测试与缺陷工作项，可按需求或模块筛选后取数，减少手工搬运造成的口径偏差。
结论区写“可以提测”还是写具体判断，有推荐写法吗？
建议写具体判断加条件，例如“核心流程可用，遗留的1个严重缺陷需在提测前修复并回归，阻塞用例解除后需补测”。这种写法把结论与统计数字、风险区条目对应起来，读者能直接看到判断依据和前置条件。避免只写“通过”“基本通过”这类无法核对的表述，也避免在结论区展开细节，细节留给统计区和风险区。
