1. Process Model核心概念与定制价值

在TestStand中，Process Model（过程模型）不是一个可选的“插件”，而是决定测试执行顺序、数据传递方式、报表生成时机以及异常处理策略的执行骨架。理解它的本质，是后续所有定制工作的起点。

一、Process Model到底是什么

TestStand的测试执行并非由单个Sequence文件独立完成，而是由Process Model在更高层级上驱动。一个测试站启动后，TestStand会加载指定的Process Model，由它依次调用入口点（Entry Point）序列，再在这些入口点中回调用户编写的测试序列。换句话说，Process Model是“调用者”，测试序列是“被调用者”。

Process Model由若干入口点构成，常见入口点包括：Test UUTs（测试被测单元）、Single Pass（单次执行）、Run MainSequence（仅运行主序列）等。每个入口点内部又由多个回调序列组成，例如PreUUT、PreUUTLoop、PostUUT、ProcessSetup、ProcessCleanup。这些回调构成了测试流程的“可插入点”，也是定制工程真正动手的地方。

需要特别区分两个概念：Process Model文件（.seq，定义流程骨架）与Model Plugin（模型插件，用于在不修改原模型的前提下扩展行为）。前者是主体，后者是扩展机制。工程实践中，优先使用Model Plugin，只有在流程结构本身需要改变时才直接修改Process Model。

二、内置模型类型与适用场景

TestStand安装后自带多个Process Model，选择哪一个取决于测试站的并行需求和被测对象数量。

选择模型时，核心判断依据是：测试资源是否可共享、UUT之间是否需要隔离、报表是按单个还是按批次输出。例如，若多个工位共用同一台电源且无法分时复用，就不适合直接使用Parallel模型，而应改用Sequential或增加资源互斥逻辑。

三、定制工程的实际应用场景与收益

标准模型能覆盖大部分通用流程，但真实产线往往有特殊要求。以下是几类高频定制场景：

• 自定义报表格式：产线MES要求特定字段和文件命名规则，需在PostUUT回调中改写报表生成逻辑。
• 增加测试前确认：在PreUUT中插入扫码校验、工装到位检测、操作员权限验证。
• 异常重测策略：在PostUUT中根据失败项决定是否自动重测、重测次数上限、重测后是否放行。
• 数据上传与追溯：测试完成后将结果写入数据库或上传MES，需在流程末尾增加数据提交节点。
• 多工位资源调度：并行测试时对仪器、夹具、操作员进行互斥或排队管理。

定制的收益体现在三个层面：流程可控（异常有明确处理路径）、数据可追溯（每个UUT的测试上下文完整记录）、维护可扩展（通过Model Plugin隔离定制逻辑，升级TestStand版本时影响面小）。

四、定制前的关键认知

在动手修改之前，必须建立两个认知。第一，Process Model的修改会影响该模型下所有测试序列，因此任何改动都要评估影响范围。第二，回调序列的执行顺序是固定的，不能随意调换，但可以在回调内部增加逻辑分支。下图展示了Sequential模型下一次完整测试的调用链与关键回调位置，帮助建立整体执行视图。

从图中可以看到，PreUUT、PostUUT、ProcessSetup、ProcessCleanup是四个最常用的定制入口。实际工程中，约80%的定制需求都可以通过在这四个回调中增加逻辑来满足，而不需要改动模型的主干结构。