测试结果汇总模板需要覆盖版本范围、执行进度、缺陷分布、覆盖情况、风险遗留和结论建议六个维度，每个统计项都写明分子、分母、时间范围和取数来源。这样同一版本内可以复核，跨版本也能比较。下面给出一张可直接复制到文档或表格中的空白模板，再逐字段说明口径，并用一份虚构版本的填写示例展示各字段如何联动。
要点总览（TL;DR）
- 模板采用“版本基本信息—执行进度—缺陷分布—覆盖情况—风险与遗留—结论与建议”六段结构，先固定版本范围，再填数据，最后写结论。
- 每个统计字段都写明分子、分母、统计时间范围和取数来源，例如通过率=通过用例数÷已执行用例数，避免同名不同义。
- 必填项按“结论是否依赖该数据”划分，进度、缺陷、覆盖、风险四类为必填；按模块、按严重程度等细分维度为选填，可按版本规模裁剪。
- 缺失数据统一标注“未统计”并注明原因，不用0代替缺失值，防止通过率和覆盖率失真。
- 模板调整需记录变更日期、内容和生效版本，口径变化后与历史版本对比前先统一换算。
可复制空白模板：测试结果汇总表
这张表按六个区块组织，填写时从上到下推进：先固定版本范围，再填执行与缺陷数据，最后写覆盖、风险和结论。表格中的“____”为待填位置，括号内为填写提示，正式使用时可以删除提示文字。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 一、版本与范围基本信息 | 版本号 | ____ |
| 测试周期 | ____（开始日期至结束日期） | |
| 测试范围 | ____（涉及的模块、需求或功能清单） | |
| 不测试范围及原因 | ____ | |
| 测试环境与版本 | ____（环境名称、被测构建号） | |
| 二、执行进度统计 | 计划用例总数 | ____ |
| 已执行用例数 | ____ | |
| 通过用例数 / 失败用例数 / 阻塞用例数 | ____ / ____ / ____ | |
| 执行率 | ____%（公式见第二节） | |
| 通过率 | ____%（公式见第二节） | |
| 三、缺陷分布统计 | 新增缺陷总数 | ____ |
| 按严重程度分布 | 致命____ / 严重____ / 一般____ / 轻微____ | |
| 按模块分布 | ____ | |
| 缺陷密度 | ____（公式见第二节） | |
| 四、覆盖情况统计 | 需求覆盖率 | ____%（公式见第二节） |
| 用例覆盖率 | ____% | |
| 未覆盖项及原因 | ____ | |
| 五、风险与遗留问题 | 未关闭缺陷清单 | ____（编号、严重程度、影响范围） |
| 已知风险 | ____（风险描述、影响、应对措施） | |
| 遗留问题处理计划 | ____（责任人、计划解决时间） | |
| 六、结论与建议 | 版本质量结论 | ____（可发布 / 有条件发布 / 不建议发布） |
| 结论依据 | ____（引用上述关键数据） | |
| 后续建议 | ____ |
六个区块之间存在依赖关系：执行进度和缺陷分布是结论的主要依据，覆盖情况说明测试是否充分，风险与遗留问题解释结论中的保留条件。填写时如果某一区块数据缺失，应在对应位置标注，而不是留空或填0。
每个字段的含义与取数来源
同一份模板在不同团队使用时，最容易出现的问题是同名字段算法不同。例如“通过率”有的按已执行用例计算，有的按计划用例计算，两者结果差异明显。下表为每个统计字段给出统一定义、计算公式、取数来源和统计时间范围，填写前先确认这四项。
| 字段 | 定义 | 计算公式 | 取数来源 | 统计时间范围 |
|---|---|---|---|---|
| 执行率 | 已执行用例占计划用例的比例 | 已执行用例数 ÷ 计划用例总数 × 100% | 用例执行记录 | 本版本测试周期内，截止汇总时点 |
| 通过率 | 执行结果通过的用例占已执行用例的比例 | 通过用例数 ÷ 已执行用例数 × 100% | 用例执行记录 | 同上 |
| 阻塞率 | 因环境或前置问题无法执行的用例占比 | 阻塞用例数 ÷ 计划用例总数 × 100% | 用例执行记录中的阻塞状态 | 同上 |
| 缺陷密度 | 单位规模内的缺陷数量，用于横向比较模块质量 | 新增缺陷数 ÷ 统计基数（如用例数或功能点数，需在模板中固定一种） | 缺陷库 | 本版本测试周期内新增缺陷 |
| 需求覆盖率 | 已有对应用例的需求占本版本需求的比例 | 已覆盖需求数 ÷ 本版本需求总数 × 100% | 需求库与用例关联关系 | 截止汇总时点 |
| 用例覆盖率 | 已执行用例占计划用例的比例，与执行率口径一致时只保留一个 | 已执行用例数 ÷ 计划用例总数 × 100% | 用例执行记录 | 同上 |
| 新增缺陷总数 | 本版本测试周期内提交的缺陷数量，不含历史遗留 | 按提交时间计数 | 缺陷库 | 测试周期起止日期 |
统计时间范围需要单独写明截止时点。测试周期内数据持续变化，汇总表应注明“数据截止至某日某时”，否则同一版本在不同时间导出会得到不同结果。缺陷密度中的统计基数必须在模板中固定为一种，例如统一按用例数计算，避免不同模块混用基数导致不可比。
取数来源要写到具体系统或记录，例如“用例执行记录”“缺陷库”“需求与用例关联表”。当数据来自多个来源时，应说明合并规则，例如缺陷数按缺陷库去重后的数量统计。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，测试计划的进度和通过率可在概览中查看，这些记录可以作为上述字段的取数基础；具体报表口径仍需与团队模板核对一致。
必填项与选填项如何划分
必填与选填的划分标准是“结论是否依赖该数据”。影响版本质量判断的字段为必填，用于细分分析和横向比较的字段为选填。这样小版本可以只填核心字段，大版本再展开细分维度，模板本身保持不变。
| 类别 | 字段 | 划分理由 / 适用场景 |
|---|---|---|
| 必填 | 版本号、测试周期、测试范围 | 没有范围和周期，数据无法复核 |
| 必填 | 计划用例总数、已执行数、通过数、失败数 | 执行进度和通过率的基础数据 |
| 必填 | 新增缺陷总数、未关闭缺陷清单 | 结论需要说明缺陷收敛情况 |
| 必填 | 需求覆盖率、未覆盖项及原因 | 说明测试是否充分 |
| 必填 | 已知风险、版本质量结论、结论依据 | 汇总结论的核心内容 |
| 选填 | 按模块的缺陷分布 | 模块较多或需要定位薄弱环节时填写 |
| 选填 | 按严重程度的缺陷分布 | 需要评估缺陷结构时填写 |
| 选填 | 缺陷密度 | 需要跨模块或跨版本比较时填写，须固定统计基数 |
| 选填 | 阻塞率 | 环境问题较多、阻塞情况影响结论时填写 |
| 选填 | 不测试范围及原因、测试环境与版本 | 范围有裁剪或环境特殊时填写 |
按版本规模裁剪时，可以遵循三条原则：小版本保留必填项，选填项只填与本次风险相关的；涉及多模块的版本增加按模块的缺陷分布，便于定位问题集中区域；跨版本比较需求出现时，再补充缺陷密度等可比指标。裁剪只减少选填项，必填项不因版本小而省略。
缺失数据的标注方式统一为“未统计”并注明原因，例如“未统计：该模块用例尚未导入”。不要用0代替缺失值，0表示真实的零结果，两者混用会让通过率和覆盖率失真。对于部分统计的数据，可写“部分统计”并说明覆盖了哪些范围。
填写示例：一个版本的完整汇总
以下示例中的版本背景和数值均为虚构情景，仅用于说明字段之间的联动方式，不代表任何真实项目数据。
示例背景：某版本包含订单、支付、账户三个模块，测试周期为两周，计划用例400条，本版本需求共20项。测试进行到第10天时进行汇总。
| 区块 | 字段 | 示例填写 |
|---|---|---|
| 基本信息 | 版本号 / 测试周期 / 测试范围 | V2.3 / 3月1日至3月14日 / 订单、支付、账户三个模块，共20项需求 |
| 执行进度 | 计划用例 / 已执行 / 通过 / 失败 / 阻塞 | 400 / 360 / 324 / 30 / 6 |
| 执行进度 | 执行率 / 通过率 | 90%（360÷400）/ 90%（324÷360） |
| 缺陷分布 | 新增缺陷总数 / 严重程度分布 | 48 / 致命2、严重10、一般26、轻微10 |
| 缺陷分布 | 按模块分布 / 缺陷密度 | 订单28、支付14、账户6 / 0.12（48÷400） |
| 覆盖情况 | 需求覆盖率 / 未覆盖项 | 95%（19÷20）/ 1项需求因接口未就绪未覆盖 |
| 风险与遗留 | 未关闭缺陷 / 已知风险 | 12个未关闭，其中严重3个 / 支付模块严重缺陷集中在退款流程，修复后需回归 |
| 结论与建议 | 质量结论 / 依据 / 建议 | 有条件发布 / 通过率90%，严重缺陷已收敛至3个且有修复计划 / 退款流程回归通过后发布 |
这份示例体现了字段联动：执行率90%说明测试基本完成，通过率90%与12个未关闭缺陷共同支持“有条件发布”的结论；需求覆盖率95%对应1项未覆盖需求，这一项需要在风险区说明。结论段先给判断，再引用关键数据，最后写发布条件，避免只写“质量良好”这类无法复核的表述。
示例中的每个数值都能在第二节的字段说明中找到对应公式。填写自己的版本时，可以按同样的顺序核对：先确认分母，再确认截止时点，最后检查结论是否引用了对应数据。
模板的调整与长期维护方法
模板需要随项目变化调整，但调整本身要有记录，否则历史数据失去可比性。维护工作集中在字段增删、口径变更和版本管理三件事上。
- 字段增删的触发条件：当团队开始按新维度做决策时增加字段，例如需要评估自动化测试效果时增加自动化用例占比；当某字段连续多个版本无人使用、也不影响结论时删除。增删应在版本开始前完成，避免测试中途改表导致数据口径不一致。
- 口径变更的记录方式：任何公式或统计范围的变化都要在模板的变更记录中写明变更日期、变更内容、变更原因和生效版本。例如把缺陷密度的统计基数从用例数改为功能点数，必须记录，否则新旧版本数据不能直接比较。
- 模板版本管理：模板本身标注版本号，与测试版本号区分。每次调整生成新模板版本，历史汇总表保留原模板版本号，便于追溯当时使用的口径。
- 与历史版本对比的注意事项：对比前先确认两个版本使用的模板版本和口径是否一致；口径不同时，应重新按统一口径换算后再比较，或明确说明差异，不直接并列展示。
ONES 测试管理支持自定义组装测试报告模板，适配不同业务场景，并可为测试活动自动生成多维度测试报告。团队可以把本文模板的字段与工具内报告配置对应起来，让执行记录、缺陷和用例关联数据在工具中沉淀，汇总时按统一口径取数；工具内指标的默认计算方式仍需与模板口径逐项核对后再使用。
常见问题
小版本只填必填项，会不会导致汇总表信息不足、无法支撑结论？
不会。必填项的划分标准就是“结论是否依赖该数据”，进度、缺陷、覆盖、风险四类数据已经覆盖了版本质量判断的主要依据。小版本省略的是按模块、按严重程度等细分维度，这些维度用于定位薄弱环节，不影响“可发布/有条件发布/不建议发布”的基本判断。
如果小版本中某一模块风险突出，可以把该模块的缺陷分布临时补上，作为选填项填写。裁剪只减少选填项，必填项不因版本小而省略。
测试进行到一半需要出汇总，截止时点怎么处理才不影响后续对比？
在汇总表中单独写明“数据截止至某日某时”，并保留该时点的数据快照。测试周期内数据持续变化，同一版本在不同时间导出会得到不同结果，注明截止时点后，这份汇总就代表该时点的状态。
后续再出汇总时，使用新的截止时点并重新取数，不要在原表上直接覆盖数值。需要对比时，两份汇总的截止时点和统计范围应保持一致，否则差异可能来自时间口径而非质量变化。
团队已经在工具里看测试计划进度和通过率，还需要单独维护这份汇总模板吗？
两者用途不同。工具内的测试计划概览适合日常跟踪执行状态，汇总模板则把执行、缺陷、覆盖、风险和结论放在一份文档中，便于评审、归档和跨版本比较。ONES TestCase 支持查看测试计划的进度和通过率，未通过用例可快速创建缺陷任务，这些记录可以作为模板的取数基础。
落地时建议先核对工具内指标的计算方式与模板口径是否一致，例如通过率的分母是已执行用例还是计划用例。口径一致时直接引用工具数据；不一致时在模板中注明换算方式，避免同一版本出现两个通过率。
缺陷密度的统计基数应该选用例数还是功能点数？
两种基数都可以用，关键是模板内固定一种，并在变更记录中写明。按用例数计算适合用例粒度较均匀、执行记录完整的团队；按功能点数计算适合需求拆分较细、需要跨模块比较缺陷集中度的场景。
同一份汇总表中不要混用基数，否则模块之间的缺陷密度不可比。如果历史数据使用另一种基数，跨版本对比前先按统一基数换算，或明确说明差异后再并列展示。
模板调整后，历史版本的汇总数据还能直接拿来比较吗？
需要先确认两个版本使用的模板版本和口径是否一致。字段增删或公式变化后，新旧数据不能直接并列。处理方式有两种：按新口径重新换算历史数据后再比较，或在对比说明中标注口径差异及其影响范围。
为减少这类问题，字段增删尽量在版本开始前完成，任何公式或统计范围的变化都记录变更日期、变更内容、变更原因和生效版本，模板本身标注版本号，与测试版本号区分开。
