CN112463585A - 固态硬盘代码的测试方法、系统、存储介质及电子设备 - Google Patents

Abstract

本发明公开了一种固态硬盘代码的测试方法、系统、存储介质及电子设备，涉及软件代码测试领域，其方法包括：获取当前待测试的固件代码；基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新；获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。本发明统一测试环境、测试标准，监控测试结果并容易进行测试结果的追溯。

Description

固态硬盘代码的测试方法、系统、存储介质及电子设备

技术领域

本发明涉及软件代码测试领域，具体是涉及一种固态硬盘代码的测试方法、系统、存储介质及电子设备。

背景技术

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作。

由于SSD产品根据市场(或客户)需求的变化而不断有新功能的支持，从而导致代码新增与优化等修改，所以SSD Firmware就需要不定期的更新，其中包括但不限于缺陷修复、功能完善、性能优化等代码提交的工作。为了最大限度的缩短开发周期，目前都是将多个不同的功能模块安排并行开发——不同的模块功能实现分配给不同的固件开发人员。待对应的功能开发完成后，经过自己的本地测试，通过后则再各自提交到主代码库中，基本的开发人员分支代码提交到主代码库示意图，如图1所示，但存在以下问题：

(1)现有的开发人员将分支代码提交到主代码库的过程，均由开发人员自己进行操作，这样导致的结果是：测试标准不统一、测试环境不定、测试结果无法监控、无法回溯相关的测试历史等问题；

(2)由于分支代码库是以某个时期的主代码库的代码作为基准进行开发，待一段时间完成开发后，由于主代码库已经融合其他代码，分支代码库与主支代码会有一定的差异了，则不能单独进行该分支代码的测试，则需要与最新的主支的代码合并后再进行测试，而这个操作也是由于各开发人员各自控制，操作的合并过程、测试过程不可控；

(3)主支代码库要设置开放所有开发人员上传、修改的权限，一旦有人员操作错误，则会对其他的使用人员有一定的影响，虽然能进行回退等操作，但是属于事后补救措施；

(4)测试固态硬盘固件的环境包括不同的操作系统、操作主机板平台、测试工具、测试用例等。如果给每位开发人员配备一套系统将会耗时耗力，并且需要开发人员熟悉各种测试工具参数，测试方法，步骤等，否则将出现操作错误或是因为参数错误等导致结果不可信赖等问题；实际上开发人员只要专注在研发功能、特性上，无需深入了解测试环境与工具的使用。如果开发人员公用一套测试环境，则无谓增加协调与资源安排冲突等的问题，大大增加人力成本。

(5)由于固态硬盘是作为存储为主要目的，相关的机器硬件配置会影响固件行为，如果测试平台导致的测试不稳定或是设置参数错误等导致的问题，会浪费开发人员调试的时间。

发明内容

本发明的目的是为了克服上述背景技术的不足，提供一种固态硬盘代码的测试方法、系统、存储介质及电子设备，统一测试环境、测试标准，监控测试结果并容易进行测试结果的追溯。

第一方面，提供一种固态硬盘代码的测试方法，包括以下步骤：

获取当前待测试的固件代码；

基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新；

获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

根据第一方面，在第一方面的第一种可能的实现方式中，所述“获取当前待测试的固件代码”步骤之前，包括以下步骤：

获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

根据所述代码信息分析各固件代码的测试顺序；

按照所述测试顺序逐一选取当前待测试的固件代码。

根据第一方面，在第一方面的第二种可能的实现方式中，所述“基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试”步骤之后，“当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新”步骤之前，包括以下步骤：

获取所述当前待测试的固件代码的固件特性信息；

根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

根据第一方面，在第一方面的第三种可能的实现方式中，所述“获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

获取待测试的更新固件代码，所述更新固件代码为已上传至主代码库的固件代码的更新版本；

基于当前的主代码库对所述更新固件代码进行代码编译测试，然后调用基本测试案例进行测试；

若测试失败，则调用所述更新固件代码上一版本的固件代码的测试结果进行比对分析，标记调整区域。

根据第一方面，在第一方面的第四种可能的实现方式中，所述“获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

生成测试日志和测试覆盖率统计信息。

第二方面，提供一种固态硬盘代码的测试系统，包括：

信息获取模块，用于获取当前待测试的固件代码；

固件测试模块，与所述信息获取模块通讯连接，用于基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

主代码更新模块，与所述固件测试模块通讯连接，用于当所述固件代码测试通过，则将所述固件代码上传至主代码库，对主代码库进行更新；

所述固件测试模块，用于获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

根据第二方面，在第二方面的第一种可能的实现方式中，还包括：

所述信息获取模块，用于获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

测试固件选择模块，与所述信息获取模块通讯连接，用于根据所述代码信息分析各固件代码的测试顺序，按照所述测试顺序逐一选取当前待测试的固件代码。

根据第二方面，在第二方面的第二种可能的实现方式中，所述信息获取模块，用于获取所述当前待测试的固件代码的固件特性信息；

所述固件测试模块，与所述信息获取模块通讯连接，用于根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

第三方面，提供一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的固态硬盘代码的测试方法。

第四方面，提供一种电子设备，包括存储介质、处理器以及存储在所述存储介质中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时实现上述的固态硬盘代码的测试方法。

与现有技术相比，本发明的优点如下：

(1)统一测试环境、测试标准，监控测试结果并容易进行测试结果的追溯；

(2)避免开发人员自己的提交测试操作，达到对提交、测试过程全程可控；用以避免实际上未经过测试或是测试实际是失败的情况下，开发人员依旧提交代码的可能；

(3)减少主分支的代码上传的权限，便于管理；例如，只将某一个账户设置为可以提交代码的权限，其余开发人员都只有下载权限，避免误操作的可能。

附图说明

图1是基本的开发人员分支代码提交到主代码库示意图；

图2是本发明一种固态硬盘代码的测试方法的实施例的流程示意图；

图3是本发明一种固态硬盘代码的测试方法的又一实施例的流程示意图；

图4是本发明一种固态硬盘代码的测试系统的实施例的结构示意图。

附图标号：

100、固态硬盘代码的测试系统；110、信息获取模块；120、固件测试模块；130、主代码更新模块；140、测试固件选择模块。

具体实施方式

现在将详细参照本发明的具体实施例，在附图中例示了本发明的例子。尽管将结合具体实施例描述本发明，但将理解，不是想要将本发明限于所述的实施例。相反，想要覆盖由所附权利要求限定的在本发明的精神和范围内包括的变更、修改和等价物。应注意，这里描述的方法步骤都可以由任何功能块或功能布置来实现，且任何功能块或功能布置可被实现为物理实体或逻辑实体、或者两者的组合。

为了使本领域技术人员更好地理解本发明，下面结合附图和具体实施方式对本发明作进一步详细说明。

注意：接下来要介绍的示例仅是一个具体的例子，而不作为限制本发明的实施例必须为如下具体的步骤、数值、条件、数据、顺序等等。本领域技术人员可以通过阅读本说明书来运用本发明的构思来构造本说明书中未提到的更多实施例。

参见图2所示，本发明实施例提供一种固态硬盘代码的测试方法，包括以下步骤：

S100获取当前待测试的固件代码；

S200基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

S300当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新；

S400获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

具体的，本实施例中，多个开发人员提交待测试的分支固件代码，需要逐一进行测试，如果测试通过则上传提交至主代码库。本实施例主要应用于固件测试代码管理平台，将提交的更多个待测试的分支固件代码，统一进行管理，以便有序测试提交。另外，唯一的固件测试代码管理平台可以通过给所有的人(包括开发人员和管理人员)设置管理权限严格控制管理固件代码的上传测试以及删除等，例如开发人员只具有上传待测试的分支固件代码的权限，管理人员则具有调整代码测试流程的权限等。

因此，获取当前待测试的固件代码，可以基于不同的优先准则选取当前测试的固件代码。

基于当前的主代码库对固件代码进行代码编译测试，然后调用基本测试案例进行测试，其中，基本测试案例主要覆盖基础功能测试，如在指定的操作系统下识别固态硬盘，系统格式化，分区，文件存储、读取操作等。另外，基本测试案例还可以覆盖不同的测试操作系统(Windows、Linux、MacOS)下，固态硬盘通用型测试；包括但不限于数据传输测试，掉电测试，快速性能测试，各种类型的格式化，基础工具等通用测试等。

此外，如果需要增加测试用例，也可以根据需求进行添加，而且添加之后的测试用例所有的固件代码都可以测试。一旦有新增测试的流程，可以直接对所有的固件代码进行测试，而如果是测试开发人员进行本地测试，会有测试覆盖率遗漏的可能性。

当固件代码测试通过，则将固件代码上传至主代码库，并对主代码库进行更新。如果固件代码测试失败，则反馈相关的测试日志等信息给对应的开发人员进行分析确认，如在解决掉缺陷后需要将再次提交上传申请。

然后获取下一待测试的固件代码，如果上一待测试的固件代码测试失败，主代码库没有进行更新，则仍然基于当前的主代码库对所述固件代码进行代码编译测试，然后按照测试上一待测试的固件代码的方式调用基本测试案例进行测试。如果上一待测试的固件代码测试通过，则基于更新后的主代码库对该下一待测试的固件代码进行代码编译测试，然后按照测试上一待测试的固件代码的方式调用基本测试案例进行测试。直至待测试的固件代码均测试完成。

也就是说，所有待测试的固件代码逐一进行测试，由于主代码库在接收到提交的通过测试的固件代码之后会进行更新，除了基于当前最新的主代码库进行代码编译测试，之后的基本测试案例各个待测试的固件代码均相同。

本实施例将测试环境、测试流程、测试标准统一化，并且不需要开发人员自己测试，不依赖于开发人员的自觉性、减少开发人员操作的不确定性。另外，统一由管理平台进行案例测试，则可以包含多个不同的操作系统、操作主机板平台、测试工具、测试用例等，测试更加全面而不需要设置多套测试设备让开发人员学习，对开发人员要求降低，让开发人员能够更加注重代码开发。

优选地，在本申请另外的实施例中，所述“S100获取当前待测试的固件代码”步骤之前，包括以下步骤：

S010获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

S020根据所述代码信息分析各固件代码的测试顺序；

S030按照所述测试顺序逐一选取当前待测试的固件代码。

具体的，本实施例中，多个开发人员提交待测试的分支固件代码，取多个待测试提交的固件代码以及固件代码的代码信息，代码信息包括固件提交时间、固件特性信息以及缺陷代码，固件特性信息包括但不限于是否与其他特性存在依赖关系、固件上传特性关键字、模块名称、上传代码简要描述，通过固件特性信息可以确定该固件代码的类型以及与其它固件代码之间是否存在提交的先后顺序。缺陷代码包括但不限于缺陷代码数量和影响级别(I级，II级，III级)，一般来说缺陷代码数量越少，影响级别越低的代码优先测试提交，避免对后续提交的代码产生阻碍。

根据代码信息分析各固件代码的测试顺序，首先基于上传的待测试的固件代码的特性优先级以及依赖关系，例如某个特性取决于另外的特性代码，则基于两者的依赖关系决定两者的先后顺序，其次，基于修复缺陷的影响级别，再次，基于申请固件代码测试提交的申请时间的先后顺序。

最后，按照测试顺序逐一选取当前待测试的固件代码进行测试，测试时首先基于当前最新的主代码库进行代码编译测试，然后调用同样的基本测试案例进行测试，从而保证所有的待测试的固件代码测试环境与标准统一。

本实施例中固件测试代码管理平台根据代码信息自动分析各固件代码的测试顺序，避免存在不通知项目管理人员而直接上传代码的情况，而且基于优先顺序以及紧迫严重程度等进行测试顺序的分析，便于统一的项目时间规划与规定。

优选地，在本申请另外的实施例中，所述“S200基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试”步骤之后，“S300当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新”步骤之前，包括以下步骤：

S250获取所述当前待测试的固件代码的固件特性信息；

S260根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

具体的，本实施例中，由于基本测试案例为所有的固件代码通用的统一测试环境和标准的测试案例，而实际上不同的固件代码基于自身的特性可能需要在自身特有的环境下进行测试。因此，在调用基本测试案例对当前待测试的固件代码进行测试之后，获取当前待测试的固件代码的固件特性信息，固件特性信息包括但不此案与代码的名称、功能等。根据固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。例如，通过开发人员提交的特性关键字、模块名称、分支代码等信息，从已有测试库中搜索相关特性模块测试用例，并进行特性个性化测试以及其他相关的测试。

本实施例一方面调用基本测试案例，使用统一测试环境和标准的测试案例进行测试，使所有的固件代码统一标准。另一方面又基于各个固件代码的固件特性信息进行特性个性测试，以便更加彻底地进行测试。

优选地，在本申请另外的实施例中，所述“S400获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

S500获取待测试的更新固件代码，所述更新固件代码为已上传至主代码库的固件代码的更新版本；

S600基于当前的主代码库对所述更新固件代码进行代码编译测试，然后调用基本测试案例进行测试；

S700若测试失败，则调用所述更新固件代码上一版本的固件代码的测试结果进行比对分析，标记调整区域。

具体的，本实施例中，固件代码测试通过之后上传至主代码库之后，各代码相互融合，之后如果某一固件代码更新之后上传至主代码库，也是需要与当前已经上传过代码的主代码库融合。因此，获取待测试的更新固件代码，该更新固件代码为已上传至主代码库的固件代码的更新版本，同样地，基于当前的主代码库对更新固件代码进行代码编译测试，然后调用基本测试案例进行测试。然后可以获取该更新固件代码的固件特性信息，根据固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

如果测试通过，则直接将更新固件代码上传至主代码库。如果测试失败，则调用更新固件代码上一版本的固件代码的测试结果进行比对分析，标记调整区域，以便开发人员能够快速确定问题区域。不必浪费时间在查找测试环境的问题上，省去交叉验证的步骤，开发人员只要重点关注于该固件代码改动的部分即可。

本实施例中所有的固件代码均基于当前的主代码库进行测试，其中当前的主代码库已是上传融合其它代码，因此能够更加准确地在真是场景下进行测试，避免开发人员单独测试自身开发的分支固件代码导致自身测试通过与其余代码融合时出错，导致测试结果不可信。

优选地，在本申请另外的实施例中，所述“S400获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

S800生成测试日志和测试覆盖率统计信息。

具体的，本实施例中，待所有测试结束成功后，自动生成相关测试日志和测试覆盖率统计信息备查，便于管理人员后续查找测试用例的执行过程、结果日志等，达到对提交、测试过程全程可控。

参见图1所示，开发人员自己本地测试自身开发的分支固件代码存在以下问题：

1.现有的开发人员将分支代码提交到主代码库的过程，均由开发人员自己进行操作，这样导致的结果是：测试标准不统一、测试环境不定、测试结果无法监控、无法回溯相关的测试历史等问题；

2.由于分支代码库是以某个时期的主代码库的代码作为基准进行开发，待一段时间完成开发后，与主分支代码会有一定的差异了，则不能单独进行该分支代码的测试，则需要与最新的主分支的代码合并后再进行测试，而这个操作也是由于各开发人员各自控制，操作的合并过程、测试过程不可控；

3.主分支代码库要设置开放所有开发人员上传、修改的权限，一旦有人员操作错误，则会对其他的使用人员有一定的影响，虽然能进行回退等操作，但是属于事后补救措施；

4.代码的上传与管理不便于项目管理人员统一管理，存在不通知项目管理人员而直接上传代码的情况，无法指定优先顺序以及紧迫严重程度等、不便于统一的项目时间规划与规定；

5.测试固态硬盘固件的环境包括不同的操作系统、操作主机板平台、测试工具、测试用例等。如果给每位开发人员配备一套系统将会耗时耗力，并且需要开发人员熟悉各种测试工具参数，测试方法，步骤等，否则将出现操作错误或是因为参数错误等导致结果不可信赖等问题；实际上开发人员只要专注在研发功能、特性上，无需深入了解测试环境与工具的使用。如果开发人员公用一套测试环境，则无谓增加协调与资源安排冲突等的问题，大大增加人力成本。

6.由于固态硬盘是作为存储为主要目的，相关的机器硬件配置会影响固件行为，如果测试平台导致的测试不稳定或是设置参数错误等导致的问题，会浪费开发人员调试的时间。

因此，鉴于图1所示的现有代码提交方案存在的问题，本发明主要从利用Jenkins平台入手，进行管控固态硬盘固件代码提交的方法。主要通过搭建自动固件代码提交、测试框架进行改善，以解决以下几个问题：

1.统一测试环境、测试标准，监控测试结果并容易进行测试结果的追溯；

2.避免开发人员自己的提交测试操作，达到对提交、测试过程全程可控；用以避免实际上未经过测试或是测试实际是失败的情况下，开发人员依旧提交代码的可能；

3.一旦有新增测试的流程，需要通知所有的测试开发人员，进行本地测试，会有测试覆盖率遗漏的可能性；

4.减少主分支的代码上传的权限，便于管理；例如，只将某一个账户设置为可以提交代码的权限，其余开发人员都只有下载权限，避免误操作的可能；

5.让产品管理人员真正进行代码提交的管理，只有开发人员提出申请后，再由管理人员进行提交触发操作，统一项目管理接口，使得代码提交有序化。

一种固态硬盘代码的测试方法，具体的实施流程如图3所示：

1.SSD固件开发人员将开发完成的模块功能代码保存于自己本地的分支库，经过自己的本地测试后，向产品管理系统提出上传请求，并在Jenkins网页填写相关的提交信息；

开发人员提交请求时，需要包含以下关键信息：

a.是否与其他特性存在依赖关系；

b.固件上传特性关键字、模块名称、上传代码简要描述；

c.缺陷代码和影响级别(I级，II级，III级)；

2.当产品管理系统接受到请求后，统一进行规划与安排提交的优先顺序，；Jenkins内置了很强大的排序功能，安排后即可按照顺序依次串行处理；

产品管理系统规划优先顺序的决定因素如下：

a.申请固件提交的时间先后；

b.上传代码的特性优先级以及依赖关系(某个特性取决于另外的特性代码)；

c.修复缺陷的影响级别；

3.通过Jenkins将触发内部既定的测试流程，执行对应的测试用例，包含但不限于代码编译测试、代码模拟测试、代码烧录测试、SSD基本测试1、SSD基本测试2：

a.SSD基本测试1：主要覆盖基础功能测试，如在指定的操作系统下识别固态硬盘，系统格式化，分区，文件存储、读取操作等；

b.SSD基本测试2：主要覆盖不同的测试操作系统(Windows、Linux、MacOS)下，固态硬盘通用型测试；包括但不限于数据传输测试，掉电测试，快速性能测试，各种类型的格式化，基础工具等通用测试等；

4.通过Jenkins将触发执行其他测试：通过开发人员提交的特性关键字、模块名称、分支代码等信息，从已有测试库中搜索相关特性模块测试用例，并进行特性个性化测试以及其他相关的测试等：

a.特性个性测试：主要覆盖该代码提交相关模块的测试，以确保该特性相关测试用例通过；

b.其他(待扩展)测试：已有测试库中没有该特性相关的测试用例时，系统自动将提示需要新增相关测试用例的信息，给测试开发人员指导增加覆盖率，起到联动效果；

5.在此过程中，所有开发人员提交的代码都是经过相同的测试用例与测试流程。当所有的测试流程都通过之后，则自动上传到主代码库中；如果测试失败，则不进行提交，反馈相关的测试日志等信息给对应的开发人员进行分析确认；如在解决掉缺陷后需要将再次提交上传申请；

6.测试标准和测试环境统一，如果遇到测试失败，则可以参考临近一版的测试结果作为对比，不必浪费时间在查找测试环境的问题上，省去交叉验证的步骤，开发人员只要重点关注于该固件代码改动的部分即可；

7.待所有测试结束成功后，自动生成相关测试日志和测试覆盖率统计信息备查；

8.依据以上流程，根据需求依次提交。

本发明在满足提交代码条件下，将测试环境、测试流程、测试标准统一化，同时，这个流程不依赖于开发人员的自觉性、减少开发人员操作的不确定性、便于管理人员后续查找测试用例的执行过程、结果日志等，并能给项目管理人员统一接口进行SSD固件代码上传管理与统一规划，避免无序上传等问题。

参见图4所示，本发明实施例提供一种固态硬盘代码的测试系统100，包括：

信息获取模块110，用于获取当前待测试的固件代码；

固件测试模块120，与所述信息获取模块110通讯连接，用于基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

主代码更新模块130，与所述固件测试模块120通讯连接，用于当所述固件代码测试通过，则将所述固件代码上传至主代码库，对主代码库进行更新；

所述固件测试模块120，用于获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

还包括：

所述信息获取模块110，用于获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

测试固件选择模块140，与所述信息获取模块110通讯连接，用于根据所述代码信息分析各固件代码的测试顺序，按照所述测试顺序逐一选取当前待测试的固件代码。

所述信息获取模块110，用于获取所述当前待测试的固件代码的固件特性信息；

所述固件测试模块120，与所述信息获取模块110通讯连接，用于根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

所述固件测试模块120，获取待测试的更新固件代码，所述更新固件代码为已上传至主代码库的固件代码的更新版本；基于当前的主代码库对所述更新固件代码进行代码编译测试，然后调用基本测试案例进行测试；若测试失败，则调用所述更新固件代码上一版本的固件代码的测试结果进行比对分析，标记调整区域。

所述固件测试模块120，生成测试日志和测试覆盖率统计信息。

具体的，本实施例中各个功能模块的具体实现流程在上述相应的方法实施例中已经进行了详细说明，依稀不再进行一一阐述。

基于同一发明构思，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法的所有方法步骤或部分方法步骤。

本发明实现上述方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Ra ndomAccess Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

基于同一发明构思，本申请实施例还提供一种电子设备，包括存储器和处理器，存储器上储存有在处理器上运行的计算机程序，处理器执行计算机程序时实现上述方法中的所有方法步骤或部分方法步骤。

所称处理器可以是中央处理单元(Central Processing Unit，CP U)，还可以是其他通用处理器、数字信号处理器(Digital Signal Pr ocessor，DSP)、专用集成电路(Application Specific Integrated Circ uit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，F PGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

存储器可用于存储计算机程序和/或模块，处理器通过运行或执行存储在存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现计算机装置的各种功能。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(例如声音播放功能、图像播放功能等)；存储数据区可存储根据手机的使用所创建的数据(例如音频数据、视频数据等)。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Fl ash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、服务器或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、服务器和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种固态硬盘代码的测试方法，其特征在于，包括以下步骤：

获取当前待测试的固件代码；

基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新；

获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

2.如权利要求1所述的固态硬盘代码的测试方法，其特征在于，所述“获取当前待测试的固件代码”步骤之前，包括以下步骤：

获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

根据所述代码信息分析各固件代码的测试顺序；

按照所述测试顺序逐一选取当前待测试的固件代码。

3.如权利要求1所述的固态硬盘代码的测试方法，其特征在于，所述“基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试”步骤之后，“当所述固件代码测试通过，则将所述固件代码上传至主代码库，并对主代码库进行更新”步骤之前，包括以下步骤：

获取所述当前待测试的固件代码的固件特性信息；

根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

4.如权利要求1所述的固态硬盘代码的测试方法，其特征在于，所述“获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

获取待测试的更新固件代码，所述更新固件代码为已上传至主代码库的固件代码的更新版本；

基于当前的主代码库对所述更新固件代码进行代码编译测试，然后调用基本测试案例进行测试；

若测试失败，则调用所述更新固件代码上一版本的固件代码的测试结果进行比对分析，标记调整区域。

5.如权利要求1所述的固态硬盘代码的测试方法，其特征在于，所述“获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成”步骤之后，包括以下步骤：

生成测试日志和测试覆盖率统计信息。

6.一种固态硬盘代码的测试系统，其特征在于，包括：

信息获取模块，用于获取当前待测试的固件代码；

固件测试模块，与所述信息获取模块通讯连接，用于基于当前的主代码库对所述固件代码进行代码编译测试，然后调用基本测试案例进行测试；

主代码更新模块，与所述固件测试模块通讯连接，用于当所述固件代码测试通过，则将所述固件代码上传至主代码库，对主代码库进行更新；

所述固件测试模块，用于获取下一待测试的固件代码，基于更新后的主代码库对下一待测试的固件代码进行代码编译测试，然后调用基本测试案例进行测试，直至待测试的固件代码均测试完成。

7.如权利要求6所述的固态硬盘代码的测试系统，其特征在于，还包括：

所述信息获取模块，用于获取多个待测试提交的固件代码以及所述固件代码的代码信息，所述代码信息包括固件提交时间、固件特性信息以及缺陷代码；

测试固件选择模块，与所述信息获取模块通讯连接，用于根据所述代码信息分析各固件代码的测试顺序，按照所述测试顺序逐一选取当前待测试的固件代码。

8.如权利要求6所述的固态硬盘代码的测试系统，其特征在于：

所述信息获取模块，用于获取所述当前待测试的固件代码的固件特性信息；

所述固件测试模块，与所述信息获取模块通讯连接，用于根据所述固件特性信息选取对应的特性模块测试用例，并进行特性个性测试。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述固态硬盘代码的测试方法。

10.一种电子设备，包括存储介质、处理器以及存储在所述存储介质中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时实现如权利要求1至5中任一项所述固态硬盘代码的测试方法。

Images