CN103679390B - 配置系统的后台测试方法及装置 - Google Patents

Abstract

本发明涉及一种配置系统的后台测试方法及装置，该方法包括：根据预先设定的项目创建方式，在所述配置系统中创建测试项目；根据预先设定的项目测试方式，在所述配置系统中测试所述测试项目；根据测试结果提示成功或失败，并删除所述测试项目。由此可见，该测试项目的上述流程模拟了开发人员使用该配置系统时的操作流程，因此，如果上述流程在执行过程中出现了问题，则表示使用该配置系统的开发人员也会遇到同样的问题，因而达到了及时发现配置系统的故障，并及时维护的技术效果。

Description

配置系统的后台测试方法及装置

技术领域

本发明涉及网络通信技术领域，具体涉及一种配置系统的后台测试方法及装置。

背景技术

配置系统是指能够为不同的项目提供一种通用的配置服务的系统，因此，很多项目都可以利用该系统实现项目的创建、测试以及管理等操作。但是，一旦配置系统本身出现问题，则会导致基于该配置系统实现的各个项目都无法正常地创建、测试及管理，由此影响各个项目的正常开发。

目前，当使用该配置系统的开发人员在具体使用的过程中发现了问题，并主动将问题上报给配置系统的运维人员时，该配置系统的问题才会被发现。或者，虽然也可以由运维人员每天以手动方式对配置系统进行测试，以便发现问题，但是，上述这些方式都存在着不能及时地发现配置系统的故障，容易导致维护不及时的缺陷。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的配置系统的后台测试方法及装置。

依据本发明的一个方面，提供了一种配置系统的后台测试方法，包括：根据预先设定的项目创建方式，在配置系统中创建测试项目；根据预先设定的项目测试方式，在配置系统中测试该测试项目；根据测试结果提示成功或失败，并删除测试项目。

可选地，后台测试方法中的各个步骤依次循环执行，则方法进一步包括：预先设置各个步骤循环执行的周期。

可选地，根据预先设定的项目创建方式，在配置系统中创建测试项目的步骤包括：创建测试项目的目标文件夹，并加载测试项目的数据文件；提交测试项目，将测试项目的数据文件保存到目标文件夹。

可选地，在提交测试项目时，进一步将测试项目的数据文件保存到版本服务器，其中，版本服务器为每次提交时保存的数据文件设置唯一的版本号。

可选地，在配置系统中测试测试项目的步骤之后进一步包括：在测试成功时对测试项目进行发布。

可选地，进一步检测在各个步骤的执行过程中是否存在错误，并在发现错误时报警。

可选地，在配置系统中创建测试项目的步骤之前，进一步包括步骤：在配置系统中加载用于创建测试项目的项目依赖文件。

依据本发明的另一方面，提供了一种配置系统的后台测试装置，包括：创建模块，适于根据预先设定的项目创建方式，在配置系统中创建测试项目；测试模块，适于根据预先设定的项目测试方式，在配置系统中测试测试项目；提示模块，适于根据测试结果提示成功或失败；以及删除模块，适于删除测试项目。

可选地，进一步包括：设置模块，适于预先设置创建模块、测试模块、提示模块以及删除模块的工作周期。

可选地，创建模块适于：创建测试项目的目标文件夹，并加载测试项目的数据文件；提交测试项目，将测试项目的数据文件保存到目标文件夹。

可选地，创建模块在提交测试项目时，进一步将测试项目的数据文件保存到版本服务器，其中，版本服务器为每次提交时保存的数据文件设置唯一的版本号。

可选地，进一步包括：发布模块，适于在测试成功时对测试项目进行发布。

可选地，进一步包括：检测模块，适于检测在各个模块的工作过程中是否存在错误，并在发现错误时报警。

可选地，进一步包括：加载模块，适于在配置系统中加载用于创建测试项目的项目依赖文件。

本发明提供的配置系统的后台测试方法及装置，能够根据预先设定的方式，在配置系统中自动地创建测试项目，并自动地对测试项目进行测试，得出测试结果。由此可见，该测试项目的上述流程模拟了开发人员使用该配置系统时的操作流程，因此，如果上述流程在执行过程中出现了问题，则表示使用该配置系统的开发人员也会遇到同样的问题，因而达到了及时发现配置系统的故障，并及时维护的技术效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的配置系统的后台测试方法的流程图;

图2示出了本发明另一具体实施例提供的配置系统的后台测试方法的流程图；以及

图3示出了本发明实施例提供的配置系统的后台测试装置的结构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例提供了一种配置系统的后台测试方法及装置，用以解决现有技术中不能及时地发现配置系统的故障，容易导致维护不及时的问题。

图1示出了本发明实施例提供的配置系统的后台测试方法的流程图。如图1所示，该方法包括如下步骤：

步骤S110：根据预先设定的项目创建方式，在配置系统中创建测试项目。

具体地，该步骤可采用如下方式实现：首先，加载创建测试项目时所需的项目依赖文件；然后，创建测试项目的目标文件夹，并加载测试项目的数据文件；最后，提交测试项目，将测试项目的数据文件保存到该目标文件夹。其中，在提交测试项目时，进一步将测试项目的数据文件保存到版本服务器，其中，版本服务器为每次提交时保存的数据文件设置唯一的版本号。

步骤S120：根据预先设定的项目测试方式，在配置系统中测试该测试项目。

步骤S130：根据测试结果提示成功或失败，并删除该测试项目。另外，在步骤S130中，当测试结果为成功时，还可以进一步对测试项目进行发布。

可选地，上述的各个步骤依次循环执行，以便实现24小时监测的效果，则该方法进一步包括：预先设置上述的各个步骤循环执行的周期。另外，为了实现全面监测的目的，还可以进一步检测在上述各个步骤的执行过程中是否存在错误，并在发现错误时报警。

上述方法能够模拟开发人员使用该配置系统时的操作流程，因此，如果上述流程在执行过程中出现了问题，则表示使用该配置系统的开发人员也会遇到同样的问题，因而达到了及时发现配置系统的故障，并及时维护的技术效果。

图2示出了本发明一个具体实施例提供的配置系统的后台测试方法的流程图。其中，图2所示的各个步骤都是按照设定周期循环执行的，为此，可以通过Crontab命令来实现这一点。Crontab命令用于设置周期性被执行的指令。具体设置时，Crontab可以任意定制指令的执行时间，例如每小时执行一次，每五分钟执行一次等，非常灵活方便。在Crontab命令中，将指令按行存储，一行代表一条指令，例如，test_project这一指令所对应的行数据的格式规范如下：“分钟/小时/月份中第几日/月份/一个星期中的第几日*要执行的程序”。例如可以用“*/5****test_project”来表示每五分钟执行一次test_project指令。通过将图2所示的各个步骤所对应的指令存储为Crontab命令的方式，就可以实现周期性执行的效果。

另外，在图2所示的各个步骤的执行过程中，一旦出现异常情况都会产生提示信息，以使测试人员在第一时间了解到该异常情况，进而及时维护。

如图2所示，该方法包括如下步骤：

步骤S210：在配置系统中加载项目依赖文件。其中，项目依赖文件是指创建测试项目时要用到的文件，也叫测试项目所依赖的文件。

具体地，项目依赖文件可以包括数据库文件、配置文件等多种文件，这些文件的功能类似于开发人员在前端使用该配置系统创建一个新项目时，配置系统所提供的系统界面的功能。例如，当开发人员在前端使用该配置系统创建一个新项目时，该配置系统的系统界面上将提供一些供开发人员使用的操作接口，例如，配置系统登录接口、新项目创建接口、项目名称设置接口等各类接口，开发人员通过这些接口实现新项目的创建。相应地，项目依赖文件就是用于在后台通过程序代码段、可执行文件等方式来实现这些操作接口的功能的文件。

在步骤S210中，可能出现的异常情况包括：项目依赖文件加载失败。通常，当配置系统的相关模块出现故障时会导致该异常情况，因此，一旦出现上述异常，在本实施例中将通过在屏幕上显示提示信息的方式提示给测试人员，以便测试人员及时维护。如果没有异常情况，则会自动转入步骤S220。

步骤S220：根据预先设定的项目创建方式，在配置系统中创建一个测试项目。

其中，创建测试项目的具体流程与开发人员在前端通过该配置系统创建一个新项目的流程相同，区别在于，开发人员在前端创建新项目时，是通过配置系统提供的系统界面上的操作接口来实现的，而本发明实施例中的测试项目是在配置系统的后台实现的，具体实现时，通过预先设定的程序代码段来模拟开发人员在前端通过操作接口创建新项目的流程，由此实现测试项目的创建。

具体地，在创建测试项目时，首先，要输入测试项目的名称，该名称是由程序预先定义好并在设定时间到达时自动输入的，例如，可通过代码“$this->prjname=$prjname;”来输入名称。

然后，要为该测试项目创建一个目标文件夹，用以存储该测试项目中产生的文件数据，例如，可通过代码“$r_local=GitWork::init($_SERVER['LOCAL_GIT'],$prjname);”来创建目标文件夹。

另外，为了便于从众多项目中查找到该测试项目，还可以进一步为该测试项目创建一个项目目录，用以表明该测试项目的存储位置，例如，可以通过代码“$r_work=GitWork::gclone($_SERVER['LOCAL_GIT']."/$prjname".".git",$_SERVER['WORKSPACE'],$prjname);”来创建该项目目录。

优选地，为了防止该测试项目中产生的文件数据出现丢失或损坏等意外情况，在本实施例中，还可以在版本服务器上设置一个项目远程仓库（也可称作项目远程文件夹），用来存储上述文件数据的备份。这里，版本服务器可以通过分布式版本控制服务器Git来实现。例如，可以通过代码“$r_remote=GitWork::init($_SERVER['REMOTE_GIT'],$prjname);$this->logger->info("[project:$prjname]create remote init");”来实现项目远程仓库的设置。在具体设置时，如果与版本服务器连接时连接失败，则会提示异常情况，由此提醒测试人员维护版本服务器与配置系统之间的网络连接，进而避免前端使用该配置系统的开发人员遭遇同样的故障。

最后，还要为该测试项目创建初始项目文件，并将这些初始项目文件作为该测试项目所产生的文件数据存储到上述目标文件夹以及项目远程仓库中。其中，创建初始项目文件的操作可通过如下代码实现：

$this->createStruct($path);//自定义配置文件

$this->createConfDef($path);//项目配置定义

$this->createConfData($path);//项目配置数据

$this->createVer($path);//项目版本文件

$this->createCheck($path);//项目测试文件

其中，上述的配置文件用以实现该测试项目的项目结构框架，配置定义用以对配置文件的格式规范进行定义，配置数据即为配置文件中的内容数据，版本文件是指反映项目版本信息的文件，项目测试文件是用于执行测试操作的文件。在创建上述初始项目文件的过程中，一旦发生异常情况也会提示给测试人员。一些常见的异常情况包括：由于本地硬盘存储空间不足，导致上述初始项目文件无法写入目标文件夹；或者，由于版本服务器的存储空间不足，导致上述初始项目文件无法写入项目远程仓库；或者，由于版本服务器与配置系统之间的连接断开，导致无法连接到版本服务器等。总之，上述异常情况一旦被发现就会由测试人员及时维护，从而避免前端的开发人员遭遇同样的故障。

步骤S230：向上述初始项目文件中写入测试数据，以保证测试项目是一个非空的项目，从而能够完成一定的功能。

这里，测试数据可以写入项目测试文件中，用以完成相应的功能。在本实施例中，测试项目的作用在于测试配置系统是否能够正常地支持一个项目从创建到测试及发布的各项操作，目的在于测试配置系统本身是否正常，因此，测试项目中的测试数据的具体内容及其实现的具体功能并不重要，只要其操作过程能够反映出一个常规项目的操作过程即可。例如，可以向项目测试文件中写入如下代码段：

上述代码段定义了测试数据的类型、属性等信息，以确保测试项目非空，且能够实现一定的功能。

除了上述代码段中定义的测试数据之外，本实施例中也可以采用其它的测试数据，具体取决于测试项目的功能。例如，在一个为多款游戏分别设置游戏标识以及对应的备案号的测试项目中，测试数据可以是多个游戏的游戏标识以及对应的备案号内容。

在写入测试数据的过程中，如果因为硬盘存储空间不足等原因也可能会提示异常情况，以便测试人员及时发现。

步骤S240：对上述的测试数据进行提交并保存。

通过测试数据的提交及保存操作，能够将测试数据分别保存到配置系统本地的目标文件夹以及版本服务器上的项目远程仓库，以便为后续的测试操作提供测试数据。另外，如果一个测试文件经过了多次修改，且在每次修改后都执行了提交并保存的操作，则版本服务器会为每次提交时的测试数据及其对应的初始项目文件设置一个唯一的版本号，用以标识每次提交时所保存的数据。在此步骤中如出现异常也会给出提示。

步骤S250：根据预先设定的项目测试方式，在配置系统中测试该测试项目。

其中，预先设定的项目测试方式是指该项目的测试流程，该测试流程可以是预先根据该测试项目的特点而设计的。例如，首先，可以在测试时先创建一个或多个测试地址，并分别构造每个测试地址所对应的测试环境。其中，测试环境是指该测试项目实际应用的场景。例如，以上述的为多款游戏分别设置游戏标识以及对应的备案号的测试项目为例来说，测试环境可以是360游戏中心，该游戏中心能够为用户提供多款游戏，因此，需要调用该项目为每款游戏设置游戏标识以及备案号。然后，将该测试项目分别加载到各个测试环境中，也就是由各个测试环境分别调用该测试项目以完成相应的功能。最后，在各个测试环境中分别运行该测试项目，以判断该测试项目能否正常运行。通过上面的方式就完成了测试项目的测试操作。

另外，为了便于对测试结果进行分析，在测试过程中，还可以进一步将产生的测试数据按照key-value的键值存储方式存储到测试数据库中。并且，在该测试数据库中，可以通过Redis存储结构来存储各项内容。并且，该测试数据库还可以对外提供统一的API（Application Programming Interface，应用程序接口），用来读取测试数据。

步骤S260：根据测试结果提示成功或失败。

如果该测试项目能够正常运行，则返回测试成功的测试结果，反之，则返回测试失败的测试结果。

步骤S270：在测试成功时对测试项目进行发布。

正常情况下，开发人员在前端通过配置系统创建一个项目并测试通过之后，会对该项目进行发布上线，使其能够在线上使用。为了测试配置系统的这一功能是否正常，在本实施例中，也需要对测试项目进行发布。具体实现时，可以通过预设的代码段来实现项目发布的功能。当项目发布之后，就可以应用到具体的实际场景中，并在该场景中提供各种配置数据。如果测试项目无法正常发布则会给出提示信息，以使测试人员及时发现这一异常。

步骤S280：删除测试项目。

当上述各个步骤都执行完毕之后，表明该测试项目的本次生命周期结束，因此，会将该测试项目及其相应的文件数据全部删除，以免产生过多的垃圾文件。

当设定时间到达时，上述的步骤S210至步骤S280将会重复执行。在本实施例中，每次执行时都会对同一个测试项目执行创建、测试和发布等操作。为了实现24小时无间隙监测的效果，可以将各个步骤的执行周期设置为与步骤S210至步骤S280的执行总时间相同，因而，每当步骤S280执行完毕后，则会立即重新开始执行步骤S210。例如，可以按照下述方式对同一个测试项目进行测试：假设步骤S210至步骤S280的执行过程总共耗时40分钟，则每天早8：00开始对该测试项目执行一次步骤S210至步骤S280中的操作，且每天早8：40开始又对该测试项目执行一次步骤S210至步骤S280中的操作……

进一步地，为了能够在任一时间点监测到步骤S210至步骤S280中的每个步骤能否正常执行，还可以将各个步骤的执行周期设置为与其中的一个步骤的执行时间相同。例如，可以按照下述方式对同一个测试项目进行测试：假设步骤S210至步骤S280的执行过程总共耗时40分钟，每个步骤平均耗时5分钟，则每天早8：00开始对该测试项目执行一次步骤S210至步骤S280中的操作，且每天早8：05开始又对该测试项目执行一次步骤S210至步骤S280中的操作，每天早8：10开始又对该测试项目执行一次步骤S210至步骤S280中的操作……通过这样的方式，在每个时间段内都有若干个不同的步骤在同时执行，从而能够及时监测到配置系统的各个功能的故障。

另外，在本发明其他的实施例中，也可以同时对多个不同的测试项目分别执行创建、测试和发布等操作，这些测试项目分别属于不同的操作类别，而且，这些测试项目在执行过程中基本能够用到配置系统提供的全部功能，因而能够全方位的监测配置系统的每个功能。例如，某些测试项目在进行测试之前，还可以执行测试预览的操作，以便开发人员检查输入的项目数据与实际生成的项目数据是否一致，为此，可以设置一个专门用于执行项目创建、预览、测试及发布等操作的测试项目。另外，还有些测试项目对应有多个版本号，在后续过程中可以根据版本服务器中存储的各个版本号对应的数据，来实现版本回滚功能，即：当某一新版本出现故障时，回滚到一个旧的版本，以实现项目的正常运行，为此，可以设置一个专门用于执行项目创建、测试、发布及回滚等操作的测试项目。

而且，在上述步骤的执行过程中发现异常情况时，不仅可以在屏幕上提示异常情况，而且还可以通过程序设定指定的接收方（例如测试人员的手机终端、邮箱地址等），以便及时通知相关负责人。

总之，通过本发明提供的配置系统的后台测试方法，能够在配置系统中自动地执行项目创建、测试及发布等操作过程，从而模拟开发人员使用该配置系统时的操作流程。因而，能够及时发现配置系统的故障，并及时进行维护。这样，既避免了现有技术中发现不及时的缺陷，也避免了人工操作时对人力成本的耗费。

图3示出了本发明实施例提供的一种配置系统的后台测试装置的结构示意图。如图3所示，该装置300至少包括：创建模块31、测试模块32、提示模块33和删除模块34。

其中，创建模块31根据预先设定的项目创建方式，在配置系统中创建测试项目。具体地，创建模块31具体用于创建该测试项目的目标文件夹，并加载该测试项目的数据文件；提交该测试项目，将该测试项目的数据文件保存到目标文件夹。其中，创建模块31在提交该测试项目时，进一步将该测试项目的数据文件保存到版本服务器，其中，版本服务器为每次提交时保存的数据文件设置唯一的版本号。可选地，该装置进一步包括：加载模块37，用于在配置系统中加载用于创建测试项目的项目依赖文件。

测试模块32根据预先设定的项目测试方式，在配置系统中测试该测试项目。

提示模块33根据测试结果提示成功或失败。可选地，该装置进一步包括：发布模块35，用于在测试成功时对该测试项目进行发布。可选地，该装置进一步包括：检测模块36，用于检测在各个模块的工作过程中是否存在错误，并在发现错误时报警。

删除模块34用于在上述各个模块执行完毕后删除该测试项目。

上述的各个模块依次循环工作。为此，该装置还可以进一步包括：设置模块，用于预先设置上述创建模块31、测试模块32、提示模块33以及删除模块34的工作周期。

其中，上述的各个模块的具体工作过程可参照方法实施例中相应步骤的描述，此处不再赘述。

本发明提供的配置系统的后台测试方法及装置，能够根据预先设定的方式，在配置系统中自动地创建测试项目，并自动地对测试项目进行测试，得出测试结果。由此可见，该测试项目的上述流程模拟了开发人员使用该配置系统时的操作流程，因此，如果上述流程在执行过程中出现了问题，则表示使用该配置系统的开发人员也会遇到同样的问题，因而达到了及时发现配置系统的故障，并及时维护的技术效果。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了A1、一种配置系统的后台测试方法，包括：根据预先设定的项目创建方式，在所述配置系统中创建测试项目；根据预先设定的项目测试方式，在所述配置系统中测试所述测试项目；根据测试结果提示成功或失败，并删除所述测试项目。

A2、如A1所述的方法，其中，所述后台测试方法中的各个步骤依次循环执行，则所述方法进一步包括：预先设置所述各个步骤循环执行的周期。

A3、如A1所述的方法，其中，所述根据预先设定的项目创建方式，在所述配置系统中创建测试项目的步骤包括：

创建所述测试项目的目标文件夹，并加载所述测试项目的数据文件；

提交所述测试项目，将所述测试项目的数据文件保存到所述目标文件夹。

A4、如A3所述的方法，其中，在提交所述测试项目时，进一步将所述测试项目的数据文件保存到版本服务器，其中，所述版本服务器为每次提交时保存的数据文件设置唯一的版本号。

A5、如A1所述的方法，其中，所述在所述配置系统中测试所述测试项目的步骤之后进一步包括：在测试成功时对所述测试项目进行发布。

A6、如A3-5任一所述的方法，其中，进一步检测在各个步骤的执行过程中是否存在错误，并在发现错误时报警。

A7、如A1所述的方法，其中，所述在所述配置系统中创建测试项目的步骤之前，进一步包括步骤：在所述配置系统中加载用于创建测试项目的项目依赖文件。

B8、一种配置系统的后台测试装置，包括：创建模块，适于根据预先设定的项目创建方式，在所述配置系统中创建测试项目；测试模块，适于根据预先设定的项目测试方式，在所述配置系统中测试所述测试项目；提示模块，适于根据测试结果提示成功或失败；以及删除模块，适于删除所述测试项目。

B9、如B8所述的装置，其中，进一步包括：设置模块，适于预先设置所述创建模块、测试模块、提示模块以及删除模块的工作周期。

B10、如B8所述的装置，其中，所述创建模块适于：创建所述测试项目的目标文件夹，并加载所述测试项目的数据文件；提交所述测试项目，将所述测试项目的数据文件保存到所述目标文件夹。

B11、如B10所述的装置，其中，所述创建模块在提交所述测试项目时，进一步将所述测试项目的数据文件保存到版本服务器，其中，所述版本服务器为每次提交时保存的数据文件设置唯一的版本号。

B12、如B8所述的装置，其中，进一步包括：发布模块，适于在测试成功时对所述测试项目进行发布。

B13、如B10-12任一所述的装置，其中，进一步包括：检测模块，适于检测在各个模块的工作过程中是否存在错误，并在发现错误时报警。

B14、如B8所述的装置，其中，进一步包括：

加载模块，适于在所述配置系统中加载用于创建测试项目的项目依赖文件。

Claims (11)

1.一种配置系统的后台测试方法，用于对所述配置系统进行测试，所述配置系统用于实现项目的创建、测试以及管理操作，该方法包括：

根据预先设定的项目创建方式，在所述配置系统的后台创建测试项目，其中，所述创建测试项目的实现方式包括：通过预先设定的程序代码段模拟在配置系统的前端通过操作接口创建新项目的流程，以实现测试项目的创建；

根据预先设定的项目测试方式，在所述配置系统中测试所述测试项目；其中，所述测试项目用于测试所述配置系统是否能够支持一个项目从创建到测试及发布的各项操作；

根据测试结果提示成功或失败，并删除所述测试项目；

其中，进一步检测在各个步骤的执行过程中是否存在错误，并在发现错误时报警；并且，所述后台测试方法中的各个步骤依次循环执行。

2.如权利要求1所述的方法，其中，所述方法进一步包括：预先设置所述各个步骤循环执行的周期。

3.如权利要求1所述的方法，其中，所述根据预先设定的项目创建方式，在所述配置系统中创建测试项目的步骤包括：

创建所述测试项目的目标文件夹，并加载所述测试项目的数据文件；

提交所述测试项目，将所述测试项目的数据文件保存到所述目标文件夹。

4.如权利要求3所述的方法，其中，在提交所述测试项目时，进一步将所述测试项目的数据文件保存到版本服务器，其中，所述版本服务器为每次提交时保存的数据文件设置唯一的版本号。

5.如权利要求1所述的方法，其中，所述在所述配置系统中测试所述测试项目的步骤之后进一步包括：在测试成功时对所述测试项目进行发布。

6.如权利要求1所述的方法，其中，所述在所述配置系统中创建测试项目的步骤之前，进一步包括步骤：在所述配置系统中加载用于创建测试项目的项目依赖文件。

7.一种配置系统的后台测试装置，用于对所述配置系统进行测试，所述配置系统用于实现项目的创建、测试以及管理操作，该装置包括：

创建模块，适于根据预先设定的项目创建方式，在所述配置系统的后台创建测试项目，其中，所述创建模块具体用于：通过预先设定的程序代码段模拟在配置系统的前端通过操作接口创建新项目的流程，以实现测试项目的创建；

测试模块，适于根据预先设定的项目测试方式，在所述配置系统中测试所述测试项目；其中，所述测试项目用于测试所述配置系统是否能够支持一个项目从创建到测试及发布的各项操作；

提示模块，适于根据测试结果提示成功或失败；以及

删除模块，适于删除所述测试项目；

检测模块，适于检测在上述各个模块的工作过程中是否存在错误，并在发现错误时报警；

其中，进一步包括：设置模块，适于预先设置所述创建模块、测试模块、提示模块以及删除模块的工作周期。

8.如权利要求7所述的装置，其中，所述创建模块适于：创建所述测试项目的目标文件夹，并加载所述测试项目的数据文件；提交所述测试项目，将所述测试项目的数据文件保存到所述目标文件夹。

9.如权利要求8所述的装置，其中，所述创建模块在提交所述测试项目时，进一步将所述测试项目的数据文件保存到版本服务器，其中，所述版本服务器为每次提交时保存的数据文件设置唯一的版本号。

10.如权利要求7所述的装置，其中，进一步包括：发布模块，适于在测试成功时对所述测试项目进行发布。

11.如权利要求7所述的装置，其中，进一步包括：加载模块，适于在所述配置系统中加载用于创建测试项目的项目依赖文件。