一种固件更新测试方法、系统、设备以及介质与流程

文档序号:24120652发布日期:2021-03-02 11:10阅读:61来源:国知局
一种固件更新测试方法、系统、设备以及介质与流程

[0001]
本发明涉及固件测试领域,具体涉及一种固件更新测试方法、系统、设备以及存储介质。


背景技术:

[0002]
为了解决固件在产品运行维护过程中的问题,在固件开发应用过程中,需要提供通过升级工具对开发的固件二进制文件进行在线烧录升级的方法。所以,研发就需要对提供的升级工具对固件二进制文件进行大压力测试,解决升级过程中升级固件失败的情况,从而保证每次的固件升级都能够成功。
[0003]
目前,在做固件升级的测试验证时,一般只进行相邻版本间固件升级的压力稳定性测试,但是考虑到不同的客户版本不尽相同,所以跨版本固件升级的稳定性测试显得十分必要。而对于跨多个版本间的固件升级稳定性测试场景往往会在研发测试流程中缺失或者缺少相应方法。


技术实现要素:

[0004]
有鉴于此,为了克服上述问题的至少一个方面,本发明实施例提出一种固件更新测试方法,包括以下步骤:
[0005]
获取包含多个固件文件的名称的配置文件;
[0006]
根据所述配置文件生成多个随机数,并根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称;
[0007]
根据多个所述固件文件的名称获取所述多个固件文件;
[0008]
利用所述多个固件文件依次对待更新的固件进行升级或回退,并记录相关参数。
[0009]
在一些实施例中,还包括:
[0010]
将多个固件文件的版本号和名称写入所述配置文件中。
[0011]
在一些实施例中,根据所述配置文件生成多个随机数,进一步包括:
[0012]
统计将版本号和名称写入所述配置文件中的所述多个固件文件的数量;
[0013]
根据所述数量确定生成的所述随机数的范围。
[0014]
在一些实施例中,根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称,进一步包括:
[0015]
根据所述随机数确定所述配置文件中的所述固件文件的版本号;
[0016]
根据所述版本号确定所述固件文件的名称。
[0017]
在一些实施例中,利用所述多个固件文件依次对待更新的固件进行升级或回退,进一步包括:
[0018]
根据所述多个随机数的生成顺序确定所述多个固件文件对待更新的固件进行升级或回退的顺序。
[0019]
在一些实施例中,记录相关参数,进一步还包括:
[0020]
记录升级或回退的次数、升级或回退前的版本号和升级或回退后的版本号以及相应的日志。
[0021]
在一些实施例中,还包括:
[0022]
响应于对所述待更新的固件升级或回退完毕,查询所述待更新的固件当前的版本号,以通过所述当前的版本号确定是否升级或回退成功。
[0023]
基于同一发明构思,根据本发明的另一个方面,本发明的实施例还提供了一种固件更新测试系统,包括:
[0024]
第一获取模块,所述第一获取模块配置为获取包含多个固件文件的名称的配置文件;
[0025]
确定模块,所述确定模块配置为根据所述配置文件生成多个随机数,并根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称;
[0026]
第二获取模块,所述第二获取模块配置为根据多个所述固件文件的名称获取所述多个固件文件;
[0027]
更新模块,所述更新模块配置为利用所述多个固件文件依次对待更新的固件进行升级或回退,并记录相关参数。
[0028]
基于同一发明构思,根据本发明的另一个方面,本发明的实施例还提供了一种计算机设备,包括:
[0029]
至少一个处理器;以及
[0030]
存储器,所述存储器存储有可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时执行如上所述的任一种固件更新测试方法的步骤。
[0031]
基于同一发明构思,根据本发明的另一个方面,本发明的实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时执行如上所述的任一种固件更新测试方法的步骤。
[0032]
本发明具有以下有益技术效果之一:本发明提出的方案通过配置文件的方式实现跨多个版本间的重复升降级,为固件二进制文件升级的成功率提供有力保证,不但能够测试稳定性还能测试压力,更提高了测试验证效率,覆盖了更多的测试场景,能够暴露更多的升级失败问题,为固件升级功能的成功提供有力保证。
附图说明
[0033]
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的实施例。
[0034]
图1为本发明的实施例提供的固件更新测试方法的流程示意图;
[0035]
图2为本发明的实施例提供的固件更新测试系统的结构示意图;
[0036]
图3为本发明的实施例提供的计算机设备的结构示意图;
[0037]
图4为本发明的实施例提供的计算机可读存储介质的结构示意图。
具体实施方式
[0038]
为使本发明的目的、技术方案和优点更加清楚明白,以下结合具体实施例,并参照附图,对本发明实施例进一步详细说明。
[0039]
需要说明的是,本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量,可见“第一”“第二”仅为了表述的方便,不应理解为对本发明实施例的限定,后续实施例对此不再一一说明。
[0040]
根据本发明的一个方面,本发明的实施例提出一种固件更新测试方法,如图1所示,其可以包括步骤:
[0041]
s1,获取包含多个固件文件的名称的配置文件;
[0042]
s2,根据所述配置文件生成多个随机数,并根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称;
[0043]
s3,根据多个所述固件文件的名称获取所述多个固件文件;
[0044]
s4,利用所述多个固件文件依次对待更新的固件进行升级或回退,并记录相关参数。
[0045]
本发明提出的方案通过配置文件的方式实现跨多个版本间的长时间的重复升降级,为固件二进制文件升级的成功率提供有力保证,不但能够测试稳定性还能测试压力,更提高了测试验证效率,覆盖了更多的测试场景,能够暴露更多的升级失败问题,为固件升级功能的成功提供有力保证。
[0046]
在一些实施例中,还包括:
[0047]
将多个固件文件的版本号和名称写入所述配置文件中。
[0048]
具体的,在利用多个固件文件对待更新的固件进行随机更新,需要配置相应多个固件文件的配置参数,对于每一个固件文件,都需要在配置文件中配置其对应的固件版本号以及对应的固件名称。通常固件升级有一个基础版本号如1.1,在该基础版本上可以添加多个版本的相应配置信息,相应版本号可以设置为2.1-10.1。这样,在对新的固件版本进行稳定性和压力测试时,只需要将新版本的固件的版本号和名称写入配置文件中即可。
[0049]
在一些实施例中,根据所述配置文件生成多个随机数,进一步包括:
[0050]
统计将版本号和名称写入所述配置文件中的所述多个固件文件的数量;
[0051]
根据所述数量确定生成的所述随机数的范围。
[0052]
具体的,根据配置文件中的固件文件的版本号的数量可以确定用于更新待更新的固件文件的多个固件文件的数量,根据数量可以确定生成的随机数的范围,例如,将版本号和名称写入配置文件中的固件文件的数量为10,则生成的随机数的范围在10以内。
[0053]
在一些实施例中,根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称,进一步包括:
[0054]
根据所述随机数确定所述配置文件中的所述固件文件的版本号;
[0055]
根据所述版本号确定所述固件文件的名称。
[0056]
具体的,可以利用生成的随机数在配置文件中确定用于更新待更新固件的固件文件的版本号,例如,在配置文件中,多个固件文件的版本号依次为2.0、3.0、4.0、5.0、6.0,而生成的随机数为4、3、5、1、2,则随机数4对应的版本号为5.0,随机数3对应的版本号为4.0,则随机数5对应的版本号为6.0,则随机数1对应的版本号为2.0,则随机数2对应的版本号为
3.0,这样根据版本号即能确定固件文件的名称。
[0057]
在一些实施例中,利用所述多个固件文件依次对待更新的固件进行升级或回退,进一步包括:
[0058]
根据所述多个随机数的生成顺序确定所述多个固件文件对待更新的固件进行升级或回退的顺序。
[0059]
具体的,生成随机数的顺序即为用于对待更新的固件更新的顺序,例如,例如,在配置文件中,多个固件文件的版本号依次为2.0、3.0、4.0、5.0、6.0,而生成的随机数为4、3、5、1、2,则随机数4对应的版本号为5.0,随机数3对应的版本号为4.0,则随机数5对应的版本号为6.0,则随机数1对应的版本号为2.0,则随机数2对应的版本号为3.0,这样更新顺序则为利用版本号为5.0、4.0、6.0、2.0、3.0的固件文件对待更新的固件进行更新。
[0060]
在一些实施例中,可以创建固件更新压力测试工具的各个文件夹和相应目录。对于固件更新可以编写一个文件包,在该文件包中创建子文件夹,如配置多个固件版本的conf配置文件夹、用于记录相应升级过程的log日志记录文件夹、用于存放升级固件工具的tool文件夹、用于存放多个固件二进制文件的file文件夹以及进行存放流程编码源码的script文件夹等。
[0061]
在一些实施例中,记录相关参数,进一步还包括:
[0062]
记录升级或回退的次数、升级或回退前的版本号和升级或回退后的版本号以及相应的日志。
[0063]
在一些实施例中,还包括:
[0064]
响应于对所述待更新的固件升级或回退完毕,查询所述待更新的固件当前的版本号,以通过所述当前的版本号确定是否升级或回退成功。
[0065]
具体的,可以通过提供的升级工具对目标版本固件进行更新,更新完毕后再次查询版本,是否为目标版本来确定是否升级成功。并且记录每次升级过程中升级前的版本号、升级完成后的版本号、升级次数以及升级过程中升级工具打印的相应日志,并将该日志保存在log文件夹下。而对于一些更新后需要重启系统的固件比如bios、cpld等,需要将更新测试命令添加在系统的启动执行文件中,如/etc.rc.local。
[0066]
本发明提出的方案通过配置文件的方式实现跨多个版本间的重复升降级,为固件二进制文件升级的成功率提供有力保证,从而能够验证固件更新流程的稳定性和压力,更提高了测试验证效率,覆盖了更多的测试场景,能够暴露更多的升级失败问题,通过定位日志解决升级失败的各种问题,为最终提高固件二进制文件升级的成功率提供有力保证。并且只需要通过修改配置文件的方式,实现不同固件版本升级测试的验证,操作简单高效。
[0067]
基于同一发明构思,根据本发明的另一个方面,本发明的实施例还提供了一种固件更新测试系统400,如图2所示,包括:
[0068]
第一获取模块401,所述第一获取模块401配置为获取包含多个固件文件的名称的配置文件;
[0069]
确定模块402,所述确定模块402配置为根据所述配置文件生成多个随机数,并根据所述多个随机数在所述配置文件中分别确定对应的固件文件的名称;
[0070]
第二获取模块403,所述第二获取模块403配置为根据多个所述固件文件的名称获取所述多个固件文件;
[0071]
更新模块404,所述更新模块404配置为利用所述多个固件文件依次对待更新的固件进行升级或回退,并记录相关参数。
[0072]
本发明提出的方案通过配置文件的方式实现跨多个版本间的重复升降级,为固件二进制文件升级的成功率提供有力保证,不但能够测试稳定性还能测试压力,更提高了测试验证效率,覆盖了更多的测试场景,能够暴露更多的升级失败问题,为固件升级功能的成功提供有力保证。
[0073]
基于同一发明构思,根据本发明的另一个方面,如图3所示,本发明的实施例还提供了一种计算机设备501,包括:
[0074]
至少一个处理器520;以及
[0075]
存储器510,存储器510存储有可在处理器上运行的计算机程序511,处理器520执行程序时执行如上的任一种固件更新测试方法的步骤。
[0076]
基于同一发明构思,根据本发明的另一个方面,如图4所示,本发明的实施例还提供了一种计算机可读存储介质601,计算机可读存储介质601存储有计算机程序指令610,计算机程序指令610被处理器执行时执行如上的任一种固件更新测试方法的步骤。
[0077]
最后需要说明的是,本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,可以通过计算机程序来指令相关硬件来完成,的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。
[0078]
此外,应该明白的是,本文的计算机可读存储介质(例如,存储器)可以是易失性存储器或非易失性存储器,或者可以包括易失性存储器和非易失性存储器两者。
[0079]
本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。为了清楚地说明硬件和软件的这种可互换性,已经就各种示意性组件、方块、模块、电路和步骤的功能对其进行了一般性的描述。这种功能是被实现为软件还是被实现为硬件取决于具体应用以及施加给整个系统的设计约束。本领域技术人员可以针对每种具体应用以各种方式来实现的功能,但是这种实现决定不应被解释为导致脱离本发明实施例公开的范围。
[0080]
以上是本发明公开的示例性实施例,但是应当注意,在不背离权利要求限定的本发明实施例公开的范围的前提下,可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外,尽管本发明实施例公开的元素可以以个体形式描述或要求,但除非明确限制为单数,也可以理解为多个。
[0081]
应当理解的是,在本文中使用的,除非上下文清楚地支持例外情况,单数形式“一个”旨在也包括复数形式。还应当理解的是,在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。
[0082]
上述本发明实施例公开实施例序号仅仅为了描述,不代表实施例的优劣。
[0083]
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
[0084]
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子;在本发明实施例的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,并存在如上的本发
明实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。因此,凡在本发明实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本发明实施例的保护范围之内。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1