什么是嵌入式软件测试？三年黑盒经验全解析

刚刚毕业三年时间，已经换了两次工作岗位，当下这家所在公司的测试团队，只有我孤孤单单一个人。视频会议系统，从硬终端开始，到App，再从Web后台延续到PC端，全部都要由我独自一个人来进行测试。这便是嵌入式软件测试的实实在在的日常状况，既繁杂又深入，要是没有一点过硬的实力，根本就承受不住。

什么是嵌入式软件测试

有着特定功能的那套程序，被称作嵌入式软件，它是安装在带有Linux系统的PCB板子之上的，其安装方式不像手机App那样是直接进行下载安装的形式，而是以固化的状态存在于硬件设备里，比如视频会议系统的硬终端里运行的是它，路由器里运行的是它，智能摄像头里运行的也是它。

暗箱检测的时候，你无需在意代码到底是如何编写的，然而却得去查验功能是否正确恰当。举例来说，就像硬性终端开启会议，你得瞧瞧画面是不是顺畅流利，声音是不是同步一致。从事测试工作的工程师站在用户视角操控设备，寻觅不符合要求事项的所在之处。

嵌入式测试相较于商用软件，对硬件环境的依赖程度更高。同样的程序，在更换一块电路板后，或许就需要再次进行测试。这是由于硬件发生了变化，驱动、接口以及性能都会出现差异。此外，这也就是嵌入式测试比普通软件测试更为复杂的原因所在。

嵌入式测试和普通测试的区别

为商用软件开展测试工作之际，要是碰到功能没办法达成的状况，直接向开发人员提交bug，把截图以及日志附上就可以了。然而针对嵌入式测试而言绝不能如此操作。当设备出现连不上网络的情况时，其原因有可能是POE网线不具备供电的支持能力，还有可能是交换机配置方面产生的问题。

经过三年时间，我形成了这么一个习惯，那就是一旦发现bug，首先查看环境。具体来说，是哪种型号的交换机，连接了多少台设备，使用的是怎样的网线，这些当中所包含的信息，比bug截图更为重要。曾经有一回，会议系统老是掉线，一番折腾之后，这才发现原来是网线仅仅支持百兆，更换成千兆网线之后，问题就解决了。

要是进行嵌入式测试，那就得懂得计算机网络，你得会配置 IP 地址，得会查看路由表，还得了解 TCP/IP 协议，视频会议系统是涉及音视频传输的，网络抖动、丢包以及延迟这些情况都会对体验造成影响，要是不懂网络原理，就连问题都没办法复现出来。

一个人测整套系统的挑战

视频会议系统涵盖五个端，其中，在Linux上运行的是硬终端，手机端为App，Web后台用于管理，PC端供用户使用，还有各类外设摄像头及麦克风。所有端的功能彼此关联，一旦一个端更改了接口，其他端皆需进行回归测试。

极为让人伤脑筋的事项便是那组合场景，由硬终端发起会议，App 加入进来，PC 端进行共享屏幕，在这个时候倘若再切换到后台去修改会议参数，极有可能就会出现 bug，并且仅仅我独自一人进行测试，每一个版本都需要手动去跑完一整套流程，压力是相当巨大的。

由硬件平台性能限制所导致的情况也会生成那种偶现的 bug，硬终端的 CPU 远远比不上电脑，在处理高码率视频之际会出现卡顿现象，这种性能方面的问题很难稳定地进行复现，需要添加日志、抓取数据包、监控内存，反复运行几十次才可以定位。

嵌入式测试的核心能力

思维应转变用于测试，商用软件如出现问题，较大概率是代码逻辑有误，嵌入式设备若出现问题，则可能是内存发生泄漏、驱动存在不匹配情况、硬件接口出现损坏、供电出现不足状况，甚至有可能是你自身接错了外设。

曾有一回，USB摄像头出现不被识别的状况，那时我险些向开发人员提交问题报告。随后经过检查，发觉是摄像头协议存在不兼容的情况，更换一款具备支持性的型号后便恢复正常了。此事件给我敲响了警钟：进行测试工作务必具备专业性，切不可无论何事都推给开发人员，应当先行排除环境以及硬件方面的诸多因素。

网络方面的知识务必要扎实，配置有交换机进行VLAN，或者抓一下包来分析RTSP流，以及排查组播出现的问题，这些通通都是日常会有的操作，视频会议系统对于网络的要求是比较高的，要是不懂TCP握手，更不懂SIP协议，那根本就测不透。

环境差异带来的测试难度

一套相同的设备，一旦更换交换机就极有可能出现问题。去年碰到过一个故障，硬终端在公司环境下状态正常，可是到了客户那里就无法连接会议服务器。最终经过排查发现，是客户的交换机开启了STP生成树协议，导致端口转发存在延迟现象。

硬件平台存在差异，这也使得工作量有所增加。因为芯片厂商不一样，所以驱动实现会存在差别。将同样的软件移植到新板子上时，Wi-Fi模块有可能连不上，音频编解码或许会出错。每次更换平台都得从头进行一遍测试，回归成本是很高的。

外围设备的兼容性测试会显得更为繁杂琐碎，对于一个会议系统而言，需要对几十款麦克风进行测试，还要对几十款摄像头进行测试，同时也要对几十款遥控器进行测试，存在着这样一些情况，其中有些外围设备采用的协议并非标准协议致使设备无法识别，还有些因为供电短缺使得工作状态不稳定，而这些问题相互交织在一起，导致排查的链路变得特别长，是这样的状况。

如何提升嵌入式测试效率

工具链必须妥善搭建起来，串口调试工具用于查看内核日志，Wireshark用于抓取网络包，ADB用于抓取Android日志，碰到偶现的bug时，要先开启日志抓取，在复现之后立刻保存现场，日志信息越全面，开发定位就会越快。

环境得实现标准化，公司的测试环境，得跟客户现场尽可能保持一致，为此我特意准备了多款交换机，准备了各种规格的网线，还准备了不同品牌的外设，并且每次测试之前都会记录环境配置，以此来减少变量干扰。

文档的沉淀是相当重要的，针对嵌入式测试而言，资料是比较少的，实战经验得依靠自身去积累，每进行一个项目测试，我都会去写出测试总结，从而记录典型问题以及排查思路，历经三年时间，这些文档变成了最为宝贵的财富。

读完这篇文字之后，我想要询问你：你于测试嵌入式产品之际，碰到过最怪异的故障是啥？欢迎在评论区域分享你的经历，点赞以便让更多从事测试的同行能够看到。