测试结果汇总模板用于把一轮测试的执行情况、缺陷情况和版本结论放在同一份记录里，便于测试、研发和项目负责人对同一组数据形成一致判断。本文提供可直接复制的四张空白表，逐字段说明统计口径，并给出一份完整填写样例，适合版本测试收尾、迭代验收和测试轮次汇报等场景使用。
要点总览（TL;DR）
- 模板由四张表组成：版本与测试轮次基本信息、用例执行统计、缺陷统计、结论与遗留问题，四张表共用同一版本号和轮次标识。
- 执行统计按模块分行，执行率=已执行数÷计划用例数，通过率=通过数÷已执行数，分母不含阻塞和未执行用例。
- 缺陷统计按致命、严重、一般、轻微四级和新增、已修复、待修复、已验证关闭、挂起/延期五种状态展开，修复率=（已修复+已验证关闭）÷新增。
- 版本号、测试范围、负责人、执行数据、遗留清单和版本结论为必填；缺失数据统一标注“0”“未统计”“不适用”，三种标注不混用。
- 小团队可精简模块行和缺陷等级，多模块项目增加模块组列；字段变更需记录版本并同步更新口径说明。
可复制空白模板：测试结果汇总表
模板由四张表组成：基本信息、用例执行统计、缺陷统计、结论与遗留问题。四张表使用同一套版本号和测试轮次标识，复制到文档或表格工具后按行填写即可。模块数量、缺陷等级数量可按项目情况增删行，字段名称保持不变，便于多轮汇总时横向对比。
表1 版本与测试轮次基本信息
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 版本号 | |
| 测试轮次 | |
| 测试类型 | |
| 测试范围 | |
| 测试环境 | |
| 测试起止时间 | |
| 测试负责人 | |
| 参与人员 | |
| 需求/变更单号 | |
| 汇总日期 |
表2 用例执行统计（按模块分行）
| 模块 | 计划用例数 | 已执行数 | 通过数 | 失败数 | 阻塞数 | 未执行数 | 执行率 | 通过率 |
|---|---|---|---|---|---|---|---|---|
| 合计 |
表3 缺陷统计（按严重程度与状态）
| 严重程度 | 新增 | 已修复 | 待修复 | 已验证关闭 | 挂起/延期 | 修复率 |
|---|---|---|---|---|---|---|
| 致命 | ||||||
| 严重 | ||||||
| 一般 | ||||||
| 轻微 | ||||||
| 合计 |
表4 结论、遗留问题与后续动作
| 项目 | 填写内容 |
|---|---|
| 版本结论 | |
| 结论依据 | |
| 遗留缺陷清单（编号/等级/影响） | |
| 遗留风险说明 | |
| 后续动作（责任人/时间） | |
| 结论确认人及日期 |
字段说明：每个字段填什么、按什么口径统计
同一份模板在不同团队填写时，最容易出现分歧的是通过率、执行率和阻塞的定义。下表把每个字段的含义、计算方式和数据来源写清楚，填写前先确认口径，汇总结果才具备可比性。
| 字段 | 含义 | 统计口径 | 填写来源 |
|---|---|---|---|
| 版本号 | 本次测试对应的发布版本标识 | 与构建包或发布单保持一致，不自行简化 | 发布记录、构建系统 |
| 测试轮次 | 同一版本内的第几轮测试 | 按轮次顺序编号，回归测试单独计轮 | 测试计划 |
| 测试范围 | 本轮覆盖的功能模块与不测内容 | 列出模块名，明确排除项 | 测试计划、需求单 |
| 计划用例数 | 本轮纳入执行的用例总数 | 以测试计划中勾选的用例为准，不含未纳入本轮的历史用例 | 用例管理记录 |
| 已执行数 | 已产生通过或失败结果的用例数 | 已执行数 = 通过数 + 失败数；阻塞与未执行不计入已执行 | 用例执行记录 |
| 阻塞数 | 因环境、依赖或前置缺陷无法执行的用例数 | 需在备注中写明阻塞原因，解除后转入执行 | 用例执行记录 |
| 执行率 | 本轮执行进度 | 执行率 = 已执行数 ÷ 计划用例数 × 100% | 由表2数据计算 |
| 通过率 | 已执行用例中通过的比例 | 通过率 = 通过数 ÷ 已执行数 × 100%；分母不含阻塞和未执行 | 由表2数据计算 |
| 严重程度 | 缺陷对业务和系统的影响级别 | 致命、严重、一般、轻微四级，按团队缺陷规范判定 | 缺陷记录 |
| 缺陷状态 | 缺陷当前处理阶段 | 新增、已修复、待修复、已验证关闭、挂起/延期 | 缺陷记录 |
| 修复率 | 缺陷修复进展 | 修复率 = （已修复 + 已验证关闭）÷ 新增 × 100% | 由表3数据计算 |
| 版本结论 | 本轮测试对版本的判断 | 从“可进入下一阶段”“有条件通过”“不通过”中选择，并写明依据 | 测试负责人判定 |
| 遗留风险 | 未关闭缺陷可能带来的影响 | 逐条对应缺陷编号，说明影响范围和触发条件 | 缺陷记录、评审结论 |
口径确定后应写入模板说明或团队测试规范，后续轮次沿用同一算法。若某轮调整了口径，需在基本信息中注明，避免与历史数据直接比较时产生误读。
必填与选填：哪些字段不能空
必填字段承担结论可追溯的作用，缺失会导致汇总无法被评审或无法与缺陷记录对应；选填字段用于补充上下文，按项目需要填写。无法获取数据时，填写“未统计”并注明原因，留空会让读者无法区分“为零”和“未采集”。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 项目名称、版本号、测试轮次 | 必填 | 唯一标识一份汇总，缺失则无法归档和对比 |
| 测试范围、测试起止时间 | 必填 | 界定结论适用范围 |
| 测试负责人 | 必填 | 结论责任人 |
| 计划用例数、已执行数、通过数、失败数 | 必填 | 通过率与执行率的计算基础 |
| 阻塞数 | 必填（可为0） | 影响对执行率的解读，需与备注对应 |
| 缺陷新增数、待修复数、遗留清单 | 必填 | 结论与风险说明的直接依据 |
| 版本结论、结论依据 | 必填 | 汇总的核心输出 |
| 测试环境 | 选填 | 多环境并行测试时建议填写 |
| 参与人员 | 选填 | 需要统计投入或交接时填写 |
| 需求/变更单号 | 选填 | 需要与需求系统关联时填写 |
| 挂起/延期缺陷数 | 选填 | 存在延期决策时填写，并进入遗留清单 |
| 结论确认人及日期 | 选填 | 汇总需要评审签字时填写 |
字段缺失时统一使用三种标注：“0”表示统计结果为零，“未统计”表示本轮未采集，“不适用”表示该字段与本轮测试无关。三种标注不能混用，否则合计行和比率计算会出现偏差。
填写示例：一个版本测试结果汇总的完整样例
以下为演示情景，数据为虚构，仅用于说明填写方式。假设某业务系统发布 V2.3 版本，进行第二轮回归测试，覆盖订单、支付、会员三个模块。
基本信息示例
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 订单交易系统 |
| 版本号 | V2.3 |
| 测试轮次 | 第2轮（回归） |
| 测试类型 | 功能测试 + 回归测试 |
| 测试范围 | 订单、支付、会员三个模块；不含报表模块 |
| 测试环境 | 预发布环境 |
| 测试起止时间 | 2025-03-10 至 2025-03-14 |
| 测试负责人 | 测试组 A |
| 汇总日期 | 2025-03-14 |
执行统计示例
| 模块 | 计划用例数 | 已执行数 | 通过数 | 失败数 | 阻塞数 | 未执行数 | 执行率 | 通过率 |
|---|---|---|---|---|---|---|---|---|
| 订单 | 120 | 118 | 110 | 8 | 2 | 0 | 98.3% | 93.2% |
| 支付 | 80 | 80 | 76 | 4 | 0 | 0 | 100% | 95.0% |
| 会员 | 50 | 46 | 45 | 1 | 1 | 3 | 92.0% | 97.8% |
| 合计 | 250 | 244 | 231 | 13 | 3 | 3 | 97.6% | 94.7% |
合计行按口径计算：执行率 244 ÷ 250 = 97.6%；通过率 231 ÷ 244 = 94.7%。订单模块的 2 条阻塞用例因支付回调环境不稳定未执行，已在备注中记录，环境恢复后补测。
缺陷统计示例
| 严重程度 | 新增 | 已修复 | 待修复 | 已验证关闭 | 挂起/延期 | 修复率 |
|---|---|---|---|---|---|---|
| 致命 | 1 | 1 | 0 | 1 | 0 | 100% |
| 严重 | 4 | 3 | 1 | 2 | 0 | 75.0% |
| 一般 | 9 | 6 | 3 | 4 | 1 | 66.7% |
| 轻微 | 5 | 3 | 2 | 2 | 0 | 60.0% |
| 合计 | 19 | 13 | 6 | 9 | 1 | 68.4% |
修复率按“（已修复 + 已验证关闭）÷ 新增”计算，合计为 13 ÷ 19 = 68.4%。已验证关闭的缺陷同时计入已修复，统计时注意不要重复累加。
结论与遗留问题示例
| 项目 | 填写内容 |
|---|---|
| 版本结论 | 有条件通过，可进入验收测试 |
| 结论依据 | 通过率 94.7%，致命缺陷已全部关闭；1 条严重缺陷待修复，3 条阻塞用例待补测 |
| 遗留缺陷清单 | BUG-1023（严重，支付超时提示错误）；BUG-1031、BUG-1035、BUG-1040（一般，订单列表排序与筛选异常）；BUG-1042（一般，挂起，会员积分显示延迟） |
| 遗留风险说明 | 支付超时场景在弱网下可能给出错误提示，影响用户判断；订单列表问题影响运营查询效率，不阻断交易 |
| 后续动作 | 研发修复 BUG-1023 后由测试组回归；订单模块 3 条阻塞用例于 3 月 17 日前补测；BUG-1042 纳入下个版本处理 |
| 结论确认人及日期 | 测试负责人、项目负责人，2025-03-14 |
调整与维护方法：按项目规模裁剪模板
模板的价值在于长期使用中保持结构稳定。裁剪时保留四张表的主干，按项目规模调整行数和字段粒度；维护时记录每次字段变更，使不同轮次的数据仍可对照。
按项目规模裁剪
- 小团队或单模块项目：表2可只保留合计行，模块列改为功能点；表3可合并“一般”和“轻微”为“其他”，但致命与严重必须单列。
- 多模块项目：表2按模块分行，模块超过十个时可增加“模块组”列做两级汇总；表3保留四级严重程度，并增加“所属模块”列便于定位。
- 多轮回归项目：在基本信息中固定版本号，每轮单独一份汇总，结论表只记录本轮变化和累计遗留，避免多轮数据混在一张表里。
- 接口或性能等专项测试：执行统计改为“场景数/请求数”，缺陷统计保留原结构，结论部分补充指标阈值与实测值对比。
模板版本与字段变更记录
在模板末尾增加一张变更记录表，字段包括版本、变更日期、变更人、变更内容和影响范围。新增字段时说明是否必填、历史数据如何补填；删除字段时保留一版过渡期，避免旧汇总无法解读。口径调整需同步更新字段说明，并在当轮基本信息中注明。
汇总数据与测试管理工具的衔接
手工汇总的主要成本在于从用例执行记录和缺陷记录中取数。若团队使用测试管理工具，可让模板字段与工具中的计划、用例、缺陷字段一一对应，减少二次录入。以 ONES 测试管理为例，测试计划可展示进度和通过率，未通过的用例可快速创建缺陷任务并在测试与研发之间流转，项目缺陷分布统计可作为表3的数据来源；测试报告支持自定义组装模板，并可按测试活动自动生成多维度报告。工具内的通过率计算口径需与本文模板口径核对一致，再决定哪些数据直接引用、哪些在汇总时手工调整。这样模板既保留统一的汇报结构，又能随工具数据更新而减少重复统计。
常见问题
测试结果汇总里的通过率，分母应该用计划用例数还是已执行数？
模板采用的分母是已执行数，即通过率 = 通过数 ÷ 已执行数 × 100%。这样计算反映的是已跑用例的质量，阻塞和未执行用例不拉低通过率，而是通过执行率单独体现进度。
如果团队习惯用计划用例数作分母，需要在基本信息或字段说明中注明，并保持各轮一致。两种口径不能在同一份汇总里混用，否则跨版本对比会失真。
同一版本做了多轮回归，每轮单独一份汇总还是合并成一份？
建议每轮单独一份汇总，在基本信息中固定版本号、轮次编号递增，结论表只记录本轮变化和累计遗留缺陷。合并成一份时，执行统计的合计行容易把不同轮次的用例重复计数，通过率也会失去可比性。
需要看版本整体情况时，可以另做一份版本级汇总，引用各轮数据并注明来源轮次，与单轮汇总分开存放。
阻塞用例解除后补测，原汇总需要修改吗？
原汇总作为当轮记录保留，补测结果记入下一轮汇总或在原表增加“补测”备注列，写明补测日期和结果。直接改写原汇总会让当时给出的版本结论失去依据。
如果补测改变了版本结论，应在结论表中新增一条修订记录，注明修订原因、修订人和日期，并通知结论确认人。
用测试管理工具取数时，工具里的通过率与模板口径不一致怎么办？
先核对工具中通过率的分母是否包含阻塞和未执行用例，再决定处理方式。口径一致时直接引用；不一致时在汇总中注明“数据来源工具，口径已调整”，并保留调整前后的数值。
以 ONES 测试管理为例，测试计划可展示进度和通过率，未通过用例可快速创建缺陷任务并在测试与研发之间流转，项目缺陷分布统计可作为缺陷统计表的数据来源，测试报告支持自定义组装模板。工具内具体计算规则建议在实际界面中确认后再固定取数方式。
专项测试（如接口、性能）能直接套用这份模板吗？
可以沿用四张表的主干，调整执行统计的计量单位。接口测试可把“用例数”换成“接口数/场景数”，性能测试换成“场景数/请求数”，并在字段说明中写明单位。
缺陷统计和结论表结构保持不变，结论部分补充指标阈值与实测值的对比，例如响应时间目标值与实测值。调整后的字段需记入模板变更记录，便于与其他轮次区分。
