NUnit高并发测试下 .Net运行并行Selenium用例是否存在数量限制

不存在通用的固定数值上限，你观测到30个并行worker执行速度优于100个的现象是典型的资源过饱和表现，该结果受.NET运行时、NUnit机制、浏览器资源占用、SUT承载能力、网络等多维度因素共同影响，核心原因和调优建议如下：

• .NET 4.7.1 运行时层面限制
  .NET Framework 4.7.1 的默认线程池配置与主机CPU逻辑核心数强绑定，默认最小工作线程数等于CPU逻辑核心数，虽可通过配置修改最大线程数，但并行数超过合理阈值后，线程上下文切换的开销会指数级上升，直接抵消并行带来的效率收益。Selenium测试属于IO密集型任务，多数时间在等待浏览器、网络、SUT响应，理论上并行数可以高于CPU核心数，但超过2~10倍核心数区间后，调度开销的增长会非常明显。
• NUnit 与 Selenium 资源开销限制
  NUnit的每个并行worker对应独立的测试执行上下文，而每个Selenium用例通常需要启动独立的浏览器进程（Chrome、Firefox等），单浏览器进程空载就会占用数百MB内存和10%左右的浮动CPU占用，100个并行worker对应100个浏览器进程时，主机的内存、CPU资源大概率已经被占满，所有进程进入资源抢占状态，执行速度自然大幅下降。如果使用Selenium Grid分布式执行，该上限还受Grid节点的总资源承载能力限制。
• SUT与网络层面限制
  被测系统本身存在并发承载上限，100个并行测试产生的请求流量远高于30个的场景，一旦触发SUT的限流、排队、超时逻辑，单条测试用例的执行时长会被拉长，也会直接导致整体执行速度变慢。如果测试请求需要跨公网传输，带宽占满后的网络排队延迟也会进一步放大该效应。

合理的并行数需要结合你的实际运行环境实测得到，推荐的调优方式为：从CPU逻辑核心数的2倍开始逐步上调并行worker数，每调整一次执行全量测试统计总耗时，找到总耗时最低的拐点值，即为当前环境下的最优并行上限，你当前实测得到的30就是适配你现有环境的合理上限。

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