为何增加Worker数量后测试性能反而下降？

结合你描述的场景（10核CPU、单Worker性能优于多Worker），以下是几个核心原因：

• 共享资源竞争：如果测试用例依赖数据库、文件系统、被测服务接口等共享资源，多Worker并行访问时会触发锁等待（比如数据库行锁、接口限流排队）。单Worker串行执行时无需等待，而多Worker会因资源争抢产生大量阻塞时间，导致总耗时上升。
• 被测系统并发瓶颈：即使本地CPU充足，被测系统本身可能不支持高并发处理（比如接口是单线程实现、数据库连接池上限过低）。多Worker发起的请求会在服务端排队，每个用例的响应时间被大幅拉长，最终整体性能下降。
• Worker初始化与上下文切换开销：每个Worker若需要重复初始化测试环境（如创建客户端实例、建立连接），Worker数量越多，初始化的总开销越大。同时，CPU在多个Worker线程间频繁上下文切换，会消耗额外资源，抵消并行带来的效率提升。
• 隐性依赖导致的冲突：即使单类用例步骤一致，不同Worker的用例可能存在隐性的全局依赖（比如测试数据需唯一、用例执行依赖前序用例的环境状态）。并行执行时会出现数据冲突或环境污染，导致用例重试、等待资源释放，进而增加耗时。
• Windows线程调度特性：Windows的线程调度在高并发线程场景下，当线程数量超过合理阈值后，调度延迟会显著增加。即使有10核CPU，过多的Worker线程也会触发调度开销上升，拖慢整体执行速度。

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