3. 接口类型分析：函数接口、消息队列接口、共享内存接口、网络协议接口
接口测试，说白了就是检查两个模块之间能不能好好说话。我在嵌入式这行干了十几年，见过太多系统崩溃、数据错乱、莫名其妙死机的问题，追根溯源，八成都是接口没处理好。
嵌入式系统里的接口类型五花八门，但归纳起来，最常见的就是这四类：函数接口、消息队列接口、共享内存接口、网络协议接口。每种接口的测试策略、关注点、坑都不一样。咱们一个一个来拆。
3.1 函数接口：最基础也最容易翻车
函数接口是模块间最直接的交互方式。A模块调用B模块的一个函数，传参数，拿返回值。听起来简单吧？但恰恰是这种“简单”最容易让人放松警惕。
测试函数接口，我一般盯着三个点：
- 参数边界：指针是不是NULL？长度是不是0？缓冲区够不够大？
- 返回值检查：调用方有没有检查返回值？很多bug就是“返回值丢了”造成的。
- 重入与并发：函数能不能被中断打断？会不会被两个任务同时调用？
核心原则：函数接口测试，本质是契约测试。调用方和被调用方必须对“输入输出”有一致的理解。
举个例子，我之前做过一个车载信息娱乐系统，有个函数叫 SetVolume(int level)。看起来人畜无害吧？结果测试发现，当 level 传 0 时，系统静音没问题；传 255 时，音量最大也没问题。但传 -1 呢？传 256 呢？函数内部没做范围检查，直接写寄存器，结果把功放芯片烧了。
我的习惯：写测试用例时，先列“非法输入清单”。NULL、负数、超大值、空结构体……把这些边界全测一遍，心里才踏实。
3.2 消息队列接口：异步通信的命门
消息队列在RTOS里太常见了。任务A发消息，任务B收消息，中间通过队列解耦。好处是灵活，坏处是——你永远不知道消息什么时候到、会不会丢、会不会乱序。
消息队列接口测试，我重点关注：
- 队列深度与溢出：发消息的速度超过收消息的速度，队列满了怎么办？
- 消息类型与长度：发的是结构体A，收的时候按结构体B解析？数据错位是家常便饭。
- 超时与阻塞：队列空的时候收消息，任务会不会死等？队列满的时候发消息，会不会把系统卡死？
我曾经踩过的坑：一个传感器采集任务，每秒发100条消息给处理任务。处理任务偶尔忙不过来，队列满了之后，发送端直接返回错误，但没做重试。结果数据丢了，系统还浑然不知。后来我加了一条规则：队列满时，发送端必须记录丢包数，并触发告警。
测试消息队列，我建议用“压力注入法”。先让接收任务休眠，然后疯狂发消息，看队列溢出后系统的行为是否符合预期。是丢弃旧消息？还是阻塞发送端？还是直接崩溃？
3.3 共享内存接口：性能之王，调试之痛
共享内存是嵌入式系统里效率最高的通信方式。没有拷贝，没有上下文切换，两个任务直接读写同一块内存。但效率越高，风险越大。
共享内存接口的核心问题只有一个：同步。
两个任务同时写同一块内存，数据就乱了。一个任务在读，另一个任务在写，读到的数据可能是“半成品”。
| 同步机制 | 适用场景 | 测试要点 |
|---|---|---|
| 互斥锁（Mutex） | 多个任务读写同一块数据 | 死锁检测、优先级反转、锁粒度 |
| 信号量（Semaphore） | 生产者-消费者模式 | 信号量泄漏、超时处理 |
| 原子操作 | 简单标志位、计数器 | 是否真正原子、编译器优化影响 |
| 无锁队列（Lock-Free） | 高性能、低延迟场景 | ABA问题、内存序（Memory Order） |
我个人习惯，测试共享内存接口时，会刻意制造“竞争窗口”。比如在写操作中间插入一个延时，让读任务刚好在这个窗口里访问数据。如果数据没被保护，十有八九会读出脏数据。
避坑指南：共享内存的测试，一定要在“多核”或“多任务”的真实环境下跑。单任务单核测不出并发问题。
3.4 网络协议接口：最复杂的接口类型
网络协议接口，比如TCP、UDP、MQTT、HTTP等，是嵌入式系统走向互联的必经之路。但网络通信的变量太多了：丢包、延迟、乱序、重传、带宽波动……
网络协议接口测试，我分三层：
- 协议一致性：报文格式对不对？字段顺序、字节序、校验和是否正确？
- 异常处理：收到非法报文怎么办？连接断开怎么恢复？超时重传机制是否生效？
- 性能与稳定性：高并发下连接数会不会耗尽？长时间运行内存会不会泄漏？
我记得有个项目，设备通过MQTT上报数据。测试时一切正常，但部署到现场后，设备每隔几天就断连一次。查了三天，发现是MQTT的Keep Alive机制没处理好——服务端没及时回复PINGREQ，客户端以为连接断了，但重连逻辑又有bug，导致死循环。
我的建议：网络协议接口测试，一定要引入“故障注入”。用工具模拟丢包、延迟、乱序、带宽限制，看看设备在这种恶劣环境下还能不能正常工作。
3.5 四种接口的对比与选择
你可能会问：这么多接口类型，我该用哪种？其实没有标准答案，得看场景。
| 接口类型 | 通信方式 | 数据量 | 实时性 | 复杂度 | 典型场景 |
|---|---|---|---|---|---|
| 函数接口 | 同步调用 | 小 | 高 | 低 | 模块内部调用、驱动层 |
| 消息队列 | 异步 | 中 | 中 | 中 | 任务间通信、事件通知 |
| 共享内存 | 同步/异步 | 大 | 极高 | 高 | 音视频处理、大数据量传递 |
| 网络协议 | 异步 | 不定 | 低 | 极高 | 设备互联、远程控制 |
嗯，这张表是我自己总结的。你想想看，如果两个任务需要频繁交换大量数据，用消息队列拷贝来拷贝去，性能肯定扛不住。这时候共享内存才是正解。但如果数据量不大，又要求解耦，消息队列就比共享内存安全得多。
3.6 接口类型知识体系总览
下面这张图，把四种接口的核心特征、测试要点、常见陷阱串起来了。建议你保存下来，做接口测试时对照着看。
这张图把四种接口从“核心特征”到“测试要点”再到“常见陷阱”串成了一条线。你写测试用例的时候，可以对着这张图，逐个接口、逐个要点去覆盖，基本不会漏掉关键项。