测试报告与原始记录对不上，通常先要分清是统计口径不同、数据同步延迟，还是查询条件遗漏。排查从固定版本号、统计截止时间和项目范围开始，再沿“原始记录→统计查询→同步任务→报告快照”逐段比对同一时间窗的明细。在用例、缺陷与需求同属一套工作项体系时，关联关系更直接，ONES 可作为这类环境的参照。
要点总览（TL;DR）
- 先固定版本号、统计截止时间和项目范围，把“不一致”拆成通过率、缺陷数、需求覆盖率各自的分子分母差异，再决定排查深度。
- 按“口径→查询→同步→关联”逐段验证：口径看分母与去重规则，查询看版本、时间窗、状态、模块筛选，同步看源表与中间表条数及任务日志，关联看用例—需求、缺陷—用例关系是否缺失或重复。
- 处置按风险从低到高：只读核对、修正口径重算、处理同步、修复关联与去重；补跑同步和批量补录关联有覆盖风险，需备份、审批并设停止点。
- 修复后用同一口径在同版本同时间窗重算三类指标，与原始明细抽样核对，并观察同步任务一个统计周期。
- 建立指标口径登记与报告发布前核对检查项，把本次差异原因和处置过程留档，供后续同类问题参照。
先确认不一致的具体表现与影响范围
“报告和原始记录不一致”本身无法直接排查，需要先拆成可核对的差异条目。建议先做一份差异登记表，把每个指标的报告值、原始值、差值、统计时点和涉及版本写清楚，再决定排查深度。差异只有几条时，多半是筛选条件或关联缺失；差异达到数量级，则优先怀疑口径定义或同步任务整体失败。
三类指标的差异要分别落到分子、分母或整体上：
- 通过率：先看分子（通过用例数）是否一致，再看分母是否包含阻塞、跳过、未执行用例，以及重跑用例是否被重复计入。
- 缺陷数：确认统计范围是否含已关闭、已拒绝、重复缺陷，以及缺陷按创建时间还是关闭时间归属统计周期。
- 需求覆盖率：分母是需求总数还是本期范围需求，分子是“有用例关联的需求”还是“有用例执行过的需求”，两种算法结果差别很大。
同时要明确三个对比对象各指什么：报告快照是发布时固化的那一版数据；统计查询是当前在系统里按条件查出的结果；原始记录明细是用例执行记录、缺陷单、需求关联关系等底层数据。三者时点不同，数值本来就可能不同，登记表里必须标注各自的取数时间。
固定版本号、统计截止时间、环境与项目范围之后，再判断差异性质。少量条目偏差可以逐条核对明细；整体比例偏差应先查口径和同步，避免在明细层面耗费大量时间。
| 指标 | 报告值 | 原始值 | 差值 | 统计时点 | 涉及版本 |
|---|---|---|---|---|---|
| 通过率 | — | — | — | — | — |
| 缺陷数 | — | — | — | — | — |
| 需求覆盖率 | — | — | — | — | — |
按数据链路逐段定位差异来源
差异登记完成后，沿数据链路提出原因假设，并为每个假设准备可观察的验证证据。原因在验证前只是假设，不能直接写进结论。下面四类假设覆盖了大多数不一致场景，可以并行验证，也可以按“口径→查询→同步→关联”的顺序推进。
口径假设：指标定义是否一致
通过率的分母口径最常见：报告可能只统计已执行用例，原始查询却把未执行用例计入总数；重跑用例在报告里按最新结果计一次，在明细里可能留下多条执行记录。缺陷数要核对状态范围和去重规则，同一缺陷被多次流转或重复提交时，按单号去重与按记录计数会得到不同结果。需求覆盖率要确认分母范围，以及“关联”是指用例关联需求还是执行记录关联需求。
验证动作：把报告使用的指标定义写成文字，与原始查询的筛选条件逐项对照；用同一批明细分别按两种口径计算，看哪种结果与报告值吻合。
查询假设：筛选条件是否对齐
版本、时间窗、状态、模块四个条件最容易出现偏差。报告按版本快照统计，原始查询可能按当前状态过滤，导致已关闭缺陷被排除；时间窗按创建时间还是更新时间截取，也会让边界日期的数据进出统计。验证时导出两边的筛选条件截图或配置记录，逐项比对，再用去掉某一条件后的结果观察数值变化。
同步假设：数据是否完整到达
当报告依赖跨系统或中间表汇总时，同步延迟、任务失败或部分成功都会造成条数差异。验证证据包括：源表与中间表在同一时间窗的条数比对、抽样明细的字段值核对、同步任务的执行日志与状态记录。条数一致但字段缺失，说明是映射问题；条数不一致，说明是抽取或写入环节中断。
去重与关联假设：关系是否缺失或重复
用例与需求、缺陷与用例的关联关系缺失时，覆盖率会偏低；关联重复或一条用例挂多个需求时，覆盖率可能虚高。缺陷与用例的关联断裂，会让“未通过用例产生的缺陷”在报告里统计不到。验证方式是抽取差异条目，逐条查看其关联字段是否存在、是否唯一。
| 原因假设 | 验证动作 | 可观察证据 | 状态 |
|---|---|---|---|
| 通过率分母口径不同 | 按两种口径分别重算 | 哪种结果与报告值吻合 | 待确认 |
| 缺陷状态范围不一致 | 对比筛选条件配置 | 条件差异清单 | 待确认 |
| 同步任务延迟或失败 | 源表与中间表条数比对 | 条数差、任务日志 | 待确认 |
| 需求与用例关联缺失 | 抽样查看关联字段 | 缺失条目清单 | 待确认 |
每验证一项，就在对照表里标注“已排除”或“待确认”，避免多个假设混在一起反复讨论。
按风险从低到高执行处置
处置顺序的原则是先只读、后写入，先改配置、后动数据。每一步都要有前置条件、操作人和回退方式，涉及覆盖写入的操作需要审批或设置停止点。
- 只读核对：导出报告数据与原始明细，比对条数，锁定差异条目清单。此步不改动任何数据，操作人可以是测试负责人或质量接口人。完成标志是差异条目可以逐条指认。
- 修正口径：统一指标定义与筛选条件后重算，确认差异是否消失。只调整查询与报告配置，不触碰底层记录，风险最低。若重算后差异消失，说明问题在口径，可直接进入验证环节。
- 处理同步：查看同步任务状态，确认失败区间与影响范围。补跑或重跑前先确认任务是否幂等，避免重复写入；对非幂等任务，先备份中间表再执行。此步需要审批，并记录补跑的时间窗。
- 修复关联与去重：补录缺失的用例—需求、缺陷—用例关联，清理重复记录。操作前备份相关数据表或导出受影响记录，逐条记录变更内容与操作人。批量修改应分批执行，每批完成后抽查。
有覆盖风险的环节集中在第三步和第四步：重跑同步可能覆盖中间表已有数据，批量补录关联可能改写原有关系。执行前应暂停报告对外发布，设置明确的停止点——例如补跑后条数仍不一致、或关联修改影响范围超出预期时，立即停止并回退到备份状态。
在用例、缺陷与需求同属一套工作项体系的环境中，这类关联由系统内的工作项关系直接承载，报告统计与原始记录取自同一数据源，跨系统同步环节减少，排查时可以更多聚焦口径与筛选条件。ONES 测试管理支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，质量统计报表与测试报告基于这些工作项生成，便于按同一版本回溯明细。
验证恢复并防止再次不一致
修复完成后，用同一口径在同一版本、同一时间窗重算三类指标，与原始明细逐条抽样核对。抽样应覆盖差异条目和被修改过的记录，确认通过率、缺陷数、需求覆盖率均与明细吻合。同步任务需观察一个完整统计周期，确认没有再次出现延迟或中断，再恢复报告的正常发布。
复发预防的核心是把口径固定下来。建议建立指标口径登记，每个指标记录四项内容：分子分母定义、统计时点、筛选条件、去重规则。口径变更时同步更新登记并通知报告使用方，避免不同人按不同理解取数。
- 报告发布前增加数据核对检查项：条数比对、关键指标抽样、同步任务状态确认。
- 为每份对外报告指定核对责任人，核对记录随报告留档。
- 记录本次差异的原因、验证证据与处置过程，作为后续同类问题的排查参照。
完成上述动作后，差异登记表、原因验证对照表、处置记录和口径登记共同构成一次完整的排查留档，下次遇到同类不一致时可以直接从链路比对开始，缩短定位时间。
常见问题
报告和原始记录只差几条，还需要按完整链路排查吗？
少量条目偏差通常不需要从同步任务整体查起。先把差异条目逐条指认出来，查看它们的筛选条件、关联字段和状态是否与报告口径一致，多数情况能在口径或关联层面定位。若逐条核对后差异条目仍在增加，再转向同步与查询条件排查。
同步任务补跑之后条数仍然对不上，下一步该查什么？
补跑后条数仍不一致，先确认补跑的时间窗是否覆盖了失败区间，再比对源表与中间表的字段级差异。条数一致但字段缺失，多为映射或转换规则问题；条数仍不一致，则检查抽取环节是否漏掉了状态变更或边界日期的记录。此时应停止继续补跑，保留现场日志再分析。
报告按快照生成，原始查询是实时结果，这种差异需要修复吗？
快照与实时查询的时点不同，数值存在差异属于正常现象，关键是把两者的取数时间标注清楚。用于质量结论时，应统一以同一时点的数据为准，并在报告中注明统计截止时间。若同一时点下仍不一致，才按口径、查询、同步、关联的顺序排查。
需求覆盖率偏低，怎么判断是关联缺失还是分母口径不同？
先抽取若干未覆盖需求，查看其是否实际有用例关联。若关联存在但报告未计入，问题在统计口径或关联字段映射；若关联确实缺失，则属于数据补录问题。两种情况的处置方式不同，前者调整查询与统计配置，后者补录关联并核对是否重复。
在用例、缺陷、需求同属一套工作项体系时，排查会有什么不同？
同一体系内报告统计与原始记录取自同一数据源，跨系统同步环节减少，排查重点更多落在口径定义和筛选条件上。ONES 测试管理支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，质量统计报表与测试报告基于这些工作项生成，便于按同一版本回溯明细。具体指标口径仍以实际配置为准。
