CN103714002A

CN103714002A - 基于配置系统的项目测试方法及装置

Info

Publication number: CN103714002A
Application number: CN201310741026.7A
Authority: CN
Inventors: 左文建; 袁家美; 殷程; 王东洋
Original assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Current assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Priority date: 2013-12-26
Filing date: 2013-12-26
Publication date: 2014-04-09
Anticipated expiration: 2033-12-26
Also published as: CN103714002B

Abstract

本发明涉及一种基于配置系统的项目测试方法及装置，该方法包括：通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址；分别构造各个测试地址所对应的测试环境，将所述待测项目的数据文件分别加载到各个测试环境中；在各个测试环境中分别测试所述数据文件是否正确，并显示各个测试环境对应的测试结果。由此既避免了手动处理测试过程的繁琐操作，也避免了手动测试时可能发生的人为错误问题。并且，能够自动地在多个测试环境下测试项目，使得测试过程更加简便快捷。

Description

基于配置系统的项目测试方法及装置

技术领域

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

背景技术

目前，软件项目的测试和发布上线这两个过程相对独立，彼此之间关联性不大，需要由测试人员手动完成测试过程，得出测试结果后再人工决定是否对测试后的项目进行发布上线。

但是，这种项目测试方式存在很多弊端，例如，需要人工手动处理测试过程，这样对于测试过程比较复杂的项目则会浪费大量的人力成本和时间成本。另外，手动处理测试还容易引入遗漏或测试错误等人为问题，从而导致线上运行时存在潜在的风险。而且，对于能够应用于多种测试环境下的项目，还需要分别针对每个测试环境来执行测试过程，导致测试过程更加漫长繁琐。

发明内容

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

依据本发明的一个方面，提供了一种基于配置系统的项目测试方法，包括：通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址；分别构造各个测试地址所对应的测试环境，将所述待测项目的数据文件分别加载到各个测试环境中；在各个测试环境中分别测试所述数据文件是否正确，并显示各个测试环境对应的测试结果。

依据本发明的另一方面，提供了一种基于配置系统的项目测试装置，包括：接收模块，适于通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址；加载模块，适于分别构造各个测试地址所对应的测试环境，将所述待测项目的数据文件分别加载到各个测试环境中；测试模块，适于在各个测试环境中分别测试所述数据文件是否正确，并显示各个测试环境对应的测试结果。

本发明提供的基于配置系统的项目测试方法及装置，能够通过配置系统的测试配置接口接收待测项目的名称以及至少一个测试地址，并分别构造各个测试地址所对应的测试环境，并自动将待测项目的数据文件加载到各个测试环境中进行测试，由此既避免了手动处理测试过程的繁琐操作，也避免了手动测试时可能发生的人为错误问题。并且，能够自动地在多个测试环境下测试项目，使得测试过程更加简便快捷。

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

附图说明

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

图1示出了本发明实施例提供的基于配置系统的项目测试方法的流程图；

图2示出了本发明一个具体实施例提供的基于配置系统的项目测试方法的流程图；

图3示出了本发明另一个具体实施例提供的基于配置系统的项目测试方法的流程图；

图4示出了接收项目结构数据时所对应的配置系统的运行界面；

图5示出了对项目结构数据进行编译后得到的项目运行界面；

图6示出了当测试结果为成功时配置系统的界面示意图；以及

图7示出了本发明实施例提供的基于配置系统的项目测试装置的结构图。

具体实施方式

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

本发明实施例提供了一种基于配置系统的项目测试方法及装置，用以解决现有技术中手动处理测试时所导致的效率低下且容易出错的问题。

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

步骤S110：通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址。其中，测试地址是指测试待测项目的地址。

步骤S120：分别构造各个测试地址所对应的测试环境，将待测项目的数据文件分别加载到各个测试环境中。

步骤S130：在各个测试环境中分别测试数据文件是否正确，并显示各个测试环境对应的测试结果。

可选地，该方法进一步包括步骤：预先在配置系统的结构定义库中设置并存储多种数据结构以及每种数据结构对应的结构定义；则步骤S120中提到的待测项目的数据文件中进一步包括项目结构数据和项目内容数据，其中，项目结构数据中包含至少一种数据结构。相应地，步骤S130的实现过程具体包括：从结构定义库中获取与项目结构数据中包含的数据结构对应的结构定义，确定该项目结构数据是否与结构定义相符；如果确定结果为否，则确定测试结果为错误；否则，验证项目内容数据是否与项目结构数据匹配；如果确定结果为否，则确定测试结果为错误；否则，确定测试结果为成功。

可选地，当确定测试结果为成功时，该方法进一步包括：通过配置系统的发布接口发布待测项目，将待测项目发布时所对应的项目内容数据存储到版本服务器；其中，当待测项目的发布次数为多次时，该版本服务器为每次发布时所对应的项目内容数据设置唯一的版本号。另外，当接收到关于待测项目的版本回滚请求时，根据版本回滚请求中包含的版本号，获取并显示该版本号对应的项目内容数据。

由此可见，本发明提供的基于配置系统的项目测试方法，能够通过配置系统的测试配置接口接收待测项目的名称以及至少一个测试地址，并分别构造各个测试地址所对应的测试环境，并自动将待测项目的数据文件加载到各个测试环境中进行测试，由此既避免了手动处理测试过程的繁琐操作，也避免了手动测试时可能发生的人为错误问题。并且，能够自动地在多个测试环境下测试项目，使得测试过程更加简便快捷。

图2示出了本发明一个具体实施例提供的基于配置系统的项目测试方法的流程图。在本实施例中，以待测项目为360桌面，测试地址为两个为例进行介绍。如图2所示，该方法包括如下步骤：

步骤S210：通过配置系统的测试配置接口接收待测项目名称以及两个测试地址。

在本实施例中，要测试“360桌面”（即360desk）这一项目，因此，待测项目名称为“360desk”。并且，在实际应用中，该项目将会分别应用到两处实际场景中，因此，在本步骤中要分别填写两个测试地址，每个测试地址分别与一处实际场景对应。其中，测试地址可以通过预先构造的URL来表示，例如，在本实施例中包含如下两个测试地址：

http://dapp.wan.360.cn/360desk/sqol?scrol=&height=750

http://dapp.wan.360.cn/360desk/sxd?scrol=&height=1000

其中，第一个测试地址中的URL表示360游戏中心提供的神曲游戏的地址，也就是说，第一个测试地址对应的实际场景为神曲游戏。第二个测试地址中的URL表示360游戏中心的地址，也就是说，第二个测试地址对应的实际场景为360游戏中心。

步骤S220：分别构造两个测试地址所对应的测试环境，将待测项目的数据文件分别加载到两个测试环境中。

其中，构造测试地址所对应的测试环境时，只需将测试地址对应的URL地址打开即可。第一个测试地址所对应的测试环境就是360游戏中心提供的神曲这一游戏的游戏界面，相应地，将待测项目“360desk”的数据文件加载到该测试环境的步骤实际上是通过神曲游戏调用“360desk”这一项目来实现的。同理，第二个测试地址所对应的测试环境就是360游戏中心的游戏界面，相应地，将待测项目“360desk”的数据文件加载到该测试环境的步骤实际上是通过360游戏中心调用“360desk”这一项目来实现的。

步骤S230：在两个测试环境中分别测试数据文件是否正确，并显示两个测试环境对应的测试结果。

其中，在每个测试环境中测试数据文件是否正确的步骤可以通过直接运行数据文件，并检查运行结果是否正常来实现。例如，可以通过如下代码段来实现：

if($s==2)//测试预览

{

$tmp=Basecontrol::readfile("$p."/check.txt");

$lines=explode("\n",$tmp);

$cls=new Detection("PREVIEW");

$args=array();

$r=$cls->urlexam(array($p),$args);

$xcontext->lines=$lines;

$xcontext->test=$r;

$result=$brain->preview();

}

elseif($s==6)//确认测试成功

{

$result=$brain->mksure();

$xcontext->p =$p;

$xcontext->project =$project;

$xcontext->res =$result;

$xcontext->status =$s;

return XNext::useTpl("index/testok.html");

}

在上述代码段中，通过参数“s”的值来表示测试状态，其中，测试状态包括：测试预览、测试成功以及测试失败等。假设两个测试环境下的测试结果均为成功，则会通过如下URL来显示结果：

测试环境一：razer/cherry http://test.conf.svc.1360.com:8360/razer/cherry------ok

测试环境二：razer http://test.conf.svc.1360.com:8360/razer------ok

反之，如果测试结果为失败，则URL末尾显示的ok将被替换为false。

步骤S240：将步骤S230中得到的测试结果的相关数据存储到测试服务器中，以便于后续查询。

其中，步骤S240并不是一个必需的步骤，而是一个优选的步骤。在步骤S240中提到的测试结果的相关数据主要包括：测试项目的名称、测试环境的名称，以及对应的测试结果。其中，当测试结果为失败时，还可以进一步包括：程序失败时所对应的具体步骤，以及失败的潜在原因。通过步骤S240可以将每个项目在每次测试时的测试情况存储下来，以便于后续的分析处理。

具体地，在存储测试结果的相关数据时，可通过如下代码段实现：

$god=new conf_god();

if($from=='loc')

{

$tmp=explode("/",$p);

$prjname=$tmp[0];

$sence=$god->load_sence_simple($prjname,$p);

$result=$sence->export_data(false,$p."/handle.php");

}

elseif($from=='test')

{

$result=$god->getConfFromRedis($p,$_SERVER["BETA_REDIS"]);

}

else

{

$result=$god->getConfFromRedis($p,$_SERVER["ONLINE_REDIS"]);

}

$result=Basecontrol::encodearr($result);

$xcontext->result=$result;

在上述代码段中，通过Redis存储结构进行存储。在Redis存储结构中，利用高性能的key-value存储方式来存储数据，由此提升了存储效率，简化了查询操作。

步骤S250：当确定测试结果为成功时，通过配置系统的发布接口发布待测项目，将待测项目发布时所对应的数据文件存储到版本服务器。其中，当待测项目的发布次数为多次时，版本服务器为每次发布时所对应的数据文件设置唯一的版本号。

其中，将待测项目发布之后，该项目就能够上线运行。在本步骤中，进一步将待测项目发布时所对应的数据文件（也就是步骤S220中加载的数据文件）存储到版本服务器里。这里，版本服务器可以通过开源的分布式版本控制系统GIT来实现。利用版本控制系统能够轻松地实现对于多个项目的管理，并且，对于每个项目，还可以进一步管理该项目的多个版本。具体地，当同一个待测项目进行了多次更新并相应地执行了多次测试时，可能每次测试后都对该项目进行了发布，这样，该项目的发布次数为多次，这时，版本服务器为每次发布时所对应的数据文件设置唯一的版本号，以便于后续的查询。

例如，对于360desk这一项目来说，可能开发人员在10月1日对其开发完成后，对开发时所生成的数据文件一进行了测试，并在测试成功后发布上线，因此，版本服务器将数据文件一存储为版本号为1001的备份文件。之后，开发人员在11月1日又对该项目中的部分功能进行了优化升级，并对相应的数据文件二进行了测试，并在测试成功后发布上线，因此，版本服务器将数据文件二存储为版本号为1101的备份文件。同理，版本服务器里还可以存储更多版本号的备份文件。

步骤S260：当接收到关于待测项目的版本回滚请求时，根据版本回滚请求中包含的版本号，获取并显示该版本号对应的数据文件。

其中，版本回滚请求用于从项目的当前版本回滚到之前的某一旧版本，主要适用于如下情况：当前版本出现问题时，直接回滚到之前的某一旧版本，从而保证该项目能够在线上正常运行。

配置系统接收到上述的版本回滚请求后，根据版本回滚请求中包含的版本号，获取该版本号对应的数据文件，并对该数据文件进行加载及显示，以确保用户可以使用该版本的项目。除了直接在版本回滚请求中包含版本号的实现方式之外，也可以由配置系统自动地将该项目的所有版本号显示出来，然后由开发测试人员根据版本号的日期选择一个对应的版本号。

例如，仍然以步骤S250中的360desk项目为例来说，假设在开发人员于11月1日对该项目进行优化升级后，该项目在线上运行时突然出现故障，这时，只需通过版本号为1001的备份文件对项目执行回滚操作，就可以使项目以10月1日发布的旧版本稳定运行。这样一来，虽然用户暂时无法使用到新版本提供的优化功能，但是，仍然可以利用旧版本完成常规的操作，从而在项目重新开发、测试、发布、上线的漫长过程中，不会对用户产生太大影响，提高了用户的体验满意度。

其中，步骤S260中的回滚操作可以通过如下代码段来实现：

if($s==7)//回滚选择版本

{

$tags=GitWork::showtag($p);

$xcontext->tags=$tags;

$xcontext->p=$p;

$xcontext->project =$project;

return XNext::useTpl("index/tags.html");

}

elseif($s==8)//回滚结果

{

$tag=$request->get('tag');

$brain->args=array("tag"=>$tag);

$result=$brain->rollback();

if($result)

{

header("location:index.php?do=builddata");

exit;

}

else

{

die('回滚失败');

}

图3示出了本发明另一个具体实施例提供的基于配置系统的项目测试方法的流程图。在本实施例中，以待测项目为game-isbn，测试地址为一个为例进行介绍。如图3所示，该方法包括如下步骤：

步骤S310：预先在配置系统的结构定义库中设置并存储多种数据结构以及每种数据结构对应的结构定义。

为了实现配置系统的通用性，结构定义库中的数据结构应尽可能全面地满足各类项目的需求。例如，结构定义库中的数据结构可以包括：简单类型、节点（node）类型、文本（text）类型、选择（select）类型、输入框（checkbox）类型、单选按钮（radio）类型、图片（img）类型、列表类型、以及自定义类型等多种类型的数据结构。其中，列表类型又可以进一步分为节点列表类型和自定义列表类型。其中，每种数据结构的结构定义用于表明该数据结构的数据格式和用法规范。

步骤S320：接收项目game-isbn的项目结构数据，该项目结构数据中包含节点类型和输入框类型的数据结构；根据结构定义库中的结构定义对项目结构数据进行编译，并显示编译后的项目运行界面。

其中，项目game-isbn能够为数百款游戏分别设置游戏标识以及备案号，从而便于对这些游戏进行管理。图4示出了接收项目结构数据时所对应的配置系统的运行界面，如图4所示，开发人员可以通过右侧的空白处输入图4所示的代码段（即上述的项目结构数据）。在图4所示的代码段中，利用节点类型和输入框类型的数据结构定义了项目game-isbn的结构数据。其中，“so”为整个结构体的名称，在该结构体内部，通过“name:游戏备案”以及“type:node”这两个字段定义了一个类型为节点类型、名称为游戏备案的页面元素，并且，通过value字段定义了该页面元素对应的内容项。具体地，在value字段中定义了两个内容项，每个内容项都通过“name”、“type”等字段定义了该内容项的名称、类型等信息。例如，第一个内容项为字符串类型的“游戏gkey”，第二个内容项为字符串类型的“备案号&ISBN号”。并且，在每个内容项中，进一步通过“input”字段定义了能够在该内容项中输入的数据，例如能够输入文本类型的数据。

接收到上述的项目结构数据之后，从结构定义库中获取对应的结构定义，该结构定义规定了每种数据结构的数据格式和用法规范，根据这些数据格式和用法规范能够确定出图4中输入的代码段中各个字段的含义，并据此编译出图5所示的项目运行界面。如图5所示，该项目运行界面上包含“游戏备案”以及“游戏备案（1）”的页面元素，且“游戏备案（1）”的页面元素下方还显示有“复制”和“删除”按钮，从而可以对该页面元素执行复制或删除的操作。另外，“游戏备案（1）”的页面元素右侧进一步对应有“游戏gkey”和“备案号&ISBN号”两个内容项，这两个内容项的具体取值可以通过右侧的输入框输入。

步骤S330：通过图5所示的项目运行界面接收项目内容数据。

首先，针对“游戏备案（1）”这一页面元素所对应的两个内容项“游戏gkey”和“备案号&ISBN号”，开发人员在其右侧的两个空白输入框内分别输入“sqol”以及“文网游备字【2012】W-RPG029”。这里通过空白输入框输入的“sqol”以及“文网游备字【2012】W-RPG029”就是上文提到的项目内容数据。采用同样的方式，开发人员还可以对“游戏备案（1）”这一页面元素进行多次复制，并分别针对每次复制后的页面元素输入相应的项目内容数据，从而实现为多款游戏分别设置游戏标识和备案号的目的。

通过上述的步骤S310至步骤S330就完成了项目game-isbn的创建。

步骤S340：通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址。

其中，测试配置接口例如可以是图5所示的“测试”按钮。当开发人员点击该按钮之后，就可以对项目game-isbn进行测试。另外，开发人员还可以通过配置系统左侧的“测试地址”按钮输入一个测试地址。

步骤S350：构造该测试地址所对应的测试环境，将项目game-isbn的数据文件加载到该测试环境中。

其中，根据测试地址构造测试环境的操作可以根据上一实施例实现，此处不再赘述。项目game-isbn的数据文件主要是指上述步骤中提到的项目结构数据和项目内容数据。

步骤S360：在该测试环境中测试上述数据文件是否正确，并显示各个测试环境对应的测试结果。

具体地，可通过如下方式来测试数据文件是否正确：首先，从结构定义库中获取与项目结构数据中包含的数据结构对应的结构定义，确定该项目结构数据是否与结构定义相符；如果确定结果为否，则确定测试结果为错误；否则，继续验证项目内容数据是否与项目结构数据匹配；如果确定结果为否，则确定测试结果为错误；否则，则确定测试结果为成功。当测试结果为成功时，配置系统将显示出图6所示的界面。

由于本实施例中预先定义了各种数据结构的结构定义，因此，在后续的测试过程中可以验证项目中的数据文件是否与结构定义相符，从而能够判定出项目是否存在错误。

步骤S370：当确定测试结果为成功时，通过配置系统的发布接口发布项目game-isbn，将项目game-isbn发布时所对应的数据文件存储到版本服务器。其中，当项目game-isbn的发布次数为多次时，版本服务器为每次发布时所对应的数据文件设置唯一的版本号。

步骤S380：当接收到关于项目game-isbn的版本回滚请求时，根据版本回滚请求中包含的版本号，获取并显示该版本号对应的数据文件。

上述的步骤S370和步骤S380可参照上一实施例的实现方式实现，此处不再赘述。

图7示出了本发明实施例提供的基于配置系统的项目测试装置的结构图，如图7所示，该装置70至少包括：接收模块71、加载模块72以及测试模块73。

其中，接收模块71通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址。

加载模块72用于分别构造各个测试地址所对应的测试环境，将待测项目的数据文件分别加载到各个测试环境中。

测试模块73用于在各个测试环境中分别测试数据文件是否正确，并显示各个测试环境对应的测试结果。

可选地，该装置进一步包括：结构定义模块，适于预先在配置系统的结构定义库中设置并存储多种数据结构以及每种数据结构对应的结构定义；则待测项目的数据文件中进一步包括项目结构数据和项目内容数据，其中，项目结构数据中包含至少一种数据结构。相应地，测试模块73进一步用于：从结构定义库中获取与项目结构数据中包含的数据结构对应的结构定义，确定项目结构数据是否与结构定义相符；如果确定结果为否，则确定测试结果为错误；否则，验证项目内容数据是否与项目结构数据匹配；如果确定结果为否，则确定测试结果为错误；否则，确定测试结果为成功。

可选地，该装置进一步包括：发布模块74，用于在确定测试结果为成功时，通过配置系统的发布接口发布待测项目，并将所述待测项目发布时所对应的项目内容数据存储到版本服务器80；其中，当待测项目的发布次数为多次时，版本服务器80为每次发布时所对应的项目内容数据设置唯一的版本号。

相应地，该装置进一步包括：回滚模块75，用于在接收到关于待测项目的版本回滚请求时，根据版本回滚请求中包含的版本号，获取并显示版本号对应的项目内容数据。

在本发明提供的项目测试方法及装置中，能够通过配置系统的测试配置接口接收待测项目的名称以及至少一个测试地址，并分别构造各个测试地址所对应的测试环境，并自动将待测项目的数据文件加载到各个测试环境中进行测试，由此既避免了手动处理测试过程的繁琐操作，也避免了手动测试时可能发生的人为错误问题。并且，能够自动地在多个测试环境下测试项目，使得测试过程更加简便快捷。

另外，在本发明中，项目的测试和发布并不是彼此孤立的，而是相互关联的，而且，在项目测试通过后进行发布时，还会进一步将本次发布时的数据文件保存到版本服务器中，从而为开发人员提供版本回滚功能。利用该功能，可以使项目回滚到之前的某一稳定版本，从而避免了项目出现问题时不能运行的状况，为开发人员提供了便利，且提高了用户体验。

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

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

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

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

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

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

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

Claims

1.一种基于配置系统的项目测试方法，包括：

通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址；

分别构造各个测试地址所对应的测试环境，将所述待测项目的数据文件分别加载到各个测试环境中；

在各个测试环境中分别测试所述数据文件是否正确，并显示各个测试环境对应的测试结果。

2.如权利要求1所述的方法，其中，进一步包括步骤：预先在所述配置系统的结构定义库中设置并存储多种数据结构以及每种数据结构对应的结构定义；则所述待测项目的数据文件中进一步包括项目结构数据和项目内容数据，其中，所述项目结构数据中包含至少一种数据结构。

3.如权利要求2所述的方法，其中，所述在各个测试环境中分别测试所述数据文件是否正确的步骤进一步包括：

从所述结构定义库中获取与所述项目结构数据中包含的数据结构对应的结构定义，确定所述项目结构数据是否与所述结构定义相符；

如果确定结果为否，则确定测试结果为错误；否则，验证所述项目内容数据是否与所述项目结构数据匹配；

如果确定结果为否，则确定测试结果为错误；否则，确定测试结果为成功。

4.如权利要求3所述的方法，其中，当确定测试结果为成功时，进一步包括：通过配置系统的发布接口发布所述待测项目，将所述待测项目发布时所对应的项目内容数据存储到版本服务器；

其中，当所述待测项目的发布次数为多次时，所述版本服务器为每次发布时所对应的项目内容数据设置唯一的版本号。

5.如权利要求4所述的方法，其中，当接收到关于所述待测项目的版本回滚请求时，根据所述版本回滚请求中包含的版本号，获取并显示所述版本号对应的项目内容数据。

6.一种基于配置系统的项目测试装置，包括：

接收模块，适于通过配置系统的测试配置接口接收待测项目名称以及至少一个测试地址；

加载模块，适于分别构造各个测试地址所对应的测试环境，将所述待测项目的数据文件分别加载到各个测试环境中；

测试模块，适于在各个测试环境中分别测试所述数据文件是否正确，并显示各个测试环境对应的测试结果。

7.如权利要求6所述的装置，其中，进一步包括：

结构定义模块，适于预先在所述配置系统的结构定义库中设置并存储多种数据结构以及每种数据结构对应的结构定义；则所述待测项目的数据文件中进一步包括项目结构数据和项目内容数据，其中，所述项目结构数据中包含至少一种数据结构。

8.如权利要求7所述的装置，其中，所述测试模块进一步适于：从所述结构定义库中获取与所述项目结构数据中包含的数据结构对应的结构定义，确定所述项目结构数据是否与所述结构定义相符；如果确定结果为否，则确定测试结果为错误；否则，验证所述项目内容数据是否与所述项目结构数据匹配；如果确定结果为否，则确定测试结果为错误；否则，确定测试结果为成功。

9.如权利要求8所述的装置，其中，进一步包括：发布模块，适于当确定测试结果为成功时，通过配置系统的发布接口发布所述待测项目，并将所述待测项目发布时所对应的项目内容数据存储到版本服务器；其中，当所述待测项目的发布次数为多次时，所述版本服务器为每次发布时所对应的项目内容数据设置唯一的版本号。

10.如权利要求9所述的装置，其中，进一步包括：回滚模块，适于当接收到关于所述待测项目的版本回滚请求时，根据所述版本回滚请求中包含的版本号，获取并显示所述版本号对应的项目内容数据。