48项全功能测试清单：从协议回环到异常边界

一句话: 按功能块组织的48项测试清单——协议回环、ADC映射、定标序列、温度控制、Flash参数、异常边界。用脚本自动发指令、解析返回、对比预期，配合命令行编译和自动烧录，整个验证闭环无人值守，上板测试从半天压缩到几分钟。

适合谁读：想系统化测试固件、把上板验证变自动化的嵌入式工程师。

按功能块组织，一个闭环测透再测下一个

测试清单按功能块划分，每块一个闭环：

组织原则：一块测透再测下一块。协议回环过了，ADC 映射才可信；映射过了，定标才有意义。每块内部，先正常路径后边界。

边界值才是重点

正常路径跑通只能证明"功能在"，边界值才是 bug 藏身的地方：

• 设定值：上限、下限、上限+1、下限-1
• 帧长度：最短帧、最长帧、超长帧
• 标志位：每个合法值 + 非法值
• 异常输入：坏帧、半帧、快速连发、命令间无间隔

每条命令都测"越界"和"边界"，这是 48 项里最容易漏、最值得加的部分。

自动化：三条腿

1. 串口自动测试

PowerShell/Python 直连串口，自动发指令、解析返回、对比预期：

def test_protocol_loopback():
    for cmd, wr, data, expect in CASES:   # 用例表驱动
        r = send_frame(cmd, wr, data)
        assert r == expect, f"cmd {cmd} 失败: {r}"

协议层测试全自动化，用例就是一张表，加用例不加代码。

2. 命令行编译

UV4.exe -b project.uvprojx -j0 -o build.log
[ $? -eq 0 ] || exit 1   # 编译不过直接失败

编译结果变成脚本断言，不靠人盯窗口。

3. 自动烧录

J-Link 脚本 + 命令行参数自动连接，烧录动作脚本化：

loadfile "build/firmware.hex"
r
g
qc

整个闭环无人值守：编译 → 烧录 → 跑 48 项 → 出报告。改一行代码，一条命令，全量回归。

提速：等待阶段只轮询最小命令集

闭环跑起来后发现：12 个测试项要 713 秒（快 12 分钟）。慢在哪？看"等待稳定"的部分——每 100ms 轮询一次，但每次轮询都发好几条命令：查状态、查参数、查读数、查配置，每一条都等设备回。

# 优化前：每次轮询发 4 条命令
while True:
    st = cmd(读状态)
    p = cmd(读功率)
    v = cmd(读电压)
    cfg = cmd(读配置)
    if st == 稳定: break
    sleep(0.1)

# 优化后：每次轮询只发 1 条
while True:
    st = cmd(读状态)
    if st == 稳定: break
    sleep(0.1)

状态命令里已经包含"现在到哪一步"的信息，稳定之后再做详细检查。等待阶段根本不需要那些细节数据：

同样的覆盖，9 倍提速。等待阶段发 4 条命令拿到的细节，稳定前根本用不上。这条也适用于人肉调试：等设备稳定时，别反复发各种命令——一条状态命令盯到稳定，再看细节。

顺手还能做：轮询间隔从 0.5s 减到 0.1s（稳定判定不受影响），测试间复用串口连接（别每个测试项重新开）。

效果

测试清单的"可回归"价值：固件每改一次，全量跑一遍。以前"改一个参数不敢动，怕影响别的"的顾虑消失——改完跑一遍就知道。

经验

1. 测试清单按功能块组织——一个闭环测透再测下一个，依赖关系清楚
2. 边界值（上限/下限/越界）是重点——正常路径跑通 ≠ 功能可用
3. 自动化把"上板测试"从半天压缩到几分钟——编译、烧录、测试三件事都脚本化，闭环才真正成立

实测对比：手动上板测试：半天测不完，边界值常漏 | 自动化清单：48项几分钟跑完，可回归

有用的话点个收藏，下次调试直接用。有问题欢迎评论区交流，看到了都会回。

下一篇：一次全量测试排掉三个bug？嵌入式调试的三条方法论——分层排查、边界测试、测试清单驱动