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

冒烟测试?

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

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

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

冒烟只是这类测试活动更形象化一些的叫法,更专业一点的 术语是 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

文章链接:作为嵌入式底层码农,我是如何对系统固件做冒烟测试的?

展开阅读全文

页面更新:2024-03-07

标签:嵌入式   测试   单板   系统   微软   底层   脚本   核心   目标   功能   人员

1 2 3 4 5

上滑加载更多 ↓
推荐阅读:
友情链接:
更多:

本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828  

© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号

Top