Azure DevOps中VSTest任务运行MSTest2动态数据测试60分钟超时问题

根因排查说明 #

经过实际验证，你遇到的固定60分钟超时触发问题，通过配置作业（Job）级别的超时阈值即可完全解决，前期两个尝试方案失效的原因非常明确：

• 你遇到的60分钟硬截断，是Azure Pipeline对单个作业的默认隐式超时约束，系统默认单个作业的最长运行时长就是60分钟，这个约束的优先级高于作业内部所有任务的超时设置，哪怕单独给VSTest测试任务配置了几小时的允许运行时长，只要整个作业跑满60分钟，就会被系统强制终止。很多开发者排查这类问题时，第一反应都是调整内部任务的超时设置，反而忽略了作业层的默认隐式约束，往往会浪费数小时的排查时间。
• 两个前期尝试方案无效的具体原因：
  • 任务级超时配置只是定义单个步骤的允许运行时长，无法突破外层作业的隐式超时上限，自然达不到预期效果
  • customRunTimePerBatchValue是测试执行器内部用来拆分用例批次、调度执行节奏的参数，和Pipeline层面的强制超时逻辑完全无关，不会对截断时间产生任何影响

具体修复配置 #

只需要在Pipeline定义的作业层级，显式覆盖默认的超时阈值即可，不需要改动现有MSTest测试代码和DynamicData的绑定逻辑，示例配置如下：

jobs:
- job: RunMSTestSuite
  # 结合你100余条用例、单条约1分钟的实际运行时长，预留20%左右的环境波动冗余设置超时值，比如设为150分钟
  timeoutInMinutes: 150
  steps:
  # 原有测试任务的配置全部保留即可，不需要额外调整参数
  - task: VSTest@2
    inputs:
      testAssemblyVer2: '**/*Tests.dll'

可选优化方向 #

如果不想调高单作业的超时阈值，也可以将绑定DynamicData生成的100余条用例按测试数据维度拆分为多个并行执行的独立作业，每个作业仅承载20-30条用例，把单作业运行时长控制在30分钟以内。这种方式既不会触发默认60分钟的超时限制，还能通过并行执行缩短整个测试流程的总耗时。

内容的提问来源于stack exchange，提问作者loganwol