VsTest任务customBatchSizeValue及批量测试并行性技术问询

1. 单批次内的测试是否并行？ #

customBatchSizeValue的作用是把测试集合拆成多个独立的vstest.console.exe运行实例，每个实例处理指定数量的测试（这里是800个），并生成独立的trx文件。但单个批次内部的测试是否并行，完全由你的测试配置（而非batchSize）决定：

• 要是你在UITest.pipeline.runsettings里配置了<MaxCpuCount>（比如设为0或大于1的数值），非UI测试会根据CPU核心数或指定数量并行执行；
• 没配置MaxCpuCount，或者测试框架本身不支持并行（比如部分UI测试框架），单批次内的测试就会串行执行。

简单总结：batchSize管的是“拆成多少个独立测试进程”，每个进程内部的并行由runsettings里的并行配置和测试类型决定。

2. UI测试与非UI测试的机制差异 #

非UI测试（如单元测试） #

• 同一批次内：只要测试无状态、不共享资源，通过MaxCpuCount配置就能实现多线程并行，充分利用代理的CPU核心；
• 多批次之间：多个vstest进程可以同时运行（单代理多核场景下），进一步提升整体执行效率；
• 无需额外隔离：runTestsInIsolation设为false也能正常运行，不会有资源冲突问题。

UI测试（如Selenium、Coded UI） #

• 同一批次内：几乎无法并行执行。因为UI测试依赖桌面会话的上下文，多个UI测试并行会出现抢焦点、操作冲突等问题，就算配置了MaxCpuCount，测试框架也会自动串行执行；
• 多批次之间：默认单代理的Windows环境是单桌面会话，多个vstest进程跑UI测试会互相干扰，导致失败。如果要实现多批次并行，需要自托管代理配置多桌面会话（比如用远程桌面隔离），但这种配置复杂度高，不推荐；
• 必须隔离：建议把runTestsInIsolation设为true，避免不同测试进程的UI上下文互相影响，你当前配置的false可能会导致UI测试不稳定。

针对你的配置的建议 #

1. 检查UITest.pipeline.runsettings中的<MaxCpuCount>节点：如果是UI测试，建议设为1（强制串行）；如果是非UI测试，可以设为0（自动匹配CPU核心数）；
2. 对于UI测试，customBatchSizeValue不宜设得过大（比如800），因为单批次串行执行时间太长，一旦失败重跑成本高。建议拆分更小的批次，同时考虑开启代理级别的并行（多代理分布式测试）来提升效率；
3. UI测试场景下，将runTestsInIsolation改为true，减少进程间的UI干扰。

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