问题不在于构建变红本身，而在于判断其原因是新的回归、间歇性测试，还是测试主机崩溃并删除了调查所需的证据。.NET Blog 介绍了 Microsoft.Testing.Platform（简称 MTP）如何让测试报告对开发人员、审阅者和持续集成工具更有用，而不只是显示一长串日志。
这些实践面向使用 GitHub Actions 或 Azure DevOps，并希望让失败信息抵达合并请求中的决策点的团队。该平台还可以在一次运行中生成多种报告格式，并提供程序、仪表板和开发工具能够稳定使用的结构化输出。
使用构建历史区分回归和间歇性故障
Azure DevOps 已经在 Tests 选项卡中显示测试证据，但向报告器传入历史窗口可以为每个失败添加上下文。使用 --report-azdo-flaky-history 14 时，平台会查询过去 14 天的管道历史，然后将间歇性失败的测试与没有类似历史记录的测试区分开来。
间歇性测试可能显示为 [flaky: failed 3/20 in last 14d]，而没有此类记录的失败则会获得 [REGRESSION] 标签。这有助于审阅者从适当的路径开始调查：没有历史记录的失败需要立即作为潜在回归处理，而重复出现的失败则可以从其已知记录入手。
如果团队希望改变这种持续集成行为，可以使用 --report-azdo-demote-known-flaky，将已知的间歇性故障转为警告，同时保留回归为错误。但文章强调，这一决定应当明确：我们是只想利用历史记录引导审阅者，还是希望它自动改变失败的严重级别？在 testfx 管道中，使用了历史评论，同时仍将所有失败状态设为阻塞构建。
还可以使用 --report-azdo-slow-test-history，利用同一历史记录发现运行缓慢的测试。该选项会将每个测试与其过去的表现进行比较，并使用可调倍数和最小运行次数阈值，以免一次冷启动运行触发不准确的警报。
测试主机崩溃时保留证据
过去，TRX 格式的结果会在运行结束时序列化，因此严重崩溃可能导致整个报告丢失。现在，结果会在生成过程中写入磁盘；结合崩溃转储扩展，主机停止时可以完成部分报告：
dotnet test --report-trx --crashdump
这样会生成一个有效的 TRX 文件，其中包含所有已完成的测试，以及崩溃时正在运行的测试列表。该扩展还会写入扩展名为 .crash.sequence.log 的文件，记录每个测试的开始和结束时间；即使并行运行多个测试，也有助于确定哪个测试已经开始但尚未结束。
附件也包含在处理范围内。当路径超过 Windows MAX_PATH 限制时，崩溃转储、停止评论和测试扩展文件不再会在 .NET Framework 上被静默忽略。如果附件无法复制，控制台会显示相应信息，而不只是将其记录在 TRX 文件中。结果是，未完成的运行会明确显示为未完成，而不会伪装成隐藏了缺失证据的绿色报告。
根据使用方选择报告格式
一次运行可以启用多种格式，无需单独的转换步骤。TRX 格式适用于 .NET 工具，HTML 适合直接检查，而 JUnit XML 和 CTRF JSON 适用于仪表板和跨技术自动化。CTRF 提供了一个共享的 JSON 架构，用于汇总 .NET 与其他语言的结果。
持续集成系统会在结果视图中读取 TRX 和 JUnit 格式，而 HTML 和 CTRF 则作为可下载文件显示，或用于仪表板。在 Azure DevOps 中，--report-azdo-upload-artifacts files 选项可以自动上传结果证据文件。此外，还应使用 --report-<format>-filename 选项以及 {asm} 和 {tfm} 等占位符命名文件，以免在面向多个运行时框架的项目中发生结果冲突。
让输出稳定并适合自动化
--list-tests json 选项会提供一份带有架构版本的文档，描述已发现的测试及其源代码位置。与分析可能在不同版本之间发生变化的控制台文本相比，这为测试选择、变更影响分析和开发环境集成提供了稳定入口。
MTP 的输出还适用于代理环境和语言模型；它会隐藏标识横幅、ANSI 字符和进度动画，并默认仅显示失败测试的 stdout 和 stderr。可以通过 NO_COLOR 以及 --ansi 和 --progress 选项控制相关行为。
固定报告策略并验证兼容性
文章建议在一个测试项目中试用 MTP 2.3 或更高版本，然后在 GitHub Actions 中启用 --report-gh，或在 Azure DevOps 中启用 --report-azdo。选择策略后，将配置保存在存储库中的 testconfig.json 文件内，使本地运行和 CI 运行生成相同的报告。还可以使用 Directory.Build.props 将统一设置应用于所有测试项目，或者使用 AllMicrosoft 配置文件启用稳定的扩展集合，同时保留 JUnit 和 CTRF 为可选项。
不使用 MSTest.Sdk 的团队应验证报告器包版本与测试框架所针对的 MTP 版本相匹配。MTP 2.x 支持 MSTest.TestAdapter 4.0.0、NUnit3TestAdapter 6.0.1、TUnit 1.7.16、YoloDev.Expecto.TestSdk 0.16.0，以及 xunit.v3 4.0 的预览版本。此外，该解决方案不支持混合使用 MTP 和 VSTest 项目，因此应在存储库级别配置 MTP 运行订阅。
Azure DevOps 历史选项需要使用 SYSTEM_ACCESSTOKEN: $(System.AccessToken)。没有该令牌时，运行仍会继续，但会跳过历史评论。在现有管道中，可以使用相应的 MTP 选项替换测试结果发布和文件发布任务，但代码覆盖率发布不会被替换；因此必须保留 PublishCodeCoverageResults@2。此外，不应同时启用直接发布和 PublishTestResults@2，因为这会为同一个构建创建两次独立的测试运行。