2. 并行测试架构选型

在 TestStand 中做并行化，第一步不是写 Sequence，而是选架构。架构选错，后面无论怎么调优都很难把节拍压下来。TestStand 本身提供了多种并行执行模型，它们并不是互相替代的关系，而是分别解决不同层面的并发问题。理解它们的边界，才能根据 UUT 数量、仪器资源和测试项独立性做出正确选择。

四种并行模型的本质区别

多线程（Thread）是 TestStand 中最轻量的并发单位。一个线程对应一个独立的执行上下文，拥有自己的调用栈、变量空间和 Sequence 执行流。线程之间共享同一进程的内存空间，因此可以通过 TestStand 的共享变量、FileGlobal 或队列快速交换数据。线程的创建和销毁开销小，适合测试项之间需要频繁通信、共享仪器句柄的场景。但线程共享进程资源，一旦某个线程调用非线程安全的 DLL 或仪器驱动，就可能出现资源竞争甚至崩溃。

多进程（Process）则是把并发提升到操作系统层面。每个进程有独立的地址空间，互不干扰。TestStand 可以通过 Process Model 启动多个测试进程，或者用 TestStand API 的 Engine.NewExecution 在不同进程中执行 Sequence。多进程的最大优势是隔离性：一个进程崩溃不会拖垮其他进程，适合测试项之间完全独立、且对稳定性要求极高的产线。代价是进程间通信只能通过文件、命名管道或 TCP 等机制，数据交换比线程慢一个数量级，启动开销也更大。

多站点（Multi-Site）是 TestStand 针对“同一测试程序同时测多个 UUT”这一场景提供的原生模型。它本质上是在一个执行体内，用站点数组（Site）来区分不同 UUT 的数据和流程。多站点模型下，所有站点共享同一套 Sequence 逻辑，但每个站点有独立的测试数据和结果记录。它适合 UUT 型号相同、测试项完全一致、只是需要同时测多台的场景。多站点的优势是资源利用率高、代码复用度好，缺点是站点之间如果存在仪器共享，仍然需要做资源仲裁。

并行测试模型（Parallel Model）是 TestStand 内置的一种 Process Model 变体，它把“测试执行”和“UUT 上下料”解耦。在并行模型下，测试线程和操作员交互线程同时运行：操作员在装夹下一台 UUT 时，测试线程正在测上一台。这种模型特别适合手动或半自动工位，能把上下料时间从节拍中“藏”起来。并行模型通常与多站点结合使用，形成“多站点并行测试”的复合架构。

按 UUT 数量与仪器资源做选择

UUT 数量决定了并行的“宽度”。如果一次只测一台，多线程和多进程的意义主要在于把测试项拆开并行执行，比如电源测试和通信测试同时跑。如果一次要测多台同型号 UUT，多站点是更自然的选择，因为 TestStand 已经帮你处理了站点索引、数据记录和报告合并。如果 UUT 型号不同、测试流程差异大，则更适合用多进程，每个进程跑各自的 Sequence，互不干扰。

仪器资源是选型的硬约束。示波器、频谱仪、电源这类仪器通常不支持多线程同时访问同一句柄。如果多个测试项要共用一台仪器，就必须做资源仲裁。TestStand 提供了 Lock 和 Unlock 步骤，也可以使用仪器驱动自带的互斥机制。在多站点模型下，如果每个站点都需要同一台仪器，通常的做法是：要么给每个站点配独立仪器，要么用队列把仪器访问串行化。前者成本高但节拍快，后者成本低但会引入等待时间。实际选型时，先列出仪器清单和每个测试项需要的仪器，再判断哪些仪器是瓶颈资源。

测试项独立性是架构分界线

测试项之间是否独立，决定了并行的粒度。完全独立的测试项，比如“电压测量”和“温度采集”，可以放在不同线程甚至不同进程中并行执行，互不等待。存在依赖关系的测试项，比如“先上电再测电流”，则必须串行，或者用同步机制保证顺序。TestStand 的 Wait 步骤、Notification 和队列可以处理这类同步。

一个实用的判断方法是画依赖图：把每个测试项作为节点，如果 A 必须在 B 之前完成，就从 A 画一条箭头到 B。没有箭头相连的节点就可以并行。依赖图越稀疏，并行的空间越大。如果依赖图几乎是一条链，那么无论选哪种架构，节拍都受限于最长的串行路径，此时应该先优化测试项本身，而不是强行并行。

一个选型示例

假设某产线需要同时测试 4 台同型号电源板，测试项包括：上电时序、输出电压、纹波、通信握手、老化前预热。仪器资源为：1 台可编程电源、1 台示波器、1 台电子负载、1 台通信测试仪。其中电源和电子负载是瓶颈资源，示波器和通信测试仪可以分时复用。

分析：4 台 UUT 型号相同、测试项一致，适合多站点。但电源只有 1 台，如果 4 个站点同时上电，电源无法同时输出 4 路独立电压。因此需要把“上电时序”和“输出电压”这两个依赖电源的测试项做资源仲裁，用队列让 4 个站点轮流使用电源。示波器测纹波可以并行，通信握手也可以并行。最终架构选择：多站点（4 站点）+ 线程级资源仲裁（电源和电子负载用 Lock 保护）+ 并行模型（操作员上下料与测试重叠）。

这个例子说明，架构选型不是单选，而是组合。先确定隔离层级（进程还是线程），再确定并行宽度（站点数），最后确定是否需要并行模型来隐藏上下料时间。

选型检查清单

总结来说，多线程适合共享内存和频繁通信的场景，多进程适合需要强隔离的场景，多站点适合同型号多台并行测试，并行模型适合隐藏上下料时间。实际产线中，这四种模型经常组合使用。选型的核心依据是：UUT 数量决定并行宽度，仪器资源决定仲裁策略，测试项独立性决定并行粒度。把这三者理清楚，架构自然就清晰了。