冒烟测试？
“冒烟测试” 源自硬件行业。
对一个硬件进行改动后，直接给设备加电，看看设备会不会冒烟，没冒烟，就表示待测硬件是通过了测试。
而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日构建有很密切的联系。
冒烟只是这类测试活动更形象化一些的叫法，更专业一点的
术语是 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/