3. 自动化测试平台需求分析与架构设计
量子系统自动化测试平台的建设，第一步不是写代码，而是把“测试任务”翻译成“平台需求”。量子实验的测试任务通常围绕比特标定、门保真度评估、读出校正、退相干时间测量、串扰扫描等展开，每个任务都包含仪器控制、脉冲序列下发、数据采集、结果拟合与判定几个环节。如果直接把这些环节硬编码成脚本，平台很快会退化成“一堆互不兼容的脚本集合”。因此，本节从测试任务出发，先提炼功能需求与非功能需求，再据此设计分层、可扩展的平台架构。
一、从测试任务到功能需求
以“单比特随机基准测试（1Q RB）”为例，一个完整的测试任务需要：选择目标比特、生成随机 Clifford 序列、编译为波形并下发到任意波形发生器（AWG）、触发采集卡读取 IQ 数据、对数据进行拟合得到每 Clifford 平均误差、与阈值比较后判定通过或失败。把这类任务抽象后，可以得到平台必须具备的功能需求：
- 任务编排：支持将“序列生成—编译—下发—采集—分析—判定”组织为可复用、可参数化的测试流程。
- 设备抽象：统一 AWG、采集卡、微波源、直流源等仪器的控制接口，屏蔽厂商差异。
- 参数管理：集中管理比特频率、脉冲幅度、采样率、触发延迟等参数，并支持版本化。
- 数据采集与存储：原始 IQ 数据、中间结果、最终指标需可追溯，支持按任务、比特、时间检索。
- 分析与判定：内置拟合、误差计算、阈值判定，并输出结构化结果。
- 调度与并发：多比特、多任务可排队执行，避免仪器资源冲突。
这些功能需求不是凭空罗列，而是从真实测试任务的执行链中逐项反推出来的。例如“设备抽象”之所以必要，是因为同一实验室内可能同时存在不同型号的 AWG，若每个任务都直接调用厂商 SDK，任务就无法跨设备复用。
二、非功能需求的提炼
量子测试对平台的非功能需求往往比功能需求更苛刻。首先是时序确定性：脉冲序列的触发抖动若超过纳秒级，会直接影响门保真度评估结果，因此平台必须保证从任务下发到硬件触发的延迟可控且可测量。其次是可扩展性：量子处理器从 5 比特扩展到 50 比特时，测试任务数量、数据量和仪器通道数都会成倍增长，平台架构必须支持横向扩展。第三是可复现性：同一测试任务在不同时间执行，应能通过参数快照和随机种子复现结果。第四是容错性：仪器偶发超时、数据丢包时，平台应能重试或标记异常，而不是让整个测试批次崩溃。最后是可观测性：任务执行状态、仪器健康度、数据质量指标应实时可见。
三、分层架构设计
综合上述需求，平台适合采用五层架构：任务层、编排层、设备抽象层、驱动层、硬件层。任务层面向实验人员，提供 RB、T1、T2、读出校正等测试任务模板；编排层负责任务解析、参数注入、调度与状态机管理；设备抽象层定义统一的仪器接口（如 set_waveform()、acquire()、trigger()），并管理资源锁；驱动层对接具体厂商 SDK；硬件层即实际仪器与量子芯片。分层的关键价值在于：新增一台仪器只需在驱动层实现接口，新增一个测试任务只需在任务层组合已有能力，二者互不干扰。
图中箭头方向表示“请求向下、数据向上”：任务层发起测试请求，逐层向下翻译为硬件动作；采集到的 IQ 数据则沿相反方向逐层上传，最终在任务层形成判定结果。这种双向流是分层架构的核心特征，也是后续实现任务编排与数据追溯的基础。
四、可扩展性的落地要点
架构分层只是起点，真正决定平台能否扩展的是接口契约与资源管理。建议在设备抽象层定义最小接口集，例如：
class Instrument:
def connect(self, address: str) -> None: ...
def set_waveform(self, channel: int, samples: list) -> None: ...
def trigger(self, channel: int) -> None: ...
def acquire(self, channel: int, n_samples: int) -> list: ...
def disconnect(self) -> None: ...
任何新仪器只要实现这五个方法，就能被编排层调度。资源锁则保证同一 AWG 通道不会被两个任务同时占用。参数快照在任务启动时自动保存，包含比特频率、脉冲幅度、采样率、随机种子等字段，使结果可复现。对于多比特扩展，编排层可按比特分组并行调度，但同一仪器通道上的任务必须串行，这一约束应在资源锁中显式表达。