学习来源：ACCELQ《RSAT Migration Guide》。文中的迁移步骤与工期是厂商文章提供的参考信息；后半部分的验证义务、切换门槛和评审建议属于本文的质量工程延伸。ACCELQ 同时提供测试工具，文中涉及工具能力的说法应结合微软官方资料和目标平台现状核实。
把停止支持日期当作规划触发点
微软 Dynamics 365 Finance & Operations（F&O）的回归套件自动化工具 RSAT，通常与 Task Recorder 和 Azure DevOps 测试管理流程配合使用。微软官方文档目前写明，RSAT 将在 2027 年 5 月 15 日之后不再受支持。
**停止支持不等于立即停用。**既有测试可能还会运行，但之后的修复、安全更新、兼容性和维护责任都将成为实际风险。制定计划前，应再核实微软公告中的具体范围和时间。
迁移的目标不是把旧脚本逐条复制到新工具，而是证明关键业务风险在新的执行方式下仍被有效验证。
ACCELQ 原文：RSAT Migration Guide: https://www.accelq.com/blog/rsat-migration-guide/ 微软官方 RSAT 文档与支持说明：https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/perf-test/rsat/rsat-overview/
建立覆盖业务风险的资产基线
从 Azure DevOps 测试计划导出清单，并收集关联的 Task Recorder 录制、Excel 参数文件和 BPM 条目。只数脚本是不够的，还要知道每条测试保护什么业务能力、依赖哪些环境和数据。
| 维度 | 需要记录的内容 | 为什么重要 |
|---|---|---|
| 资产 | 用例标识、名称、版本、录制文件位置 | 保证可追溯，避免遗漏 |
| 业务 | F&O 模块、业务流程、关键控制点 | 判断真实风险覆盖 |
| 特殊渠道 | Cloud POS、Warehouse App | 识别不同迁移路径 |
| 复杂度 | 单屏、多步骤、跨模块或集成场景 | 安排试点并估算工作 |
| 依赖 | 数据、权限、外部系统和环境 | 发现阻塞项 |
| 验证 | 原有断言、预期结果、关联缺陷 | 防止验证能力缩水 |
可以先分成三档：简单的单屏或单模块操作；同一模块内跨多个页面的业务流程；涉及多个模块、外部系统、异步任务或财务数据流的集成场景。少数复杂用例往往决定整体工期，不能按用例总量平均估算。
六步迁移流程
第一步：导出并盘点
建立统一清单，关联测试计划、录制文件（学习笔记提及 .axtr 和 .xml）、Excel 参数和 BPM 记录。确认是否遗漏 Cloud POS、仓库或其他特殊场景。
第二步：按复杂度和风险分类
除复杂度外，也记录业务关键性、执行频率、失败历史、环境依赖和合规影响。按实际业务优先检查过账、结算、库存和授权控制等高风险流程。
第三步：决定每条测试的去留
每条测试明确选择原样重建、增强断言后重建，或淘汰。只有业务流程确已下线、覆盖重复或不再有价值时，才考虑淘汰，并记录业务批准。迁移工具不应自行删除覆盖。
第四步：导入或重建
能否直接导入录制文件取决于目标工具当前能力，不能假设这些格式一定兼容。旧录制可以作为业务流程蓝图，再针对当前 D365 界面重建，避免照搬过时的页面行为；但原有验证意图必须保留下来。
第五步：验证覆盖等价性
**新测试显示绿色，不等于迁移成功。**尽可能在等价环境和测试数据下比较新旧测试，检查前置条件、角色、业务规则、金额、状态变化、下游影响和失败诊断证据。
把每项原始验证义务映射到一条或多条新测试，并标记为“已保留”“已增强”“已移除”或“尚未解决”。已移除和未解决的项目都需要明确的风险决定。
第六步：并行跑完完整业务周期
新旧套件应并行运行至少一个完整业务发布周期。周期应包含实际关键节点，例如月末结账、批处理、系统升级或发布波次，而不是随便选连续四周。
记录新旧结果差异、误报、漏报、环境不一致和调查结论。重要差异得到解释后，再考虑停用旧套件。
把厂商工期当作起始假设
以下区间来自 ACCELQ 学习笔记，是厂商给出的参考估算，不是经过独立验证的行业基准。
| 规模 | 用例数量 | 参考工期 |
|---|---|---|
| 小型 | 少于 50 | 2–4 周 |
| 中型 | 50–200 | 6–10 周 |
| 大型 | 200 及以上 | 12–20 周或更长 |
原文的工期边界在恰好 200 条用例时存在重叠：表格把中型写成 50–200 条、大型写成 200 条及以上；问答又把 200 条归为大型，并给出 12–20 周或更长的估算。以上数字是厂商估算，不是承诺；制定计划时应先明确项目采用哪条分界。
正式规划前，先按复杂度分层抽样试迁移，记录重建、数据准备、调试、评审和并行验证所需时间，再按实际吞吐量估算剩余工作，并为集成风险留出缓冲。
这些风险会让迁移看起来完成得太早
**把迁移当成录制工具替换。**旧套件遗漏的集成验证，应触发覆盖讨论，而不是被原样复制。
ACCELQ 原文还指出，RSAT 不支持涉及 Excel、XML 或 CSV 导入导出的 Data Management 工作区场景，工作流配置测试则需要第三方连接。这是厂商文章对 RSAT 能力边界的描述，使用前应结合微软当前文档和目标测试平台再次确认。微软另有明确建议：数据集成测试不要使用 RSAT，应使用 Data Management Framework 及其数据任务自动化能力。跨模块业务流程回归与文件数据集成验证不是一回事，测试策略应按验证目标拆开。
**跳过盘点。**Cloud POS 或仓库场景可能遗漏，导致完成率看起来很高，实际覆盖却不完整。
**一次性全部重建。**先用代表性小试点验证目标工具，再处理跨模块的复杂情况。
**太早停掉 RSAT。**没有经历完整业务周期，结账、批处理和升级问题可能还没出现。
用验证义务决定何时切换
以下是本文的质量工程建议，不是 ACCELQ 原文的直接结论。
映射表中的测试 ID 和结果均为示例。每条映射还应关联旧、新测试版本，使用的角色与数据，执行环境，关键断言，以及双方的 run ID。对照时若环境或数据不等价，应先记录差异，不能直接把结果视为可比。
| 旧用例 | 验证义务 | 新用例 | 状态 | 证据 |
|---|---|---|---|---|
| RSAT-101 | 提交后订单状态正确 | NEW-011 | 已保留 | 新旧执行记录 |
| RSAT-102 | 过账金额与总账一致 | NEW-021 | 已增强 | 账务核对结果 |
| RSAT-103 | 已下线流程 | — | 已移除 | 业务批准记录 |
测试数量可以减少，但高风险断言不能悄悄消失。迁移验收门槛应按业务风险设定：关键流程有可追溯的新测试，高风险断言已保留或增强，淘汰项有业务依据，并行运行覆盖完整业务周期且重大差异已解释，权限、数据和环境可复现，维护者知道如何诊断与回滚。
“已保留”表示新测试仍验证原有义务且有对应证据；“已增强”表示在保留原义务的基础上增加了检查；“已移除”需要业务批准和理由；没有可靠映射或可比较证据时应标为“尚未解决”。这些状态描述覆盖处理结果，不代表新测试已执行通过。
可以按“盘点、试点、重建、等价性评审、并行运行、切换”的节奏分批推进，按业务流程或模块切换。如果关键验证仍不稳定，就暂时保留旧路径或人工控制，直到有人明确接受剩余风险。
选工具时保持厂商中立：对比 D365 F&O、Cloud POS 和仓库应用支持，断言能力、测试数据管理、Azure DevOps 集成、可维护性、安全、费用和供应商锁定。概念验证应包含有代表性的复杂流程，而不只是一个成功的厂商演示。
切换前还要回答的问题
- 是否掌握全部在用测试及其业务目的？
- 是否区分脚本迁移率与验证义务保留率？
- 是否用等价数据和环境比较新旧结果？
- 并行运行是否包含财务、批处理和集成等关键周期？
- 谁批准淘汰的覆盖和剩余风险？
- 切换、暂停与回滚条件是否明确？
成功看覆盖是否保住，不看绿灯数量
**RSAT 迁移的成功标准，不是新工具跑出了多少绿色结果，而是团队能否证明关键业务风险仍被有效验证。**越早盘点、越早试点、越早积累覆盖等价性证据，迁移就越可控。
资料边界：迁移流程和工期区间依据 ACCELQ 文章及用户提供的笔记；工期为厂商估算。RSAT 支持日期应以微软最新官方资料为准，目标工具的录制格式兼容性也需要逐项验证。
参考资料
- ACCELQ，《RSAT Migration Guide》（厂商文章）: https://www.accelq.com/blog/rsat-migration-guide/
- Microsoft Learn，RSAT 概览、支持说明与数据集成测试指引：https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/perf-test/rsat/rsat-overview/