摘要

  • 新测试针对现代化后的代码生成，不等于已经证明旧功能被保留。
  • 迁移的已有测试、自动新建测试、本地构建验证和运行验收各有范围；生成时点也会改变已有验证的证明力。

迁移项目最容易统计的，未必是客户最终购买的结果。代码能构建、测试文件增加，都可以进入进度表；业务是否按原有规则运行，则需要另外的依据。AWS 在 9 月 10 日为 Transform for .NET 加入单元测试生成，自动评估可测试性、规划覆盖，并为业务逻辑、控制器等适合测试的类生成测试。这是 AWS Toolkit for Visual Studio 中可主动开启的功能，但新的交付物能证明什么，仍须说清楚。

单元测试说明给出了一条直接的边界：测试在现代化之后生成，不验证原始代码功能在现代化代码中的保留。补充测试可以提高新代码后续维护时的回归检查能力，却不会凭空找回旧系统应当怎样工作的记录。不能因为两者都叫“测试”，便把一种价值当成另一种证明。

原来已有的测试走的是另一条路径。工具会移植受支持的 MSTest、NUnit、xUnit 项目，并运行移植后的测试、汇总结果。这给原先已经表达出来的预期留下了核对渠道，但不证明原测试本来就覆盖完整，更不证明每一个业务条件都已写入。新生成的测试是补充，不能仅靠数量把自己变成改动前的基线。

同一项新功能内部，也存在时间差别。若在任务开始时选择生成，新测试会进入本地构建验证；若等转化完成后通过交互方式请求生成，则不会被纳入已经结束的那次验证。后一条路径允许先进行后续代码调整，再生成测试。其含义不是这些测试永远不能运行，而是早先一次验证成功，不能追溯证明后来才产生的内容。

因此，交接记录应同时标出交付物与证据的来历：哪些测试从原项目移来，哪些是新生成，验证对应哪个代码版本，还有哪些任务尚未实际运行。一项笼统的“测试通过”总数，会遮住这些区别。覆盖范围的描述，不独立决定被检查的预期是否符合客户需要。

AWS 的迁移前建议本身就要求制定验证计划，考虑行为、外观、安全控制、业务逻辑和数据存储，并将 .NET 现代化与应用架构重构分开。购买自动测试生成，不应悄悄扩大交付承诺，也不应让本来就需要保留的验证工作消失。

在完成与验证指南中，用户仍须阅读报告、运行应用，并检查功能及界面行为是否与原应用相符。这不是覆盖率变好后的形式手续，而是把代码成果接回实际服务的过程。此次发布证明的是一种自动化能力，不是已经完成的生产迁移，也不是可直接写进预算的验收工时节省或缺陷下降比例。