CN109871310B

CN109871310B - 一种版本质量测试的方法和装置

Info

Publication number: CN109871310B
Application number: CN201711261003.0A
Authority: CN
Inventors: 李一伟
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2017-12-04
Filing date: 2017-12-04
Publication date: 2023-05-02
Anticipated expiration: 2037-12-04
Also published as: CN109871310A

Abstract

本发明公开了一种版本质量测试的方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：确定待测版本，获取所述待测版本的标识信息；根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态。该实施方式通过版本质量状态的确定规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了自动化测试执行不稳定和覆盖不全等问题。

Description

一种版本质量测试的方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种版本质量测试的方法和装置。

背景技术

随着科技的日益进步和人们对生活需求的逐渐提升，应用于智能终端的版本也越来越丰富，开发者要开发版本新特征或者解决版本的bug时，需要对该版本进行多次测试，只有测试成功，版本的质量达标后，才能前线发布给用户使用。

现有技术中，对于版本的质量测试工作主要通过相关人员操作完成，具体地，结合代码提交时间和版本打包时间来判断。例如，从代码提交历史中看到有关某个bug修复代码的提交历史和提交时间，再结合版本的打包时间来确定bug有没有修复，以此判断当前版本的质量是否达到上线标准。

在实现本发明的过程中，发明人发现现有技术至少存在如下问题：

(1)现有技术对于版本质量的测试，主要依赖相关人员经验，导致人力投入成本较高；另外，当版本数量较多或者较为复杂时，存在人为操作错误造成版本质量错估的情况；

(2)现有技术对于版本质量的测试，尤其是新特征开发以及需要修复的版本，手工回归测试耗时较长、操作效率较低，导致测试具有不稳定以及覆盖不全的问题，影响版本质量的测试。

发明内容

有鉴于此，本发明实施例提供一种版本质量测试的方法和装置，至少能够解决现有技术中测试依赖人力导致测试错误率以及人力投入成本较高的问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种版本质量测试的方法，包括：确定待测版本，获取所述待测版本的标识信息；根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态。

可选地，所述根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态包括：

当所述父版本的数量为一个且所述父版本的质量状态为合格时，确定所述待测版本的质量状态为合格；或

当所述父版本的数量为一个且所述父版本的质量状态为不合格时，若不存在与所述标识信息相关联的代码变更信息，确定所述待测版本的质量状态为不合格；其中，所述代码变更信息为所述父版本的打包时间点到所述待测版本的打包时间点之间的代码变更信息。

当所述父版本的数量为多个且所有父版本的质量状态均为合格时，确定所述待测版本的质量状态为合格；或

当所述父版本的数量为多个且至少一个父版本的质量状态为不合格时，若不存在所述代码变更信息，确定所述待测版本的质量状态为不合格。

可选地，在所述确定待测版本，获取所述待测版本的标识信息之前，还包括：监测主干代码信息，接收到与所述主干代码信息相关联的分支代码信息，合并所述分支代码信息至所述主干代码信息以生成代码提交信息；当达到预定周期时，打包处理所述代码提交信息，以生成所述待测版本。

为实现上述目的，根据本发明实施例的另一方面，提供了一种版本质量测试的装置，包括：第一获取模块，用于确定待测版本，获取所述待测版本的标识信息；第二获取模块，用于根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；确定模块，用于根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态。

可选地，所述确定模块用于：

可选地，还包括代码模块，用于监测主干代码信息，接收到与所述主干代码信息相关联的分支代码信息，合并所述分支代码信息至所述主干代码信息以生成代码提交信息；当达到预定周期时，打包处理所述代码提交信息，以生成所述待测版本。

为实现上述目的，根据本发明实施例的再一方面，提供了一种版本质量测试的电子设备。

本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的版本质量测试的方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的版本质量测试的方法。

根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：通过版本质量状态的继承或者合并规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了测试执行不稳定和覆盖不全等问题。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的一种版本质量测试的方法的主要流程示意图；

图2是根据本发明实施例的一种可选的版本质量测试的方法的流程示意图；

图3是根据本发明实施例的另一种可选的版本质量测试的方法的流程示意图；

图4是根据本发明实施例的又一种可选的版本质量测试的方法的流程示意图；

图5是根据本发明实施例的再一种可选的版本质量测试的方法的流程示意图；

图6是根据本发明实施例的一种版本质量测试的装置的主要模块示意图；

图7是本发明实施例可以应用于其中的示例性系统架构图；

图8是适于用来实现本发明实施例的移动设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

需要说明的是，本发明实施例所提供的方法可适用于版本新特征开发、版本bug修复、版本管理等场景，本发明实施例对于版本质量状态的不合格以版本bug为例进行说明。

本发明实施例所提供的代码变更信息，可以是版本bug修复代码信息、版本新特征代码信息等，本发明在此不做限制。

参见图1，示出的是本发明实施例提供的一种版本质量测试的方法的主要流程图，包括如下步骤：

S101：确定待测版本，获取待测版本的标识信息。

S102：根据标识信息，确定与待测版本相关联的父版本，获取父版本的质量状态。

S103：根据父版本的质量状态以及预设的版本质量状态确定规则，确定待测版本的质量状态。

上述实施方式中，对于步骤S101，在版本开发过程中，每个阶段的版本都有着各自的基本属性信息，该基本属性信息一般录入在数据库中(例如软件版本属性信息库)，并将新生成的版本备份到版本库中(例如版本服务器)。因此，在确定待测版本之后，可以在数据库中获取有关待测版本的信息。

进一步的，该基本属性信息包括版本运行正常的判定标识信息等。每个版本都具有唯一标识版本ID，以区分不同的版本。该版本通过版本ID和软件版本属性信息库进行关联。

对于步骤S102，根据待测版本的标识信息，首先确定该待测版本所处的节点。之后依据节点的结构关系，例如DOM(Document Object Model，文档对象化模型)树，确定与待测版本相关联的父版本。例如，从版本A和版本B合并生成版本C，即版本C有两个父版本，或者多个版本A、B、C合并生成版本D，那么版本D有三个父版本。

对于所确定的父版本，有着相应的质量状态，例如合格或不合格。该质量状态同样可以存储于数据库中。在获取其质量状态时，也可以在数据库中依据父版本的标识信息进行获取。另外，也可以是在父版本存储时，对该父版本进行版本标注，以说明该父版本的质量状态。因此，此时对于该父版本质量状态的获取，可以是通过人为方式或者识别方法对该版本的标注信息进行识别，以判断并确定该父版本的质量状态。

对于步骤S103，当父版本的质量状态为合格时，可以直接确定待测版本的质量状态为合格。但当父版本的质量状态为不合格时，此时需要判断父版本的bug是否解决了，若没有解决，即证明待测版本的质量状态也为不合格；否则，确定待测版本的质量状态为合格。

上述实施例所提供的方法，提供了一种依据父版本的质量状态确定待测版本质量状态的思路，降低了对人力的依赖程度，提高了版本质量测试的准确性与智能程度，克服了现有技术中测试不稳定导致质量错估的问题。

参见图2，示出的是本发明实施例提供的一种可选的版本质量测试的方法的主要流程图，包括如下步骤：

S201：确定待测版本，获取待测版本的标识信息。

S202：根据标识信息，确定与待测版本相关联的父版本，获取父版本的质量状态。

S203：当父版本的数量为一个且父版本的质量状态为合格时，确定待测版本的质量状态为合格。

S203’：当父版本的数量为一个且父版本的质量状态为不合格时，若不存在与标识信息相关联的代码变更信息，确定待测版本的质量状态为不合格；其中，代码变更信息为父版本的打包时间点到待测版本的打包时间点之间的代码变更信息。

上述实施方式中，步骤S201与步骤S202可分别参见图1所示步骤S101与步骤S102的描述，在此不再赘述。

根据待测版本所处节点的结构关系，可以确定与待测版本相关联的父版本的数量。当待测版本所处的节点处于单个分支时，确定相关联的父版本的数量为一个。

上述实施方式中，对于步骤S203，当父版本的数量只有一个，且该父版本的质量状态为合格时，可以依据版本质量状态确定规则(例如继承规则)来推算当前待测版本的质量状态为合格，即待测版本的质量状态＝父版本的质量状态，例如从版本A->版本B。

对于步骤S203’，当父版本的数量为一个且该父版本的质量状态为不合格(例如bug没有修复)时，此时需要依据父版本打包时间点到待测版本的打包时间点之间是否存在代码提交信息，以对待测版本的质量状态进行判断。若在父版本的打包时间点到待测版本打包时间点之间没有代码变更信息时，即证明父版本中的bug没有解决，此时可以推算当前待测版本的质量状态为不合格。

上述实施例提供的方法，当父版本的数量只有一个时，提供了一种质量状态继承的方法以确定待测版本质量状态的新思路，所示方法降低了对人力的依赖程度，提高了版本质量测试的准确性与智能程度，克服了现有技术中测试不稳定导致质量错估的问题。

参见图3，示出的是本发明实施例提供的另一种可选的版本质量测试的方法的主要流程图，包括如下步骤：

S301：确定待测版本，获取待测版本的标识信息。

S302：根据标识信息，确定与待测版本相关联的父版本，获取父版本的质量状态。

S303：当父版本的数量为多个且所有父版本的质量状态均为合格时，确定待测版本的质量状态为合格。

S303’：当父版本的数量为多个且至少一个父版本的质量状态为不合格时，若不存在代码变更信息，确定待测版本的质量状态为不合格。

上述实施方式中，步骤S301与步骤S302可分别参见图1所示步骤S101与步骤S102的描述，在此不再赘述。

根据待测版本所处节点的结构关系，可以确定父版本的数量。当待测版本所处的节点处于多个分支的交界处时，确定相关联的父版本的数量为多个。

上述实施方式中，对于步骤S303，当父版本的数量为多个，每个父版本的质量状态都会影响到待测版本的质量状态。若所有父版本的质量状态均为合格，此时可以依据版本质量状态确定规则(例如合并规则，悲观测试规则)，确定待测版本的质量状态为合格。

对于步骤S303’，但若至少一个父版本的质量状态为不合格时，同理图2所示步骤S203’，此时需要判断是否存在介于各父版本的打包时间点到待测版本打包时间点之间的代码变更信息。例如，版本A以及版本B->版本C，若版本A的质量状态为不合格(例如bug没有修复)，但版本A与版本C的打包时间内无代码变更信息时，此时同样依据版本质量状态确定规则，确定待测版本的质量状态为不合格。

上述实施例提供的方法，提供了另外一种父版本的数量为多个时，依据质量状态确定规则以推测待测版本质量状态的思路，所示方法降低了对人力的依赖程度，提高了版本的质量测试的准确性与智能程度，克服了现有技术中测试不稳定导致质量错估的问题。

参见图4，示出的是本发明实施例提供的又一种可选的版本质量测试的方法的主要流程图，包括如下步骤：

S401：监测主干代码信息，接收到与主干代码信息相关联的分支代码信息，合并分支代码信息至主干代码信息以生成代码提交信息。

S402：当达到预定周期时，打包处理代码提交信息，以生成待测版本。

S403：确定待测版本，获取待测版本的标识信息。

S404：根据标识信息，确定与待测版本相关联的父版本，获取父版本的质量状态。

S405：根据父版本的质量状态以及预设的版本质量状态确定规则，确定待测版本的质量状态。

上述实施方式中，步骤S403与步骤S404可分别参见图1所示步骤S101与步骤S102的描述，步骤S405可分别参见图1～图3的描述，在此不再赘述。

上述实施方式中，对于步骤S401，可以通过git(分布式版本控制系统)提供的api(Application Programming Interface，应用程序编程接口)来监控主干代码信息。如果有新分支代码需要合并到主干，则将分支代码合并到主干代码中，以生成代码提交信息上传至打包环节进行打包处理，同时将合并后的主干代码信息同步更新到信息库中，例如，自动化用例代码库。

对于步骤S402，可以通过jenkins(可扩展的持续集成引擎)对所提交的代码提交信息进行代码编译，打包处理。另外，还可以将与该代码提交信息相关联的代码注释进行打包处理，以生成待测版本。

进一步的，还可以依据待测版本的关键词、版本ID等标识信息，将代码提交信息以及代码注释和待测版本做关联存入数据库中，同时将待测版本备份到版本服务器中。

上述实施例所提供的方法，将代码管理、版本管理以及版本质量测试等软件开发环节的测试工作进行了关联，将之前需要相关人员手工执行的工作自动化处理，大幅度降低了企业对人力的投入成本，同时提高了版本质量测试结果的准确性以及智能化。

参见图5，示出的是本发明实施例提供的再一种可选的版本质量测试的方法的主要流程图，包括如下步骤：

S501：监测主干代码信息，接收到与主干代码信息相关联的分支代码信息，合并分支代码信息至主干代码信息以生成代码提交信息。

S502：当达到预定周期时，打包处理代码提交信息，以生成待测版本。

S503：确定待测版本，获取待测版本的标识信息。

S504：根据标识信息，确定与待测版本相关联的父版本，确定父版本的质量状态；

S505：当父版本的数量为一个且父版本的质量状态为合格时，根据预设的版本质量状态继承规则，确定待测版本的质量状态为合格。

S505’：当父版本的数量为一个且父版本的质量状态为不合格时，若不存在与标识信息相关联的代码变更信息，则根据预设的版本质量状态继承规则，确定待测版本的质量状态为不合格；其中，代码变更信息为父版本的打包时间点到待测版本的打包时间点之间的代码变更信息。

S506：当父版本的数量为多个且所有父版本的质量状态均为合格时，根据预设的版本质量状态合并规则，确定待测版本的质量状态为合格。

S506’：当父版本的数量为多个且至少一个父版本的质量状态为不合格时，若不存在代码变更信息，则根据预设的版本质量状态合并规则，确定待测版本的质量状态为不合格。

上述实施例所提供的方法，将代码管理、版本管理以及版本质量测试等软件开发环节的测试工作进行了关联，将之前需要相关人员手工执行的工作自动化处理，大幅度降低了企业对人力的投入成本；依据版本质量状态的继承或者合并规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了自动化测试执行不稳定和覆盖不全等问题。

本发明实施例中，当父版本的质量状态为不合格时，若在父版本的打包时间点至待测版本打包时间点之间，存在代码变更信息，此时需要依据该代码变更信息对待测版本的质量状态进行确定。

例如，当父版本的数量为一个时，即版本A->版本B，若版本A的质量状态为不合格(例如bug没有修复)，但版本A与版本B之间存在代码变更信息，表示版本A的bug解决了，即证明版本B的质量状态为合格。

该方式同样适用于父版本数量为多个的情况，例如版本A以及版本B->版本C，若仅版本A的质量状态为不合格(例如bug没有修复)，但版本A与版本C之间存在代码变更信息，表示版本A的bug解决了，即证明版本C的质量状态为合格。

另外，对于版本A以及版本B->版本C，若版本A与版本B的质量状态均为不合格(例如bug没有修复)，但版本A与版本C之间存在代码变更信息，表示版本A的bug解决了；但版本B与版本C之间无代码变更信息，即证明版本B的bug没有解决，此时同样采用悲观测试方式，证明版本C的质量状态为不合格。

另外，也可以依据与代码变更信息相关联的代码注释，对其中不合格版本的bug是否已修复进行判断，以此确定待测版本的质量状态，具体地，该过程可以人为操作，也可以是机器操作。

本发明实施例中，质量状态可以用不同颜色进行标识，以区分版本是否达到合格标准，例如：

红色：标识版本有明显的bug，不能达到上线标准；

黄色：标识版本有bug风险，对于特定的特征继续进行回归测试；

绿色：标识版本测试通过，可以达到上线标准。

其中，红色与黄色均对应于版本质量不合格的状态，当父版本的质量状态有一个版本的质量状态为红色且不存在代码变更信息时，确定待测版本的质量状态为红色；当父版本的质量状态有一个版本的质量状态为黄色且不存在代码变更信息时，确定待测版本的质量状态为黄色；当父版本的质量状态均为绿色时，确定待测版本的质量状态为绿色。

进一步的，也可以将红色与黄色归为一类，例如，颜色标识橙色。当父版本中有一个版本的质量状态为红色或者黄色时，所得的的待测版本的质量状态为橙色，即表示该待测版本质量状态不合格。

更进一步的，在待对待测版本进行质量测试之后，还可以对其质量状态进行颜色标识并提供日志信息，例如，通过为绿色，未通过为橙色。

本发明实施例中，还可以依据对待测版本所测试的质量状态对其他测试结果进行纠错处理，例如，自动化测试，具体以本发明实施例所提供的方法测得结果为准。同时还可以依据该结果，对现有测试过程进行更新，以提高自动化测试结果的准确性以及覆盖度。

进一步的，对于版本状态初始化，可以通过继承上一版本的给定初始值。对于最开始版本的初始值，可以通过专业人员，利用现有测试环节进行测试，并将确定准确性较高的结果为该初始值。

本发明实施例所提供的方法，通过版本质量状态的继承或者合并规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了自动化测试执行不稳定和覆盖不全等问题。另外，本发明整合了代码管理、版本管理等软件版本开发环节的测试工作，将手工操作自动化，大幅度降低了企业对软件版本开发所投入的人力成本。

参见图6，示出了本发明实施例提供的一种版本质量测试的装置600的主要模块示意图，包括：

第一获取模块601，用于确定待测版本，获取所述待测版本的标识信息；

第二获取模块602，用于根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；

确定模块603，用于根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态。

本发明实施装置中所述确定模块603用于：当所述父版本的数量为一个且所述父版本的质量状态为合格时，确定所述待测版本的质量状态为合格；或

本发明实施装置中所述确定模块603用于：当所述父版本的数量为多个且所有父版本的质量状态均为合格时，确定所述待测版本的质量状态为合格；或

本发明实施装置还包括代码模块604，用于：监测主干代码信息，接收到与所述主干代码信息相关联的分支代码信息，合并所述分支代码信息至所述主干代码信息以生成代码提交信息；当达到预定周期时，打包处理所述代码提交信息，以生成所述待测版本。

本发明实施例所提供的装置，通过版本质量状态的继承或者合并规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了自动化测试执行不稳定和覆盖不全等问题。另外，本发明整合了代码管理、版本管理等软件版本开发环节的测试工作，将手工操作自动化，大幅度降低了企业对软件版本开发所投入的人力成本。

参见图7示出了可以应用本发明实施例的版本质量测试方法或版本质量测试装置的示例性系统架构700。

如图7所示，系统架构700可以包括终端设备701、702、703，网络704和服务器705。网络704用以在终端设备701、702、703和服务器705之间提供通信链路的介质。网络704可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备701、702、703通过网络704与服务器705交互，以接收或发送消息等。终端设备701、702、703上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交系统软件等(仅为示例)。

终端设备701、702、703可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器705可以是提供各种服务的服务器，例如对用户利用终端设备701、702、703所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的版本质量测试方法一般由服务器705执行，相应地，版本质量测试装置一般设置于服务器705中。

应该理解，图7中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

参见图8，其示出了适于用来实现本发明实施例的终端设备的计算机系统800的结构示意图。图8示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括第一获取模块、第二获取模块、确定模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，确定模块还可以被描述为“质量状态确定模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

确定待测版本，获取所述待测版本的标识信息；

根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；

根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态。

根据本发明实施例的技术方案，通过版本质量状态的继承或者合并规则，依据父版本的质量状态对待测版本进行质量状态测试，提高了版本质量测试的准确性以及智能度，同时克服了自动化测试执行不稳定和覆盖不全等问题。另外，本发明整合了代码管理、版本管理等软件版本开发环节的测试工作，将手工操作自动化，大幅度降低了企业对软件版本开发所投入的人力成本。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims

1.一种版本质量测试方法，其特征在于，包括：

确定待测版本，获取所述待测版本的标识信息；

根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态；其中，在父版本数量为一个的情况下使用继承规则，在父版本数量为多个的情况下使用合并规则或悲观测试规则。

2.根据权利要求1所述的方法，其特征在于，所述根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态包括：

3.根据权利要求1所述的方法，其特征在于，所述根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态包括：

当所述父版本的数量为多个且至少一个父版本的质量状态为不合格时，若不存在与所述标识信息相关联的代码变更信息，确定所述待测版本的质量状态为不合格。

4.根据权利要求1所述的方法，其特征在于，在所述确定待测版本，获取所述待测版本的标识信息之前，还包括：

监测主干代码信息，接收到与所述主干代码信息相关联的分支代码信息，合并所述分支代码信息至所述主干代码信息以生成代码提交信息；

当达到预定周期时，打包处理所述代码提交信息，以生成所述待测版本。

5.一种版本质量测试装置，其特征在于，包括：

第一获取模块，用于确定待测版本，获取所述待测版本的标识信息；

第二获取模块，用于根据所述标识信息，确定与所述待测版本相关联的父版本，获取所述父版本的质量状态；

确定模块，用于根据所述父版本的质量状态以及预设的版本质量状态确定规则，确定所述待测版本的质量状态；其中，在父版本数量为一个的情况下使用继承规则，在父版本数量为多个的情况下使用合并规则或悲观测试规则。

6.根据权利要求5所述的装置，其特征在于，所述确定模块用于：

7.根据权利要求5所述的装置，其特征在于，所述确定模块用于：

8.根据权利要求5所述的装置，其特征在于，还包括代码模块，用于：

9.一种版本质量测试的电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-4中任一所述的方法。

10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-4中任一所述的方法。