 测试程序是一串测试项按顺序执行的结果。但这个顺序不是随便排的。有些测试项必须在前，有些必须在后。开短路没过，后面的功能测试测了也没意义。电源没上电，寄存器读写必然失败。高温测试之前没做常温基线，数据没法比。 这些先后关系，就是测试项之间的依赖关系。 如果忽略了这些依赖，轻则测试结果无效，重则损坏硬件。  一、依赖关系从哪来 测试项之间的依赖关系，主要来自三个方面： 1.硬件层面：某些测试项会改变芯片的物理状态。 电源上电后才能测开短路；开短路通过后才能进行功能测试；功能测试过程中可能配置了寄存器，影响后续测试项的条件。 2.数据层面：某些测试项的结果是后续测试项的输入。 常温下的漏电流测量值是高温漏电流的参考基线；某个引脚的输出电压正常，才能继续测该引脚的时序参数。 3.安全层面：某些测试项如果失败，继续测试可能造成损害。 开短路测试如果发现电源引脚对地短路，继续施加电压可能烧坏测试座或Loadboard。 二、四种常见的依赖类型 1.前置条件依赖：B必须在A通过之后才能执行。 开短路测试是所有其他测试的前置条件，开短路不过说明连接不可靠，后续测量结果都不可信。 这种依赖的处理方式很简单——A失败则B跳过，标记为“因前置条件失败而跳过”。 2.配置状态依赖：B依赖芯片处于某种特定配置状态，而这个状态由之前的测试项设置。 功能测试之前需要先通过寄存器配置芯片工作模式，不同频率下的时序测试需要不同PLL设置。 处理方式是按顺序执行配置操作，或在每个测试项开头检查当前状态。 3.数据依赖：B需要使用A的测量结果作为参考或判断依据。 高温漏电流的Pass/Fail判断需要参考常温漏电流值；某些芯片的校准流程需要先测基准电压再算修正系数。 处理方式是把A的测量值存入变量，B执行时读取。 4.安全依赖：A失败时B不应执行，否则可能损坏硬件。 电源电流测试发现过流，应立即断电，不再执行后续任何测试项。 这种依赖的处理方式是A失败时触发紧急停止，跳过所有后续测试项。 三、依赖关系的三种管理方式 1.线性顺序：测试项按依赖关系排成一条线，前一项Pass才执行下一项。优点是逻辑清晰，缺点是任何一项失败都会中断整个测试。 2.条件分支：根据测试项结果决定后续执行哪些测试项。开短路Pass则继续执行全部后续测试项，Fail则只执行不依赖开短路的测试项（如有）。优点是灵活，缺点是依赖关系需要显式定义，代码复杂度增加。 3.依赖图：把每个测试项定义为一个节点，依赖关系定义为有向边，程序执行前解析依赖图确定执行顺序。优点是依赖关系清晰，缺点是实现成本高，适用于大型测试程序。 从小项目入手，线性顺序够用；规模大了再考虑引入条件分支或依赖图，不必一开始就追求最复杂的方案。 四、依赖关系设计中的四个常见错误 1.隐式依赖未识别：有些依赖关系没有写在代码里，但实际存在。功能测试之前需要先配置寄存器，如果寄存器配置测试项被跳过，后续功能测试就会失败，但失败原因不明确。解决办法是显式声明所有依赖，被跳过的测试项所依赖的后续测试项也应跳过，并在日志中记录原因。 2.依赖链过长：A依赖B，B依赖C，C依赖D……任何一个环节失败都会导致大量测试项被跳过。解决办法是尽量减少依赖链长度，能不依赖就不依赖，能用并行就不用串行。 3.循环依赖：A依赖B，B依赖A，程序无法确定先执行谁。解决办法是在设计阶段检查依赖图，确保没有环路。出现循环依赖说明设计有问题，需要重新拆分测试项。 4.依赖关系写在注释里：注释对程序没有约束力，换一个人维护就可能出错。解决办法是用代码显式声明依赖，让程序自动处理，不要依赖人工记忆。 五、实际项目中的三条建议 1、把依赖关系集中管理：不要在每个测试项里单独写依赖判断逻辑。用一个配置文件或数据结构集中定义所有依赖关系，程序统一解析执行。这样修改依赖关系时不用改代码，只需改配置。 2、测试项失败时的处理策略要明确：致命失败（如开短路Fail、电源短路）立即停止所有测试；非致命失败（如某个参数超限）记录失败，继续执行不依赖该测试项的其他项目；条件失败（如某个配置无法完成）跳过依赖该配置的所有测试项。 3、日志中记录跳过的原因：如果一个测试项因为依赖失败而被跳过，日志里要写明“因测试项XXX失败而跳过”，而不是简单地不执行。否则后续分析时不知道是没测还是被跳过了。 测试序列不是测试项的简单堆叠。排错了顺序、忽略了依赖，测出来的数据可能从头到尾都是错的。 设计测试序列时，先理清楚谁依赖谁，再排顺序。不用等到出了问题再去翻日志。 我们设计了一套芯片测试工程师培训课程。 内容包含半导体测试基础、ATE 机台操作、晶圆测试流程、测试向量优化、失效分析等，适合零基础入门和岗位能力提升。 如果你想系统学习芯片测试技术，可以联系我们。 刘老师｜13166339996（微信同号）  |
