第二章 测试环境搭建：硬件测试台架、软件工具链、ADB与串口调试
做座舱系统稳定性测试，环境搭建是第一步，也是最容易踩坑的一步。我见过不少团队，测试方案写得天花乱坠，结果一上电就各种翻车——说白了，就是台架没搭好，工具链没配通。今天咱们就聊聊这块，我把这些年摸爬滚打的经验都掏出来。
2.1 硬件测试台架
硬件台架，说白了就是给MTK8678芯片搭个「家」。这个家要稳，要能模拟真车环境。我个人习惯把台架分成三个层级：
- 核心板层：MTK8678核心板，带DDR和存储
- 接口板层：引出所有外设接口，包括CAN、以太网、USB、HDMI等
- 负载模拟层：模拟屏幕、摄像头、麦克风等外设
嗯，这里要注意一个细节——供电。座舱系统对电源纹波很敏感，我遇到过好几次测试过程中系统莫名重启，查了半天发现是电源适配器质量不行。建议用可编程电源，设置12V/5A输出，纹波控制在50mV以内。
台架搭建清单（我常用的配置）：
- MTK8678开发板（带散热模组）
- 12V/5A可编程直流电源
- USB转CAN模块（PCAN或Kvaser）
- HDMI采集卡（用于录制屏幕）
- 串口转USB线（FT232芯片，稳定）
- 千兆交换机（用于以太网通信）
你想想看，如果台架供电不稳，测出来的稳定性数据能信吗？所以这块千万别省。
2.2 软件工具链
软件工具链，就是咱们测试人员的「武器库」。MTK8678的软件栈比较重，我一般会装这几样：
| 工具名称 | 用途 | 版本建议 |
|---|---|---|
| ADB | Android调试桥，控制设备 | ≥ 1.0.41 |
| Fastboot | 刷机、分区操作 | 最新版 |
| 串口终端（Putty/MobaXterm） | 内核日志、低层调试 | 任意 |
| Python 3.8+ | 自动化脚本编写 | ≥ 3.8 |
| Scrcpy | 屏幕投屏、录制 | ≥ 1.24 |
这里我特别想提一下Scrcpy。以前做稳定性测试，我得一直盯着屏幕看，眼睛都快瞎了。后来发现Scrcpy可以投屏到电脑上，还能自动录制，配合Python脚本做图像识别，简直不要太爽。
我的小技巧：把ADB和Scrcpy的路径加到系统环境变量里。这样在命令行里直接敲命令，不用每次cd到工具目录。省下的时间够你喝杯咖啡了。
2.3 ADB调试
ADB是Android调试的「瑞士军刀」。对于MTK8678座舱系统，我常用的ADB命令就这几条：
# 查看设备连接状态
adb devices
# 进入shell
adb shell
# 抓取logcat日志（稳定性测试必备）
adb logcat -v time > crash_log.txt
# 查看CPU占用率
adb shell top -n 1
# 查看内存使用
adb shell dumpsys meminfo
# 模拟按键（比如Home键）
adb shell input keyevent KEYCODE_HOME
# 截图
adb shell screencap /sdcard/screenshot.png
adb pull /sdcard/screenshot.png为什么会强调adb logcat -v time？因为稳定性测试最怕的就是不知道问题什么时候发生。加上时间戳，你才能定位到具体的时间点。我曾经排查一个内存泄漏问题，就是靠logcat里的时间戳，发现每次播放视频30分钟后内存暴涨——嗯，这就是线索。
注意：ADB连接有时会掉线，尤其是长时间跑稳定性测试时。建议写个心跳检测脚本，每隔30秒检查一次adb devices状态，如果断开就自动重连。别问我怎么知道的——有一次跑了12小时的测试，第11小时ADB断了，前功尽弃。
2.4 串口调试
串口调试，是咱们嵌入式工程师的「最后一道防线」。当系统死机、ADB连不上时，串口就是唯一的救命稻草。MTK8678的串口一般映射到UART0，波特率通常是115200。
接线其实很简单：
- 开发板的TX接串口工具的RX
- 开发板的RX接串口工具的TX
- GND接GND
嗯，这里有个坑——电平匹配。MTK8678的串口是1.8V电平，而很多USB转串口模块是3.3V或5V的。直接接上去可能会烧芯片。我建议用带电平转换的模块，或者直接用MTK官方的调试板。
串口终端设置示例（以Putty为例）：
Session:
Serial line: COM3 (根据实际端口修改)
Speed: 115200
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None连上串口后，你会看到内核启动日志。从uboot到kernel，再到Android系统启动，每一步都有输出。如果系统卡在某个阶段，串口日志会告诉你原因。比如：
[ 1.234567] mmc0: error -110 whilst initialising SD card
[ 1.240123] mmc0: card never left busy state看到这种日志，基本可以断定是eMMC通信有问题。要么是焊接不良，要么是供电不稳。我曾经排查过一个「开机偶尔黑屏」的问题，就是靠串口日志发现是DDR初始化时序不对——说白了，就是PCB走线太长，信号质量差了。
串口调试的黄金法则：
- 开机时按住空格键，可以进入uboot命令行
- 内核启动阶段按任意键，可以进入内核调试模式
- Android启动后，串口输出的是kernel log，不是logcat
- 如果串口没输出，先检查接线，再检查波特率
2.5 环境验证
台架搭好了，工具链装好了，怎么知道环境是不是OK？我一般会跑一个「冒烟测试」：
- 上电，看串口能否正常输出内核日志
- 等待系统启动完成，用ADB连接
- 执行
adb shell dumpsys battery，确认电池状态正常 - 播放一段视频，看屏幕显示是否正常
- 用Scrcpy投屏，确认画面流畅
- 跑一个简单的压力脚本（比如循环打开关闭App）
如果以上六步都通过，恭喜你，环境搭建完成。可以开始正式的稳定性测试了。
我的习惯：每次搭建完环境，我都会把串口日志和ADB连接状态截图保存。这样万一后续出问题，可以对比「正常状态」和「异常状态」的差异。你想想看，没有基线数据，你怎么判断问题是新出现的还是本来就有的？
好了，环境搭建这块就聊到这儿。下一章咱们聊聊具体的稳定性测试用例设计——那才是真正考验功力的地方。