CN112631935B - 一种基于版本冲突的测试方法和装置 - Google Patents

Abstract

本申请公开了一种基于版本冲突的测试方法和装置，该方法包括：应用于基于版本控制系统subversion的测试环境，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断该第一公用代码文件直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，基于待测试增量代码文件版本和该第二公用代码文件，获得待测试增量代码文件的测试版本；基于目标代码文件版本和测试版本进行测试。待测试增量代码文件版本包括公用代码文件时，判断该公用代码文件与目标代码文件版本的已测试增量代码文件版本中公用代码文件存在冲突时，先消除版本冲突再进行测试，尽量减少版本冲突问题，提高测试结果和测试进度。

Description

一种基于版本冲突的测试方法和装置

技术领域

本申请涉及代码版本控制技术领域，尤其涉及一种基于版本冲突的测试方法和装置。

背景技术

在项目的迭代开发过程中，每次开发得到的代码文件版本，常常需要几个不同测试环境来进行测试，以保证测试的充分。目前，将某一时间点对应的投产的代码文件版本作为目标代码版本，之后修改均得到基于目标代码版本的增量代码文件版本，当增量代码文件版本在开发环境测试完成后，将增量代码文件版本发送至除开发环境之外的其他测试环境进行新一轮测试。

代码文件之间存在一定的复用性，涉及不同功能模块的代码之间具有相互独立的私有代码文件，但是，由于不同功能模块的依赖关系和框架层次，不同功能模块的代码之间可能存在公用代码文件。发明人经过研究发现，当增量代码文件版本包括公用代码文件时，在除开发环境之外的其他测试环境中，仍然直接基于目标代码版本和该增量代码文件版本进行测试，往往忽略了该增量代码文件版本与基于目标代码版本的其他增量代码文件版本的冲突，影响测试结果进而影响测试进度。

发明内容

有鉴于此，本申请实施例提供一种基于版本冲突的测试的方法和装置，先消除版本冲突再进行测试，尽量减少版本冲突问题，从而提高测试结果和测试进度。

第一方面，本申请实施例提供了一种基于版本冲突的测试的方法，应用于基于版本控制系统subversion的测试环境，所述方法包括：

当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖基于所述目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；

若是，基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；

基于所述目标代码文件版本和所述测试版本进行测试。

可选的，所述第一公用代码文件的类型具体为常量型或配置型。

可选的，若所述第一公用代码文件的类型为配置型，所述方法还包括：

判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；

若是，基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件；

对应地，所述基于所述目标代码文件版本和所述测试版本进行测试，具体为：

按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

可选的，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。

可选的，所述基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本，包括：

合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

第二方面，本申请实施例提供了一种基于版本冲突的测试装置，其特征在于，应用于基于版本控制系统subversion的测试环境，所述装置包括：

第一判断单元，用于当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖基于所述目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；

第一获得单元，用于若是，基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；

测试单元，用于基于所述目标代码文件版本和所述测试版本进行测试。

可选的，所述第一公用代码文件的类型具体为常量型或配置型。

可选的，若所述第一公用代码文件的类型为配置型，所述装置还包括：

第二判断单元，用于判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；

第二获得单元，用于若是，基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件；

对应地，所述测试单元具体用于：

按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

可选的，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。

可选的，所述第一获得单元包括：

合并子单元，用于合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

获得子单元，用于基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

与现有技术相比，本申请至少具有以下优点：

采用本申请实施例的技术方案，应用于基于版本控制系统subversion的测试环境，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断第一公用代码文件直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，基于待测试增量代码文件版本和已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；基于目标代码文件版本和测试版本进行测试。由此可见，当待测试增量代码文件版本包括公用代码文件时，在测试环境中并非直接基于目标代码文件版本和该待测试增量代码文件版本进行测试，而是判断上述公用代码文件与目标代码文件版本的已测试增量代码文件版本中公用代码文件存在冲突时，先消除版本冲突再进行测试，尽量减少版本冲突问题，从而提高测试结果和测试进度。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例中一种应用场景所涉及的系统框架示意图；

图2为本申请实施例提供的一种基于版本冲突的测试的方法的流程示意图；

图3为本申请实施例提供的一种基于版本冲突的测试的装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

现阶段，将某一时间点对应的投产的代码文件版本作为目标代码版本，之后修改均得到基于目标代码版本的增量代码文件版本，当增量代码文件版本在开发环境测试完成后，将增量代码文件版本发送至除开发环境之外的其他测试环境进行新一轮测试。但是，当增量代码文件版本包括公用代码文件时，在除开发环境之外的其他测试环境中，仍然直接基于目标代码版本和该增量代码文件版本进行测试，往往忽略了该增量代码文件版本与基于目标代码版本的其他增量代码文件版本的冲突，影响测试结果进而影响测试进度。

为了解决这一问题，在本申请实施例中，应用于基于版本控制系统subversion的测试环境，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断第一公用代码文件直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，基于待测试增量代码文件版本和已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；基于目标代码文件版本和测试版本进行测试。由此可见，当待测试增量代码文件版本包括公用代码文件时，在测试环境中并非直接基于目标代码文件版本和该待测试增量代码文件版本进行测试，而是判断上述公用代码文件与目标代码文件版本的已测试增量代码文件版本中公用代码文件存在冲突时，先消除版本冲突再进行测试，尽量减少版本冲突问题，从而提高测试结果和测试进度。

举例来说，本申请实施例的场景之一，可以是应用到如图1所示的场景中，该场景包括开发系统101和测试系统102，开发系统101将基于目标代码文件版本的待测试增量代码文件版本发送至测试系统102，测试系统102采用本申请实施例提供的基于版本冲突的测试方法实施方式，实现对基于目标代码文件版本的待测试增量代码文件版本的测试。

首先，在上述应用场景中，虽然将本申请实施例提供的实施方式的动作描述由测试系统102执行；但是，本申请实施例在执行主体方面不受限制，只要执行了本申请实施例提供的实施方式所公开的动作即可。

其次，上述场景仅是本申请实施例提供的一个场景示例，本申请实施例并不限于此场景。

下面结合附图，通过实施例来详细说明本申请实施例中基于版本冲突的测试的方法和装置的具体实现方式。

示例性方法

参见图2，示出了本申请实施例中一种基于版本冲突的测试方法的流程示意图。在本实施例中，应用于基于版本控制系统subversion的测试环境，所述方法例如可以包括以下步骤：

步骤201：当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖基于所述目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，执行步骤202。

由于现有技术中当增量代码文件版本包括公用代码文件时，在除开发环境之外的其他测试环境中，仍然直接基于目标代码版本和该增量代码文件版本进行测试，往往忽略了该增量代码文件版本与基于目标代码版本的其他增量代码文件版本的冲突，影响测试结果进而影响测试进度。因此，在本申请实施例中，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，首先需要判断基于该第一公用代码文件与基于同一目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突，即，执行步骤201。如果存在冲突，在除开发环境之外的其他测试环境中，直接基于目标代码版本和待测试增量代码文件版本进行测试，容易出现严重错误，影响测试结果进而影响测试进度；则需要执行步骤202。

其中，基于公用代码文件所包括代码内容的类型，可以将公用代码文件分为常量型和配置型。因此，在本申请实施例一种可选的实施方式中，所述第一公用代码文件的类型具体为常量型或配置型。

步骤202：基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本。

在本申请实施例中，如果存在冲突，首先需要解决该冲突问题，即，消除基于目标代码文件版本的待测试增量代码文件版本中第一公用代码文件，直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件存在的冲突。因此，可以在基于目标代码文件版本的待测试增量代码文件版本的基础上，结合基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件，获得该待测试增量代码文件的测试版本。

在步骤202具体实施时，首先，可以通过合并基于目标代码文件版本的待测试增量代码文件版本中第一公用代码文件，以及基于目标代码文件版本的待测试增量代码文件版本中第一公用代码文件的方式，解决上述冲突问题，得到合并公用代码文件；然后，在基于目标代码文件版本的待测试增量代码文件版本中私有代码文件的基础上，结合上述合并公用代码文件，得到待测试增量代码文件的测试版本。因此，在本申请实施例一种可选的实施方式中，所述步骤202例如可以包括以下步骤：

步骤A：合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

步骤B：基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

作为一种示例，假设目标代码文件版本为版本1，基于目标代码文件版本的待测试增量代码文件版本为基于版本1的版本2，基于目标代码文件版本的已测试增量代码文件版本为基于版本1的版本3，当版本2包括第一公用代码文件时，且版本2中第一公用代码文件直接覆盖版本3中第二公用代码文件存在冲突时，需要合并版本2中第一公用代码文件和版本3中第二公用代码文件，获得合并公用代码文件，基于版本2中私有代码文件和该合并公用代码文件，获得版本2的测试版本。

步骤203：基于所述目标代码文件版本和所述测试版本进行测试。

在本申请实施例中，在步骤202获得待测试增量代码文件的测试版本之后，在基于版本控制系统subversion的测试环境中，利用目标代码文件版本和待测试增量代码文件版本的测试版本，代替目标代码文件版本和待测试增量代码文件版本进行测试。

此外，在本申请实施例中，如果第一公用代码文件的类型为常量型，测试环境对应的常量型公用代码文件相较于第一公用代码文件“只多不少”，多余的一些常量型公用代码文件并不影响测试结果和测试进度；但是，如果第一公用代码文件的类型为配置型，测试环境对应的配置型公用代码文件与第一公用代码文件之间的关系必须“不多不少”，即，测试环境对应的配置型公用代码文件与第一公用代码文件之间需要一一对应，不对应的情况一般表示为测试环境对应的配置型公用代码文件与基于目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件冲突。

具体地，当第一公用代码文件的类型为配置型时，还需要判断测试环境对应的配置型公用代码文件与基于目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突。如果存在冲突，在除开发环境之外的其他测试环境中，直接按照测试环境对应的配置型公用代码文件执行步骤203，容易出现严重错误，影响测试结果进而影响测试进度；则需要解决该冲突问题，即，消除测试环境对应的配置型公用代码文件，与基于目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件存在的冲突。基于此，可以在测试环境对应的配置型公用代码文件中，删除基于目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件，实现对测试环境对应的配置型公用代码文件的改动，得到测试环境对应的配置型公用代码新文件，以便利用测试环境对应的配置型公用代码新文件，代替测试环境对应的配置型公用代码文件执行步骤203。因此，在本申请实施例一种可选的实施方式中，若所述第一公用代码文件的类型为配置型，所述方法还包括以下步骤：

步骤C：判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；若是，执行步骤D。

其中，测试环境对应的配置型公用代码文件，与基于目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件的冲突，表示为其他待测试增量代码文件版本中配置型第三公用代码文件，存在于测试环境对应的公用代码文件中。因此，在本申请实施例一种可选的实施方式中，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。

步骤D：基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件。

作为一种示例，假设目标代码文件版本为版本1，基于目标代码文件版本的待测试增量代码文件版本为基于版本1的版本4，基于目标代码文件版本的其他待测试增量代码文件版本为基于版本1的版本5，当版本4包括配置型第一公用代码文件，且测试环境对应的配置型公用代码文件包括版本5中配置型第三公用代码文件时，在测试环境对应的配置型公用代码文件中，删除版本5中配置型第三公用代码文件，得到测试环境对应的配置型公用代码新文件。

对应地，所述步骤203例如具体可以为：按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

通过本实施例提供的各种实施方式，应用于基于版本控制系统subversion的测试环境，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断第一公用代码文件直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，基于待测试增量代码文件版本和已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；基于目标代码文件版本和测试版本进行测试。由此可见，当待测试增量代码文件版本包括公用代码文件时，在测试环境中并非直接基于目标代码文件版本和该待测试增量代码文件版本进行测试，而是判断上述公用代码文件与目标代码文件版本的已测试增量代码文件版本中公用代码文件存在冲突时，先消除版本冲突再进行测试，尽量减少版本冲突问题，从而提高测试结果和测试进度。

示例性装置

参见图3，示出了本申请实施例中一种基于版本冲突的测试装置的结构示意图。在本实施例中，应用于基于版本控制系统subversion的测试环境，所述装置例如具体可以包括：

第一判断单元301，用于当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖基于所述目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；

第一获得单元302，用于若是，基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；

测试单元303，用于基于所述目标代码文件版本和所述测试版本进行测试。

在本申请实施例一种可选的实施方式中，所述第一公用代码文件的类型具体为常量型或配置型。

在本申请实施例一种可选的实施方式中，若所述第一公用代码文件的类型为配置型，所述装置还包括：

第二判断单元，用于判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；

第二获得单元，用于若是，基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件；

对应地，所述测试单元303具体用于：

按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

在本申请实施例一种可选的实施方式中，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。

在本申请实施例一种可选的实施方式中，所述第一获得单元302包括：

合并子单元，用于合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

获得子单元，用于基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

通过本实施例提供的各种实施方式，应用于基于版本控制系统subversion的测试环境，当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断第一公用代码文件直接覆盖基于目标代码文件版本的已测试增量代码文件版本中第二公用代码文件是否存在冲突；若是，基于待测试增量代码文件版本和已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；基于目标代码文件版本和测试版本进行测试。由此可见，当待测试增量代码文件版本包括公用代码文件时，在测试环境中并非直接基于目标代码文件版本和该待测试增量代码文件版本进行测试，而是判断上述公用代码文件与目标代码文件版本的已测试增量代码文件版本中公用代码文件存在冲突时，先消除版本冲突再进行测试，尽量减少版本冲突问题，从而提高测试结果和测试进度。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制。虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请。任何熟悉本领域的技术人员，在不脱离本申请技术方案范围情况下，都可利用上述揭示的方法和技术内容对本申请技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本申请技术方案的内容，依据本申请的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本申请技术方案保护的范围内。

Claims (8)

1.一种基于版本冲突的测试方法，其特征在于，应用于基于版本控制系统subversion的测试环境，包括：

当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖第二公用代码文件是否存在冲突，所述第二公用代码文件在基于所述目标代码文件版本的已测试增量代码文件版本中；

若是，基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；

基于所述目标代码文件版本和所述测试版本进行测试；

其中，所述基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本，包括：

合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

2.根据权利要求1所述的方法，其特征在于，所述第一公用代码文件的类型具体为常量型或配置型。

3.根据权利要求2所述的方法，其特征在于，若所述第一公用代码文件的类型为配置型，所述方法还包括：

判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；

若是，基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件；

对应地，所述基于所述目标代码文件版本和所述测试版本进行测试，具体为：

按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

4.根据权利要求3所述的方法，其特征在于，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。

5.一种基于版本冲突的测试装置，其特征在于，应用于基于版本控制系统subversion的测试环境，包括：

第一判断单元，用于当基于目标代码文件版本的待测试增量代码文件版本包括第一公用代码文件时，判断所述第一公用代码文件直接覆盖第二公用代码文件是否存在冲突，所述第二公用代码文件在基于所述目标代码文件版本的已测试增量代码文件版本中；

第一获得单元，用于若是，基于所述待测试增量代码文件版本和所述已测试增量代码文件版本中第二公用代码文件，获得待测试增量代码文件的测试版本；

测试单元，用于基于所述目标代码文件版本和所述测试版本进行测试；

其中，所述第一获得单元，具体用于：

若是，合并所述待测试增量代码文件版本中第一公用代码文件和所述已测试增量代码文件版本中第二公用代码文件，获得合并公用代码文件；

基于所述待测试增量代码文件版本中私有代码文件和所述合并公用代码文件，获得所述待测试增量代码文件的测试版本。

6.根据权利要求5所述的装置，其特征在于，所述第一公用代码文件的类型具体为常量型或配置型。

7.根据权利要求6所述的装置，其特征在于，若所述第一公用代码文件的类型为配置型，所述装置还包括：

第二判断单元，用于判断所述测试环境对应的配置型公用代码文件与基于所述目标代码文件版本的其他待测试增量代码文件版本中配置型第三公用代码文件是否存在冲突；

第二获得单元，用于若是，基于所述其他待测试增量代码文件版本中配置型第三公用代码文件，改动所述测试环境对应的配置型公用代码文件，获得所述测试环境对应的配置型公用代码新文件；

对应地，所述测试单元具体用于：

按照所述测试环境对应的配置型公用代码新文件，基于所述目标代码文件版本和所述测试版本进行测试。

8.根据权利要求7所述的装置，其特征在于，所述测试环境对应的配置型公用代码文件与所述其他待测试增量代码文件版本中配置型第三公用代码文件存在冲突具体为：所述测试环境对应的公用代码文件包括所述其他待测试增量代码文件版本中配置型第三公用代码文件。