第二章 测试程序架构：测试程序的基本结构、Main Flow与Test Item、测试程序执行流程
好，咱们直接进入正题。这一章聊的是测试程序的骨架——架构。你想想看，一个测试程序动辄几千行，如果没有清晰的结构，调试起来简直是一场噩梦。我见过不少新人，上来就写流水账式的代码，结果出了问题根本不知道从哪里查起。
说白了，测试程序架构就是一套约定俗成的组织方式。它让代码可读、可维护、可复用。今天我就把我在日月光这些年积累的经验，掰开了揉碎了讲给你听。
2.1 测试程序的基本结构
一个标准的测试程序，通常由三大部分组成：初始化部分、测试流程部分、收尾部分。嗯，这里要注意，这三部分缺一不可。
| 组成部分 | 作用 | 常见内容 |
|---|---|---|
| 初始化部分 | 加载配置、建立通信、设置硬件 | LoadLibrary、OpenSite、SetLevels |
| 测试流程部分 | 执行测试项、判断结果、记录数据 | Main Flow、Test Item、Bin分配 |
| 收尾部分 | 释放资源、生成报告、关闭连接 | CloseSite、UnloadLibrary |
我个人习惯把初始化部分单独拎出来写成一个函数。为什么？因为这样方便复用。比如同一个平台的不同产品，初始化流程可能80%是一样的，你只需要改参数就行。
核心原则：初始化要彻底，收尾要干净。我曾经遇到过一个case，因为收尾部分没关掉电源，导致下一颗芯片上电时直接短路，烧了三个site的板卡。从那以后，我每次写收尾代码都格外小心。
2.2 Main Flow与Test Item
这是测试程序的核心。很多人搞不清楚Main Flow和Test Item的关系，我打个比方你就明白了：
- Main Flow 就像一张流程图，它规定了测试的先后顺序和分支逻辑。
- Test Item 就像流程图里的每一个具体步骤，它负责执行真正的测试动作。
举个例子，一个典型的Main Flow可能是这样的：
Main Flow: PowerUp
-> Test Item: VDD_Check
-> Test Item: IDD_Standby
-> Test Item: Function_Test
-> Test Item: AC_Param
-> Test Item: DC_Param
-> Bin_Assign
你看，Main Flow只关心「先做什么，后做什么」，而每个Test Item才关心「具体怎么做」。
我的小技巧：在写Test Item时，尽量让每个Item只做一件事。比如「测电压」就只测电压，「测电流」就只测电流。别把两个测试混在一个Item里，否则出了问题你都不知道是哪个环节挂了。
2.3 测试程序执行流程
好，现在咱们聊聊程序跑起来之后，到底是怎么一步步执行的。你想想看，一颗芯片从进测试机台到出结果，中间经历了什么？
- 加载程序：测试机台读取编译好的测试程序文件。
- 初始化硬件：设置电压、电流、时序等参数。
- 执行Main Flow：按照流程顺序，逐个调用Test Item。
- 判断结果：每个Test Item执行完后，根据测试值判断Pass/Fail。
- 分配Bin：根据测试结果，给芯片打上Bin1、Bin2、Bin3等标签。
- 记录数据：把测试数据写入日志或数据库。
- 收尾：释放资源，准备测试下一颗芯片。
这里有个关键点：执行流程是串行的。也就是说，一个Test Item没跑完，下一个不会开始。所以如果你某个Item写得特别慢，整个测试时间就会被拖长。
避坑指南：我曾经遇到过一个项目，测试时间总是超预算。查了半天，发现是一个Test Item里写了大量的循环等待。其实那个等待完全可以用硬件中断替代，省掉好几毫秒。所以，写Test Item时一定要考虑执行效率。
2.4 一个完整的例子
光说不练假把式。我写一个简化版的测试程序结构，你感受一下：
// 初始化部分
void Init_TestProgram() {
LoadLibrary("ATE_Library.dll");
OpenSite(1);
SetLevels(VDD=1.8V, VDDQ=1.2V);
SetTiming(Period=10ns);
}
// 测试流程部分
void Main_Flow() {
// 第一步：检查电源
if (Test_VDD_Check() == FAIL) {
AssignBin(BIN_FAIL);
return;
}
// 第二步：功能测试
if (Test_Function() == FAIL) {
AssignBin(BIN_FUNC_FAIL);
return;
}
// 第三步：参数测试
Test_AC_Param();
Test_DC_Param();
// 全部通过
AssignBin(BIN_PASS);
}
// 收尾部分
void Close_TestProgram() {
CloseSite();
UnloadLibrary();
}
你看，结构是不是很清晰？每个部分各司其职，出了问题一眼就能定位到。
2.5 我的一些经验总结
- 命名规范很重要：Main Flow用动词开头，Test Item用名词+动词。比如「PowerUp_Flow」、「VDD_Check_Item」。
- 注释要写到位：别偷懒。我见过最离谱的注释是「// 这里测电压」，结果下面代码是测电流的。这种注释还不如不写。
- 预留调试接口：在Main Flow里加一个「Debug Mode」开关。开启后可以跳过某些Item，只跑你关心的那一个。这能省下大量调试时间。
- 版本控制：每次修改程序，记得在文件头加版本号和修改日期。别问我为什么强调这个——有一次我改完程序忘了备份，结果新版本有bug，旧版本又找不回来，那叫一个惨。
好了，这一章就讲到这里。测试程序架构这东西，说白了就是「先搭骨架，再填血肉」。骨架搭好了，后面写代码就顺风顺水。下一章咱们聊聊具体的测试项怎么写，到时候我会拿几个实际案例出来，保证干货满满。