• 0
  • 0
分享
  • 一种数字对讲机功能测试与软件BUG抓取方法——软件测的圈
  • TIMI 2022-01-26 15:14:24 字数 4301 阅读 1769 收藏 0

摘要:多年的数字对讲机测试经验总结出一种“总分总”软件测试法(又称三步测试法),该测试方法基于传统软件测试过程V模型的右方集成测试、系统测试、验收测试阶段,结合现代软件测试过程,综合运用黑盒测试法、灰盒测试法、冒烟测试法、回归测试法、探索性测试法,并进一步尝试发散性思维测试。

关键词:数字对讲机;软件测试;总分总测试法;三步测试法;BUG抓取

自从工信部2009年666号文件《工业和信息化部关于150MHz 400MHz频段专用对讲机频率规划和使用管理有关事宜的通知》颁布拉开了对讲机模转数的序幕,国内企业经过几年的模转数的技术积累和产业结构调整,已有能力批量生产制造数字对讲机。随着微电子技术的发展,数字对讲机的集成度高,大多厂家采用3片制方案,由基带芯片、射频收发芯片、微处理器芯片以及射频放大电路和外围辅助电路组成,硬件部分调试复杂度低,可靠性高。数字对讲机与模拟对讲机相比,话音质量好、频谱利用率高、省电节能、保密性好、业务功能丰富。业务功能丰富意味着数字对讲机软件开发工作量大且逻辑关系复杂,目前数字对讲机制式不统一,仅仅国内数字对讲机标准(征求意见稿)就有四种制式[1],面对多制式且功能丰富的数字对讲机软件开发,需要一套行之有效的测试方法进行功能验证和性能测试,尽早发现程序的错误、缺陷和不足,及时修正,防止错误积累影响开发进度乃至开发失败。目前关于数字对讲机软件测试研究还处于萌芽状态,行业中关于数字对讲机的软件测试指导也近似空白。作者结合自己实践数字对讲机软件测试经验,总结出“总分总”测试法。利用“总分总”测试思想测试的数字对讲机从开发到投放市场情况反馈看,功能满足要求,性能稳定可靠,降低开发成本,提高开发效率有积极作用。

1 数字对讲机软件“总分总”测试法思想

软件测试分为静态测试和动态测试。静态测试可以尽早发现逻辑错误和编码缺陷,静态测试需要测试人员深入了解对讲机制式以及协议且有读懂代码分析代码的能力,对人员业务素质要求较高,不适合目前数字对讲机行业的现实情况。动态测试发现错误和缺陷晚于静态测试,动态测试结合手工测试目前仍然是发现错误的最有效的方法。自动测试虽然可以提高效率,实现自动测试编写脚本和维护脚本的资源和技能成本比较高,数字对讲机软件回归测试不是很大,综合考虑自动测试的产出比,选定手工测试作为测试的方式。

总分总测试的总体思路如下:

1)软件开发人员提供一版可供测试的软件,软件测试人员按照设计要求或开发规格书全面仔细做一遍测试,测试的准确性要有保证,并把发现的问题和现象反馈给开发人员;

2)开发人员修正更新软件版本,测试人员有针对性的测试项目,把已发现的问题和现象逐个测试是否修正。如有没有修正的,再次反馈给开发人员修正,如此反复迭代更新软件版本,直到第一遍完整测试发现的问题现象都得到解决和满足设计要求;

3)把反复迭代后的最新软件版本再次做一次完整全面的测试,如满足设计要求则可以发布beta版本。如不满足要求再次进行版本迭代直到无问题,再做完整全面测试;

4)在已发布beta版本的基础上,再做随机性测试和探索性测试以及非常规测试,如发现问题则返回2),如未发现问题则作为正式版本发布。该测试方法是黑盒测试法,灰盒测试法,冒烟测试法、回归测试法、随机测试法[3-4]的综合运用。

2 数字对讲机软件“总分总”测试法的具体运用

2.1 第一阶段测试

第一次总体完整测试旨在综合运用冒烟测试法、黑盒测试法、手工测试法进行功能性测试,主要测试开发的软件是否实现了设计要求或开发规格的项目。

第一次完整测试至关重要,该阶段是发现问题最早的阶段,该阶段抓住的软件问题和软件BUG越多,越有利于提高开发效率,降低开发成本。该阶段运用黑盒测试法,主要是避免测试人员形成代码定性思维,完全根据设计要求或开发规格进行验证测试。

在测试时运用冒烟测试法,把设计要求或开发规格的各个项目分为若干优先级,越是主要重要的功能,优先级越高,优先测试优先级高的项目,再测试优先级低的项目,直至所有项目验证测试完毕,形成固件软件反馈文档给开发设计人员。根据不同的机型和产品定义,功能测试的细节有所不同。

总体上说有以下几方面:写频软件兼容不同操作系统测试,写频软件安装测试以及界面评估易用评估,对讲机各项功能测试,对讲机互操作性测试,中继测试以及集群测试。

在第一次总体完整测试时,同步建立对讲机各项功能测试用例,对讲机互操作性测试用例,中继测试以及集群测试用例,这些测试用例的建立和设计,是为第二阶段的软件版本迭代测试,逐个验证第一阶段发现的问题准备的,也为第三阶段的总体完整性测试做了准备,第一阶段建立的测试用例节约了第二三阶段再次建立测试用例的时间。

第一阶段建立的测试用例根据功能项目命名保存于计算机中,第二三阶段直接调取使用。如果第二三阶段发现测试用例还不完善,继续完善测试用例。

2.2 第二阶段测试

软件版本迭代测试,本阶段是持续发现问题分析问题解决问题的关键阶段。该阶段综合运用了回归测试法和灰盒测试法,防止解决了旧问题引入新问题,测试人员可以和开发人员沟通代码修改后的关联影响,从而制定适当范围的测试策略。

灰盒测试法的效率在黑盒法和白盒测试法之间,非常适合该阶段的测试,并满足效率要求,也一定程度上关注了代码内部的正确性。软件开发人员跟进测试人员反馈的问题和优先级,复现并分析问题,修改代码,为了提高开发效率,软件开发人员修改一定的问题后,更新版本并版本号自动升级发给测试人员测试,同步更新软件问题反馈表,在表中描述修改的问题的原因和方法,并用不同颜色标注(例如绿色表示更新解决,黄色表示待处理,红色表示未解决,蓝色表示代码更新未解决),测试人员收到反馈表一目了然测试验证代码已更新解决的问题。测试验证满足要求不再反馈,维持绿色标注。

测试人员发现问题仍旧存在则标注蓝色,以表示代码更新未解决,软件开发人员看到蓝色标注则继续分析修改代码解决。在软件代码反复迭代测试阶段,软件更新和测试都以较快的步伐进行,软件反馈表只是反馈了问题和现象,针对个别疑难问题不易描述清晰明了,测试人员和开发人员可以面对面或电话或QQ或微信等一切可以利用的通信工具和手段快速沟通,快速让开发人员发现问题。根据不同机型和项目要求,软件复杂度不同,首次软件版本完整度不同,软件迭代测试的测试量可能很大,工作量占到软件开发和测试的一半以上。

2.3 第三阶段

在第二阶段反复迭代测试未发现问题的基础上进入该阶段测试,第二阶段未发现问题,软件问题基本已解决80%以上了,基本满足设计要求和开发规格。该阶段总体完整测试一遍的目的是再次利用回归测试法验证软件功能,规避第二阶段高效测试时回归的不彻底不全面。由于测试用例经过前述两阶段的完善已比较成熟,可以直接使用,该阶段测试如未发现问题,则可以发布beta版本给产线生产以及客户试用。如发现了问题则返回到第二阶段继续软件版本迭代测试无问题后,再次进入第三阶段总体完整测试,直至第三阶段总体完整测试无问题再发布beta版本。

探索测试阶段,探索测试阶段对测试人员业务素质要求较高,没有现成的测试用例、测试方法、测试技术、测试工具可用,依靠测试人员的思维和主观能动性进行测试,需要经常性改变测试策略。探索测试需要测试人员对软件设计要求和开发规格的项目有较深的理解,也是未来测试领域的发展方向。结合数字对讲机的实际情况,行业内人士可以采用探索性测试,在该测试阶段综合运用“无招胜有招”非常规输入以及使用的非常规测试,可以发现软件的可靠性和稳定性的问题。

3 数字对讲机软件测试实例

作者使用“总分总”测试法测试过DMR、DPMR、企业自定义制式数字对讲机,以及这些制式的中继台达几十款系列产品,达到了预期的测试效果。在某型号数字对讲机开发阶段,运用第一阶段测试出色码3与33与63不能区分,不同机型加密通信问题,不同机型报警系统兼容性问题,不同厂家短信兼容性问题,强插强拆问题,模拟模式的亚音误解率高以及模拟亚音不同机型兼容问题, DTMF兼容性问题,尽早发现并及时反馈问题,提高了开发效率。

运用第二阶段测试出代码更新后带来的数字乱码啸叫问题以及死机和重启问题,结合灰盒测试法分析,与开发人员一起查找修改代码引起这些问题的原因,并及时根据代码关联性预估可能影响的功能,及时修改测试策略并扩大测试范围,及时测试出旋转信道偶尔会乱码啸叫问题,录音模式影响模拟信道出现乱码啸叫问题。

运用第三阶段探索性测试,采用非常规测试法测试出双时隙模式死机问题,大声讲话数字对讲机语音变小且不能在一PTT周期内恢复问题,运用第三阶段的探索测试测出了非常规的问题,这些问题在正常使用不会出现问题,但是在特定场合特定行业应用中则会造成不良影响和客户对产品稳定性产生怀疑,虽然第三阶段可以发现的问题有的目前业界暂时无法解决,但为今后的技术演进和产品设计提供了一定的参考。

运用该测试法形成的软件测试反馈更新情况表,读者可以结合项目实际情况作为参考。在状态列可以清楚地看到哪些问题解决了,在软件版本列可以清楚地看到在哪个版本解决问题了,哪些问题已修改代码还未解决,哪些问题初始版本发现未解决和未处理,哪些软件迭代版本出现了新问题。在这个表格中软件开发人员和测试人员可以很清晰明了的了解现阶段的软件反馈更新情况。

软件开发人员可以在软件版本列加上版本发布时间,在解决情况列加上解决时间和解决方法,测试人员可以在对应的版本列和问题行交叉的CELL内填写验证情况和日期,以备今后查验以及项目总结作为分析和改进的参考,软件版本更新可以持续在右侧添加软件版本列,问题增加可以在末行持续增加行,直至该软件稳定可靠运行发布。后续因工程应用和产品升级也可以在该表格上继续增加版本和问题,产品的软件功能演进也明确体现了。

4 结束语

总结了数字对讲机软件测试经验,形成一种数字对讲机功能测试与软件BUG抓取方法,该方法采用类似议论文总分总的格式,故名曰“总分总”测试法,从测试阶段划分也称三步测试法。从几年的测试结果可以得出,该测试方法是高效可行的,行之有效的,测试出软件的问题在覆盖率、深度性、可靠性、容错性、稳定性、前沿性都表现良好。

采用该方法测试可以发现软件绝大部分的问题和BUG,还有5%左右的问题和BUG可以在个别工程应用和极限条件下发现,根据实际情况Update软件。探索性测试可以发现前沿性的问题和稳定性、容错性问题,作者进一步关注与研究,并尝试发散性思维测试在实践中运用。该测试方法在其他行业软件测试有一定借鉴意义和参考价值。


作者:闫复利


  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   购物车页面用例设计  一、购物车页面  二、购物车页面测试范围列表  三、购物车页面功能点需求分析  四、部分功能点的测试用例设计  购物车页面  1、验证添加商品到购物车页面合法,添加成功  ·步骤描述  选择不大于20种商品点击加入购物车,再进入我的购物车页面对比选中的商品结果。  ·测试数据  商品种类:1种、19种、20种  ·预期结果  1)购物车页面显示的商品与添加的商品一致  2)公共头部购物车角标+1、+19、+20  3)数据库表tp_cart新增1条/19条/20条记录  2、验证添加商品到购物车页面种类数非法,添加失败  ·步骤描述  选择大于20种商品加入购物车,再...
            10 10 2265
            分享
          •   华为nova11系列及全场景新品发布会正式举办,nova11系列、畅享60X、MateBook系列等新品相继亮相。这其中,有一个“大家伙”非常值得关注,华为智慧屏S3Pro相较于上一代实现了全面升级,搭载智慧双芯实现了音画体验和智慧体验的大幅提升。同时,也带来了业界最强的超级投屏功能,全面革新投屏体验。  华为智慧屏S3Pro搭载了一颗4K旗舰主芯和一颗AI视觉芯片,智慧双芯的性能组合成为了行业新的解决方案。这颗4K旗舰主芯拥有四核A73CPU,主频可达1.5GHz,在应用启动速度、操作流畅性等方面起到了关键作用。同时,这颗芯片还配备了一块1.6TOPS的NPU单元,带来了鸿鹄AIHDR增...
            0 0 757
            分享
          •   我是一名转IT测试人,我的专业是化学,去化工厂实习才发现这专业的坑人之处,化学试剂害人不浅,有毒,易燃易爆,实验室经常用丙酮,甲醇,四氯化碳,接触多了,吃个饭都感觉在吃试剂,实属被逼无奈,只能选择转行。  在这期间我迷茫过,纠结过,不知道该选择什么方向,后来我的发小推荐我转行去做软件测试,看他在这行发展的还挺好,我就想着要么我也试试看。然而走上这条路,我才发现完全不懂it的我,学起来也不会太困难。就这样转行测试改变了我的人生轨迹,和一群努力奋斗、满腔热血的同事们一起,燃起了我的斗志,也为自己创造了更好的前途!  努力奋斗!满腔热血!  好了,我发泄完了,文风要突转了::  成功不能复制,但...
            0 0 2083
            分享
          •   当企业在招聘性能测试工程师时,往往会遇到一个难题:简历上看起来很不错的候选人,在面试时却表现平平,缺乏足够的实战经验。  有一位HR在招聘性能测试工程师时收到了一个简历,上面写着有多年的性能测试经验,参与过多个高并发、大流量的项目,并使用了各种性能测试工具进行测试。  这个人似乎是一个完美的人选。HR非常期待与这位候选人见面,但当候选人来到面试时,情况却并非如此,这位候选人在面试中回答了一些基础性能测试问题,但当被问及具体的性能瓶颈分析案例时,他却无法回答。HR开始怀疑这位候选人是否真的具备所需的实战经验。  为了进一步考察候选人,HR决定让他做一个现场性能测试实验:模拟了一个高并发的电商...
            0 0 647
            分享
          • 需求评审之后,开发人员一般会开始拆分任务,测试人员需要对新需求进行消化,消化过程最好的产物就是输出对新功能的需求项梳理,并且根据需求项列出测试注意点以及影响模块。这个过程很像去肉剔骨,抽丝剥茧的感觉,也就是掌握到了版本的精髓。需求点的形式有哪些呢?简单来说就是这个版本产品提出的希望实现的很多个功能点,比如:需要给门加一个锁,这就是一个需求点,智能锁还是机械锁,能不能支持反锁,装几个锁,安全性怎么样,可靠性怎么样,这些是根据需求点发散的测试点,这些测试点有一些在文档里有说明,有一些是没有说明的,需要根据用户实际使用场景考虑。很多人又会有这样的疑惑:测试项和需求项之间的区别有哪些呢。不看以下内容,...
            1 1 7922
            分享
      • 51testing软件测试圈微信