3. 测试任务建模
并行测试任务调度的第一步不是“排顺序”，而是把测试任务描述成调度器能够理解、比较和计算的对象。测试任务建模就是完成这一转换：把测试需求、测试流程、仪器资源、人员约束和交付节点，抽象为具有属性、依赖和约束的任务集合，并用任务图表达它们之间的关系。模型建得是否准确，直接决定后续调度结果是否可执行、是否高效。
一、任务定义：从测试活动到可调度单元
一个测试任务通常对应一个可独立启动、可观测完成状态的测试活动。它既不能切得太粗，否则并行度不足；也不能切得太细，否则调度开销和资源切换成本会吞掉收益。工程上常用“一个测试用例集 + 一组被测对象 + 一次资源占用周期”作为任务边界。
任务定义至少应包含以下字段：
- 任务标识：唯一 ID，如
T_CPU_001，用于依赖引用和日志追踪。 - 任务名称与类型：如功能测试、性能测试、环境试验、老化测试。
- 执行时间：预计时长或历史统计时长，是调度估算的基础。
- 资源需求：所需仪器、工装、被测件、软件许可证、人员技能。
- 优先级：反映交付紧迫度或关键路径权重。
- 约束条件：时间窗、互斥、顺序、资源容量等。
例如，一个典型的任务定义可以写成如下结构化形式：
task_id: T_RF_002
name: 射频发射功率测试
duration: 45 min
resources:
- instrument: 频谱仪-01
- fixture: RF夹具-A
- operator: 射频测试员
priority: 8
constraints:
- after: T_RF_001
- time_window: 08:00-18:00
- exclusive: 暗室-01
这种定义方式既便于人工评审，也便于程序解析。关键点是：所有会影响调度决策的信息都必须显式建模，不能藏在测试人员的经验里。
二、依赖关系：任务之间的先后与数据耦合
依赖关系描述“谁必须在谁之前完成”。常见类型包括：
- 完成-开始（FS）：前置任务完成后，后置任务才能开始，最常见。
- 开始-开始（SS）：两个任务需同时启动，如多通道同步采集。
- 完成-完成（FF）：两个任务需同时结束，如配对测试。
- 数据依赖：后置任务需要前置任务输出的测试数据或标定结果。
- 资源依赖：并非逻辑顺序，而是同一资源被占用导致的隐式串行。
依赖关系必须区分“硬依赖”和“软依赖”。硬依赖不可违反，否则测试无效；软依赖可以权衡，例如“建议先做高温再做低温”以提高效率，但并非强制。调度器应优先满足硬依赖，再优化软依赖。
常见误区：把资源冲突误写成逻辑依赖。例如“频谱仪只有一台，所以 A 和 B 必须串行”，这是资源约束，不是任务逻辑依赖。若后续增加第二台频谱仪，该依赖应自动消失。建模时混淆二者，会导致调度空间被错误压缩。
三、资源需求、优先级与约束条件
资源需求可分为四类：仪器设备、工装夹具、被测件、人员与软件许可。每类资源都有容量属性，例如频谱仪数量为 2，暗室数量为 1，射频测试员数量为 3。任务对资源的需求可以是“独占”或“共享”，也可以是“指定实例”或“任意可用实例”。
优先级用于在资源竞争时决定谁先获得资源。常见做法是综合交付节点、关键路径长度、任务等级和等待时间计算优先级。简单场景可用 1～10 的整数，复杂场景可用加权函数：
priority = w1 * 交付紧迫度
+ w2 * 关键路径权重
+ w3 * 任务等级
+ w4 * 已等待时间
约束条件则包括时间窗、互斥、容量、技能匹配和顺序约束。下表给出建模要素与调度影响的对应关系：
| 建模要素 | 典型表达 | 对调度的影响 |
|---|---|---|
| 执行时间 | duration = 45 min | 决定任务占用资源的时间长度 |
| 资源需求 | 频谱仪-01、RF夹具-A | 决定任务能否启动及并行上限 |
| 优先级 | priority = 8 | 决定资源竞争时的排序 |
| 时间窗 | 08:00-18:00 | 限制任务可执行区间 |
| 互斥约束 | 暗室-01 独占 | 禁止任务重叠执行 |
| 依赖关系 | after: T_RF_001 | 决定任务最早开始时间 |
四、任务图表示方法：从列表到有向图
任务图是任务建模的核心表达形式。常用方法包括有向无环图（DAG）、甘特图、资源-任务矩阵和网络图。其中 DAG 最适合表达依赖关系：节点表示任务，有向边表示依赖方向，边权可表示数据量或传输时间，节点权表示执行时间。
下图展示了一个射频测试场景的任务图：任务 T1 完成标定后，T2 和 T3 可并行执行；T2 与 T3 都完成后，T4 才能进行整机性能测试；T4 完成后，T5 输出测试报告。图中同时标注了资源占用和优先级，便于调度器直接读取。
从图中可以看出，T2 和 T3 是并行分支，但二者都依赖 T1；T4 是汇合节点，必须等待 T2 和 T3 都完成。若 T2 和 T3 同时竞争暗室-01，则资源约束会迫使其中一个等待。调度器读取该图后，可计算最早开始时间、最晚开始时间和关键路径，从而判断哪些任务有浮动时间、哪些任务必须优先保障。
五、案例复盘：建模错误如何导致调度失败
某实验室曾将“高温老化”和“低温老化”建模为无依赖任务，但二者共用同一台温箱。调度器安排它们同时启动，实际执行时因温箱冲突被迫中断，导致测试数据无效。复盘发现两个问题：第一，资源需求只写了“温箱”，未指定实例和容量；第二，把资源冲突误判为可并行。修正后，任务图中增加资源节点或资源约束边，调度器即可自动串行化。
建模检查清单：任务边界是否可独立执行；执行时间是否有依据；资源是否指定到实例；依赖是硬依赖还是软依赖；优先级是否可比较；时间窗和互斥是否完整；任务图是否存在环；汇合节点是否明确。逐项确认后，再进入调度算法阶段。
总之，测试任务建模是把测试现场转化为调度问题的桥梁。任务定义提供可计算单元，依赖关系提供顺序骨架，资源需求提供容量边界，优先级提供竞争规则，约束条件提供可行性边界，任务图则把这些信息组织成一张可分析、可优化、可验证的网络。只有模型准确，后续的并行调度才有意义。