评估研发数据迁移映射表的覆盖范围，实质是核对“应迁数据”是否都被纳入映射口径。建议从实体、字段、用户身份、附件与富文本、链接与层级关系、历史与时间信息六个维度逐项盘点，用“已映射项数÷应映射项数”计算覆盖率，并单独记录缺失、降级和待确认项。覆盖率说明范围完整性，迁移后数据是否可用仍需另行验证。
要点总览（TL;DR）
- 覆盖范围评估的对象是映射表本身，回答“应迁数据是否都纳入了映射口径”，产出逐维度覆盖率与缺口清单，不判断迁移执行是否成功。
- 建议按六类维度逐项盘点：实体范围、字段范围、用户身份、附件与富文本、链接与层级关系、历史与时间信息，每类维度单独核对判定要点。
- 覆盖率=已映射项数÷应映射项数×100%；分母来自源系统盘点导出并固定时点与筛选条件，分子取完全映射项，降级与待确认项单独计数。
- 缺失、空字段、系统内置项和分母为零的维度需事先约定统计规则：空字段计入分母，明确不迁移的项剔除并说明，分母为零标注为不适用而非100%。
- 覆盖率只反映范围完整性，不能等同于迁移后数据可用；不同维度不宜加权平均，降级项需单独评估业务影响，并与迁移验证、切换管理的结果核验配合解读。
评估目标：覆盖范围要回答什么问题
覆盖范围评估的对象是映射表本身，回答一个具体问题：源系统中需要迁移的数据，是否都在映射表里有对应的目标位置和处理方式。评估的产出是一份逐维度的覆盖率结果和缺口清单，用来发现遗漏项、降级项和待确认项，为迁移方案补充和资源安排提供依据。
这项评估与另外两类工作有明确分工。工作流、插件行为、权限规则等配置类迁移，关注的是系统行为能否在新环境中复现，属于配置迁移评估；迁移结果核验关注数据落到目标系统后是否完整、可用、业务可继续，属于迁移验证与切换管理。覆盖范围评估处在两者之前，只判断“映射表有没有把该迁的东西纳进来”，不判断迁移执行是否成功。
明确这个边界可以避免两种误用：一是把覆盖率当作迁移成功的证明，二是把配置迁移的问题混入数据映射缺口。评估结论应当写成“某维度覆盖率为多少、缺口有哪些、降级项影响哪些业务”，而不是“迁移可以上线”。
覆盖维度清单：实体、字段、身份、附件与链接
维度划分的作用是让盘点有稳定的分类口径，避免遗漏，也避免同一类数据被重复统计。以下六类维度覆盖研发数据迁移中常见的应迁内容，实际项目可在此基础上增删，但增删需在评估说明中写明理由。
| 维度 | 盘点对象 | 判定是否覆盖的要点 |
|---|---|---|
| 实体范围 | 工作项类型、需求、缺陷、测试用例、迭代、版本、文档等 | 源系统中每一类实体是否有对应的目标实体类型；实体数量是否与盘点清单一致 |
| 字段范围 | 系统字段、自定义字段、状态与枚举值、必填与只读属性 | 每个字段是否有目标字段；字段类型是否兼容；枚举值是否逐项对应；必填与只读属性在目标端是否可满足 |
| 用户身份 | 账号、姓名、邮箱、所属组与角色 | 账号是否有唯一对应关系；同名或离职账号如何处理；组与角色归属是否在映射表中体现 |
| 附件与富文本 | 附件、图片、评论正文中的内嵌资源 | 附件是否按实体逐条登记；正文中的图片和嵌入资源是否有处理方式；文件大小与格式限制是否记录 |
| 链接与层级关系 | 父子层级、关联、依赖、跨实体引用 | 每类关系是否有映射规则；跨实体引用在目标端能否重建；关系两端实体都纳入映射时才计为覆盖 |
| 历史与时间信息 | 创建/更新时间、状态流转历史、评论时间线 | 时间字段是否保留原值；流转历史与评论时间线是否有承载方式；无法保留时是否登记为降级 |
实体维度是其他维度的基础。实体类型没有纳入映射，其字段、附件和关系通常也无从谈起，因此盘点时应先锁定实体清单，再逐类展开字段与关系。字段维度要特别关注自定义字段和状态枚举：这两类在源系统中往往由业务团队自行扩展，数量多、命名不统一，容易在映射表中被笼统带过。用户身份维度不能只统计账号数量，还要看组与角色归属，因为权限和通知往往依赖这层关系。附件与富文本维度需要区分独立附件和正文内嵌资源，两者的处理方式通常不同。链接与层级关系维度按关系类型逐类核对，关系两端都覆盖才算覆盖。历史与时间维度则要区分“保留时间值”和“保留变更过程”，后者对审计和追溯更关键。
数据口径：分母、分子与缺失值怎么定
覆盖率要可复算，前提是分母和分子都有固定来源。分母来自源系统盘点导出，导出时需固定时点、筛选条件和导出人，例如“某项目全部未关闭工作项及其字段清单，导出日期为某日”。分子来自映射表的实际条目，按维度逐条计数。两者用同一套键值匹配，才能保证分子分母口径一致。
| 维度 | 分母来源 | 分子来源 | 缺失与特殊项处理 |
|---|---|---|---|
| 实体范围 | 源系统实体类型清单及各类数量 | 映射表中已登记的目标实体类型 | 源系统存在但映射表未提及的实体类型计为缺失 |
| 字段范围 | 源系统字段清单（含自定义字段、枚举值） | 映射表中逐字段登记的目标字段 | 空值字段仍计入分母；系统内置且不迁移的字段需在说明中列明并剔除 |
| 用户身份 | 源系统账号、组、角色清单 | 映射表中的账号对应关系与组角色归属 | 离职或重复账号单独列出，不直接计入缺失 |
| 附件与富文本 | 按实体统计的附件数量与含内嵌资源的正文条目 | 映射表中登记的附件处理方式与正文资源处理方式 | 超出大小限制的附件登记为降级，不计为完全映射 |
| 链接与层级关系 | 源系统关系类型清单及各类关系数量 | 映射表中逐类关系规则 | 关系一端实体未纳入映射时，该关系计为待确认 |
| 历史与时间信息 | 需保留的时间字段与历史类型清单 | 映射表中对应承载方式 | 仅保留时间值、不保留变更过程的登记为降级 |
分子需要区分三类结果：完全映射、降级映射、待确认。完全映射指源项在目标端有明确对应且属性可完整承载；降级映射指有对应但部分属性丢失或转换；待确认指映射规则尚未定论。覆盖率的主口径使用完全映射项数，降级与待确认单独列出，避免用“有登记就算覆盖”抬高数字。
缺失值和空字段的处理规则要事先约定。字段在源系统中大量为空，不代表可以不盘点，空字段仍计入分母，因为目标端字段结构需要承载它。系统内置且明确不迁移的项，应在分母中剔除并在评估说明中列明剔除清单。某个维度在源系统中确实不存在，例如项目没有附件，则该维度标注为“不适用”，不按100%计入汇总，也不参与平均。
计算与评估步骤：从盘点表到覆盖率结论
以下步骤按顺序执行，每一步都留下可复核的中间产物，便于他人复算或在下一次评估中对比。
- 按维度导出源系统盘点清单并冻结版本。每个维度一份清单，记录导出时点、筛选条件、导出人和数据量。冻结后如需更新，另存新版本并注明差异。
- 将映射表条目与盘点清单做键值匹配。为每类对象确定匹配键，例如实体用类型编码、字段用“实体类型+字段标识”、用户用账号。匹配结果标记为已匹配、未匹配、多对一或一对多。
- 按维度计算覆盖率并标注降级与待确认。公式为：覆盖率 = 已映射项数 ÷ 应映射项数 × 100%。已映射项数取完全映射项，降级与待确认项在覆盖率之外单独计数。
- 汇总缺口清单并给出处置优先级。缺口按影响面排序，例如影响全部工作项的字段缺失优先于个别项目的附件超限；待确认项指定确认人和确认时限。
计算时保持维度独立，不把六个维度的覆盖率直接相加或平均。若需要向上汇报一个总览数字，可以按维度分别列出，并注明各维度分母规模，让读者自行判断权重。评估结果建议形成一张表：维度、应映射项数、完全映射项数、降级项数、待确认项数、覆盖率、主要缺口。这张表既是结论，也是后续补充映射表的工作清单。
在盘点清单和映射表需要多人协作维护时，可以把清单和映射表作为文档或工作项放在同一协作平台中管理，按维度分配负责人、记录确认状态和变更历史。ONES 的迁移方案覆盖项目、工作项、状态、字段、附件和历史记录等内容，迁移用户、用户组与系统配置，问题数据包含属性、属性值、附件和评论；这些迁移范围可以作为映射表盘点的对照参考，具体字段级对应关系仍需在项目评估中逐项确认。
示例：一张映射表覆盖率的计算过程
以下为演示情景，数字用于说明计算方法，不代表任何真实项目。
设定某项目需迁移“缺陷”这一类工作项，盘点清单显示：缺陷共 1,200 条，涉及字段 42 个（系统字段 18 个、自定义字段 24 个），涉及用户账号 86 个，附件 340 个，缺陷间关联关系 210 条，需保留的状态流转历史 1,200 条。
字段维度：映射表登记了 38 个字段的对应关系，其中 35 个为完全映射，3 个自定义字段因目标端类型不兼容登记为降级。覆盖率 = 35 ÷ 42 × 100% ≈ 83.3%，另有降级 3 项、缺失 4 项。缺失的 4 个字段需补充映射规则或确认不迁移。
用户身份维度：86 个账号中 80 个有明确对应，4 个为离职账号待确认归属，2 个因邮箱重复需人工合并。覆盖率 = 80 ÷ 86 × 100% ≈ 93.0%，待确认 6 项。
附件维度：340 个附件中 322 个登记了处理方式，18 个超出目标端大小限制登记为降级。覆盖率 = 322 ÷ 340 × 100% ≈ 94.7%。
关联关系维度：210 条关联中 150 条有映射规则，60 条因关联对象属于未纳入本次迁移的实体类型而计为待确认。覆盖率 = 150 ÷ 210 × 100% ≈ 71.4%，是本次评估中最低的维度，应优先处理。
从结果读出的结论是：字段与关联关系是主要缺口，前者影响缺陷信息的完整表达，后者影响追溯链路；用户身份的待确认项集中在离职账号，需业务方确认归属后再定。降级项单独列出，交由业务方评估可接受程度。
解读与限制：覆盖率能说明什么、不能说明什么
覆盖率反映的是映射表在范围上的完整性，即应迁数据被纳入口径的比例。它不能说明迁移后数据在目标系统中是否可用、字段值是否正确转换、业务流程能否连续运转。覆盖率高的维度仍可能在执行阶段出现转换错误，覆盖率低的维度也可能因为缺口项业务价值低而影响有限，因此覆盖率需要与迁移验证的结果配合解读。
不同维度的覆盖率不宜简单加权平均。实体、字段、用户、附件、关系、历史六类维度的分母规模和业务影响不同，一个总平均数字会掩盖关键缺口。汇报时按维度并列呈现，并标注分母规模，比给出单一总分更有决策价值。
降级映射需要单独评估业务影响。降级项在覆盖率计算中不计入分子，但它们并非全部不可接受，例如部分历史时间线只保留时间值可能满足审计要求。评估时应为每类降级项写明影响范围和业务方的接受结论，而不是统一按缺失处理。
覆盖范围评估的结论应与迁移验证、切换管理的结果核验配合使用。前者回答“映射表是否纳全了”，后者回答“迁移后是否真的可用”。两者都完成，才能对迁移准备程度形成完整判断。对于映射表中尚未明确的链接关系、历史记录保留程度等细节，应在具体项目的迁移评估中逐项确认后再更新覆盖率。
常见问题
源系统里大量字段是空的，盘点时能不能跳过这些字段？
不建议跳过。字段在源系统中为空，目标端的字段结构仍然需要承载它，因此空字段通常仍计入分母，只是不产生实际数据迁移量。真正可以从分母中剔除的是“系统内置且明确不迁移”的字段，剔除时要在评估说明中列出清单和理由，便于他人复核。把空字段直接排除，会让字段维度的覆盖率偏高，掩盖目标端字段结构是否够用的问题。
某个维度在源系统中不存在，覆盖率应该记100%还是0？
两者都不合适，应标注为“不适用”。例如项目本身没有附件，附件维度的分母为零，此时覆盖率没有计算意义。把它记成100%会抬高整体观感，记成0%又会制造并不存在的缺口。处理方式是单独标注不适用，并在汇总时排除该维度，不参与任何平均或加权计算，同时在评估说明中写明判断依据。
降级映射项在覆盖率里算不算已覆盖？
建议不计入覆盖率主口径。覆盖率分子取完全映射项，降级映射和待确认项在覆盖率之外单独计数并列示。降级项并非全部不可接受，例如部分历史时间线只保留时间值可能满足审计要求，因此需要为每类降级项写明影响范围和业务方的接受结论。这样处理可以避免“有登记就算覆盖”抬高数字，也保留了降级项的业务判断空间。
映射表在评估过程中还在补充，覆盖率怎么保证可复算？
关键是固定分母并给映射表留版本。分母按维度从源系统导出后冻结版本，记录导出时点、筛选条件、导出人和数据量；映射表后续补充时另存新版本并注明差异。计算时用同一版本的盘点清单与同一版本的映射表匹配，结论中注明所用版本。这样他人在下一次评估时可以复算，也能对比两次评估之间覆盖率的变化来自哪些补充项。
覆盖率评估做完，是不是就可以安排迁移上线了？
还不能。覆盖范围评估只回答映射表是否把应迁数据纳全了，迁移后数据在目标系统中是否可用、字段值是否正确转换、业务流程能否连续运转，需要由迁移验证与切换管理的结果核验来回答。两类工作都完成，才能对迁移准备程度形成完整判断。评估结论宜写成“某维度覆盖率为多少、缺口有哪些、降级项影响哪些业务”，并据此补充映射表、安排验证重点。
