MSTest 4.4 支持使用应用在生产环境中可能采用的同一部署模型来运行测试项目，即生成测试源代码并启用 Native AOT 和裁剪。其目的不是取代常规的托管测试运行，而是增加一条原生路径，在应用发布前发现与预编译和删除未使用代码相关的问题。
据 Principal Software Engineer Amaury Levé 介绍，将 MSTest.Sdk/4.4.0 与 net10.0 目标框架搭配使用，并设置 PublishAot=true，即可启用 MSTest 源代码生成和原生可执行文件路径。MSTest.Sdk 默认使用 Microsoft Testing Platform，即 MTP。仍在使用 VSTest 的项目应查看迁移到 MTP 的指南，因为命令行参数、CI 集成以及部分受支持的 .runsettings 配置项有所不同。
实际会发生什么变化？
完成项目配置后，应针对应用所面向的相同操作系统和架构发布测试。来源示例使用标识符 linux-x64，也可以替换为 win-x64 或 osx-arm64 等值。发布后，直接运行生成的可执行文件；在 Windows 上则使用带 .exe 扩展名的文件。
该路径减少了对程序集全面反射扫描的依赖，例如调用 Assembly.GetTypes()，并使用生成的特性和委托来创建和调用受支持的测试。但源代码生成并不意味着完全没有 Reflection；默认的 ReflectionFree 模式仍保留部分反射后备路径。在调查兼容性问题时，可以使用 MSTestSourceGenMode=Rooting 保留已发现测试的成员，同时继续进行反射执行。
在扩展前采用有限的 CI 流程
实际建议是保留快速的托管测试运行，以提供日常反馈，然后选择一个与部署路径直接相关的测试项目，在 CI 中增加 Native AOT 试验。应从以下三个明确方面比较两条路径：
- 发现完全相同数量的测试。
- 获得相同的测试结果。
- 将原生发布和运行时间与测试执行时间分开记录。
最好先在计划任务或发布验证阶段开始试验；只有当它提供的信号值得额外的发布和运行成本时，才将其移至每个合并请求中。同时，应选择能够测试部署敏感路径的项目，例如序列化、依赖注入、配置绑定、依赖 Reflection 的扩展，或团队需要证明其与 Native AOT 兼容性的库。仅包含简单计算测试的项目，无法为应用的实际就绪状态提供太多证据。
应转化为验收门槛的限制
部分测试可能成功运行，进程也会成功退出，但某些类并未被记录。例如，测试类只是继承了 [TestClass] 特性，而不是直接声明该特性；或者该类不可访问、为文件本地类、静态类、开放泛型类或抽象类。来源指出，诊断信息 MSTEST0069 有助于发现其中一种情况。因此，测试数量一致应当成为发布条件，而不是可以忽略的备注。
其他限制包括公共测试方法，或使用 ref、out 或 in 参数的方法；此外，通过 [AssemblyFixtureProvider] 也不支持某些静态部件模式。部分 MSTest SDK 集成、MTP 扩展和 CI 报告在 Native AOT 路径中不可用，而根据本文，TRX 和 Code Coverage 仍受支持。因此，应将分析器警告和构建诊断视为迁移门槛，而不是需要屏蔽的警告。
为什么这种方式很重要？
托管测试和 Native AOT 路径回答的是两个不同的问题：前者加快开发周期，后者验证测试本身能否在应用将使用的部署模型中运行。这并不等同于对最终生产构件进行全面测试；配置、操作系统、架构、外部服务和打包方式可能有所不同。但它消除了一个重要变量，即测试与应用之间裁剪和预编译模型的差异。
性能提升并无保证，也不应成为主要理由。源代码生成可能缩短发现和启动时间，但执行时间、进程启动、发布以及剩余的 Reflection 可能主导总耗时。这里的编辑性结论是，这一试验的核心价值在于提高测试与部署之间的一致性，即使速度提升有限。该方法仍然可以回退：如果该路径的成本超过其带来的信心，可以降低运行频率、更换所选项目，或停止试验，而不会影响托管测试套件。