📚 课程目录第4章测试数据录制原理

测试数据录制原理：三种核心纬度

说实话，刚开始做Replay回放的时候，我第一个遇到的问题就是：数据到底怎么录进去的？你想想看，如果在产线上连数据都录不对，那后面的回放全是白做。这一章，咱们就掰开揉碎聊聊测试数据录制的原理。

我个人习惯把录制原理拆成三个维度来理解：录制模式怎么选、数据捕获机制怎么工作、文件格式怎么存。这三块缺一不可。

核心观点：录制不是简单“录屏”，而是对被测设备与测试设备之间的所有交互信号、状态、时序进行精确捕获与保存。

4.1 录制模式：手动 vs 自动

先说说录制模式。我刚开始做的时候也纠结过，到底用手动还是全自动？后来踩了坑才明白，这两种模式各有各的用武之地。

手动录制模式

手动模式说白了就是由测试工程师在交互界面上一步步操作，系统跟着记录每一步。优点是灵活，适合调试阶段。缺点是依赖人的操作一致性。

触发方式：按一次记录一次，比如点击“开始录制”按钮
适用场景：单板调试、故障复现、边界条件验证
个人经验：我习惯在手动模式下加一个“数据有效性校验”步骤。录制前先检查一次信号完整性，避免录进去一堆垃圾数据

小技巧：手动录制时，建议先用一个“预录”模式跑一遍，确认捕获范围正确再正式录制。我在一个项目中就因为没预录，录了三个小时的无效数据，那叫一个心疼。

自动录制模式

自动模式是量产场景下的主力。它由测试脚本或自动化框架驱动，按预定流程自动启停。核心要素是触发条件和录制时长。

触发条件：可以是测试项开始、某个信号跳变、或者时间触发
录制时长：往往设定为固定窗口（比如10ms）或事件窗口（比如从触发起直到信号稳定）
数据裁剪：自动录制通常会在后端做一个后处理裁剪，扔掉前后无效片段

我曾经在一条产线上遇到过一个问题：自动录制的数据量太大，导致存储爆了。后来加了个“动态采样率调整”：信号变化快的时候高采样率，变化慢的时候自动降采样。效果立竿见影。

避坑指南：自动模式不要直接套用手动模式的触发逻辑。手动可以靠工程师盯着屏幕判断“该开始了”，自动模式必须用明确的信号或时间条件定义触发点。我曾经有一个项目就是因为触发条件定义模糊，导致50%的录制文件空白。血的教训。

4.2 数据捕获机制：你抓的是什么东西？

这个维度我觉得是录制原理最核心的部分。数据捕获机制决定了你会录到什么、录得多准。按捕获层级，我把它分为三类：

捕获层级	捕获对象	实时性	资源占用	典型应用
软捕获	应用层/驱动层寄存器	中（受OS调度影响）	低	ATE测试站的测试向量、仪器控制指令
硬捕获	物理信号/总线时序	高（纳秒级精度）	中	高速ADC/DAC信号、SPI/I2C总线
混合捕获	软件状态 + 硬件信号	高	高	系统级测试、SiP封装测试

为什么要分这么细？因为不同的捕获机制对回放的影响巨大。软捕获适合录“行为”，比如指令序列。但它的带外时间戳可能不准。硬捕获适合录“波形”，比如模拟信号。它是完全同步的，但数据量也大得多。

嗯，这里要注意。我个人建议在量产环境下优先采用混合捕获。为什么呢？因为测试软件的启动、初始化这些软状态往往占用大量时间。而物理层的关键信号又是判断通过率的直接依据。两样都录，回放时才能做到“既知道做了什么，也知道发生了什么”。

4.3 录制文件格式：JSON vs XML vs 二进制

数据录下来了，用什么格式存？这个问题我当初被问到过很多次。每种格式都有对应的使用场景。

JSON 格式

轻量、易读、自描述。适合记录结构化的事件。

{
  "capture_id": "CAP_20241015_001",
  "timestamp_us": 1234567890,
  "test_item": "ADC动态测试",
  "signals": [
    {"name": "DUT_CLK", "value": 1000000, "unit": "Hz"},
    {"name": "DUT_OUT", "value": 2048, "unit": "LSB"}
  ],
  "metadata": {
    "equipment": "ATE_Station_03",
    "room_temp": 25.3
  }
}

优点：人类可读，方便调试解析
缺点：冗余字符多，解析效率偏低，不适合高频数据流
适用：轻量级的测试状态记录、配置交换、日志归档

XML 格式

XML 比 JSON 更严格，支持命名空间和 Schema 校验。我记得在半导体行业的 STDF 标准里，很多衍生格式都基于 XML。

<?xml version="1.0" encoding="UTF-8"?>
<CaptureData>
  <CaptureID>CAP_20241015_002</CaptureID>
  <Timestamp>1234567895</Timestamp>
  <TestItem name="功耗测试">
    <Signal name="VBAT" value="3.3" unit="V"/>
    <Signal name="IBAT" value="0.12" unit="A"/>
  </TestItem>
</CaptureData>

优点：强校验、扩展性好、适合企业级系统交互
缺点：冗余多、解析慢、文件大
适用：需要多方校验的格式（比如测试审批、跨部门数据交换）

二进制格式

这才是量产场景下的主力选手。二进制格式没有多余字符，直接按字节或位对齐存储。

// 简化的二进制头 + 数据体结构
// Header: 4字节 CaptureID, 8字节 Timestamp, 2字节 NumSignals
// Data:  连续排列的 signal records（每个record: 2字节信号类型 + 4字节值 + 4字节单位标识）
// 0001 23456789ABCDEF 0002
// 0001 000003E8 0001   // CLK = 1000 Hz
// 0002 00000800 0002   // OUT = 2048 LSB

优点：体积小、写入/读取速度快、适合硬实时捕获
缺点：人类不可读、解析依赖协议定义、扩展性差
适用：高速信号捕获（如有分选机/探针台的实时响应场景）、大规模产线数据汇聚

建议：量产环境主用二进制格式存储原始信号，同时用一个JSON摘要文件记录测试上下文（设备ID、测试项、时间范围）。这样既保留了回放所需的精确时序，又方便追溯和审计。

4.4 三种捕获机制的关系：一张图说清

说了这么多，我自己觉得最直观的方式依然是画一张关系图。下面这张 SVG 图把三种捕获机制、它们的输入对象和输出方向串了一遍。

你能看到，从捕获对象到回放引擎，中间经过了一系列转化。而且不同的捕获机制对文件格式的偏好也不同。软捕获倾向于 JSON 或 XML（因为内容偏事件化、层级多），硬捕获几乎非二进制不可（时序太密），而混合捕获最常见的方式是分两路存储：一路二进制流保存波形，一路 JSON 摘要保存状态。

个人建议：如果你正在搭建一个新的量产录制系统，不要在一开始就追求“完美格式”。先跑通一套最小的录制链路（比如手动 + 软捕获 + JSON），验证完数据准确性之后，再逐步换成自动 + 混合 + 二进制的方案。这样可以尽早暴露问题，避免后期大规模返工。

4.5 总结几个要点

录制模式：手动适合调试，自动适合量产——触发条件和时长定义是关键
捕获机制：软、硬、混合三种，按实时性和资源权衡选择
文件格式：JSON/XML/Binary，没有银弹。我的经验是：兼顾可读性与性能，用“二进制主体+JSON摘要”双轨制
避坑：录制数据的大小、存储速率、以及链路中的任何截断都是暗坑。我曾在一条产线上发现，因为文件系统缓存写不完，导致连续录制丢帧。后来强行加了 flush 机制才解决

你把这些点搞明白了，接下来的章节处理回放匹配算法时会轻松很多。毕竟，录得不准，回放就无从谈起。