冒烟测试? "冒烟测试" 源自硬件行业。 对一个硬件进行改动后,直接给设备加电,看看设备会不会冒烟,没冒烟,就表示待测硬件是通过了测试。 而在软件研发中,冒烟测试其实是微软首先提出来的一个概念,和微软一直提倡的每日构建有很密切的联系。 冒烟只是这类测试活动更形象化一些的叫法,更专业一点的 术语是 BVT (Build Verification Testing) 。 有什么意义? 点击查看大图 通常一提到冒烟测试,大家都习惯性的把关注点放在后面两个字:测试 。 开发人员一听到 "测试" 两个字,条件反射地就会认为这不是我们的活儿,应该是测试人员来完成的。 这其实是一种误解。 通常,冒烟测试是交给开发人员去做的。 只有开发人员确认了核心功能和目标功能都可用后,再转交给测试人员。 这么做是有好处的: 用于确认代码中的更改是否按预期运行,且不会破坏整个版本的稳定性; 不要求覆盖面有多广,但至少要保证覆盖待测产品的多数核心功能; 不要求每个功能都测的很详细,但至少要保证被修复了的 bug 所属的功能和系统其他核心功能都是可用的,即这个版本能拿去做系统测试了; 如果系统的核心功能没跑通,或者目标 bug 没被修复,后续的系统测试就没必要了; 总之, 冒烟测试是确定 bug 是否修复、目标功能是否实现的一种经济且有效的方法。 嵌入式物联网需要学的东西真的非常多,千万不要学错了路线和内容,导致工资要不上去! 无偿分享大家一个资料包,差不多150多G。里面学习内容、面经、项目都比较新也比较全!某鱼上买估计至少要好几十。 点击这里找小助理0元领取:加微信领取资料 我怎么做? 老吴我作为一个嵌入式底层码农,手头上管理的嵌入式单板大概有 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/ 文章链接: https://mp.weixin.qq.com/s/hHol9iAtwc3e-VBro7aCQg 转载自:老吴嵌入式 ,作者吴伟东Jack 文章链接: 作为嵌入式底层码农,我是如何对系统固件做冒烟测试的?