测试报告的数据来源可以归为三类记录：测试执行记录、缺陷记录、需求与覆盖记录。执行结果从用例或用例步骤的执行记录取数，缺陷从缺陷单及其状态流转取数，需求覆盖从需求与用例的追溯关系取数。三类数据通过用例、需求、版本三个共同键对齐，形成同一版本口径下的结论。本文说明每类记录的字段、常见承载系统、取数口径与边界，帮助读者按统一规则算出可复核的版本结论。
要点总览（TL;DR）
- 测试报告的数据来源归为三类记录：测试执行记录、缺陷记录、需求与覆盖记录，分别回答测了什么、发现了什么、需求是否测到。
- 执行结果从用例或用例步骤的执行记录取数，先确定按最近一次执行、指定轮次还是首次执行，再明确通过、失败、阻塞、未执行在分母中的归并规则。
- 缺陷从缺陷单及状态流转取数，按发现版本、关联对象和创建时间筛选，区分新增与存量，已修复与已验证分别统计。
- 需求覆盖从需求—用例追溯关系取数，覆盖率看需求是否被用例关联，通过覆盖率看关联用例是否执行并通过，无关联用例的需求列为覆盖缺口。
- 三类数据通过用例、需求、版本三个共同键对齐到同一版本口径；组织级质量趋势与发布门禁不在测试报告取数范围内。
测试报告的数据来源包括哪些记录和系统
测试报告的数据来源按记录类型分为三类，每类记录回答不同问题：执行记录回答“测了什么、结果如何”，缺陷记录回答“发现了什么问题、处理到什么程度”，需求与覆盖记录回答“该测的需求是否都测到、是否通过”。三类记录通常分散在不同系统中，取数时需要先确认每类记录存放在哪里、有哪些关键字段。
| 记录类型 | 承载的信息 | 关键字段 | 常见承载系统 |
|---|---|---|---|
| 测试执行记录 | 用例、用例步骤、执行轮次、执行结果、执行时间、执行人 | 用例编号、所属计划或轮次、步骤结果、状态、执行时间 | 测试管理工具 |
| 缺陷记录 | 缺陷单、状态流转、严重程度、优先级、发现版本、关联用例或需求 | 缺陷编号、状态、严重程度、发现版本、关联对象、创建与关闭时间 | 缺陷跟踪系统，或项目协作平台中的缺陷工作项 |
| 需求与覆盖记录 | 需求条目、需求与用例的追溯关系、需求所属版本与范围 | 需求编号、所属版本、关联用例、需求状态 | 需求管理或项目协作平台 |
| 自动化执行结果 | 自动化用例的运行结果、运行批次、失败日志 | 用例标识、运行批次、结果状态、运行时间 | 持续集成与自动化执行平台 |
这张清单的作用是确定取数入口。实际取数前，需要确认三类记录是否使用同一套用例编号和需求编号，否则后续关联会断在编号不一致上。自动化执行结果通常以用例标识回写到测试管理工具，取数时以测试管理工具中的记录为准，避免同一用例在两边各算一次。
测试报告的数据边界：哪些内容不属于报告取数范围
测试报告的取数对象是当前测试或当前版本的结论，即“这个版本测了多少、通过多少、遗留多少缺陷、需求覆盖到什么程度”。围绕这个对象，纳入与不纳入的内容可以这样划分：
| 内容 | 是否纳入本期报告取数 | 理由 |
|---|---|---|
| 本期用例执行记录与结果 | 纳入 | 构成执行结论的直接依据 |
| 本期发现及处理的缺陷 | 纳入 | 构成缺陷结论的直接依据 |
| 本期需求与用例追溯关系 | 纳入 | 构成覆盖结论的直接依据 |
| 历史版本的执行与缺陷数据 | 仅作对比基线 | 用于趋势参照，不改变本期口径 |
| 跨版本、跨团队的质量趋势 | 不纳入 | 属于研发质量度量，面向组织级分析 |
| 是否允许发布的判定规则 | 不纳入 | 属于发布审批与质量门禁，面向放行决策 |
边界清晰的好处是口径稳定：本期报告只对本期数据负责，历史数据只作为参照列示，不混入本期分子分母。当报告需要引用历史数据时，应单独标注为对比项，避免读者把两个版本的数字直接相加。
执行结果怎么取数：从用例执行记录到通过率
执行结果的取数对象是用例或用例步骤的执行记录。取数前先确定口径，再确定状态如何计入分母，最后按维度汇总。口径不统一是通过率对不上的最常见原因。
口径选择有三种常见方式：按最近一次有效执行取数，适合同一用例多轮执行后只保留最终结论；按指定轮次取数，适合回归轮次或验收轮次的单独统计；按首次执行取数，适合观察首次通过情况。三种口径得出的通过率不同，报告中应写明采用哪一种。
| 状态 | 是否计入分母 | 是否计入通过数 | 说明 |
|---|---|---|---|
| 通过 | 是 | 是 | 执行完成且结果符合预期 |
| 失败 | 是 | 否 | 执行完成但结果不符合预期 |
| 阻塞 | 是 | 否 | 因环境或前置条件无法执行，需在报告中单列数量 |
| 未执行 | 视口径而定 | 否 | 按计划应执行但尚未执行；若统计计划完成率则计入分母，若统计已执行通过率则单列 |
通过率的基本公式为：通过率 = 通过用例数 ÷ 计入分母的用例数。分母是否包含未执行用例，取决于报告要回答的问题：回答“计划执行得怎么样”时包含未执行，回答“已执行的质量如何”时排除未执行并单独说明未执行数量。
自动化执行结果与手工执行结果合并时，先统一状态映射，例如把自动化平台的“成功/失败/跳过”映射为“通过/失败/未执行”，再按同一口径汇总。同一用例既有手工执行又有自动化执行时，按选定口径取其中一次，避免重复计数。汇总维度通常包括模块、优先级、版本和测试计划，便于定位问题集中的区域。
在测试管理工具中，这类取数依赖执行记录本身是否完整。ONES 测试管理支持测试计划的规划与执行、用例分配执行人，并可查看测试计划的进度和通过率，为按计划或轮次取执行结果提供记录基础；具体按最近一次执行还是指定轮次统计，需要在报告模板中明确约定。
缺陷怎么取数：从缺陷单到版本缺陷结论
缺陷取数的对象是缺陷单及其状态流转记录。取数时先按条件筛出本期缺陷集合，再按状态口径分类统计，最后用关联关系定位影响范围。
| 取数要素 | 常用规则 | 注意事项 |
|---|---|---|
| 发现版本 | 筛选发现版本等于本期版本的缺陷 | 修复版本与发现版本不同，统计新增用发现版本 |
| 关联对象 | 按关联用例或关联需求筛选 | 用于定位缺陷影响的模块与需求 |
| 创建时间区间 | 限定在本期测试周期内 | 与发现版本配合使用，避免跨期混入 |
| 状态口径 | 新增、已修复、已验证、关闭、重新打开分别统计 | “已修复”与“已验证”是不同阶段，不能合并为一个数 |
| 严重程度与优先级 | 按等级分布统计 | 分布比总数更能说明问题结构 |
存量与新增要分开：本期新增缺陷按创建时间或发现版本统计，存量缺陷指此前版本发现、本期仍在处理或仍未关闭的缺陷。两者混在一起统计，会高估本期发现的问题量。重新打开的缺陷需要单独说明，它反映修复未通过验证的情况，通常计入本期未关闭缺陷。
缺陷与用例、需求的关联关系用于定位影响范围。例如某模块的失败用例集中，可进一步查看这些用例关联的缺陷状态，判断问题是已修复待验证还是仍在处理。关联缺失的缺陷不应静默丢弃，应在报告中单列数量并说明原因。
ONES 支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，并提供项目缺陷分布统计。这些记录为按版本、按关联对象取缺陷数据提供了基础；具体状态项如何归入新增、已修复、已验证、关闭，需要按团队实际使用的状态流转定义映射。
需求覆盖怎么取数：从需求—用例追溯到覆盖率
需求覆盖的取数起点是需求条目与需求—用例的追溯关系，而非用例数量。没有追溯关系，就无法判断某条需求是否被测试到。覆盖统计通常分两层：一层看需求是否被用例关联，另一层看关联用例是否执行并通过。
| 指标 | 公式 | 回答的问题 |
|---|---|---|
| 需求覆盖率 | 有用例关联的需求数 ÷ 本期需求数 | 需求是否都有测试设计 |
| 需求执行覆盖率 | 关联用例已执行的需求数 ÷ 本期需求数 | 有测试设计的需求是否都执行了 |
| 需求通过覆盖率 | 关联用例已执行且通过的需求数 ÷ 本期需求数 | 测试过的需求是否验证通过 |
无对应用例的需求应标记为覆盖缺口，并在报告中列出需求编号与原因，例如需求刚变更、用例尚未编写或判定为不需测试。覆盖缺口数量本身是报告结论的一部分，直接排除会让覆盖率虚高。
需求变更后，追溯关系需要同步更新：新增或修改的需求要补充关联用例，被删除或拆分的需求要解除旧关联，否则覆盖率会按失效关系计算。取数时应以本期需求清单为准，核对每条需求的关联用例是否仍然有效。
ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，使需求、用例与执行记录处在同一条追溯链上。覆盖率的具体公式与缺口标记规则需要在报告模板中约定，工具提供的是关联记录，口径仍由报告定义。
三类数据如何关联：用例、需求、版本三个共同键
三类数据各自统计后，需要对齐到同一版本口径，否则执行通过率、缺陷数、需求覆盖率会各说各话。关联依靠三个共同键：用例键连接执行记录与缺陷，需求键连接用例与需求，版本键把执行轮次、缺陷发现版本、需求所属版本对齐到同一期。
| 关联键 | 连接的数据 | 缺失时的处理 |
|---|---|---|
| 用例键 | 执行记录 ↔ 缺陷 | 无关联用例的缺陷单列，标注“未关联用例” |
| 需求键 | 用例 ↔ 需求 | 无追溯关系的需求标记为覆盖缺口 |
| 版本键 | 执行轮次、缺陷发现版本、需求所属版本 | 版本信息缺失的记录单列，不并入本期结论 |
汇总顺序建议为：先锁定本期版本与需求清单，再取该版本下的执行记录算出执行结论，然后取该版本发现的缺陷算出缺陷结论，最后按需求—用例追溯关系算出覆盖结论。每一步都以版本键过滤，确保三类数字来自同一范围。关联缺失的记录集中列在报告附注中，说明数量与原因，读者才能判断结论的完整程度。
ONES 中测试计划与迭代关联、用例与需求关联、缺陷可关联至迭代，这些关联关系为三个键的对齐提供了记录基础；报告模板可自定义组装，便于把执行、缺陷与覆盖数据放在同一版本口径下呈现。
相邻概念区别：测试报告取数与质量度量、发布门禁的区别
测试报告取数、研发质量度量、发布审批与质量门禁都使用测试与缺陷数据，但数据范围、时间跨度和使用角色不同，混用会导致口径争议。
| 概念 | 数据范围 | 时间跨度 | 主要使用角色 | 用途 |
|---|---|---|---|---|
| 测试报告取数 | 当前测试或当前版本的执行、缺陷、覆盖记录 | 单版本或单测试周期 | 测试负责人、项目成员 | 形成版本测试结论 |
| 研发质量度量 | 跨版本、跨团队的缺陷密度、逃逸率等指标 | 多版本、季度或年度 | 质量管理者、研发管理者 | 观察组织级质量趋势 |
| 发布审批与质量门禁 | 放行所需的判定条件与审批记录 | 单次发布 | 发布负责人、审批人 | 决定是否允许发布 |
三者的关系是：测试报告提供本期事实，质量度量在这些事实上做跨期汇总，发布门禁引用报告结论并叠加放行规则。报告取数不应承担趋势分析或放行判定的职责，否则口径会被拉宽，单版本结论反而难以复核。
具体例子与常见误解
假设某版本计划执行 200 条用例，实际执行 180 条，其中通过 150 条、失败 20 条、阻塞 10 条，未执行 20 条；本期发现缺陷 30 个，其中已修复 18 个、已验证关闭 8 个、仍在处理 4 个；本期需求 40 条，其中 36 条关联了用例，关联用例全部执行且通过的需求为 30 条。
按前述口径取数：执行通过率若以已执行用例为分母，为 150 ÷ 180 ≈ 83.3%，未执行的 20 条单独列示；若以计划用例为分母，则为 150 ÷ 200 = 75%。缺陷方面，本期新增 30 个，已关闭 8 个，已修复待验证 18 个，处理中 4 个，按严重程度给出分布。需求覆盖方面，需求覆盖率为 36 ÷ 40 = 90%，需求通过覆盖率为 30 ÷ 40 = 75%，剩余 4 条无关联用例的需求列为覆盖缺口。三类数字都限定在同一版本，读者可以据此判断该版本的测试充分性与遗留风险。
常见误解有四个。其一，把缺陷总数直接当作版本质量结论：30 个缺陷中已关闭 8 个、待验证 18 个，处理进度不同，只报总数无法说明风险。其二，用用例数代替需求覆盖：执行了 200 条用例不代表 40 条需求都被覆盖，覆盖要看追溯关系。其三，混用不同轮次的执行结果：把首轮失败、回归通过的用例都算作失败，或把多轮执行次数累加进分母，都会让通过率失真。其四，把未关联缺陷排除在报告之外而不说明：关联缺失的记录应单列并注明原因，静默排除会让缺陷结论看起来比实际更好。
常见问题
同一用例多轮执行后，测试报告应该取哪一次结果？
取决于报告要回答的问题。观察版本最终结论时，按最近一次有效执行取数，同一用例只保留最终状态；单独评估回归或验收轮次时，按指定轮次取数；观察首次通过情况时，按首次执行取数。三种口径得出的通过率不同，报告中应写明采用哪一种，并保持同一版本内口径一致。
缺陷的发现版本和修复版本不同，统计新增缺陷时用哪个？
统计本期新增缺陷时用发现版本，它标识缺陷是在哪个版本被发现的。修复版本用于判断缺陷在哪个版本被处理，适合统计修复进度或验证情况。两个字段混用会让新增缺陷数量失真，报告里最好分别说明按哪个字段筛选。
需求没有关联用例，覆盖率应该怎么处理？
将这类需求标记为覆盖缺口，在报告中列出需求编号和原因，例如需求刚变更、用例尚未编写或判定不需测试。覆盖缺口数量本身是报告结论的一部分，直接排除会让覆盖率虚高。取数时以本期需求清单为准，逐条核对关联用例是否仍然有效。
自动化执行结果和手工执行结果怎么合并统计？
先统一状态映射，例如把自动化平台的“成功/失败/跳过”映射为“通过/失败/未执行”，再按同一口径汇总。同一用例既有手工执行又有自动化执行时，按选定口径取其中一次，避免重复计数。自动化结果通常以用例标识回写到测试管理工具，取数以测试管理工具中的记录为准。
测试报告里的数字和研发质量度量里的数字对不上，是什么原因？
两者数据范围和时间跨度不同。测试报告取数面向当前测试或当前版本，形成单版本结论；研发质量度量面向跨版本、跨团队的趋势分析，统计口径通常包含更多历史数据。数字对不上时，先核对各自的版本范围、时间区间和分母定义，再判断是否需要统一口径，而不是直接把两套数字相加或互相替代。
