评估研发数据迁移映射表的覆盖范围，核心是回答“源系统里哪些数据对象、哪些字段、哪些身份与关联关系，在映射表里有明确去向和处置方式”。可以按实体、字段、用户身份、附件文件、链接关系、未映射项处置六个维度逐层核对，每个维度同时给出分母、分子和缺失项清单，覆盖率才具备可比性。需要先说明：覆盖率是映射完整性的证据，不能直接等同于迁移成功。
要点总览（TL;DR）
- 覆盖评估的对象是映射表本身，要回答源端哪些实体、字段、身份、附件和关联关系在表里有明确去向与处置方式，而不是迁移执行结果。
- 按实体、字段、用户身份、附件文件、链接关系、未映射项处置六个维度分别核对，每个维度同时给出分母、分子和缺失项清单，覆盖率才可比。
- 覆盖率＝已确认映射条目数÷源端应迁条目数×100%；分母取源端导出快照并注明冻结时点，分子只计状态为已确认的条目，分母为零记为不适用。
- 覆盖率反映映射完整性，不反映映射正确性与数据质量，需与字段语义抽样核对、迁移验证和切换管理配合使用。
- 评审通过标准由项目方按业务重要性设定，不同维度不宜加权成一个总分，核心数据与历史归档数据可采用不同要求。
评估目标：映射表覆盖范围要回答什么问题
覆盖评估的对象是映射表本身，而不是迁移执行结果。迁移执行结果关注数据是否已写入目标系统、写入后是否可用；覆盖评估关注的是迁移前，源端数据是否在映射表里被逐项登记、逐项安排了去向。两者时间点不同、证据不同，不能互相替代。
一份可用的覆盖评估，需要回答四类问题：
- 迁什么：源系统里有哪些实体类型、多少条记录、哪些字段，属于本次迁移范围。这决定了评估的分母。
- 迁到哪：每个源端对象和字段在目标系统中对应哪个对象、哪个字段，或者对应到目标系统的哪种配置方式。
- 怎么处置：无法直接映射的条目，是丢弃、人工补录，还是保留原值，处置方式要逐项写明，不能留空。
- 谁负责确认：每个维度的映射结论由谁评审、谁签字确认，缺失项由谁跟进闭环。
覆盖评估与迁移验证、切换管理的分工边界也要提前说清。覆盖评估在迁移执行前完成，产出的是映射表版本和缺失项清单；迁移验证在数据写入后核对抽样结果与业务可用性；切换管理负责上线节奏与回退方案。三者串行衔接，覆盖评估通过不代表后两步可以省略。
覆盖维度与指标：实体、字段、身份、附件、链接
六个维度各自回答一类完整性问题，指标定义要统一到“已确认映射条目数÷源端应迁条目数”这一口径上，避免各维度各算各的。下表给出各维度的核对对象与指标定义。
| 维度 | 核对对象 | 分子（已覆盖） | 分母（应迁总量） |
|---|---|---|---|
| 实体覆盖 | 工作项类型、项目、迭代、需求、缺陷、测试用例等对象类型及记录数 | 映射表中已登记且状态为已确认的对象类型与记录数 | 源端导出快照中属于迁移范围的对象类型与记录数 |
| 字段覆盖 | 系统字段与自定义字段，含字段类型、选项值 | 已明确目标字段或已标注丢弃理由的字段数 | 源端在迁移范围内被使用的字段总数 |
| 用户身份覆盖 | 账号、用户组、角色、权限归属、历史操作人 | 已建立对应关系的账号与角色数 | 源端涉及迁移数据的账号与角色总数 |
| 附件与文件覆盖 | 附件、图片、文档及其存储位置 | 已登记目标存储位置与处理方式的文件数 | 源端关联到迁移数据的文件总数 |
| 链接与关联关系覆盖 | 父子、关联、依赖、评论引用、外部链接 | 已登记目标关系类型的关系条目数 | 源端存在的关系条目总数 |
| 未映射项处置口径 | 上述维度中无法映射的条目 | 已明确处置方式（丢弃、人工补录、保留原值）并注明理由的条目数 | 识别出的未映射条目总数 |
实体覆盖要按类型逐类登记，不能只给一个总数。需求、缺陷、测试用例的字段结构和关联方式差异较大，合并计数会掩盖某一类对象的缺失。字段覆盖要区分系统字段与自定义字段：系统字段通常有固定对应关系，自定义字段需要逐个确认目标字段或明确丢弃，丢弃也要写理由，例如该字段在目标流程中无对应语义、历史值仅用于旧报表。
用户身份覆盖容易被低估。除了账号本身，还要核对角色与权限归属，以及历史操作人——工作项创建人、评论作者、变更记录操作人。历史操作人无法对应时，处置方式要提前约定，例如归并到迁移专用账号并在映射表中标注。附件与文件覆盖要落到存储位置：文件迁到目标系统的哪个空间、是否保留原目录结构、同名文件如何处理。链接与关联关系覆盖要区分系统内关系与外部链接，外部链接通常只能保留文本形式，需要在映射表中标注为“保留原值”。
数据口径与证据：分母怎么定、证据怎么留
分母取源系统的导出快照，并在映射表中注明统计截止时点。迁移窗口内源系统仍在产生新数据时，分母会随时间变化，因此要约定一个冻结时点，冻结之后新增的数据要么纳入下一批迁移，要么在映射表中单独标注。没有冻结时点的覆盖率，两次统计之间不具备可比性。
分子取映射表中已登记且状态为“已确认”的条目。仅登记但未评审的条目计入“待定”，不计入分子。这样处理会让覆盖率略低，但能避免把未确认的映射当成已完成，减少迁移执行阶段的返工。
证据形式建议保留三类：源端导出清单（含导出时间、导出人、记录数）、映射表版本（每次评审后冻结版本号）、评审记录（参与人、结论、遗留问题）。三类证据与覆盖率数字一起归档，后续复核时才能复算。
缺失值、空字段和重复记录要有统一规则。源端字段为空，按“空值”计入分母但不要求映射目标值，在映射表中标注为空值处理；重复记录先去重再计数，去重规则写入口径说明；同一字段在源端存在多种类型混用的情况，按类型拆分统计，不合并成一个条目。
以下情形会导致覆盖率不可比，需要在报告中说明：源端统计口径发生变化（例如统计范围从全部项目缩小到活跃项目）、映射表版本不一致（分子与分母取自不同版本）、导出快照与映射表登记时间跨度较大。出现这些情形时，应重新取数后再比较，不直接引用历史数字。
计算与评估步骤：从清单到覆盖率结论
评估按五个步骤推进，每一步都有明确产物，便于复算和交接。
- 导出源端全量清单并计数。按实体类型分别导出，记录每类的记录数、字段使用情况、关联关系数量、附件数量。产物是分类型的源端清单与计数表，作为各维度的分母。
- 逐类比对映射表登记条目。对每个源端条目在映射表中查找对应记录，标记为“已映射”“待定”“未映射”三种状态。产物是带状态标记的比对结果表。
- 按维度计算覆盖率。公式为：覆盖率＝已确认映射条目数÷源端应迁条目数×100%。六个维度分别计算，不合并成一个总分。产物是分维度覆盖率表。
- 汇总未映射项清单。每条未映射项写明所属维度、源端标识、处置方式（丢弃、人工补录、保留原值）、理由和责任人。产物是未映射项处置清单。
- 评审确认并冻结映射表版本。由业务方与技术方共同评审覆盖率结果和处置清单，确认后冻结版本号，作为迁移执行的依据。产物是评审记录与冻结版本。
计算时注意两个细节：同一源端条目可能同时涉及实体和字段两个维度，分别计数，不互相抵扣；关联关系的分母按关系条目计，不按工作项条数计，否则一条工作项挂多个关联时会被少算。
示例：一张映射表覆盖率的算法演示
以下为演示情景，数字仅用于说明算法。
某类工作项源端共1200条，映射表中已确认1080条，覆盖率＝1080÷1200×100%＝90%。剩余120条进入未映射项处置清单：其中80条因属于已关闭的历史项目、不在本次迁移范围，标记为丢弃并注明理由；40条因字段结构特殊需人工补录，指定责任人和补录完成时间。
字段维度：源端自定义字段40个，已映射34个，覆盖率＝34÷40×100%＝85%。未映射的6个字段全部标记丢弃，理由分别为：3个仅用于旧版报表、2个与目标字段语义重复、1个为测试遗留字段。丢弃理由逐条写入映射表，不停留在“不迁”两个字。
分母为零时的处理：某类实体在源端不存在记录，该维度分母为0，覆盖率记为“不适用”，不记为100%。记为100%会虚增整体完整性，评审时容易被误读为已全部覆盖。
把三个维度的结果放在一起看：实体90%、字段85%、某类实体不适用。报告应同时呈现三个数字和各自的分母，而不是给出一个加权平均分。加权方式一旦引入权重，就需要说明权重依据，否则不同项目之间的数字无法比较。
解读与限制：覆盖率高低说明什么、不说明什么
覆盖率反映映射完整性，即源端应迁条目中有多少在映射表里有了明确去向和处置方式。它不反映映射正确性，也不反映数据质量。一个字段在映射表中登记了目标字段，但两边语义不一致，覆盖率仍然计入，迁移后数据可能失真。因此高覆盖率仍需要配合字段语义抽样核对。
不同实体维度的覆盖率不宜简单加权成一个总分。需求、缺陷、测试用例对业务的重要性不同，权重设定缺乏统一依据，加权后的总分反而掩盖了某一维度的明显缺口。更稳妥的做法是分维度呈现，由项目方按业务重要性判断哪些维度必须达到更高水平。
覆盖率需要与迁移验证、切换管理的结果核验配合使用。覆盖评估回答“有没有安排去向”，迁移验证回答“迁过去对不对、能不能用”，切换管理回答“什么时候切、出问题怎么回退”。三者证据链完整，才能支撑迁移决策。
评审通过标准由项目方按业务重要性设定，不存在通用达标线。核心交易类数据可能要求接近全覆盖并逐条确认，历史归档类数据允许较高比例的丢弃，但丢弃必须有理由和责任人确认。标准一旦确定，应写入评审记录，后续批次沿用同一口径，保证不同批次之间可比。
在评审与未映射项处置环节，映射表、处置清单和评审记录需要有承载位置和状态流转。ONES 的文档与工作项可以承担这一过程：映射表作为文档维护版本，未映射项作为工作项逐条登记处置方式与责任人，评审结论通过状态流转留痕。ONES 从 Jira 迁移到 ONES Project 时，迁移范围覆盖项目、工作项、字段配置、附件、评论等信息，用户、用户组和系统配置也在迁移范围内；从 Confluence 迁移到 ONES Wiki 时，可迁移空间、页面、附件和权限结构。这些范围说明可以作为映射表实体与字段维度登记的参照，具体到每个字段和关联关系的映射粒度，仍需在迁移前逐项确认。
常见问题
源系统在迁移窗口内还在产生新数据，分母应该怎么定？
先约定一个数据冻结时点，分母取该时点的源端导出快照，并在映射表中注明导出时间、导出人和记录数。冻结之后新增的数据，要么纳入下一批迁移，要么在映射表中单独标注为后续批次，不混入本次分母。如果两次统计的冻结时点不同，覆盖率数字之间不具备可比性，报告中应说明取数时点，避免直接引用历史结果做趋势判断。
映射表里已登记但还没评审的条目，算不算覆盖？
建议不计入分子。分子只取状态为“已确认”的条目，已登记未评审的条目归入“待定”，单独列出数量和清单。这样算出的覆盖率会略低，但能避免把未确认的映射当成已完成，减少迁移执行阶段的返工。评审时可以把“已确认覆盖率”和“含待定的登记率”两个数字并列呈现，前者用于判断可执行范围，后者用于判断工作进度。
某一类实体在源端没有记录，覆盖率记100%还是记不适用？
记为“不适用”，不记为100%。分母为零时，覆盖率公式没有意义，记100%会虚增整体完整性，评审时容易被误读为已全部覆盖。报告中应同时写明该类实体在源端无记录这一事实，以及判断依据，例如导出清单中该类对象计数为零。如果后续批次源端出现了该类数据，再重新纳入统计。
覆盖率高是否意味着迁移后数据可以直接使用？
不能这样推断。覆盖率只说明源端条目在映射表里有了明确去向和处置方式，不说明映射关系正确。字段语义错配、选项值口径不一致、关联关系指向错误，都可能在覆盖率很高的情况下发生。因此覆盖评估之后仍需做字段语义抽样核对，并在数据写入后通过迁移验证检查业务可用性。覆盖评估、迁移验证、切换管理三段证据链完整，才能支撑迁移决策。
未映射项应该由谁确认处置方式，处置清单要写到什么程度？
处置方式由业务方确认、技术方复核，逐条写明所属维度、源端标识、处置类型（丢弃、人工补录、保留原值）、理由和责任人。丢弃类条目要写清为什么丢弃，例如仅用于旧版报表、与目标字段语义重复、测试遗留字段；人工补录类要给出补录责任人和完成时间。只写“不迁”两个字，后续复核时无法判断处置是否合理，也无法追溯决策依据。
