机顶盒看起来是个非常成熟的产品很多人觉得产线工作无非就是“组装、测试、包装”三板斧。但真正在工厂待过就会知道产线日常每天面对的不是寂寞而是无穷无尽的变量今天换了一版固件明天 Wi-Fi 模组换了供应商后天有一批 eMMC 的批次不良率突然升高再往后可能只是操作员换了一个人测试良率就掉了两个点。这篇文章不聊怎么开发机顶盒而是站在产线测试与工程的角度讲清楚一台机顶盒从贴片完成到包装出货中间要经历哪些测试环节每个环节容易出什么问题以及产线工程人员怎么把这些问题管起来。核心判断是机顶盒产线真正比拼的不是测试项目多不多而是异常响应速度和数据追溯能力。测试项写得再全如果出了问题无法快速定位到批次、固件版本、工位和操作员产线就永远在救火。因此接下来会从产线流程、测试原理、环境搭建、自动化脚本、数据采集、异常排查和工程管理几个角度展开并给出可复用的脚本与配置示例。1. 机顶盒产线日常到底在解决什么问题一台机顶盒从硬件上看并不复杂主控芯片、DDR、eMMC、Wi-Fi/BT 模组、Tuner、HDMI、电源、遥控接收头再加一个外壳。但从贴片完成到用户可以正常使用中间的测试环节一点都不少。产线日常的本质是在有限的节拍时间内用最可靠的方式验证三件事硬件有没有问题。贴片有没有虚焊、短路DDR 能不能稳定读写射频信号强度是否达标电源纹波是否在允许范围内。软件有没有烧对。固件版本是否正确SN、MAC、HDCP Key 等唯一信息有没有写入写进去之后能不能被正确读取和校验。整机能不能稳定工作。Aging 老化测试中是否出现死机、重启、花屏高温环境下 Wi-Fi 是否掉线遥控器响应是否灵敏。产线日常之所以难不在于某个单项技术有多深而在于它是一个典型的“多变量耦合系统”。固件版本、硬件批次、操作员手法、测试治具状态、环境温湿度任何一个变量变化都可能影响测试结果。更麻烦的是有些问题只在产线上出现离开产线环境就复现不了这时候如果没有完整的日志和数据记录排查会非常被动。这篇文章适合三类读者一是刚接手产线测试工作的嵌入式工程师二是做测试开发、需要编写产线自动化脚本的同学三是负责工厂信息化、需要对接 MES 系统的软件开发人员。读完这篇文章你会对整个机顶盒产线测试链条有一个完整认识并且可以直接参考其中的脚本思路搭建最小可用的产线测试工具。2. 机顶盒产线整体流程拆解机顶盒的生产测试流程一般从 SMT 贴片开始到包装出货结束。不同工厂的组织方式会有差异但核心环节大致可以分为七个阶段。2.1 SMT 贴片与 PCBA 外观检查SMT 贴片完成之后PCBA 先过 AOI 光学检测检查贴片位置、极性、桥连等缺陷。这个环节的效率很高一台 AOI 每小时可以检测几百片板子但它只能发现“看得见”的问题。AOI 之后通常还会安排一次人工目检重点检查连接器、插座、屏蔽罩等 AOI 不容易覆盖的位点。这里容易出现的问题有两个一是 AOI 误判率过高导致频繁停机确认二是漏判率过高导致有缺陷的板子流入后段测试。因此AOI 程序的维护和误判复判流程非常重要。每天开班前用标准板校准一次是最基本的动作。2.2 PCBA 单板测试PCBA 在组装成整机之前通常会先做一次单板测试也叫 FCTFunctional Circuit Test。这个工站主要验证主板供电路径、晶振起振、主控芯片能否正常启动、能否进入升级模式。单板测试的好处是在组装之前就把坏板拦截掉避免把一块坏板装进外壳之后再拆机返修浪费大量工时。FCT 工站一般使用测试治具压合 PCBA 上的测试点通过串口或者 USB 与主板通信。测试内容比较简单重点是“能不能开机”和“能不能烧录”。这个环节如果发现某一块板卡无法进入烧录模式大概率是主控芯片周边电路有问题比如晶振、电源、复位电路。2.3 整机装配单板测试通过之后PCBA 进入整机装配环节装外壳、贴标签、连接天线、装配电源板、安装散热片等。装配环节看似没有技术含量但恰恰是很多“灵异问题”的源头。比如 Wi-Fi 天线端子在装配过程中松脱、散热片压到了某个元器件、外壳卡扣压住了排线这些硬件问题往往要到功能测试甚至老化测试才会暴露出来。因此装配工位通常会有一个简单的外观确认动作并且关键连接器会拍照留档或者由巡检人员定时抽检。如果产线后面批量出现“信号弱”的问题第一步不是怀疑硬件设计方案而是先检查装配工位的操作是否规范。2.4 整机功能测试整机装配完成之后进入产线最核心的工站整机功能测试一般叫做 MMIMan-Machine Interface测试。所有功能都会在这个工站验证一遍包括开机启动是否正常进系统时间是否在允许范围内SN、MAC、HDCP Key 等唯一信息是否正确写入Wi-Fi 信号强度和蓝牙功能是否正常HDMI 输出是否有画面分辨率是否设置正确USB 接口读写是否正常以太网连接是否正常遥控器按键和红外接收是否正常音视频输出是否正常这个工站的节拍时间直接决定了产线的产能。节拍压得越短测试覆盖越容易缩水测试覆盖越全节拍就越难压缩。优秀的产线工程团队会把“必须全检的功能”和“可以抽检的功能”区分开把有限的产线时间花在最关键的验证项上。2.5 烧录与写号烧录和写号在很多工厂是放在功能测试之前的也有放在中间的取决于软件架构和测试流程设计。烧录包括烧写 Bootloader、系统固件、基带固件等写号则包括写入 SN、MAC、HDCP Key、区域配置等信息。这个环节最容易出的问题就是“烧错版本”和“写错号”。烧错版本一般是升级包管理混乱导致的写错号则往往是因为操作员扫码时扫描枪多扫了一位、或者扫码内容与订单不一致而系统没有校验。这两个问题都属于“批量事故”一旦发生轻则返工重烧重则整批流向市场后被发现序列号冲突引发客诉和召回。2.6 老化测试老化测试Aging Test是机顶盒产线里耗时最长的一个环节一般持续 4 到 8 个小时甚至更久。目的是通过长时间通电运行让早期失效的元器件提前暴露。常见的做法是让机顶盒在高温环境下持续播放视频或者循环跑压力测试同时监测是否出现死机、重启、花屏、Wi-Fi 掉线等问题。老化测试的瓶颈在于占地面积大、耗时长、需要占用大量治具和电源。因此产线一般只会对批量订单的代表性样本做全量老化或者对首件、工程变更后的批次做全量老化其余批次按比例抽检。如果老化测试中发现某批次不良率异常偏高就会触发批次隔离和原材料追溯流程。2.7 包装与出货老化测试通过之后机顶盒经过最终外观检查、附件清点、彩盒包装就可以入库出货了。最后一个环节通常还会做一次“出货前快速开机确认”防止在老化之后、包装之前的存放期间出现运输损伤或静电损伤。从这段流程可以看出机顶盒产线其实是一条“层层拦截、逐级确认”的质量链条。每一道工序都在为后一道工序提供输入任何一个环节的错误都可能被放大。因此产线日常的核心工作除了完成当前的测试任务之外更关键的是把每一个环节的数据和异常记录管理起来。3. 机顶盒产线测试的核心原理明白了整体流程之后再深入看每个测试环节背后的原理。这里不会讲到芯片寄存器级别而是从产线工程的角度讲清楚每个测试为什么存在、它检测的是什么类型的缺陷。3.1 单板测试的核心原理单板测试FCT本质上是一个“最小系统验证”。它把 PCBA 当作一个独立的电子系统测试电源、时钟、复位、主控启动链路是否正常。单板测试的关键在于测试治具的设计通过探针压合 PCBA 上的测试点把电源、地、串口、USB 等信号引出来连接到一个测试控制板或者直接连接到工控机。FCT 常见的检测项包括各电压轨是否正常比如 3.3V、1.8V、1.0V晶振是否起振主控能否通过串口输出启动日志能否进入烧录模式单板测试的逻辑很简单如果最小系统都不能正常启动后续所有测试都无从谈起。因此这个工站的通过率一般要求在 99% 以上如果低于这个水平往往意味着 SMT 焊接工艺出现了系统性问题优先查炉温曲线、锡膏质量、贴片压力设置。3.2 功能测试的核心原理功能测试的核心是一个“软硬协同验证”的过程。机顶盒运行测试 APK 或通过 ADB 指令执行测试用例同时测试工装模拟用户操作验证各功能模块是否正常。以 Wi-Fi 测试为例产线通常不测真实吞吐量而是通过读取系统内的 RSSI 值来判断信号强度是否达标。机顶盒连接一个指定的 AP然后读取cmd wifi status或者通过系统 API 获取当前的信号强度。如果 RSSI 低于某个阈值比如 -60dBm就判为失败。这个测试速度快、覆盖率高但它有一个盲区它只能证明 Wi-Fi 模块能够连上 AP不能证明实际吞吐量是否达标。因此有些对无线性能要求高的订单会额外增加一个吞吐量抽检环节使用 iperf 进行实际打流测试。HDMI 测试的原理类似。机顶盒通过 HDMI 连接到一个带 HDMI 输入的监视器或者视频采集卡测试系统播放一段测试画面由采集卡抓取图像并做比对。常见的判断方式有两种一种是做像素比对通过计算图像相似度判断画面是否正常另一种是检测是否有 HDMI 信号输出比如读取显示器或采集卡是否有有效分辨率信息。像素比对更严格但速度更慢信号检测速度快但无法发现花屏、偏色等问题。产线需要根据订单质量要求做取舍。3.3 写号与校验原理SN、MAC 这些唯一信息在产品出厂后承担着追溯、激活、网络鉴权等职责。写号环节最核心的要求就是两点唯一性和一致性。唯一性是指同一个 SN 不能出现两次一致性是指写入的内容必须和订单、标签、包装箱上的内容一致。为了实现这两点产线通常会采用“扫码→比对→写入→回读→校验→上传”的流程。操作员先扫描机顶盒标签上的条码系统根据条码生成或者获取对应的 SN、MAC 信息通过 ADB 或串口写入设备然后回读写入结果并与原始数据比对。比对通过之后这些信息会同步上传到 MES 系统作为后续追溯的依据。这里的关键是“写入后的回读校验”很多早期产线只写不读导致 SN 写入失败但测试仍然判 PASS 的情况直到产品流向市场才被发现。回读校验会额外增加几百毫秒的时间但相比整批返工的代价这点时间非常值得。3.4 老化测试的原理老化测试的本质是“加速失效验证”。电子元器件的失效曲线呈现典型的浴盆形状早期失效率较高随后进入低而平稳的随机失效期最后进入磨损失效期。老化测试的目的就是通过高温、长时间通电、高负载运行把早期失效提前暴露在工厂内而不是等到用户手里再爆发。常见的做法是将机顶盒放置在 45℃ 左右的高温老化房里持续播放本地或者在线视频循环执行重启、待机唤醒、Wi-Fi 重连等操作同时通过串口或网络上报设备状态。老化测试中发现的问题一般集中在散热不良、DDR 兼容性、电源模块在高温下的稳定性、Wi-Fi 在高温下的连接稳定性等。老化测试的价值不能用“检出多少不良”来衡量更准确地说它的价值在于建立信心。一批产品在老化工序中连续运行 8 小时无故障这本身就说明这批产品的早期失效风险比较低。4. 产线测试环境搭建与工具链产线测试环境是一个容易被低估的部分。表面上看测试环境无非就是工控机、测试治具、网络、电源但实际上一个设计良好的产线测试环境可以大幅降低误判率、提升换线效率。4.1 产线网络的规划机顶盒产线测试有一个特点设备数量多、IP 地址变化频繁、安全隔离要求高。每台机顶盒在测试时都需要一个独立的 IP 地址测试完成之后这个 IP 要么释放要么被回收。如果机顶盒的 IP 和产线办公网络的 IP 段冲突或者和 MES 服务器的 IP 冲突排查起来会非常痛苦。一个比较常见的做法是把产线网络划分为三个隔离的网段管理网段用于工控机、测试服务器、MES 客户端之间的通信测试网段用于机顶盒设备接入一般由 DHCP 动态分配地址每台测试治具对应一个独立的网口或 VLAN工厂局域网段用于连接 ERP、MES 数据库、文件服务器等这样做的好处是测试网段的广播风暴不会影响管理网络而且便于做 IP 资源的统筹管理。机顶盒在测试完成后DHCP 租约可以设置得较短比如 5 到 10 分钟这样 IP 资源能够快速回收复用。如果想避免 DHCP 带来的地址管理问题也可以使用 USB 网络共享或者通过 ADB over WiFi 的方式连接设备但这通常只适用于某些特定的测试场景不是主流方式。4.2 测试工控机的软件环境产线测试工控机建议使用 Ubuntu 系统主要原因是 Android 调试工具链ADB、Fastboot在 Linux 环境下运行更稳定而且 Python 脚本生态更丰富。工控机作为产线测试的核心节点软件环境需要尽量精简、稳定。一个典型的工控机环境包括Ubuntu 20.04 或 22.04 LTS 系统Python 3.8使用虚拟环境管理依赖Android Platform Tools包含 adb、fastboot串口调试工具如 minicom、pyserialMES 客户端或者 MES API 调用脚本安装好系统之后建议将测试脚本统一放在/opt/line_test/目录下按照工站进行子目录划分避免不同脚本之间互相依赖。测试记录和日志统一输出到/var/log/line_test/方便集中收集和排查。# 安装 Python 虚拟环境和依赖 sudo apt update sudo apt install -y python3 python3-venv python3-pip # 创建测试项目目录 mkdir -p /opt/line_test/{fct,mmi,aging,report} cd /opt/line_test python3 -m venv venv source venv/bin/activate # 安装 pyserial 和 requests pip install pyserial requests # 确认 adb 版本 adb version这里有一点需要注意产线工控机不建议频繁升级系统和工具链因为每次升级都可能引入兼容性问题。正确的做法是先在实验室环境验证好版本组合再批量同步到产线工控机。版本升级要像固件发布一样走测试、灰度、全量的流程。4.3 测试治具的准备测试治具是连接工控机和被测设备的桥梁。机顶盒整机测试一般通过 USB 线连接工控机和机顶盒的 USB 口使用 ADB 通信PCBA 单板测试则通过治具上的探针和排线连接串口。治具的维护和保养是一个容易被忽视但影响很大的细节。USB 线在反复插拔之后接触不良探针在长期压合之后弹性下降这些都会导致测试结果不稳定。因此产线需要为每个测试工位制定一个“治具点检表”每天开班前检查线材、探针、电源、网络连接每周进行一次深度清洁和阻抗检查。治具的防呆设计也很重要。比如 USB 方向插反会导致通信失败治具上要设计防反插结构批头、探针要设计成快拆结构方便操作员在出现问题时快速更换而不是拿着烙铁在现场焊接。4.4 测试固件与升级包的版本管理产线最容易出的问题之一就是测试固件版本和订单不一致。很多工厂还在用共享文件夹的方式管理固件文件名上加上日期和版本号操作员手动拷贝到工控机。这种方式在订单少的时候勉强可用一旦多个订单并行就很容易出现操作员拿错固件包、烧错版本的情况。更稳妥的方式是搭建一个简单的固件管理服务可以是 MES 系统的一个模块也可以是一个独立的版本管理工具。固件包统一存放在服务器上工位机通过订单号或者产品型号自动拉取对应的固件包拉取之后计算 MD5 校验值确保固件包完整。产线工控机上不保留历史版本固件只保留当前订单对应的固件。如果你所在工厂还没有上 MES也可以先用 Git LFS 配合一个简单的 Python 脚本来管理固件版本。核心思路是固件文件走版本管理工位机通过脚本拉取记录拉取日志。5. 关键测试项与判定标准不同客户的机顶盒测试要求会有差异但核心测试项基本一致。下面以比较典型的整机功能测试为例整理一个测试项与判定标准参考。实际执行时标准需要根据产品规格书和客户要求进行细化。测试工站测试项目判定标准参考失败处理FCT电源电压3.3V/1.8V/1.0V ± 5%检查电源电路与焊接FCT晶振起振频率偏差在规格允许范围内更换晶振或检查负载电容FCT串口输出能正常输出启动日志检查主控最小系统烧录固件版本与订单要求完全一致重新烧录并核对升级包写号SN 写入与回读回读值和目标值一致检查写入工具与标签写号MAC 写入与回读回读值和目标值一致检查写入工具与标签MMI开机时间从上电到进桌面不超过设定值检查系统启动项与 eMMC 速率MMIWi-Fi 信号强度RSSI 大于等于 -60dBm检查天线连接与射频匹配MMI蓝牙扫描能扫描到指定蓝牙设备检查蓝牙天线与屏蔽MMIHDMI 输出能检测到有效分辨率信号检查 HDMI 座子与外围电路MMIUSB 读写U 盘读写正常检查 USB 数据线对与供电MMI以太网连接DHCP 获取 IP 且 ping 通网关检查网口变压器与连接器MMI遥控接收按键响应正常检查红外接收头与遥控器Aging长时间运行无死机、重启、花屏定位失效元件批次隔离Aging高温 Wi-Fi持续连接不断线检查散热与射频高温特性这些测试项中有些适合全检有些适合抽检。比如 USB 读写在硬件设计稳定的情况下产线做全检的边际收益很低反而拖慢节拍。一般建议新导入的机型做全量全检量产稳定后对非关键项改为抽检把时间留给真正容易出问题的环节。6. 自动化脚本与代码实现产线测试自动化是一个很大的话题这里从实际情况出发给出几个可以直接参考的脚本示例。这些脚本解决的场景包括SN 读取校验、MMI 测试主流程、MES 数据上报。实际产线脚本会比这复杂得多但这些示例可以帮助你快速理解产线自动化的基本模式。6.1 通过串口读取并校验 SNPCBA 单板测试阶段设备还没有完全启动 Android 系统无法使用 ADB 通信只能通过串口访问。此时可以用 pyserial 读取设备输出的信息并对 SN 等关键信息做校验。# 文件路径/opt/line_test/fct/read_sn.py import re import serial import serial.tools.list_ports def find_device_port(): 自动查找测试治具对应的串口号 ports serial.tools.list_ports.comports() for port in ports: # 这里以 USB 转串口的 VID/PID 作为识别依据 # 实际产线中建议使用 port.serial_number 做更严格的判断 if USB in port.description or UART in port.description: return port.device raise RuntimeError(未找到串口设备) def read_sn_from_device(port: str, timeout: int 10) - str: 从设备串口读取 SN 信息 pattern re.compile(rSN[:]\s*([A-Za-z0-9\-_])) with serial.Serial(port, 115200, timeout1) as ser: buf b end_time time.time() timeout while time.time() end_time: data ser.read(64) if not data: continue buf data text buf.decode(utf-8, errorsignore) match pattern.search(text) if match: return match.group(1) raise RuntimeError(读取 SN 超时) def check_sn_format(sn: str) - bool: 校验 SN 格式具体规则由产品定义 if re.fullmatch(r[A-Z0-9]{8,16}, sn): return True return False if __name__ __main__: port_name find_device_port() sn_value read_sn_from_device(port_name) if check_sn_format(sn_value): print(fSN 读取成功: {sn_value}) else: print(fSN 格式异常: {sn_value}) raise SystemExit(1)这段代码的思路是先自动识别串口设备然后持续读取串口数据通过正则表达式匹配 SN 字段读取后做格式校验。实际产线中SN 格式规则一般由产品定义比如前几位是产品代码、中间是生产日期、后面是流水号。还可以在读取 SN 之后调用 MES 接口比对 SN 是否在订单范围内防止混料。6.2 MMI 测试主流程脚本整机功能测试阶段设备已经启动了 Android 系统可以通过 ADB 执行测试操作。下面的脚本演示了 MMI 测试的主流程框架开机确认、检查固件版本、读取 SN、执行指定测试动作、把结果写入本地报告。#!/bin/bash # 文件路径/opt/line_test/mmi/mmi_test.sh # 用法bash mmi_test.sh 设备序列号 set -e DEVICE_SN$1 if [ -z $DEVICE_SN ]; then echo 请传入设备序列号 exit 1 fi # 第一步确认 ADB 设备已连接 adb devices | grep -w $DEVICE_SN /dev/null || { echo 设备不在线: $DEVICE_SN exit 1 } # 第二步获取设备型号和固件版本 MODEL$(adb -s $DEVICE_SN shell getprop ro.product.model | tr -d \r) FW_VERSION$(adb -s $DEVICE_SN shell getprop ro.build.version.release | tr -d \r) echo 设备型号: $MODEL, 系统版本: $FW_VERSION # 第三步检查设备是否有开机动画/桌面异常 BOOT_COMPLETED$(adb -s $DEVICE_SN shell getprop sys.boot_completed | tr -d \r) if [ $BOOT_COMPLETED ! 1 ]; then echo 设备未完成开机 exit 1 fi # 第四步读取 SN 并与传入参数比对 DEVICE_SN_VALUE$(adb -s $DEVICE_SN shell getprop ro.serialno | tr -d \r) if [ $DEVICE_SN_VALUE ! $DEVICE_SN ]; then echo SN 不匹配: 期望$DEVICE_SN, 实际$DEVICE_SN_VALUE exit 1 fi # 第五步占位这里可以扩展为执行具体测试 # 例如adb shell am instrument -w com.test.mmi/androidx.test.runner.AndroidJUnitRunner echo MMI 基础检查 PASS这段 Shell 脚本虽然简单但体现了产线测试脚本的通用结构设备在线检查、静态信息读取、关键字段比对、测试执行、结果输出。脚本中的sys.boot_completed是判断 Android 是否完成开机的一个常用属性在产线测试中很有用。实际产线的 MMI 测试不会只在命令行里检查属性而是会启动一个专门的测试 APK由 APK 内部调用系统接口执行 Wi-Fi、蓝牙、HDMI、USB 等测试并通过广播或者文件方式把结果返回给测试脚本。APK 测试的好处是可读性强、扩展性好而且可以对每一个测试项输出详细的日志。6.3 测试结果上报 MES产线测试的最终目的是把数据汇集到 MES 系统形成单台设备的完整测试档案。下面给出一个简单的 Python 上报脚本把测试结果以 JSON 格式提交到 MES API。# 文件路径/opt/line_test/report/upload_result.py import json import time import requests MES_API_URL http://mes-server.example.com:8080/api/v1/line-test/report TOKEN generate-yours-by-mes-login def build_report(device_sn: str, station: str, result: str, items: list, logs: str) - dict: 构造测试报告数据 return { deviceSn: device_sn, station: station, result: result, testTime: time.strftime(%Y-%m-%d %H:%M:%S), items: items, logs: logs[:2000], # 日志过长时截断 } def upload_report(report: dict) - bool: 上报 MES 系统 headers { Content-Type: application/json, Authorization: fBearer {TOKEN}, } try: resp requests.post(MES_API_URL, jsonreport, headersheaders, timeout5) if resp.status_code 200: return True # 这里可以增加重试机制 print(f上报失败: {resp.status_code}, body{resp.text}) return False except requests.exceptions.RequestException as exc: print(f上报异常: {exc}) return False if __name__ __main__: sample_items [ {name: power_on, result: PASS, detail: boot time: 23s}, {name: wifi_rssi, result: PASS, detail: -45dBm}, {name: sn_check, result: PASS, detail: sn match}, ] sample_report build_report( device_snSN20250101001, stationMMI-01, resultPASS, itemssample_items, logssample test log, ) ok upload_report(sample_report) print(上报成功 if ok else 上报失败)上报逻辑的要点在于数据要结构化、结果要可追溯、失败要有重试机制。上面这个示例中的TOKEN需要在真实环境中通过登录接口获取生产环境建议使用服务账号而不是个人账号同时控制权限范围。另外上报失败一定不能静默忽略要把失败记录写入本地待补传队列等网络恢复后重新上报。7. 产线数据采集与追溯体系测试做完只是第一步把测试过程中产生的数据管理起来才是产线工程的核心工作。每一台机顶盒都应该有完整的“出生档案”包括测试结果、关键参数、操作员、工位、时间、所用固件版本等信息。这样当市场端出现批量质量问题时仓库可以根据 SN 反查这批货是哪一天、哪条线、哪一批物料生产的。7.1 单台设备档案单台设备档案最简单的实现方式就是 MES 系统里的一张宽表每条记录对应一台设备。记录的核心字段包括设备 SN、MAC、Wi-Fi MAC、蓝牙 MAC产品型号、硬件版本、软件版本各工站的测试结果、测试时间、操作员工号、工位编号关键测试参数比如 RSSI 值、吞吐量、供电电压原料批次信息包括主控批次、DDR 批次、eMMC 批次、Wi-Fi 模组批次这些字段不需要全部手工录入而应该通过测试脚本自动采集。人一多、环节一长手工录入的错误率会非常高。7.2 批量数据分析建立档案之后还需要建立批量分析的习惯。很多质量问题不是靠单台测试发现的而是靠统计发现的。比如某一天的 Wi-Fi 测试通过率从 99% 下降到 95%单独看每一台都定位不到什么问题但是按批次、按时间段、按工位、按操作员维度聚合之后问题往往就浮出水面了。一个务实的做法是每周拉取一次 MES 测试数据按测试项统计通过率按工位统计一次通过率按操作员统计操作耗时和误判率。如果某个工位的通过率明显低于其他工位优先排查治具问题而不是设备问题这是产线排障中非常有效的一个经验法则。8. 常见问题与排查方法产线运行过程中会遇到各种问题下面整理几个最常见的问题现象、可能原因和排查思路。问题现象可能原因排查方式解决方案设备无法进入烧录模式主控最小系统异常查看串口日志确认供电、时钟、复位检查 PCBA 焊接特别是电源和晶振ADB 设备列表看不到设备USB 线接触不良或驱动异常更换 USB 线检查设备管理器更换线材重新安装驱动SN 写入后回读不一致写入工具读取分区错误查看写入日志确认分区挂载更新写入工具检查镜像分区表Wi-Fi 测试 RSSI 偏低天线未装配到位或模组批次异常拆机检查天线连接抓取射频日志重新装配反馈模组供应商老化测试死机高温下供电不稳或 DDR 兼容问题查看内核日志与温度日志改善散热调整 DDR 参数测试脚本偶发超时网络抖动或 USB 通信不稳定查看 ping 丢包率更换 USB 口优化网络使用独立 USB 控制器某工位通过率明显偏低治具老化或操作手法差异与相邻工位对比检查治具清洁或更换治具加强培训MES 上报失败接口异常或网络隔离检查 MES 服务状态和网络策略增加重试队列联系 MES 管理员从这些常见问题可以看出产线问题的排查思路往往是“先环境后设备、先批次后单台、先治具后主板”。如果一上来就怀疑主控芯片方向很容易跑偏。9. 产线工程最佳实践与后续方向最后把这些年产线工程中比较有价值的经验整理成几条通用的实践建议。这些建议不仅适用于机顶盒也适用于其他智能硬件产品的产线测试。9.1 自动化防呆优先于事后检查产线测试的核心原则是“不要让流程依赖人的自觉”。操作员每天重复成百上千次动作总会有疲劳的时候。所以凡是能够用系统校验的就不要让人工判断。比如固件版本选择不应该让操作员手动选文件而应该扫码之后自动匹配SN 校验也不应该依赖人眼比对而应该由系统自动读取、自动比对。9.2 脚本幂等与异常恢复产线脚本必须做成幂等的也就是同一台设备重复执行测试脚本结果应该一致且不会产生副作用。原因是产线测试经常遇到中途异常、重启测试、返工重测的情况。如果脚本逻辑假设“设备处于全新状态”第二次运行就可能失败。正确的做法是在每个测试环节开始前先恢复到一个确定的初始状态比如清理测试数据、关闭干扰应用、重置 Wi-Fi 列表。9.3 日志要留存但要有结构很多产线测试程序只输出一个PASS或FAIL出了问题之后什么线索都没有。更好的做法是把关键操作和关键参数记录下来并输出为结构化字段。比如 Wi-Fi 测试失败时除了保存“Wi-Fi FAIL”之外还要保存当时的 SSID、BSSID、RSSI、信道、连接耗时。这些信息在排障时可以大大缩小问题范围。9.4 最小权限与安全边界产线工控机的权限管理也需要注意。测试脚本应该使用专用的服务账号运行不要使用 root 账号跑日常测试MES API 的密钥要保存在独立的配置文件中不能硬编码在脚本里固件包从服务器拉取时要校验哈希值防止文件在传输过程中损坏或被替换。工厂环境虽然不像互联网环境那样面临强烈攻击但内部数据的安全边界依然需要守好。9.5 后续方向从“测出来”到“管起来”机顶盒产线测试的未来方向不是加更多的测试项而是把测试数据和制造数据打通。当测试系统、MES、仓储系统之间形成完整的数据链路之后产线就可以实现更精细的管理比如基于历史通过率动态调整抽检比例、基于原料批次预测潜在风险批次、基于老化数据优化测试策略。对于正在搭建产线测试体系的团队建议分三步走。第一步先把单工站的自动化跑通保证每个测试工站能自动测试、自动记录、自动判定。第二步把测试数据统一收集到 MES 或者一个简单数据库实现单台设备的完整档案。第三步再做批量分析和异常预测这一阶段才有足够的数据支撑。产线工作最大的价值不是简单地“把测试做完”而是让任何一台机器出现问题时都能够在十分钟内定位到它是什么时候生产的、用了哪一批物料、经过了哪些工站、在哪一个环节开始出现异常。把这条链路打通之后机顶盒产线才真正从“经验驱动”走向“数据驱动”。对于个人开发者或者小团队来说这套体系听起来很重但其实可以从最小闭环开始推进。先用一台工控机跑通 ADB 测试把结果写进 SQLite然后逐步增加工站、增加字段、增加分析报表。产线自动化建设的路是一步一步走出来的关键不是一步到位而是每走出来一步都能让下一次遇到问题时轻松一点。 机顶盒产线测试全流程解析：从FCT到老化测试的自动化与数据追溯
机顶盒看起来是个非常成熟的产品很多人觉得产线工作无非就是“组装、测试、包装”三板斧。但真正在工厂待过就会知道产线日常每天面对的不是寂寞而是无穷无尽的变量今天换了一版固件明天 Wi-Fi 模组换了供应商后天有一批 eMMC 的批次不良率突然升高再往后可能只是操作员换了一个人测试良率就掉了两个点。这篇文章不聊怎么开发机顶盒而是站在产线测试与工程的角度讲清楚一台机顶盒从贴片完成到包装出货中间要经历哪些测试环节每个环节容易出什么问题以及产线工程人员怎么把这些问题管起来。核心判断是机顶盒产线真正比拼的不是测试项目多不多而是异常响应速度和数据追溯能力。测试项写得再全如果出了问题无法快速定位到批次、固件版本、工位和操作员产线就永远在救火。因此接下来会从产线流程、测试原理、环境搭建、自动化脚本、数据采集、异常排查和工程管理几个角度展开并给出可复用的脚本与配置示例。1. 机顶盒产线日常到底在解决什么问题一台机顶盒从硬件上看并不复杂主控芯片、DDR、eMMC、Wi-Fi/BT 模组、Tuner、HDMI、电源、遥控接收头再加一个外壳。但从贴片完成到用户可以正常使用中间的测试环节一点都不少。产线日常的本质是在有限的节拍时间内用最可靠的方式验证三件事硬件有没有问题。贴片有没有虚焊、短路DDR 能不能稳定读写射频信号强度是否达标电源纹波是否在允许范围内。软件有没有烧对。固件版本是否正确SN、MAC、HDCP Key 等唯一信息有没有写入写进去之后能不能被正确读取和校验。整机能不能稳定工作。Aging 老化测试中是否出现死机、重启、花屏高温环境下 Wi-Fi 是否掉线遥控器响应是否灵敏。产线日常之所以难不在于某个单项技术有多深而在于它是一个典型的“多变量耦合系统”。固件版本、硬件批次、操作员手法、测试治具状态、环境温湿度任何一个变量变化都可能影响测试结果。更麻烦的是有些问题只在产线上出现离开产线环境就复现不了这时候如果没有完整的日志和数据记录排查会非常被动。这篇文章适合三类读者一是刚接手产线测试工作的嵌入式工程师二是做测试开发、需要编写产线自动化脚本的同学三是负责工厂信息化、需要对接 MES 系统的软件开发人员。读完这篇文章你会对整个机顶盒产线测试链条有一个完整认识并且可以直接参考其中的脚本思路搭建最小可用的产线测试工具。2. 机顶盒产线整体流程拆解机顶盒的生产测试流程一般从 SMT 贴片开始到包装出货结束。不同工厂的组织方式会有差异但核心环节大致可以分为七个阶段。2.1 SMT 贴片与 PCBA 外观检查SMT 贴片完成之后PCBA 先过 AOI 光学检测检查贴片位置、极性、桥连等缺陷。这个环节的效率很高一台 AOI 每小时可以检测几百片板子但它只能发现“看得见”的问题。AOI 之后通常还会安排一次人工目检重点检查连接器、插座、屏蔽罩等 AOI 不容易覆盖的位点。这里容易出现的问题有两个一是 AOI 误判率过高导致频繁停机确认二是漏判率过高导致有缺陷的板子流入后段测试。因此AOI 程序的维护和误判复判流程非常重要。每天开班前用标准板校准一次是最基本的动作。2.2 PCBA 单板测试PCBA 在组装成整机之前通常会先做一次单板测试也叫 FCTFunctional Circuit Test。这个工站主要验证主板供电路径、晶振起振、主控芯片能否正常启动、能否进入升级模式。单板测试的好处是在组装之前就把坏板拦截掉避免把一块坏板装进外壳之后再拆机返修浪费大量工时。FCT 工站一般使用测试治具压合 PCBA 上的测试点通过串口或者 USB 与主板通信。测试内容比较简单重点是“能不能开机”和“能不能烧录”。这个环节如果发现某一块板卡无法进入烧录模式大概率是主控芯片周边电路有问题比如晶振、电源、复位电路。2.3 整机装配单板测试通过之后PCBA 进入整机装配环节装外壳、贴标签、连接天线、装配电源板、安装散热片等。装配环节看似没有技术含量但恰恰是很多“灵异问题”的源头。比如 Wi-Fi 天线端子在装配过程中松脱、散热片压到了某个元器件、外壳卡扣压住了排线这些硬件问题往往要到功能测试甚至老化测试才会暴露出来。因此装配工位通常会有一个简单的外观确认动作并且关键连接器会拍照留档或者由巡检人员定时抽检。如果产线后面批量出现“信号弱”的问题第一步不是怀疑硬件设计方案而是先检查装配工位的操作是否规范。2.4 整机功能测试整机装配完成之后进入产线最核心的工站整机功能测试一般叫做 MMIMan-Machine Interface测试。所有功能都会在这个工站验证一遍包括开机启动是否正常进系统时间是否在允许范围内SN、MAC、HDCP Key 等唯一信息是否正确写入Wi-Fi 信号强度和蓝牙功能是否正常HDMI 输出是否有画面分辨率是否设置正确USB 接口读写是否正常以太网连接是否正常遥控器按键和红外接收是否正常音视频输出是否正常这个工站的节拍时间直接决定了产线的产能。节拍压得越短测试覆盖越容易缩水测试覆盖越全节拍就越难压缩。优秀的产线工程团队会把“必须全检的功能”和“可以抽检的功能”区分开把有限的产线时间花在最关键的验证项上。2.5 烧录与写号烧录和写号在很多工厂是放在功能测试之前的也有放在中间的取决于软件架构和测试流程设计。烧录包括烧写 Bootloader、系统固件、基带固件等写号则包括写入 SN、MAC、HDCP Key、区域配置等信息。这个环节最容易出的问题就是“烧错版本”和“写错号”。烧错版本一般是升级包管理混乱导致的写错号则往往是因为操作员扫码时扫描枪多扫了一位、或者扫码内容与订单不一致而系统没有校验。这两个问题都属于“批量事故”一旦发生轻则返工重烧重则整批流向市场后被发现序列号冲突引发客诉和召回。2.6 老化测试老化测试Aging Test是机顶盒产线里耗时最长的一个环节一般持续 4 到 8 个小时甚至更久。目的是通过长时间通电运行让早期失效的元器件提前暴露。常见的做法是让机顶盒在高温环境下持续播放视频或者循环跑压力测试同时监测是否出现死机、重启、花屏、Wi-Fi 掉线等问题。老化测试的瓶颈在于占地面积大、耗时长、需要占用大量治具和电源。因此产线一般只会对批量订单的代表性样本做全量老化或者对首件、工程变更后的批次做全量老化其余批次按比例抽检。如果老化测试中发现某批次不良率异常偏高就会触发批次隔离和原材料追溯流程。2.7 包装与出货老化测试通过之后机顶盒经过最终外观检查、附件清点、彩盒包装就可以入库出货了。最后一个环节通常还会做一次“出货前快速开机确认”防止在老化之后、包装之前的存放期间出现运输损伤或静电损伤。从这段流程可以看出机顶盒产线其实是一条“层层拦截、逐级确认”的质量链条。每一道工序都在为后一道工序提供输入任何一个环节的错误都可能被放大。因此产线日常的核心工作除了完成当前的测试任务之外更关键的是把每一个环节的数据和异常记录管理起来。3. 机顶盒产线测试的核心原理明白了整体流程之后再深入看每个测试环节背后的原理。这里不会讲到芯片寄存器级别而是从产线工程的角度讲清楚每个测试为什么存在、它检测的是什么类型的缺陷。3.1 单板测试的核心原理单板测试FCT本质上是一个“最小系统验证”。它把 PCBA 当作一个独立的电子系统测试电源、时钟、复位、主控启动链路是否正常。单板测试的关键在于测试治具的设计通过探针压合 PCBA 上的测试点把电源、地、串口、USB 等信号引出来连接到一个测试控制板或者直接连接到工控机。FCT 常见的检测项包括各电压轨是否正常比如 3.3V、1.8V、1.0V晶振是否起振主控能否通过串口输出启动日志能否进入烧录模式单板测试的逻辑很简单如果最小系统都不能正常启动后续所有测试都无从谈起。因此这个工站的通过率一般要求在 99% 以上如果低于这个水平往往意味着 SMT 焊接工艺出现了系统性问题优先查炉温曲线、锡膏质量、贴片压力设置。3.2 功能测试的核心原理功能测试的核心是一个“软硬协同验证”的过程。机顶盒运行测试 APK 或通过 ADB 指令执行测试用例同时测试工装模拟用户操作验证各功能模块是否正常。以 Wi-Fi 测试为例产线通常不测真实吞吐量而是通过读取系统内的 RSSI 值来判断信号强度是否达标。机顶盒连接一个指定的 AP然后读取cmd wifi status或者通过系统 API 获取当前的信号强度。如果 RSSI 低于某个阈值比如 -60dBm就判为失败。这个测试速度快、覆盖率高但它有一个盲区它只能证明 Wi-Fi 模块能够连上 AP不能证明实际吞吐量是否达标。因此有些对无线性能要求高的订单会额外增加一个吞吐量抽检环节使用 iperf 进行实际打流测试。HDMI 测试的原理类似。机顶盒通过 HDMI 连接到一个带 HDMI 输入的监视器或者视频采集卡测试系统播放一段测试画面由采集卡抓取图像并做比对。常见的判断方式有两种一种是做像素比对通过计算图像相似度判断画面是否正常另一种是检测是否有 HDMI 信号输出比如读取显示器或采集卡是否有有效分辨率信息。像素比对更严格但速度更慢信号检测速度快但无法发现花屏、偏色等问题。产线需要根据订单质量要求做取舍。3.3 写号与校验原理SN、MAC 这些唯一信息在产品出厂后承担着追溯、激活、网络鉴权等职责。写号环节最核心的要求就是两点唯一性和一致性。唯一性是指同一个 SN 不能出现两次一致性是指写入的内容必须和订单、标签、包装箱上的内容一致。为了实现这两点产线通常会采用“扫码→比对→写入→回读→校验→上传”的流程。操作员先扫描机顶盒标签上的条码系统根据条码生成或者获取对应的 SN、MAC 信息通过 ADB 或串口写入设备然后回读写入结果并与原始数据比对。比对通过之后这些信息会同步上传到 MES 系统作为后续追溯的依据。这里的关键是“写入后的回读校验”很多早期产线只写不读导致 SN 写入失败但测试仍然判 PASS 的情况直到产品流向市场才被发现。回读校验会额外增加几百毫秒的时间但相比整批返工的代价这点时间非常值得。3.4 老化测试的原理老化测试的本质是“加速失效验证”。电子元器件的失效曲线呈现典型的浴盆形状早期失效率较高随后进入低而平稳的随机失效期最后进入磨损失效期。老化测试的目的就是通过高温、长时间通电、高负载运行把早期失效提前暴露在工厂内而不是等到用户手里再爆发。常见的做法是将机顶盒放置在 45℃ 左右的高温老化房里持续播放本地或者在线视频循环执行重启、待机唤醒、Wi-Fi 重连等操作同时通过串口或网络上报设备状态。老化测试中发现的问题一般集中在散热不良、DDR 兼容性、电源模块在高温下的稳定性、Wi-Fi 在高温下的连接稳定性等。老化测试的价值不能用“检出多少不良”来衡量更准确地说它的价值在于建立信心。一批产品在老化工序中连续运行 8 小时无故障这本身就说明这批产品的早期失效风险比较低。4. 产线测试环境搭建与工具链产线测试环境是一个容易被低估的部分。表面上看测试环境无非就是工控机、测试治具、网络、电源但实际上一个设计良好的产线测试环境可以大幅降低误判率、提升换线效率。4.1 产线网络的规划机顶盒产线测试有一个特点设备数量多、IP 地址变化频繁、安全隔离要求高。每台机顶盒在测试时都需要一个独立的 IP 地址测试完成之后这个 IP 要么释放要么被回收。如果机顶盒的 IP 和产线办公网络的 IP 段冲突或者和 MES 服务器的 IP 冲突排查起来会非常痛苦。一个比较常见的做法是把产线网络划分为三个隔离的网段管理网段用于工控机、测试服务器、MES 客户端之间的通信测试网段用于机顶盒设备接入一般由 DHCP 动态分配地址每台测试治具对应一个独立的网口或 VLAN工厂局域网段用于连接 ERP、MES 数据库、文件服务器等这样做的好处是测试网段的广播风暴不会影响管理网络而且便于做 IP 资源的统筹管理。机顶盒在测试完成后DHCP 租约可以设置得较短比如 5 到 10 分钟这样 IP 资源能够快速回收复用。如果想避免 DHCP 带来的地址管理问题也可以使用 USB 网络共享或者通过 ADB over WiFi 的方式连接设备但这通常只适用于某些特定的测试场景不是主流方式。4.2 测试工控机的软件环境产线测试工控机建议使用 Ubuntu 系统主要原因是 Android 调试工具链ADB、Fastboot在 Linux 环境下运行更稳定而且 Python 脚本生态更丰富。工控机作为产线测试的核心节点软件环境需要尽量精简、稳定。一个典型的工控机环境包括Ubuntu 20.04 或 22.04 LTS 系统Python 3.8使用虚拟环境管理依赖Android Platform Tools包含 adb、fastboot串口调试工具如 minicom、pyserialMES 客户端或者 MES API 调用脚本安装好系统之后建议将测试脚本统一放在/opt/line_test/目录下按照工站进行子目录划分避免不同脚本之间互相依赖。测试记录和日志统一输出到/var/log/line_test/方便集中收集和排查。# 安装 Python 虚拟环境和依赖 sudo apt update sudo apt install -y python3 python3-venv python3-pip # 创建测试项目目录 mkdir -p /opt/line_test/{fct,mmi,aging,report} cd /opt/line_test python3 -m venv venv source venv/bin/activate # 安装 pyserial 和 requests pip install pyserial requests # 确认 adb 版本 adb version这里有一点需要注意产线工控机不建议频繁升级系统和工具链因为每次升级都可能引入兼容性问题。正确的做法是先在实验室环境验证好版本组合再批量同步到产线工控机。版本升级要像固件发布一样走测试、灰度、全量的流程。4.3 测试治具的准备测试治具是连接工控机和被测设备的桥梁。机顶盒整机测试一般通过 USB 线连接工控机和机顶盒的 USB 口使用 ADB 通信PCBA 单板测试则通过治具上的探针和排线连接串口。治具的维护和保养是一个容易被忽视但影响很大的细节。USB 线在反复插拔之后接触不良探针在长期压合之后弹性下降这些都会导致测试结果不稳定。因此产线需要为每个测试工位制定一个“治具点检表”每天开班前检查线材、探针、电源、网络连接每周进行一次深度清洁和阻抗检查。治具的防呆设计也很重要。比如 USB 方向插反会导致通信失败治具上要设计防反插结构批头、探针要设计成快拆结构方便操作员在出现问题时快速更换而不是拿着烙铁在现场焊接。4.4 测试固件与升级包的版本管理产线最容易出的问题之一就是测试固件版本和订单不一致。很多工厂还在用共享文件夹的方式管理固件文件名上加上日期和版本号操作员手动拷贝到工控机。这种方式在订单少的时候勉强可用一旦多个订单并行就很容易出现操作员拿错固件包、烧错版本的情况。更稳妥的方式是搭建一个简单的固件管理服务可以是 MES 系统的一个模块也可以是一个独立的版本管理工具。固件包统一存放在服务器上工位机通过订单号或者产品型号自动拉取对应的固件包拉取之后计算 MD5 校验值确保固件包完整。产线工控机上不保留历史版本固件只保留当前订单对应的固件。如果你所在工厂还没有上 MES也可以先用 Git LFS 配合一个简单的 Python 脚本来管理固件版本。核心思路是固件文件走版本管理工位机通过脚本拉取记录拉取日志。5. 关键测试项与判定标准不同客户的机顶盒测试要求会有差异但核心测试项基本一致。下面以比较典型的整机功能测试为例整理一个测试项与判定标准参考。实际执行时标准需要根据产品规格书和客户要求进行细化。测试工站测试项目判定标准参考失败处理FCT电源电压3.3V/1.8V/1.0V ± 5%检查电源电路与焊接FCT晶振起振频率偏差在规格允许范围内更换晶振或检查负载电容FCT串口输出能正常输出启动日志检查主控最小系统烧录固件版本与订单要求完全一致重新烧录并核对升级包写号SN 写入与回读回读值和目标值一致检查写入工具与标签写号MAC 写入与回读回读值和目标值一致检查写入工具与标签MMI开机时间从上电到进桌面不超过设定值检查系统启动项与 eMMC 速率MMIWi-Fi 信号强度RSSI 大于等于 -60dBm检查天线连接与射频匹配MMI蓝牙扫描能扫描到指定蓝牙设备检查蓝牙天线与屏蔽MMIHDMI 输出能检测到有效分辨率信号检查 HDMI 座子与外围电路MMIUSB 读写U 盘读写正常检查 USB 数据线对与供电MMI以太网连接DHCP 获取 IP 且 ping 通网关检查网口变压器与连接器MMI遥控接收按键响应正常检查红外接收头与遥控器Aging长时间运行无死机、重启、花屏定位失效元件批次隔离Aging高温 Wi-Fi持续连接不断线检查散热与射频高温特性这些测试项中有些适合全检有些适合抽检。比如 USB 读写在硬件设计稳定的情况下产线做全检的边际收益很低反而拖慢节拍。一般建议新导入的机型做全量全检量产稳定后对非关键项改为抽检把时间留给真正容易出问题的环节。6. 自动化脚本与代码实现产线测试自动化是一个很大的话题这里从实际情况出发给出几个可以直接参考的脚本示例。这些脚本解决的场景包括SN 读取校验、MMI 测试主流程、MES 数据上报。实际产线脚本会比这复杂得多但这些示例可以帮助你快速理解产线自动化的基本模式。6.1 通过串口读取并校验 SNPCBA 单板测试阶段设备还没有完全启动 Android 系统无法使用 ADB 通信只能通过串口访问。此时可以用 pyserial 读取设备输出的信息并对 SN 等关键信息做校验。# 文件路径/opt/line_test/fct/read_sn.py import re import serial import serial.tools.list_ports def find_device_port(): 自动查找测试治具对应的串口号 ports serial.tools.list_ports.comports() for port in ports: # 这里以 USB 转串口的 VID/PID 作为识别依据 # 实际产线中建议使用 port.serial_number 做更严格的判断 if USB in port.description or UART in port.description: return port.device raise RuntimeError(未找到串口设备) def read_sn_from_device(port: str, timeout: int 10) - str: 从设备串口读取 SN 信息 pattern re.compile(rSN[:]\s*([A-Za-z0-9\-_])) with serial.Serial(port, 115200, timeout1) as ser: buf b end_time time.time() timeout while time.time() end_time: data ser.read(64) if not data: continue buf data text buf.decode(utf-8, errorsignore) match pattern.search(text) if match: return match.group(1) raise RuntimeError(读取 SN 超时) def check_sn_format(sn: str) - bool: 校验 SN 格式具体规则由产品定义 if re.fullmatch(r[A-Z0-9]{8,16}, sn): return True return False if __name__ __main__: port_name find_device_port() sn_value read_sn_from_device(port_name) if check_sn_format(sn_value): print(fSN 读取成功: {sn_value}) else: print(fSN 格式异常: {sn_value}) raise SystemExit(1)这段代码的思路是先自动识别串口设备然后持续读取串口数据通过正则表达式匹配 SN 字段读取后做格式校验。实际产线中SN 格式规则一般由产品定义比如前几位是产品代码、中间是生产日期、后面是流水号。还可以在读取 SN 之后调用 MES 接口比对 SN 是否在订单范围内防止混料。6.2 MMI 测试主流程脚本整机功能测试阶段设备已经启动了 Android 系统可以通过 ADB 执行测试操作。下面的脚本演示了 MMI 测试的主流程框架开机确认、检查固件版本、读取 SN、执行指定测试动作、把结果写入本地报告。#!/bin/bash # 文件路径/opt/line_test/mmi/mmi_test.sh # 用法bash mmi_test.sh 设备序列号 set -e DEVICE_SN$1 if [ -z $DEVICE_SN ]; then echo 请传入设备序列号 exit 1 fi # 第一步确认 ADB 设备已连接 adb devices | grep -w $DEVICE_SN /dev/null || { echo 设备不在线: $DEVICE_SN exit 1 } # 第二步获取设备型号和固件版本 MODEL$(adb -s $DEVICE_SN shell getprop ro.product.model | tr -d \r) FW_VERSION$(adb -s $DEVICE_SN shell getprop ro.build.version.release | tr -d \r) echo 设备型号: $MODEL, 系统版本: $FW_VERSION # 第三步检查设备是否有开机动画/桌面异常 BOOT_COMPLETED$(adb -s $DEVICE_SN shell getprop sys.boot_completed | tr -d \r) if [ $BOOT_COMPLETED ! 1 ]; then echo 设备未完成开机 exit 1 fi # 第四步读取 SN 并与传入参数比对 DEVICE_SN_VALUE$(adb -s $DEVICE_SN shell getprop ro.serialno | tr -d \r) if [ $DEVICE_SN_VALUE ! $DEVICE_SN ]; then echo SN 不匹配: 期望$DEVICE_SN, 实际$DEVICE_SN_VALUE exit 1 fi # 第五步占位这里可以扩展为执行具体测试 # 例如adb shell am instrument -w com.test.mmi/androidx.test.runner.AndroidJUnitRunner echo MMI 基础检查 PASS这段 Shell 脚本虽然简单但体现了产线测试脚本的通用结构设备在线检查、静态信息读取、关键字段比对、测试执行、结果输出。脚本中的sys.boot_completed是判断 Android 是否完成开机的一个常用属性在产线测试中很有用。实际产线的 MMI 测试不会只在命令行里检查属性而是会启动一个专门的测试 APK由 APK 内部调用系统接口执行 Wi-Fi、蓝牙、HDMI、USB 等测试并通过广播或者文件方式把结果返回给测试脚本。APK 测试的好处是可读性强、扩展性好而且可以对每一个测试项输出详细的日志。6.3 测试结果上报 MES产线测试的最终目的是把数据汇集到 MES 系统形成单台设备的完整测试档案。下面给出一个简单的 Python 上报脚本把测试结果以 JSON 格式提交到 MES API。# 文件路径/opt/line_test/report/upload_result.py import json import time import requests MES_API_URL http://mes-server.example.com:8080/api/v1/line-test/report TOKEN generate-yours-by-mes-login def build_report(device_sn: str, station: str, result: str, items: list, logs: str) - dict: 构造测试报告数据 return { deviceSn: device_sn, station: station, result: result, testTime: time.strftime(%Y-%m-%d %H:%M:%S), items: items, logs: logs[:2000], # 日志过长时截断 } def upload_report(report: dict) - bool: 上报 MES 系统 headers { Content-Type: application/json, Authorization: fBearer {TOKEN}, } try: resp requests.post(MES_API_URL, jsonreport, headersheaders, timeout5) if resp.status_code 200: return True # 这里可以增加重试机制 print(f上报失败: {resp.status_code}, body{resp.text}) return False except requests.exceptions.RequestException as exc: print(f上报异常: {exc}) return False if __name__ __main__: sample_items [ {name: power_on, result: PASS, detail: boot time: 23s}, {name: wifi_rssi, result: PASS, detail: -45dBm}, {name: sn_check, result: PASS, detail: sn match}, ] sample_report build_report( device_snSN20250101001, stationMMI-01, resultPASS, itemssample_items, logssample test log, ) ok upload_report(sample_report) print(上报成功 if ok else 上报失败)上报逻辑的要点在于数据要结构化、结果要可追溯、失败要有重试机制。上面这个示例中的TOKEN需要在真实环境中通过登录接口获取生产环境建议使用服务账号而不是个人账号同时控制权限范围。另外上报失败一定不能静默忽略要把失败记录写入本地待补传队列等网络恢复后重新上报。7. 产线数据采集与追溯体系测试做完只是第一步把测试过程中产生的数据管理起来才是产线工程的核心工作。每一台机顶盒都应该有完整的“出生档案”包括测试结果、关键参数、操作员、工位、时间、所用固件版本等信息。这样当市场端出现批量质量问题时仓库可以根据 SN 反查这批货是哪一天、哪条线、哪一批物料生产的。7.1 单台设备档案单台设备档案最简单的实现方式就是 MES 系统里的一张宽表每条记录对应一台设备。记录的核心字段包括设备 SN、MAC、Wi-Fi MAC、蓝牙 MAC产品型号、硬件版本、软件版本各工站的测试结果、测试时间、操作员工号、工位编号关键测试参数比如 RSSI 值、吞吐量、供电电压原料批次信息包括主控批次、DDR 批次、eMMC 批次、Wi-Fi 模组批次这些字段不需要全部手工录入而应该通过测试脚本自动采集。人一多、环节一长手工录入的错误率会非常高。7.2 批量数据分析建立档案之后还需要建立批量分析的习惯。很多质量问题不是靠单台测试发现的而是靠统计发现的。比如某一天的 Wi-Fi 测试通过率从 99% 下降到 95%单独看每一台都定位不到什么问题但是按批次、按时间段、按工位、按操作员维度聚合之后问题往往就浮出水面了。一个务实的做法是每周拉取一次 MES 测试数据按测试项统计通过率按工位统计一次通过率按操作员统计操作耗时和误判率。如果某个工位的通过率明显低于其他工位优先排查治具问题而不是设备问题这是产线排障中非常有效的一个经验法则。8. 常见问题与排查方法产线运行过程中会遇到各种问题下面整理几个最常见的问题现象、可能原因和排查思路。问题现象可能原因排查方式解决方案设备无法进入烧录模式主控最小系统异常查看串口日志确认供电、时钟、复位检查 PCBA 焊接特别是电源和晶振ADB 设备列表看不到设备USB 线接触不良或驱动异常更换 USB 线检查设备管理器更换线材重新安装驱动SN 写入后回读不一致写入工具读取分区错误查看写入日志确认分区挂载更新写入工具检查镜像分区表Wi-Fi 测试 RSSI 偏低天线未装配到位或模组批次异常拆机检查天线连接抓取射频日志重新装配反馈模组供应商老化测试死机高温下供电不稳或 DDR 兼容问题查看内核日志与温度日志改善散热调整 DDR 参数测试脚本偶发超时网络抖动或 USB 通信不稳定查看 ping 丢包率更换 USB 口优化网络使用独立 USB 控制器某工位通过率明显偏低治具老化或操作手法差异与相邻工位对比检查治具清洁或更换治具加强培训MES 上报失败接口异常或网络隔离检查 MES 服务状态和网络策略增加重试队列联系 MES 管理员从这些常见问题可以看出产线问题的排查思路往往是“先环境后设备、先批次后单台、先治具后主板”。如果一上来就怀疑主控芯片方向很容易跑偏。9. 产线工程最佳实践与后续方向最后把这些年产线工程中比较有价值的经验整理成几条通用的实践建议。这些建议不仅适用于机顶盒也适用于其他智能硬件产品的产线测试。9.1 自动化防呆优先于事后检查产线测试的核心原则是“不要让流程依赖人的自觉”。操作员每天重复成百上千次动作总会有疲劳的时候。所以凡是能够用系统校验的就不要让人工判断。比如固件版本选择不应该让操作员手动选文件而应该扫码之后自动匹配SN 校验也不应该依赖人眼比对而应该由系统自动读取、自动比对。9.2 脚本幂等与异常恢复产线脚本必须做成幂等的也就是同一台设备重复执行测试脚本结果应该一致且不会产生副作用。原因是产线测试经常遇到中途异常、重启测试、返工重测的情况。如果脚本逻辑假设“设备处于全新状态”第二次运行就可能失败。正确的做法是在每个测试环节开始前先恢复到一个确定的初始状态比如清理测试数据、关闭干扰应用、重置 Wi-Fi 列表。9.3 日志要留存但要有结构很多产线测试程序只输出一个PASS或FAIL出了问题之后什么线索都没有。更好的做法是把关键操作和关键参数记录下来并输出为结构化字段。比如 Wi-Fi 测试失败时除了保存“Wi-Fi FAIL”之外还要保存当时的 SSID、BSSID、RSSI、信道、连接耗时。这些信息在排障时可以大大缩小问题范围。9.4 最小权限与安全边界产线工控机的权限管理也需要注意。测试脚本应该使用专用的服务账号运行不要使用 root 账号跑日常测试MES API 的密钥要保存在独立的配置文件中不能硬编码在脚本里固件包从服务器拉取时要校验哈希值防止文件在传输过程中损坏或被替换。工厂环境虽然不像互联网环境那样面临强烈攻击但内部数据的安全边界依然需要守好。9.5 后续方向从“测出来”到“管起来”机顶盒产线测试的未来方向不是加更多的测试项而是把测试数据和制造数据打通。当测试系统、MES、仓储系统之间形成完整的数据链路之后产线就可以实现更精细的管理比如基于历史通过率动态调整抽检比例、基于原料批次预测潜在风险批次、基于老化数据优化测试策略。对于正在搭建产线测试体系的团队建议分三步走。第一步先把单工站的自动化跑通保证每个测试工站能自动测试、自动记录、自动判定。第二步把测试数据统一收集到 MES 或者一个简单数据库实现单台设备的完整档案。第三步再做批量分析和异常预测这一阶段才有足够的数据支撑。产线工作最大的价值不是简单地“把测试做完”而是让任何一台机器出现问题时都能够在十分钟内定位到它是什么时候生产的、用了哪一批物料、经过了哪些工站、在哪一个环节开始出现异常。把这条链路打通之后机顶盒产线才真正从“经验驱动”走向“数据驱动”。对于个人开发者或者小团队来说这套体系听起来很重但其实可以从最小闭环开始推进。先用一台工控机跑通 ADB 测试把结果写进 SQLite然后逐步增加工站、增加字段、增加分析报表。产线自动化建设的路是一步一步走出来的关键不是一步到位而是每走出来一步都能让下一次遇到问题时轻松一点。