2、测试环境搭建：嵌入式测试工具链（JTAG、串口、逻辑分析仪）、版本管理（Git）、缺陷管理（Jira）
好，咱们直接进入正题。测试环境搭建这件事，说简单也简单，说复杂能让你折腾一整天。我在扫地机项目里踩过的坑，有一半都跟环境没搭好有关。你想想看，代码写好了，烧录进去发现跑不起来，结果查了半天是JTAG线松了——这种低级错误，我犯过不止一次。
所以这一章，我把嵌入式测试最核心的三块工具链给你捋清楚：硬件调试工具（JTAG、串口、逻辑分析仪）、版本管理（Git）、缺陷管理（Jira）。这三样东西，是咱们嵌入式测试工程师的吃饭家伙。
2.1 硬件调试工具链：JTAG、串口、逻辑分析仪
嵌入式测试跟纯软件测试最大的区别在哪？你得跟硬件打交道。代码跑在芯片上，出了问题，你不能光靠printf看日志——有时候芯片压根没跑起来，你printf给谁看？
2.1.1 JTAG：调试的“生命线”
JTAG，说白了就是用来控制芯片的。你可以通过它单步执行代码、看寄存器值、烧录固件。我个人习惯，拿到一块新板子，第一件事就是确认JTAG能不能连上。
JTAG连接检查清单：
- 确认调试器驱动已安装（J-Link、ST-Link、OpenOCD等）
- 检查接线：TMS、TCK、TDI、TDO、GND，一根都不能少
- 目标板供电是否正常？JTAG本身不供电
- 芯片是否被锁定？有些芯片有读保护，需要先解锁
我在项目中遇到过一件事：新来的同事折腾了一上午连不上JTAG，最后发现是调试器的USB线质量太差，供电不稳。嗯，这种问题你排查的时候往往想不到。
常用的JTAG调试命令（以OpenOCD为例）：
# 启动OpenOCD，连接目标板
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg
# 在OpenOCD终端中，检查芯片ID
> halt
> flash banks
> mdw 0x08000000 10 # 读取Flash前10个字小技巧：如果你用J-Link，可以用J-Link Commander先测试连接。输入"connect"后选择芯片型号，能连上再进IDE调试，省得在IDE里干着急。
2.1.2 串口：最朴素的“眼睛”
串口调试，是嵌入式开发里最基础也最实用的手段。没有显示屏？没关系，串口就是你的屏幕。我在扫地机项目里，几乎所有模块的调试信息都是通过串口打印出来的。
串口配置其实很简单，但有几个坑要注意：
- 波特率要一致：发送端和接收端必须设置相同的波特率。我见过有人用115200发，用9600收，结果全是乱码。
- 电平匹配：MCU通常是3.3V，但有些USB转串口模块是5V的。直接接可能会烧引脚。我曾经烧过一块板子，就是因为没注意电平转换。
- 接地要共地：串口通信的GND必须连在一起，否则信号参考点不同，数据会出错。
常用的串口工具：
| 工具名称 | 适用平台 | 特点 |
|---|---|---|
| PuTTY | Windows | 轻量、稳定，支持串口和SSH |
| MobaXterm | Windows | 功能丰富，支持多标签、日志记录 |
| screen | Linux/macOS | 命令行工具，适合脚本化操作 |
| minicom | Linux | 老牌工具，配置稍复杂但功能强大 |
举个例子，用screen连接串口：
# 查看串口设备
ls /dev/ttyUSB*
# 连接串口，波特率115200
screen /dev/ttyUSB0 115200
# 退出：Ctrl+A，然后按K注意：串口打印会占用CPU时间。在实时性要求高的场景（比如电机控制），别在中断里加printf。我见过有人把printf放在定时器中断里，结果系统直接卡死——因为printf太慢了。
2.1.3 逻辑分析仪：抓“看不见的信号”
有些问题，靠串口日志根本查不出来。比如I2C通信偶尔丢包、SPI时序不对、PWM波形异常。这时候就需要逻辑分析仪上场了。
逻辑分析仪说白了就是“数字示波器”，但它更擅长抓数字信号。我常用的逻辑分析仪有两种：
- Saleae Logic：USB接口，软件界面友好，采样率最高100MHz，适合日常调试
- DSLogic：国产替代方案，性价比高，采样率也能到400MHz
用逻辑分析仪抓I2C信号的步骤：
- 将通道0接SCL，通道1接SDA，GND共地
- 设置采样率：至少4倍于信号频率（比如I2C是400kHz，采样率设2MHz以上）
- 设置触发条件：比如SCL下降沿触发
- 开始采集，然后让设备执行I2C通信
- 分析波形：检查起始条件、地址、数据、应答位
避坑指南：我曾经调试一个扫地机的激光雷达，I2C通信总是随机失败。用逻辑分析仪抓了一整天，才发现是SCL线上有个毛刺，导致从机误判了时钟周期。加了个10pF的滤波电容就解决了。这种问题，你不看波形根本想不到。
2.2 版本管理：Git
嵌入式项目跟纯软件项目不一样，代码、配置文件、硬件描述文件、测试脚本混在一起。没有版本管理，你根本不知道哪个版本是能跑的。
我个人习惯，每个嵌入式项目都按这个结构组织：
project/
├── firmware/ # 固件源码
├── hardware/ # 原理图、PCB文件
├── tests/ # 测试脚本、测试用例
├── docs/ # 文档
├── tools/ # 调试工具、烧录脚本
└── README.mdGit的基本操作我就不啰嗦了，说几个嵌入式项目里特别要注意的点：
- .gitignore要写好：编译生成的.o、.hex、.bin文件不要提交。还有IDE的配置文件（比如.idea、.vscode）也建议忽略。
- 提交信息要规范：我推荐用"类型: 描述"的格式，比如"fix: 修复I2C超时导致激光雷达数据丢失"。
- 标签管理：每个发布版本打一个tag，比如v1.0.0、v1.1.0。这样出问题能快速回退。
小技巧：用Git的pre-commit钩子，自动检查代码风格和编译错误。我写过一个小脚本，每次提交前自动编译固件，编译不过就不让提交。这招帮我省了不少事。
2.3 缺陷管理：Jira
测试过程中发现的bug，不能靠口头传达或者记在本子上。你得有个系统来跟踪。Jira是目前最主流的缺陷管理工具，没有之一。
在扫地机项目里，我一般这样用Jira：
- 创建缺陷：标题要清晰，比如“扫地机在瓷砖地面打滑，无法正常回充”
- 描述要详细：包括测试环境（固件版本、硬件版本）、复现步骤、预期结果、实际结果
- 附件要全：日志文件、截图、甚至视频。我习惯把串口日志和逻辑分析仪波形一起附上
- 优先级要合理：P0是阻塞性问题（比如无法开机），P1是严重问题（比如回充失败），P2是一般问题（比如UI显示异常）
避坑指南：我曾经遇到一个bug，开发说“我这边复现不了”，然后就把bug关了。后来我附上了完整的串口日志和逻辑分析仪波形，他才承认是硬件问题。所以，缺陷描述一定要有证据，别光靠文字描述。
Jira的工作流一般是：
- 新建：测试人员提交bug
- 待确认：开发确认是否有效
- 处理中：开发开始修复
- 已修复：开发提交修复代码
- 待验证：测试人员验证修复是否有效
- 已关闭：验证通过，bug关闭
这个流程看起来简单，但实际执行中容易出问题。比如开发修完bug不通知测试，或者测试验证不充分就关闭。我建议每周开一次bug评审会，把积压的bug过一遍。
注意：Jira不是万能的。工具只是辅助，关键是团队要有规范的流程。我见过有人把Jira当记事本用，bug描述就写“有问题”，然后让开发自己去猜。这种习惯要不得。
好了，这一章的内容就这些。工具链搭好了，后面的事情才能顺利推进。下一章咱们聊聊测试用例的设计，那才是真正考验功力的地方。