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

冒烟测试？

“冒烟测试” 源自硬件行业，用于测试硬件的稳定性和可靠性。

原始的冒烟测试方法是在对硬件进行改动后，直接给设备通电，观察设备是否会冒烟。如果设备没有冒烟，那么就意味着待测硬件通过了测试。

然而，在软件研发中，冒烟测试的概念首次由微软提出，并与其一直倡导的每日构建过程密切相关。

冒烟测试仅是对这类测试活动的一种形象化称谓。而更专业的术语是 “构建验证测试（Build Verification Testing，简称 BVT）”。

BVT 是一种通过在每个构建期间运行一组关键测试来验证软件构建的完整性和稳定性的方法。这些关键测试通常会针对软件的核心功能进行执行，以确保构建的基本功能可以正常工作。BVT 在软件开发周期的早期执行，以及每个新构建生成后运行，这有助于快速发现潜在的问题和缺陷。

冒烟测试和 BVT 的目标是确保软件在达到基本可接受水平之前通过最关键的测试，以减少后续更详细的测试阶段的工作量。这种方法在软件开发过程中起到了重要的质量保证和时间节约的作用。

尽管术语可能有所不同，但冒烟测试和 BVT 的核心目标始终是相同的，即通过关键测试来验证软件的基本功能和稳定性，以确保软件能够正常工作并满足预期的需求。

有什么意义？

点击查看大图

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

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

这其实是一种误解。

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

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

这么做是有好处的：

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

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

不要求每个功能都测的很详细，但至少要保证被修复了的 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 快速写一个嵌入式测试框架

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

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

总结

冒烟测试的要点：

由开发人员负责。

适用于每日构建的软件。

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

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

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！