作为嵌入式底层码农，我是如何对系统固件做冒烟测试的？

冒烟测试？

"冒烟测试" 源自硬件行业。

对一个硬件进行改动后，直接给设备加电，看看设备会不会冒烟，没冒烟，就表示待测硬件是通过了测试。

而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日构建有很密切的联系。

冒烟只是这类测试活动更形象化一些的叫法，更专业一点的 术语是 BVT (Build Verification Testing) 。

有什么意义？

点击查看大图

通常一提到冒烟测试，大家都习惯性的把关注点放在后面两个字：测试 。

开发人员一听到 "测试" 两个字，条件反射地就会认为这不是我们的活儿，应该是测试人员来完成的。

这其实是一种误解。

通常，冒烟测试是交给开发人员去做的。

只有开发人员确认了核心功能和目标功能都可用后，再转交给测试人员。

这么做是有好处的：

用于确认代码中的更改是否按预期运行，且不会破坏整个版本的稳定性;

不要求覆盖面有多广，但至少要保证覆盖待测产品的多数核心功能；

不要求每个功能都测的很详细，但至少要保证被修复了的 bug 所属的功能和系统其他核心功能都是可用的，即这个版本能拿去做系统测试了;

如果系统的核心功能没跑通，或者目标 bug 没被修复，后续的系统测试就没必要了;

总之，

冒烟测试是确定 bug 是否修复、目标功能是否实现的一种经济且有效的方法。

我怎么做？

老吴我作为一个嵌入式底层码农，手头上管理的嵌入式单板大概有 10 多个，几乎每天都要修 bug，然后要构建新的系统固件。

在将这些系统固件转交测试人员之前，我都会调用自己写的自动化冒烟测试脚本。

下面是其中某个真实产品的冒泡测试项列表：

declare -a TEST_TABLE=(
    'Kernel-Boot_Stability'
    'Ethernet-1000M_Perf'
    'USB3.0-Host1_Perf'
    'USB2.0-Host1_Perf'
    'USB2.0-Host2_Perf'
    'WiFi-2.4G_Connect'
    'WiFi-2.4G_Perf'
    'WiFi-5G_Connect'
    'WiFi-5G_Perf'
    'WiFi_Switch_Stability'
    'Memory_Stability'
    'GPU_Perf'
)

declare -gA TEST_CFG_TABLE=(
    ['Kernel-Boot_Stability']=""
    ['Ethernet-1000M_Perf']="Ethernet-1000M_Perf.cfg"
    ['USB3.0-Host1_Perf']="USB_Perf_ETHUSB1.cfg"
    ['USB2.0-Host1_Perf']="USB_Perf_ETHUSB2.cfg"
    ['USB2.0-Host2_Perf']="USB_Perf_ETHUSB3.cfg"
    ['WiFi-2.4G_Connect']="WiFi-2.4G_Connect.cfg"
    ['WiFi-2.4G_Perf']="WiFi-2.4G_Perf.cfg"
    ['WiFi-5G_Connect']="WiFi-5G_Connect.cfg"
    ['WiFi-5G_Perf']="WiFi-5G_Perf.cfg"
    ['Memory_Stability']="Memory_Stability.cfg"
    ['GPU_Perf']=""
    ['WiFi_Switch_Stability']="WiFi_Switch_Stability.cfg"
)

declare -gA TEST_MOD_TABLE=(
    ['Kernel-Boot_Stability']="dmesg"
    ['Ethernet-1000M_Perf']="iperf"
    ['USB3.0-Host1_Perf']="iperf"
    ['USB2.0-Host1_Perf']="iperf"
    ['USB2.0-Host2_Perf']="iperf"
    ['WiFi-2.4G_Connect']="wifi_connect"
    ['WiFi-2.4G_Perf']="iperf_wifi"
    ['WiFi-5G_Connect']="wifi_connect"
    ['WiFi-5G_Perf']="iperf_wifi"
    ['Memory_Stability']="memtester"
    ['GPU_Perf']="glmarktest"
    ['WiFi_Switch_Stability']="wifi_switch"
)

declare -gA RESULT_TABLE=()

其核心实现思路极其简单，我在上一篇文章里介绍过：

用 Shell 快速写一个嵌入式测试框架

我用相同的思路为所有的单板都编写了自动化的冒烟测试脚本。

这些脚本不仅为我个人节省了大量的精力，同时在一定程度上降低了公司测试人员的工作负担，性价比极高。

总结

冒烟测试的要点：

由开发人员负责。

适用于每日构建的软件。

不要求全面测试，但是要快速地验证出最核心的功能和目标功能是否运行正常。

冒烟测试通过后，再将软件转交给测试人员进行更全面的系统测试。

点击查看大图

参考资料

https://zhuanlan.zhihu.com/p/39786718

https://www.guru99.com/smoke-testing.html

https://www.guru99.com/smoke-sanity-testing.html

https://www.edureka.co/blog/what-is-smoke-testing/