企业官网建设流程全解析

在芯片测试这一行待久了，你会发现一个很微妙的规律：真正拉开测试工程师之间差距的，往往不是谁写的测试项更高深，而是“数据能不能干净地从测试机台上出来”。Data Logging，也就是咱们嘴里的数据记录、日志落盘，在 SmarTest 8 里就是这么个看似不起眼、实际能折腾人一下午的功能。尤其是当你从别的测试平台切到 SmarTest 8 环境时，最常踩的坑有两类：测试程序里明明配置了日志，测试也跑得顺顺利利，可磁盘上就是没有文件；或者文件确实生成了，打开一看全是莫名其妙的占位符和乱码。

这篇文章不打算只给你列几个菜单项的位置，而是把 SmarTest 8 Data Logging 的运行机制从头到尾拆一遍：它到底在什么环节产生数据、由谁决定记不记、从测试执行到文件落盘中间经过了哪些环节、量产和调试两种场景下应该怎么配。如果你刚接手芯片测试程序开发，或者正在被测试数据的完整性问题折磨，这篇应该能帮你省下几个通宵。

1. 先弄明白一件事：Data Logging 到底在为什么服务

1.1 量产测试现场的数据命脉

说句实话，单看功能开关，Data Logging 跟普通软件里的日志系统长得差不多，就是把运行信息写进文件。但在半导体量产测试的场景里，它的地位完全不是“辅助排错”这么简单。每一颗被测芯片经过测试机台，每跑完一个测试项，产线良率、失效模式分布、某一批材料导致的一致性偏差，这些分析全都依赖 Data Logging 输出的原始记录。

我见过一个真实的产线场景：某批次产品良率从 95% 突然掉到 91%，如果没有 Data Logging 定位到是哪几项测试、哪一个 site、甚至哪一片晶圆的失效集中，排查根本无从下手。只有把每个 die 的每项测试结果按坐标、按 site、按测试项拆开看，才能判断是制程漂移、探针接触不良，还是测试程序本身在某类边界条件下出了 bug。

打个比方，晶圆测试就像给一大片鸡蛋做质检，Data Logging 不只是告诉你“这批蛋有多少是坏的”，它还要能告诉你坏的是哪一箱、哪一层、哪个位置。没有这套细颗粒度的记录，产线上的任何波动都只能靠猜。

1.2 SmarTest 8 的数据记录和普通日志有什么不一样

如果只把它当普通日志用，你会在配置界面上迷路。SmarTest 8 的 Data Logging 有一个非常容易迷惑新手的设计：配置分成了“测试程序侧”和“系统运行侧”两层。

测试程序侧，也就是你在测试项级别设置的那些参数，决定了“我这个测试项愿不愿意输出日志、愿意以什么格式输出”。而系统运行侧，是测试执行时整个机台对日志的整体控制，它负责“当前这个运行阶段到底收不收日志、往哪个目录写、写文件头还是追加”。

这两层是“与”的关系：程序侧想写，运行侧也必须打开；运行侧打开了，程序侧的测试项也得设对了 type。很多人在 SmarTest 8 里操作了很久才反应过来，原来日志不生成文件，不是“开关坏了”，而是两层配置有一层没生效。

1.3 一条日志真正落盘的三要素

一条测试记录要最终落到磁盘上，必须具备三个条件：

1. 程序侧该测试项的 Datalog Type 非“关闭”状态；
2. 运行侧的整体 Datalog 开关处于打开或者启动状态；
3. 输出路径有效、可写。

这三点缺一个，结果都是“测试正常跑，日志不出现”。后面我讲排查链路时，基本也是按这三个条件逐项排查。

2. 测试程序侧的两个关键旋钮：Datalog Type 与 Datalog String

2.1 Datalog Type：这五个值怎么选

在 SmarTest 8 的测试项属性里，有个叫 Datalog Type 的字段，默认通常是 0。这是整个 Data Logging 机制最基础的控制位。

不同的 type 值决定了该测试项在不同结果下是否输出日志，以及输出时是否附带额外信息。常见的取值含义大致如下（不同版本界面文字可能略有差异，但总体逻辑一致）：

为什么要有这种区分？直接原因就是数据量。量产机台一旦多 site 同测，比如 32 个 site 同时测试，如果你把所有 pass 项的测量值全部落盘，一个 shift 下来轻松产生几个 GB 的文本文件，这对磁盘 IO 和后续解析都是灾难。而只记录 fail 项，数据量可能缩到百分之一，但恰恰把产线上最关心的信息保住了。

我看到很多新手上来喜欢把全部测试项设为“全记录”，觉得这样最保险。其实不是，量产阶段全记录会让文件系统先撑不住，还是按阶段切换 type 更合理。

2.2 Datalog String：决定每条记录长什么样的模板

Datalog Type 决定“记不记”，Datalog String 则决定“记出来的内容长什么样”。SmarTest 8 允许通过一段字符串模板来定义每条日志的输出格式，里面可以引用当前测试项的名称、测试结果、测量值、软 bin、硬 bin、site 编号、执行时间等系统变量。

举个最小化的模板示例：

LOTID=%LOT%|SN=%SN%|TNAME=%TNAME%|SITE=%SITE%|BIN=%BIN%|MEAS=%MEAS%|TIME=%TIME%

（注：具体变量名在不同版本里写法不同，这里只是让大家理解结构。）

这条模板会被套用到每个测试项的每条日志记录上。实际配置时，我喜欢把晶圆批号、片号、测试项名、site、bin、关键测量值这几项放进去。尤其是 site 字段，千万别省——多 site 测试时如果日志里没有 site，后续做分布分析会非常痛苦。

2.3 为什么说测试程序侧只是“声明”

搞清楚这个概念，能省掉很多排查时间：测试程序侧设置 type 和 string，本质上只是告诉系统“我这个测试项愿意输出日志，并且按这个格式输出”。它不等于最终的日志一定会产生。最终是否落盘，还要看运行侧那一层开关。

当然，这个“声明”也不是小事情。测试项如果连 type 都设成 0，运行侧就算把功率开满，该测试项也照样不会有日志。这也是为什么调试阶段改完程序，很多人以为重启加载就生效了，结果日志还是空的——很可能是这个测试项在程序里确实是 0，你只改了运行侧，自然没效果。

3. 系统运行侧：数据从测试头流向日志文件的完整链路

3.1 运行侧的总开关和输出路径

SmarTest 8 在运行环境里有一个用于 datalog 控制的整体配置区域，管着总开关、输出目录、命名规则这些全局信息。测试程序加载之后，系统会按运行侧配置来决定“这批测试的日志往哪里写”。

这里有个特别容易被忽略的点：输出路径尽量不要放在系统盘，更别放在机台软件的安装目录下。量产测试一天产出几百 MB 到几个 GB 的日志文件，如果路径区域有权限限制，或者两个 job 共用同一个目录，很容易出现写失败或者文件名互相覆盖。

我做过一个模拟项目，把日志输出到了网络共享盘，结果因为网络延迟，量产后段出现大量 IO 等待，测试节拍被拖慢了接近 2%。后来全部改为本地盘，再通过定时任务同步到分析服务器，才把问题解决。路径的取舍，不只是“能不能写”的问题，还会影响量产速度。

3.2 停止模式与实时模式的工作差异

SmarTest 8 的数据写入大体分两类模式：一类是“实时写盘”，一类是“停止模式下统一写盘”。这两者在运行机制上差别很大。

实时写盘模式下，每个测试项跑完，数据会立即追加到输出文件里。好处是内容连续、外部工具可以边跑边读，甚至可以在测试还在进行时做实时监控；代价是磁盘 IO 压力大，多 site 同测时会加剧，而且每条记录的写入延迟都会占用测试节拍。

停止模式则是测试过程中先把记录积攒在内存缓冲里，等一个批次结束，或者你手动触发，再一次性把缓冲中的数据写进文件。这种模式对测试速度影响最小，但风险是：如果测试中途机台突然断电或者软件异常退出，缓冲里没来得及落盘的数据就全部丢了。

选择原则其实很朴素：调试新程序时用实时，方便立刻发现问题；量产稳定阶段用停止模式，性能优先，同时配置好批次结束自动落盘。具体配置入口每个版本叫法不同，但基本逻辑都是“Datalog 运行模式”相关选项。

3.3 文件命名、追加写与滚动切分

日志文件不是无限增长的。SmarTest 8 在运行侧通常会按“批次启动”自动创建新文件，文件命名模板里可以带机台编号、批次号、时间戳。比如：

Datalog_%TESTER%_%LOT%_%STARTTIME%.log

同一批次内的数据持续追加写，直到批次结束、文件被正常关闭。

量产场景下，我强烈建议开启按文件大小或按时间滚动切分。原因很简单：一个批次几万颗芯片，跑完后日志文件可能达到几个 GB，单文件过大不仅打开慢，万一文件损坏，一整批数据全废。滚动切分后，每个文件控制在可管理的大小，即使某一段文件坏了，损失也只是极小一部分。

4. 从零配一次完整的 Data Logging：一套可以抄的实操流程

4.1 最小配置清单

这一节不聊理论，直接列出我每次配置 Data Logging 时都会走一遍的清单。这套流程在多个模拟项目里验证过，照着做基本不会漏东西。

第一，先在测试程序里确定哪些测试项需要输出日志。调试阶段建议把目标测试项 Datalog Type 设为“全记录”，工程分析阶段需要看 fail 细节的话，可以保持所有项记录；量产阶段再改成“只记 fail”。

第二，检查 Datalog String 模板。第一次配置时最容易漏掉 site 字段，后面解析数据时又得回头补。建议先规划好模板再动手。

第三，进入运行侧配置界面，打开 Datalog 总开关。选择输出目录，注意路径一定可写、有足够剩余空间；设置命名模板，带上机台号和批次信息。

第四，配置写入模式。调试用实时模式，量产用停止模式批次落盘。如果支持滚动切分，顺手把单文件大小上限设好，比如 200MB 切一个文件。

第五，加载测试程序，跑一个 3～5 颗模拟芯片的小批量。打开输出文件确认数据格式正确、字段完整。这个“小批量验证”习惯我坚持了很多年，每次都帮我提前发现配置错误。

4.2 用一个小批量把机制跑通

实操时你不一定需要真芯片。很多测试机台配合相关模拟功能，可以让你使用模拟芯片/虚拟数据跑完整个流程，重点不是测得好不好，而是观察数据和文件是否按预期产生。

跑完之后去看输出文件。一个正常的记录片段大概是这个样子：

LOTID=TESTLOT01|SN=0000001|TNAME=CONT_OPEN|SITE=0|BIN=1|MEAS=0.0002V|TIME=0.0312ms LOTID=TESTLOT01|SN=0000001|TNAME=CONT_OPEN|SITE=1|BIN=1|MEAS=0.0003V|TIME=0.0315ms

注意看两个细节：一是不同 site 是不是各有一行，二是每条记录里的字段是不是都填了真实值而不是 0、空格或者默认占位符。如果发现字段是空的，先回去查 Datalog String 里的变量引用名是否写错；如果整条记录缺字段，多半是 Datalog String 模板没有正常生效。

4.3 验证时最容易忽略的三个细节

第一个细节是文件头部。部分模式下，文件前几行会写入批次信息、机台信息和测试程序版本，这些信息对后续追溯非常重要。验证时不要只看数据行，还要确认头部信息是否正确。

第二个细节是写入时机的差异。实时模式下，文件内容在你跑第一个测试项后就会立刻出现；停止模式下，跑完小批量可能文件里还是空的，一定要等批次结束、缓冲落盘完成后再去查看。很多工程师在这步误判“日志没生效”，其实只是模式差异。

第三个细节是编码。SmarTest 8 输出的文本文件一般是纯 ASCII 或 UTF-8，如果 Datalog String 里不小心写入了全角空格、中文引号，可能导致解析端读乱。建议模板里全部使用半角字符，字段分隔符统一用竖线或逗号。

5. 运行中的几个典型故障：完整排查链路

5.1 现象一：开了 Datalog，却没有生成任何文件

这恐怕是问得最多的一个问题。排查不要乱猜，按链路一步步来。

先看运行侧总开关是否为打开状态。很多人是在“某个测试项”的界面里把 type 改了，但运行侧总开关压根没拨过来。再看输出路径是否有效：路径不存在、权限不足、盘符挂载失败，都会让文件创建失败且没有明显弹窗。接着确认测试程序是否真正重新加载了修改后的版本。SmarTest 8 里程序修改后需要重新加载并生效，如果你只是改了文件没加载，跑的还是旧配置。最后返回测试项属性，确认该测试项的 Datalog Type 不是 0。注意，如果是在停止模式下，还要考虑批次是否已正常结束，缓冲是否真的刷新到磁盘了。

这些环节，十次里有七次是卡在“运行侧总开关没开”或者“程序没重新加载”。

5.2 现象二：文件生成了，但内容全是空格、缺少字段、或者字段错位

出现这类问题，九成以上是 Datalog String 模板写错。尤其是字段名引用不对时，SmarTest 8 不会报错，而是原样输出占位符，或者输出空白，解析端看到的就是一堆乱掉的表头。

排查方法是：先用一个最简单的模板，只输出测试项名和结果，跑通之后再逐步加字段，确认每个字段都正确。这样二分定位法，几分钟就能找到是哪个字段引用出了问题。

还有一种情况是模板里被粘贴进了不可见字符。看起来正常的竖线分隔符，实际可能是两个全角竖线，解析时字段数就会多出来。遇到字段错乱，先把模板全部手动重敲一遍，往往就好了。

5.3 现象三：量产时日志文件把磁盘写满

这个现象在只记录 pass/fail 的场合不常见，但如果有人把测试项 type 设成了“全记录”，马上就会来。32 site 同测、每颗芯片 300 个测试项、全记录模式，几天下来目录占用会非常难看。

对策有几个：量产阶段改回“只记 fail”；开启按大小滚动切分；设置日志保留天数或写定时清理脚本；文件名里带上机台号和批次，方便按批次归档。我在量产线习惯的做法是：每个批次结束，把当批日志压缩后挪到归档目录，原始日志只保留最新的几个文件。这样既能应对工程追溯，又不会把本地盘子塞满。

5.4 关于解析端的一点个人建议

Data Logging 的最终目的不是“有文件”，而是“能被人和工具读”。所以配置 File Log 之前，我建议先把下游的解析逻辑想清楚：你打算用什么工具读？要求一行一条记录，还是允许跨行？分隔符是什么？字段顺序固定吗？

这些如果在配置阶段就想好，后面就不用为了迁就解析格式回去改测试程序。我自己有一份固定的字段顺序模板：批次号、芯片号、site、测试项名、bin、测量值、执行时间，所有项目统一用，几乎没有出过解析阶段的离谱问题。

6. 一些长期积累的操作习惯

最后聊几个我自己的习惯，不一定适用于所有产线，但至少能让人少踩几次坑。

第一，任何 Datalog 配置改动，先跑一个小批量验证再上量产。这是成本最低的保险。改一个字符的模板，如果不验证，可能到第二天量产时才发现整个批次文件全废。一个是几分钟的空跑测试，一个是整批数据作废的风险，这笔账怎么算都清楚。

第二，Datalog 配置这件事要当成测试程序的一部分来管理，改了什么、为什么改、实测文件是否正常，都记下来。Data Logging 虽然只是辅助功能，但它和测试项本身一样，属于整个测试程序的资产。换人维护时，如果没有记录，光靠翻界面去猜别人当初为什么这么设，非常费劲。

第三，定期主动看一眼日志文件的大小和内容。不用每天都看，但至少每次切换量产模型或换批次时，随机抽一个日志文件检查大小、行数、字段是否正常。去年我在某个模拟项目里就遇到过后端解析报错，最后发现是设备日志文件在一批里自动切换到了新文件，旧文件尾部缺了一条结束标记，导致整批导入失败。这类问题在测试环节完全不报错，只有定期抽查才能抓到。

SmarTest 8 的 Data Logging 机制，说穿了并不复杂，难点在于两层配置的配合、type 与 string 的分工，以及实时写盘和停止写盘两种模式的取舍。把这些底层逻辑理清了，绝大多数所谓“日志问题”都能自己定位。希望这篇分享能帮你少走几个弯路。