测试报告的数据来源：执行结果、缺陷与需求覆盖怎么取数

测试报告的数据来源围绕“当前测试或版本结论”组织，主要包括测试用例与执行记录、缺陷记录、需求与用例的追溯关系，以及用于界定范围的测试计划、轮次和构建版本记录。执行结果从用例执行记录取数，缺陷从缺陷库按发现版本与轮次筛选，需求覆盖则依赖需求—用例追溯关系计算。三类数据需用版本、轮次、用例编号和需求编号对齐，才能形成口径一致的版本结论。

要点总览（TL;DR）

• 测试报告的数据来源围绕当前测试或版本结论组织，核心是测试用例与执行记录、缺陷记录、需求与用例的追溯关系，测试计划、轮次和构建版本记录用于界定范围。
• 执行结果以用例执行记录为最小取数单位，先按版本与轮次筛选，再按通过、失败、阻塞、未执行统计；通过率需注明分母是计划用例数还是已执行用例数。
• 缺陷以缺陷记录为单位，按发现版本、发现轮次和时间窗筛选，再按严重程度、状态、模块分组，已关闭与遗留缺陷分开统计。
• 需求覆盖依赖需求—用例追溯关系，分母为报告范围内的需求数或需求点数量，覆盖率与执行通过率应分开统计。
• 三类数据用版本、轮次作为共同筛选条件，用例编号关联执行与缺陷，需求编号关联覆盖与缺陷分布，并在同一时点截取数据。

测试报告的数据来源包括哪些记录和系统

测试报告的数据来源可以按“承载什么信息、在报告中承担什么角色”来识别。它们分布在测试管理、缺陷跟踪、需求管理和构建发布等系统中，取数时通常需要跨系统汇总。

来源	承载信息	在报告中的用途
测试用例库	用例编号、所属模块、关联需求、优先级、预期结果	确定报告范围内的用例集合，作为执行统计和覆盖计算的基础
测试执行记录	每条用例在某轮次、某版本下的执行状态、执行人、执行时间、实际结果	计算执行进度、通过率、失败与阻塞分布
缺陷跟踪记录	缺陷编号、发现版本、发现轮次、严重程度、状态、所属模块、关联用例与需求	呈现问题分布、修复进展与遗留缺陷
需求条目与追溯关系	需求编号、需求点、需求状态、需求与用例的关联关系	计算需求覆盖率，判断哪些需求已被用例验证
测试计划与轮次记录	计划范围、轮次编号、起止时间、参与人员	界定报告覆盖的测试轮次与计划用例数
测试环境与构建版本记录	被测版本号、构建时间、环境配置	标明结论对应的版本与环境，避免跨版本混算

这份清单中，前三类是报告的核心数据，后三类主要承担范围界定和对齐作用。缺少轮次与版本记录时，执行记录和缺陷记录容易混入其他版本的数据，报告结论就失去可比性。

数据来源的边界：哪些内容不进入测试报告

测试报告的取数范围以版本、测试轮次和时间窗共同界定。一份“某版本第二轮测试报告”，只应纳入该版本在该轮次内产生的执行记录和缺陷记录，以及该版本对应的需求范围。范围一旦确定，报告中的分子和分母都应来自同一范围。

以下内容通常不纳入单份测试报告的取数范围：

• 组织级质量趋势：跨版本、跨项目的缺陷密度变化、长期质量走势，属于研发质量度量的范畴，需要按季度或年度聚合多个版本的数据。
• 发布决策门禁：是否允许发布、是否满足准入门槛，属于发布审批与质量门禁的职责，测试报告为其提供输入，但不替代门禁规则本身。
• 其他版本的执行与缺陷数据：除非报告明确做版本对比，否则不应把历史版本数据混入当前结论。

同一批数据在不同口径下可能得出不同结论。例如按“已执行用例”计算通过率会高于按“计划用例”计算，报告必须注明所用口径，读者才能正确理解结论。

执行结果怎么取数：从用例执行记录到通过率

执行结果以用例执行记录为最小取数单位，而不是以用例本身为单位。同一条用例在不同轮次、不同版本下会有多条执行记录，取数时先按版本和测试轮次筛选，再对筛选后的记录做状态统计。

状态口径需要事先统一，常见划分为：

• 通过：实际结果与预期一致。
• 失败：实际结果与预期不一致，且已确认是产品问题。
• 阻塞：因环境、依赖或前置条件不满足而无法执行。
• 未执行：在报告范围内尚未产生执行记录。

通过率的分母有两种常见选择：按计划用例数计算，反映整体完成度；按已执行用例数计算，反映已执行部分的稳定性。两者含义不同，报告中应明确写出分母。对于重复执行和重测记录，通常以最终轮次的结果计入，或在报告中单独说明重测通过情况，避免同一用例被重复计数。

在测试用例与执行记录的管理上，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环，便于按版本和轮次组织执行记录。

缺陷怎么取数：从缺陷记录到问题分布

缺陷数据以缺陷记录为取数单位。取数时先按发现版本、发现轮次和时间窗筛选，确保纳入的缺陷是在报告范围内被发现的问题，再按严重程度、状态和模块分组统计。

分组统计通常关注三个维度：

• 严重程度分布：致命、严重、一般、轻微各占多少，判断问题对版本的影响面。
• 状态分布：新建、处理中、已修复、已验证、已关闭、遗留各多少，反映修复进展。
• 模块分布：缺陷集中在哪些功能模块，为后续测试重点提供依据。

已关闭缺陷与遗留缺陷必须分开统计。遗留缺陷指报告时点仍未修复或未验证的问题，是版本结论的重要组成部分；已关闭缺陷反映已处理的问题量。缺陷记录中的关联用例和关联需求字段，用于回溯问题来源，也为后续关联分析提供键值。

ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并提供项目缺陷分布统计，便于按模块和状态汇总问题。

需求覆盖怎么取数：从需求—用例追溯到覆盖率

需求覆盖的取数基础是需求条目与用例之间的追溯关系。没有建立追溯关系，就无法判断某条需求是否被用例验证，覆盖率也就无从计算。取数时先确定报告范围内的需求集合，再通过追溯关系找到对应的用例，最后按覆盖判定口径分类。

覆盖率的分母是报告范围内的需求数或需求点数量，分子是已被覆盖的部分。覆盖状态通常分为三类：

• 已覆盖：需求至少关联一条有效用例，且用例已执行。
• 部分覆盖：需求只关联了部分需求点的用例，或关联用例尚未全部执行。
• 未覆盖：需求没有关联任何用例，或关联用例均未执行。

需求发生变更后，追溯关系需要同步更新，否则覆盖率会基于过期关系计算。覆盖率与执行通过率应分开统计：覆盖率回答“需求有没有被验证”，通过率回答“验证的结果如何”，两者不能互相替代。

ONES 测试管理支持用例与产品需求、研发任务关联，需求与用例的追溯关系可以在同一平台内维护，为覆盖率统计提供数据基础。

三类数据如何关联：用统一键对齐执行、缺陷与覆盖

三类数据来自不同记录，只有用统一的筛选条件和关联键对齐，才能形成一致的版本结论。对齐步骤可以按以下顺序执行：

1. 统一范围：以版本和测试轮次作为共同筛选条件，三类数据都限定在同一版本、同一轮次内。
2. 关联执行与缺陷：以用例编号为键，把失败用例与由其创建的缺陷记录对应起来，确认失败原因是否已进入缺陷跟踪。
3. 关联覆盖与缺陷：以需求编号为键，把缺陷分布落到需求维度，观察哪些需求的验证过程中问题集中。
4. 处理关联缺失：当缺陷未关联用例或需求时，在报告中标注关联缺失的数量，不强行归入某一类。
5. 统一取数时间点：执行记录、缺陷状态和需求覆盖应在同一时点截取，避免报告撰写过程中数据继续变化导致口径不一致。

关联完成后，报告可以同时回答三个问题：计划用例执行到什么程度、发现的问题分布和修复状态如何、需求验证是否完整。三者相互印证，结论才具备可解释性。

相邻概念区别：测试报告、质量度量与发布门禁

测试报告、研发质量度量和发布门禁使用部分相同的数据源，但回答的问题、时间范围和聚合层级不同。

概念	回答的问题	时间范围	聚合层级
测试报告	当前测试或版本的质量结论是什么	单个版本、单个测试轮次或指定时间窗	用例、缺陷、需求条目级别
研发质量度量	组织质量趋势如何、团队或项目之间如何比较	跨版本、跨项目的周期区间	项目、团队、季度等聚合层级
发布审批与质量门禁	当前版本是否满足放行条件	发布决策时点	按门禁规则聚合关键指标

同一份执行记录，在测试报告中按用例逐条统计，在质量度量中可能按项目汇总为月度通过率，在门禁中则只取是否满足阈值。用途不同，取数口径和聚合方式也应随之调整。

具体例子与常见误解

以一个版本的第二轮测试报告为例，演示完整取数过程。假设该版本共有 120 条计划用例，关联 30 条需求，第二轮执行了 100 条，其中通过 82 条、失败 12 条、阻塞 6 条，未执行 20 条；本轮发现缺陷 18 个，其中已关闭 7 个、遗留 11 个。

• 执行结果：按计划用例数计算通过率为 82÷120≈68.3%，按已执行用例数计算为 82÷100=82%。报告中需注明采用哪个分母。
• 缺陷分布：18 个缺陷按严重程度和模块分组，11 个遗留缺陷单独列出，并标注其关联的用例和需求。
• 需求覆盖：30 条需求中，已覆盖 22 条、部分覆盖 5 条、未覆盖 3 条，覆盖率为 22÷30≈73.3%，部分覆盖的需求单独说明缺口。

围绕这个例子，有三条常见误解需要澄清：

• 用例数不等于需求覆盖数：用例数量多不代表需求都被验证，覆盖要看需求与用例的追溯关系，一条需求可能对应多条用例，也可能一条都没有。
• 缺陷数不能直接跨版本比较：不同版本的用例规模、测试深度和轮次不同，缺陷绝对数受这些因素影响，比较时应结合范围说明或使用密度类指标。
• 执行通过率高不代表质量达标：通过率只反映已执行用例的结果，未执行用例、遗留缺陷和未覆盖需求同样影响版本结论。

报告末尾应注明取数口径，包括版本与轮次范围、通过率分母、覆盖判定规则和取数时间点。ONES 测试管理支持各类质量统计报表，可自动生成测试报告，并支持自定义组装测试报告模板以适配不同业务场景，便于把上述口径固化到报告模板中重复使用。

常见问题

测试报告的范围怎么界定？只按版本筛选够不够？

只按版本筛选通常不够。同一版本往往经历多轮测试，不同轮次的用例范围、执行进度和缺陷发现量差异明显，混在一起统计会让通过率和缺陷分布失去解释力。建议用版本、测试轮次和时间窗三者共同界定范围，报告中的分子和分母都来自同一范围。如果报告需要做版本对比，应单独说明对比口径，避免把历史版本数据混入当前结论。

同一条用例执行了多次，通过率应该怎么算？

先明确统计对象是执行记录还是用例。按执行记录统计时，每次执行都计入，重测会改变分母；按用例统计时，通常取该轮次的最终结果，避免同一用例被重复计数。两种方式都能用，关键在于报告中写清楚。若重测较多，可以单独列出重测通过情况，让读者区分首次执行结果和修复后的验证结果。

缺陷没有关联用例或需求，还能进入报告统计吗？

可以进入缺陷统计，但关联分析时要单独标注。缺陷按发现版本、轮次和时间窗筛选后，仍可计入严重程度、状态和模块分布；只是在把缺陷落到用例或需求维度时，这部分缺陷无法归位。报告中注明关联缺失的数量，比强行归入某一类更准确，也便于后续推动缺陷记录补全关联字段。

需求在测试过程中发生变更，覆盖率怎么处理？

需求变更后，需求—用例追溯关系需要同步更新，否则覆盖率会基于过期关系计算。处理方式通常有两种：以报告时点的最新需求范围为准重新计算，或在报告中说明变更影响，把变更前已覆盖的部分单独标注。无论采用哪种方式，都应保证覆盖分母与报告范围内的需求集合一致，并与执行通过率分开呈现。

测试报告的数据可以直接用于发布决策吗？

测试报告为发布决策提供输入，但发布是否放行由发布审批与质量门禁的规则决定。测试报告回答当前版本测试得怎么样，门禁回答是否满足放行条件，两者取数的聚合层级不同。把报告结论直接等同于放行结论，容易忽略门禁中对遗留缺陷、覆盖阈值等条件的单独要求。