📚 课程目录第4章测试程序开发环境搭建（Python/STIL等）

第四章：测试程序开发环境搭建（Python/STIL等）

好，聊完了测试方案和向量结构，咱们得先把家伙事儿备齐了。环境搭建这事儿，看着基础，但坑是真不少。我见过太多新人，上来就写代码，结果被环境问题折腾一整天，最后发现是Python版本不对。咱们这节课，就把HS400量产测试的开发环境一次讲透。

4.1 整体环境思路：为什么是Python+STIL？

你可能会问，搞个测试程序，直接用厂商的ATE工具不就行了？嗯，理论上可以。但在量产场景下，你面对的是几十万、上百万颗芯片。我需要的是自动化、可复用、可版本控制的脚本体系。说白了，就是让机器替我们干脏活累活。

我个人习惯把环境拆成三层：

核心层：Python 3.8+，负责逻辑控制、数据处理、流程调度。
数据层：STIL文件，负责描述测试向量、时序、波形。它相当于芯片和测试机之间的“通用语言”。
接口层：ATE厂商提供的Python API或者命令行工具。各家叫法不同，但本质都一样——把STIL和Python翻译成测试机能执行的指令。

核心原则：Python控制“做什么”，STIL定义“怎么做”，API负责“去执行”。三者解耦，后期维护成本会低很多。

4.2 Python 环境搭建：基础中的基础

先聊Python。别嫌我啰嗦，版本问题真的会卡死人。我之前有一次就是因为用了3.11的新特性，结果产线工控机上的环境是3.7，直接跑不起来。从那以后，我建议统一使用 Python 3.8，兼容性最好，ATE厂商的SDK基本都支持。

4.2.1 安装与虚拟环境

我个人习惯用 pyenv 管理多版本，但稳妥起见，直接用 Anaconda 或者 Miniconda 也行。核心是要把虚拟环境隔离好。

小技巧：每个项目建一个独立的虚拟环境，避免依赖冲突。我一般用 python -m venv hs400_test_env，干净利落。

创建完环境后，激活它：

# Windows
hs400_test_env\Scripts\activate

# Linux / macOS
source hs400_test_env/bin/activate

4.2.2 核心库安装

安装这些库就够了，别一股脑全装：

numpy：数据处理，尤其做测试向量解析时经常用到。
pyyaml：配置文件解析。我把测试参数都写在YAML里，方便修改。
pandas：日志分析和Bin统计。
ATE厂商SDK：比如 Teradyne 的 igxl 或 Advantest 的 t6700 包。这个得找厂商要。

举个requirements.txt的例子：

numpy==1.23.5
pyyaml==6.0
pandas==1.5.3
# 厂商SDK根据自己的版本写，比如：
# igxl==2023.1.0

然后直接 pip install -r requirements.txt 就完事了。嗯，这步一般不会翻车。

4.3 STIL 环境与工具链

STIL 文件不是拿记事本手写的，那样会崩溃的。我用的是官方标准的语法，搭配一些验证工具，确保生成的向量没有问题。

4.3.1 STIL 文件的结构预览

咱们先看一眼 STIL 长什么样，心里有个底：

STIL 1.0 {
    Header {
        Title "HS400_V1_Pattern";
        Date "2024-05-20";
    }
    Signals {
        CLK In;
        DATA InOut;
        RESET In;
    }
    SignalGroups {
        bus = 'DATA[7:0]';
    }
    Timing {
        WaveformTable wft_main {
            Period '20ns';
            Waveforms {
                CLK { 'P' : '0ns'; '1' : '10ns'; }
                DATA { 'D' : '5ns'; 'Z' : '15ns'; }
            }
        }
    }
    PatternBurst pat_burst_main {
        PatList { pat_func; pat_scan; }
    }
    Pattern pat_func {
        W { wft_main; }
        V { 'P'; '1'; '10'; }  // 时钟、数据、保持时间
    }
}

别被吓到：STIL语法很严格，缩进、分号都不能错。我建议用专门的编辑器，比如 VS Code 装个 STIL 语法高亮插件，事半功倍。

4.3.2 工具链推荐

我这里列几个实际用下来比较顺手的：

工具/库	用途	备注
VS Code	代码编辑器	装 STIL 扩展，支持语法高亮和基础校验
stil_validator (自制)	STIL 语法检查	简单正则写一个，或者用开源库
Python pySTIL (封装)	解析/生成 STIL	我习惯自己封装一套解析类，方便转成字典
ATE 离线编译器	STIL → 机台格式	厂商都会提供，离线跑一次能筛出一堆问题

注意避坑：STIL文件的编码格式。我曾经遇到过用UTF-8但带BOM的情况，直接导致所有Pattern加载失败，排查了俩小时。现在一律用 UTF-8 without BOM。

4.4 验证环境：跑通第一个“Hello World”

环境搭完，怎么知道好不好使？跑个最简单的测试。我个人习惯先不接硬件，用ATE模拟器或者离线模式跑一下。

4.4.1 Python 侧验证

import sys
import numpy as np

# 试试能不能导入咱的核心库
try:
    import yaml
    print("[OK] pyyaml 导入成功")
except ImportError:
    print("[FAIL] 请安装 pyyaml")

# 试试调用厂商API（示例用假接口）
try:
    # from ate_sdk import tester  # 假API，实际替换
    print("[OK] ATE SDK 加载正常（模拟）")
except:
    print("[FAIL] SDK 加载失败，检查环境变量")

# 写个简单配置测试
config_data = {
    'test_mode': 'functional',
    'voltage': 1.8,
    'pattern_file': 'hs400_func.stil'
}
with open('test_config.yaml', 'w') as f:
    yaml.dump(config_data, f)
print("[OK] 配置文件写入正常")

这段脚本跑通了，就说明Python环境和基本的库没问题了。

4.4.2 STIL 侧验证

对于STIL，我会用厂家提供的离线编译器跑一下：

# 假设厂商提供 stil_compiler 命令
stil_compiler --input hs400_func.stil --output /dev/null --check-only

如果编译器没报错，那STIL语法就是干净的。你也需要注意，有些编译器对 MacroDefs 的处理不一样，我遇到过一次，编译通过但实际加载报错，原因是宏定义里有个换行符不兼容。所以，离线编译完，最好再在真实的测试机环境里跑一次空运行。

我常用的捷径：写一个 makefile 或者 shell script，把环境检查、STIL编译、向量加载、甚至头文件依赖检查都串起来。一键执行，省心省力。

4.5 关于依赖管理的个人建议

量产环境里，最怕的就是这个版本不兼容，那个库被更新。我建议你做到：

锁定版本：用 pip freeze > requirements_lock.txt 把精确版本锁住。别用 >=，直接用 ==。
容器化部署：如果产线允许，直接打包成 Docker 镜像。环境固定，再也不怕IT升级系统了。
备一份离线包：产线有时没外网。把 wheel 文件都下载到本地，建个本地源。我在N+1项目上就是这么干的，稳得很。

好啦，环境这关咱们算是过了。有了趁手的工具，接下来写程序心里才有底。