当测试进程突然死亡时，一个红色的 CI 任务往往不足以说明问题。更重要的是：主机消失的那一刻，到底哪些测试已经完成，哪些还在运行？Microsoft.Testing.Platform（MTP）的崩溃恢复 TRX 功能给出了第一个答案——它在测试运行期间持续写入已完成的结果，而不是等到进程干净退出后才生成报告。而配套的崩溃序列文件（crash-sequence）则记录测试进度，帮助定位中断发生时正在执行的测试。 这种机制把原本不透明的基础设施故障，变成了可以归档、可以复查的证据。本文附带一个可运行示例：它故意触发受控的主机崩溃，然后验证部分 TRX 报告依然有效，且序列日志准确指向被中断的测试。 从 MTP 2.3 版本开始，TRX 报告器会在测试执行过程中流式输出结果。如果宿主进程意外终止，已经写入的结果会保留在一份有效的部分报告里。微软官方在 MTP 测试报告指南中明确记载了这一行为。 这个区别很关键。传统的报告只在测试完全干净地运行结束后才统一写入；一旦进程崩溃，报告很可能随进程一起消失，所有已完成的工作都化为乌有。流式报告虽然无法恢复一个从未运行完的测试，但至少能保住那些已经完成的测试结果。 为了在崩溃时获得更多诊断信息，我通常将 TRX 与两个稳定的 MTP 崩溃诊断选项配合使用：`--crashdump --crashdump-type Mini --crash-sequence on`。其中迷你转储文件包含进程状态，适合深度调试；序列日志体积更小，记录了测试进度，因此可以快速锁定崩溃时正在运行的测试。微软的崩溃和挂起转储文档详细解释了这些开关的用法以及平台限制。 这几个产物回答了不同的问题：TRX 告诉我“什么完成了”，序列文件缩小了“执行在哪里停止”，转储文件则可能回答“为什么停止”。 示例项目针对 .NET 10，使用 MSTest.Sdk 4.3.3；解析后的 MTP 报告与崩溃转储包版本为 2.3.3。在项目文件中启用崩溃转储扩展，默认的 MSTest 配置即可提供 TRX 报告。你可以在项目文件里看到类似 `` 的设置，后续只需确保 crash-dump 扩展包含在内。 通过这套组合，CI 中的进程崩溃不再是一片空白。你可以把证据留存下来，在事后准确回答：“当时哪些测试已经成功？哪个测试正在进行？” 这正是崩溃恢复 TRX 的核心价值。
热门跟贴