CN108536578A - 一种测试方法及装置 - Google Patents

Abstract

本申请公开了一种测试方法及装置，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：确定待测试对象和待测试的测试类别，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。通过本方法，摆脱对沙箱环境的依赖，能够有效简化用户在测试前期的准备操作，从而提升测试过程准备阶段的效率，并缩减测试过程的整体耗时。

Description

一种测试方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种测试方法及装置。

背景技术

区别与传统在线旅游平台(Online Travel Agent，OTA)，EBooking等线下传输订单的销售模式，直连对接技术是一种最新兴起的在线旅游平台(后续称之为业务平台)与业务提供方(例如：酒店、机票等商家)之间的连接技术。

传统OTA技术采用预订代理商的方式(即指传统的业务平台作为预订代理商，酒店、航空公司等业务提供方作为业务平台预留一定数量的客房、机票等业务产品，业务平台再将预留的业务产品提供给用户，从而用户可在业务平台上获得相应的业务产品)，用户在传统的OTA平台上预订酒店时，在预订平台上生成订单，并通过人工处理的方式下单到对应的酒店系统。而直连对接技术可以实现业务提供方(如：酒店服务器)与业务平台在后台系统的联通，当用户通过直连的业务平台预订酒店或者其他资源时，直接与用户进行实时对接，这样用户可以通过业务平台，直接在业务提供方处获得预订服务。

其中，业务提供方将后台系统接入到业务平台上，首先需要进行账号授权，然后是服务授权和接入，为了保证采用直连技术的业务平台能够正常运行，需要对业务提供方的账号测试和权限验证，在业务平台上对接入的业务提供方进行联调测试。

现在的测试方法，对业务提供方的测试账号、测试数据、测试环境、权限验证的依赖都很重，使得联调对接非常复杂，耗时耗力，效率低下。

发明内容

本申请实施例提供一种测试方法及装置，用以解决现有技术中业务提供方在进行测试时的操作繁琐且效率较低的问题。

本申请实施例提供的一种测试方法，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，所述方法包括：

确定待测试对象和待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

本申请实施例另提供的一种测试方法，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

提供测试界面；

基于所述测试界面确定待测试对象以及待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

本申请实施例提供的一种测试装置，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

测试确定模块，确定待测试对象和待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

事件确定模块，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

本申请实施例另提供的一种测试装置，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

界面展示模块，提供测试界面；

测试确定模块，基于所述测试界面确定待测试对象以及待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

测试确定模块，确定待测试对象以及调用的待测试的测试类别；

事件确定模块，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

业务平台针对不同的业务功能，创建了相应的测试服务，同时，业务平台针对不同类别的测试服务，设置了能够触发该类别测试服务下不同测试功能的事件，作为待测试事件，并且，为了便于测试操作，业务平台还针对不同测试事件设定相应的测试数据。故在进行实际测试时，业务平台将确定待测试对象和待测试的测试类别，又由于测试服务与测试事件之间具有对应关系，那么，业务平台将确定相应的待测试事件，并基于测试请求确定出待测试对象、所要测试的测试类别、待测试事件，进一步确定出相应的测试数据，从而将测试数据发送给待测试对象执行测试。显然，相对于现有技术中的沙箱测试方式，本申请实施例中的测试方式能够有效减少在测试前期繁琐的设置操作，从而缩减了整个测试过程的耗时，提升了测试的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中采用沙箱环境的测试过程；

图2a为本申请实施例提供的直连对接架构示意图；

图2b及2c为本申请实施例提供的测试方法所基于的结构示意图；

图2d为本申请实施例提供的测试过程；

图3a为本申请实施例提供的另一种测试过程的示意图；

图3b为本申请实施例提供的测试界面的示意图

图4a为本申请实施例提供的在实际应用场景下业务平台所提供的mock服务的架构示意图；

图4b为本申请实施例提供的对接商进行测试的过程示意图；

图4c及4d为本申请实施例提供的两种测试界面示意图；

图5为本申请实施例提供的测试装置结构示意图；

图6为本申请实施例提供的另一种测试装置结构示意图。

具体实施方式

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

现有测试技术中，业务平台通常会提供一种用于进行测试的仿真测试环境，即，沙箱环境。沙箱环境可认为是具有完整业务功能的封闭测试环境，在使用沙箱环境进行测试时，业务提供方需要按照真实的业务对接流程进行测试准备，具体而言，业务提供方在使用沙箱环境执行测试前，需要根据不同的业务场景，在业务平台上注册不同的沙箱测试账号，同时针对业务平台进行服务授权，并自行准备相应的测试数据，此后便可进行相应的测试。

以现有的淘宝开放平台(Taobao Open Platform，TOP)为例，如图1所示，当业务提供方需要在TOP平台上进行测试时，其需要注册满足沙箱环境的测试账号，只有在业务提供方注册了测试账号的前提下，才能够使用沙箱环境进行测试。此后，业务提供方还需要发布待测试数据，所发布的待测试数据通常需要按照设定的规则逐一进行编辑，否则在测试过程中将出现测试异常。并且，若业务提供方要进行不同的测试，往往需要进入不同的测试环境。

可见，业务提供方在现有测试过程中，往往需要进行过于繁琐的前期操作，对业务提供方的测试账号、测试数据、测试环境、权限验证的依赖都很重，使得联调对接非常复杂，导致测试过程的耗时较长且效率较低。

直连对接技术(又可以简称为直连技术)作为一种新的连接技术，应用于诸如酒店、票务的预订业务场景下。不同于传统预订代理商的方式(预定代理商的方式，是指传统的业务平台作为预订代理商，酒店、航空公司等业务提供方为业务平台预留一定数量的客房、机票等业务产品，业务平台再将预留的业务产品提供给用户，从而用户可在业务平台上获得相应的业务产品)，用户在传统的OTA平台上预订酒店时，在预订平台上生成订单，由于传统平台与酒店系统无法相连，所以没有办法直接在对应的酒店系统上生成订单，只能通过人工处理的方式下单到对应的酒店系统(目的在于核销预留的资源)。直连对接技术可以实现业务提供方(如：酒店服务器)与业务平台在后台系统的联通，当用户通过直连的业务平台预订酒店或者其他资源时，在直连的业务平台上生成订单的同时，也通过直连接口可以直接下单到业务提供方，无需再进行人工处理，直接与用户进行实时对接，这样用户可以通过业务平台，直接在业务提供方处获得预订服务(如：用户直接向酒店发送房间的预订请求)。

但正如前述，业务提供方为了实现与用户之间的直连对接，业务提供方往往需要将自身的接口与业务平台上的接口进行适配，为了保证适配后的接口在实际应用时能够正常运行，业务提供方通常会对能够实现不同业务功能的接口进行测试，在执行测试过程中，主要依赖业务平台上的沙箱测试环境，由于沙箱测试环境属于封闭的自主运行测试环境，那么，对于业务提供方而言，其前期准备较为繁琐，使得进行测试的成本和时长均消耗较大。

基于此，本申请实施例提供一种测试方法，在业务平台上将各类业务功能采用mock的方式进行相互隔离，使得每一种业务功能形成独立运行的测试服务。从而，业务提供方可摆脱对沙箱测试环境的依赖，不再需要采用现有的服务授权过程，而是可以直接使用不同的测试服务对相应的业务功能进行测试。

需要说明的是，本申请实施例中，所采用的架构可如图2a所示，在图2a 中，业务平台上接入了不同的业务提供方，不同业务提供方通过与业务平台上的业务接口统一适配，从而满足了业务平台的要求，实现与同样使用该业务平台的需求方用户之间进行直连对接。

其中，所述的业务平台，包括但不限于：网站。所述的用户，包括但不限于：个人用户、企业用户、商户、在线旅行社(Online Travel Agent，OTA) 等。所述的业务提供方，包括但不限于：酒店、航空公司、影院、医院等能够提供预订业务的提供方。

当然，针对如图2a所示的架构，在实际操作时，需求方用户可以通过业务平台的客户端(或浏览器)访问至业务平台服务器，需求方用户所发出的业务操作将直接传输至业务提供方的服务器中，从而直接获得业务提供方所提供的业务(即，直连对接)。

基于图2a所示的架构，在本申请实施例中，当某一业务提供方需要接入该业务平台时，则需要进行相应的测试，以模拟实际的运行环境，在一种测试场景中，如图2b所示，业务提供方将使用业务平台上的测试服务进行测试。而在另一种测试场景中，如图2c所示，多个业务提供方均使用业务平台上的测试服务进行测试，业务平台可以针对不同的业务提供方提供不同的测试服务，当然，业务平台也可预先与各业务提供方约定采用相同的业务接口，故此时，不同的业务提供方可使用相同的测试服务进行测试。

这里需要说明的是，在测试环境下，业务平台为业务提供方提供了测试服务，那么，业务提供方便可看作是使用了业务平台测试服务的待测试对象。上述如图2b或2c所示的测试场景并不应理解为对本申请的限定。

具体而言，本申请实施例提供一种测试方法，如图2d所示，该方法应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，具体包括以下步骤：

S201：确定待测试对象和待测试的测试类别。

在本申请实施例中，在测试发起时，可认为是针对业务平台上测试服务的触发或调用，在一种方式下，测试服务的触发或调用可由待测试对象发出，而在另一种方式下，测试服务的触发或调用可由业务平台自行发出(如：在自动测试场景下，当待测试对象接入业务平台后，该业务平台可自行发出针对相应测试服务的触发或调用，以完成测试)，这两种方式并不构成对本申请的限定。

所述的测试对象，包括但不限于：需要进行测试的业务提供方服务器、该服务器中某个业务功能单元等，在本申请实施例中，待测试对象可认为是与提供测试服务的测试平台建立连接的业务提供方。

待测试的测试服务，由业务平台提供，测试服务面向与业务平台对接的各待测试对象。应理解，在测试环境下，业务平台可模拟实际应用中不同的业务功能，形成分别对应于不同业务功能的测试服务。

以接口测试为例，业务平台能够模拟不同类别接口的实际功能，形成不同类别的测试服务，不同的接口用于实现不同的业务。对应于每一接口的测试服务，具备该接口的实际接口功能，例如：对于下单接口而言，该下单接口所对应的下单测试功能，在测试环境下能够实现下单功能。其中，这里所述的接口，可包括业务平台提供给业务提供方的各类软件接口。诸如：应用程序编程接口 (Application Programming Interface，API)、JAVA接口等。需要说明的是，本申请实施例中，可采用mock测试的方式，创建测试服务。这里并不构成对本申请的限定。

S202：根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件。

业务平台针对不同类别的测试服务，预先设置了不同的事件(即，待测试事件，如：下单测试事件、订单查询测试事件等等)，这些待测试事件用于触发不同类别测试服务下的不同测试功能，也即，业务平台预先建立了测试类别与测试事件之间的对应关系。

需要说明的是，在本申请实施例中的一种情况下，对于任一类别的测试服务而言，可以对应某一待测试事件；而在本申请实施例中的另一种情况下，对于任一类别的测试服务而言，可以对应多个待测试事件。当然，这里并不构成对本申请的限定。

S203：根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据。

本申请实施例中，不同的事件对应不同的测试数据，所述的测试数据，可认为是能够触发相应业务功能的代码数据，故测试数据可看作是待测试事件的载体。而业务平台在预设了待测试事件的同时，也设置了与测试事件所对应的测试数据，那么，便可以根据测试请求所对应的待测试事件，确定出相匹配的测试数据。

S204：通过所述测试类别对应的接口将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

在确定了测试数据后，便可以将该测试数据发送给待测试对象，在本申请实施例中，业务平台上不同类别的测试服务对应着相应的接口，业务提供方在与业务平台建立连接后，也会进行接口适配，换言之，业务平台上某一类别的测试服务与业务提供方自身相同类别的业务功能之间通过相应的接口对接。其中，所述的接口可以包括如前所述的软件接口，也可以包括硬件接口，这里并不构成对本申请的限定。

测试数据是待测试事件的载体，那么，当待测试对象接收到了测试数据，也就相当于产生了相应的事件，进一步地，待测试对象中的某项业务功能将处理该测试数据，即，执行测试。

从上述内容中可知，业务平台针对不同的业务功能，创建了相应的测试服务，同时，业务平台针对不同类别的测试服务，设置了能够触发该类别测试服务下不同测试功能的事件，作为待测试事件，并且，为了便于测试操作，业务平台还针对不同测试事件设定相应的测试数据。故在进行实际测试时，业务平台将确定待测试对象和待测试的测试类别，又由于测试服务与测试事件之间具有对应关系，那么，业务平台将确定相应的待测试事件，并基于测试请求确定出待测试对象、所要测试的测试类别、待测试事件，进一步确定出相应的测试数据，从而将测试数据发送给待测试对象执行测试。显然，相对于现有技术中的沙箱测试方式，本申请实施例中的测试方式能够有效减少在测试前期繁琐的设置操作，从而缩减了整个测试过程的耗时，提升了测试的效率。

在本申请实施例中，不同类别的测试服务具有多种具体的测试功能，显然，为了实现对每一种测试功能的测试，也就需要多种测试事件，换言之，对于任一类别的测试服务而言，均对应的多个待测试事件(即，待测试事件集合)，基于此，前述步骤中，确定与所述待测试的测试类别对应的待测试事件，包括：确定与所述待测试的测试类别对应的待测试事件集合，从所述待测试事件集合中，确定出与所述待测试的测试类别对应的待测试事件。

这里需要说明的是，除了按照不同的测试功能来确定每一类别的测试服务对应的全部待测试事件之外，还可以按照不同的测试场景所确定，具体而言，确定所述测试服务所对应的测试场景，统计所述测试场景对应的事件，作为触发所述测试服务的事件。例如：针对进行酒店预订的支付测试服务而言，可以按照银行卡支付、第三方应用支付等场景来设置相应的测试事件。

此外，作为本申请实施例中一种可能的方式，不同的待测试事件具有相应的待测试事件标识，那么，在实际操作中，便可以根据所需调用的待测试事件的标识，来确定待测试事件，其中，待测试事件标识可以是采用编号的形式，例如：A-1事件，其表示在待测试的A类测试服务中的1号事件。当然，这里并不构成对本申请的限定。对于该示例而言，每一类别的测试服务所对应的待测试事件集合中，可按照事件的排列顺序对待测试事件进行编号，也可以按照测试场景进行编号，这里并不构成对本申请的限定。

在本申请实施例中，业务平台预先建立测试事件与测试数据之间的对应关系，具体而言，通过以下方式建立测试事件与测试数据之间的对应关系，包括：针对不同类别的测试服务，分别执行以下操作：

确定该种测试类别所包含的至少一个测试事件，并为每个所述测试事件配置测试数据，建立所述测试事件与所述测试数据之间的对应关系。其中，不同测试事件对应的测试数据进行隔离存储。

采用隔离存储的方式使得每一测试事件均具备归属于自身的测试数据，使得不同的测试事件之间不会相互干扰。

当确定了测试数据后，便可以将测试数据发送给测试对象，在本申请实施例中，针对不同的测试对象，可预先指示任一测试对象，设置该测试对象所对应的地址(即，测试地址)，那么，将所述测试数据发送给所述待测试对象，包括：确定所述待测试对象的地址，根据所述地址，将所述测试数据发送至所述地址对应的服务器。

其中，所述测试地址可以采用诸如统一资源定位符(Uniform Resource Locator，URL)、IP地址等形式，这里并不作具体限定。

除了上述内容之外，在将所述测试数据发送给所述待测试对象之后，所述方法还包括：接收所述待测试对象发送的测试反馈信息，所述测试反馈信息中包含测试事件标识和实际测试结果，根据测试事件与参考测试结果之间的对应关系，确定与所述测试反馈信息中包含的测试事件标识对应的参考测试结果，根据所述实际测试结果和所述参考测试结果，判断所述待测试对象是否运行正常。

在待测试对象接收到了测试数据进行测试之后，便会生成实际的测试结果，并向业务平台反馈该结果，也即，测试反馈信息。同时，由于测试数据中包含测试事件标识，所以，由待测试对象所反馈的测试反馈信息中，也就会包含测试事件标识。

此外，所述的参考测试结果，也可由业务平台预先生成，其反映了测试事件的期望测试结果。相应地，也就可以根据所述实际测试结果和所述参考测试结果，判断所述待测试对象是否运行正常。

上述的测试结果均会被业务平台所存储，以便于查询使用，所以，所述方法还包括：获取测试结果查询消息，所述测试结果查询消息中包含测试类别，确定与所述测试类别对应的判断结果，并显示。

基于此，作为本申请实施例中的一种方式，所述方法还包括：在确定与所述测试类别对应的判断结果时，分析判断结果，并确定对所述测试类别进行测试的优化策略。

本申请实施例中的上述方法，适用于实际的酒店业务测试场景，其中，所述测试对象包括：与所述测试平台通过直连方式进行连接的酒店服务器。

具体地，在接口测试场景，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，包括：当确定的测试类别为接口类测试服务时，通过第一测试接口，将与所述接口类测试服务对应的测试数据发送给所述酒店服务器，使所述酒店服务器基于所述测试数据进行测试。

其中，所述接口类测试服务包含验证价格库存接口、预订接口、订单查询接口和取消订单接口中的至少一种或者多种。

此外，在订单测试场景，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，包括：当确定的测试类别为订单状态类测试服务时，通过第二测试接口，将与所述订单状态类测试服务对应的测试数据发送给所述酒店服务器，使所述酒店服务器基于所述测试数据进行测试；

其中，所述订单状态类测试服务包含入住状态、离店状态、结账状态、订单状态中的至少一种或者多种。

基于以上内容，在本申请实施例中还提供一种测试方法，如图3a所示，具体包括以下步骤：

S301：提供测试界面。

所述的测试界面可以如图3b所示，该测试界面中含有测试服务选择区域、待测事件菜单、测试数据展示区域、测试结果展示区域、测试地址展示区域等。在进行测试时，可基于该测试界面发出测试请求。

以测试服务选择区域和待测试事件菜单为例，图3b中的测试界面上，具有不同的待测接口服务(即，测试服务选择区域)，测试发起者可以点击不同的待测接口选项，以选择需要进行测试的接口。同时，针对每一待测接口服务，测试界面上还提供了对应的待测试事件菜单，那么，测试发起者便可以通过待测试事件菜单，选择不同的待测试事件。当然，如图3b所示的方式并不构成对本申请的限定。

S302：基于所述测试界面确定待测试对象以及待测试的测试类别。

S303：根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件。

S304：根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据:。

S305：通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

步骤S302至步骤S305可参考前述内容，这里不再过多赘述。

其中，需要说明的是，基于所述测试界面确定待测试对象以及待测试的测试类别，包括：当在所述测试界面的所述测试类别选择区域中监测到测试服务的选择指令时，根据所述选择指令，确定待测试对象以及待测试的测试类别。

所述方法还包括：若测试界面中还包含实际测试结果显示区域，则接收所述测试对象发送的实际测试结果，并将所述实际测试结果显示在所述实际测试结果显示区域。

基于如图3a所述的方法，业务平台针对自身的接口，创建与该接口对应的测试服务，其中，测试服务具备该接口全部的接口功能，可以在测试环境下使用，同时，业务平台还会统计出能够触发不同接口功能的事件，可以认为，在测试环境下，将统计出的事件作为待测试事件，就可以对相应的接口功能进行测试，并且，为了便于用户便于执行测试操作，业务平台还会针对各事件设定相应的测试数据，本申请实施例中的测试数据，可认为是一种数据模板，测试发起者可以在该数据模板中按照实际测试的需要调节相应的参数，避免了自行准备测试数据的繁琐操作。

相较于现有技术，本申请实施例中的上述方式，摆脱对沙箱环境的依赖，能够有效简化了测试前期的准备操作，从而提升测试过程准备阶段的效率，并缩减测试过程的整体耗时。

下面以一应用示例对以上方法进行说明：

在本示例中，对接商可以是酒店(或酒店集团)，业务平台仍可采用如图 3b所示的测试界面，故对接商可以在该测试界面中选择需要进行测试的待测试事件。

同时，结合图4a所示，对于酒店等对接商而言，其能够提供相应的预订业务，所以，图4a中所包含的接口包括：试单、下单、查询、取消等4种类型的接口，相应地，在图4a中，还包括不同的业务场景，即包括：入住、离店、结账、卖家取消、取消结账等业务场景。这里需要说明的是，图4a中所示出的接口类型和场景类型，仅是一种示例，在实际应用中，还可能包含其他类型的接口和业务场景，这里并不构成对本申请的限定。

此外，业务平台能够向对接商提供mock服务，在图4a中，不同的mock 服务由不同的功能单元表示，“mock请求组装”功能单元，用于根据用户在测试界面中所选择的待测试事件和测试数据，生成测试请求(可以是下单测试请求、查询测试请求等)。“响应接收和校验”功能单元用于接收对接商所回传的订单状态，并确定订单状态的正确性。“接口标准定义”功能单元，用于确定不同待测试事件所对应的标准响应结果。“订单更新服务”单元用于更新订单。“订单结账服务”用于模拟对支付、结算等操作的响应。

业务平台上还具有数据存储单元，用户持久化存储测试结果和相应的测试数据。

基于上述内容，对于接口类测试而言，具体例如：假设在该示例中，对接商进行针对酒店客房的下单测试，那么，对于本申请实施例中的业务平台而言，将确定本次测试类别为下单接口测试，即，本次测试对应的接口为“下单接口”，并根据该下单测试接口与测试事件的对应关系，确定本次测试的待测试事件为“酒店客房下单”，进一步地，业务平台将根据测试事件与测试数据之间的对应关系，确定出酒店客房下单这一事件对应的下单数据(即，测试数据)，由此，业务平台可生成下单测试请求，再通过下单接口将该下单测试请求，按照酒店服务器的地址发送给酒店服务器，相应地，酒店服务器将会根据下单测试请求进行下单测试，酒店服务器下单后，将以订单数据的形式通过下单接口反馈给业务平台，从而，业务平台将该订单数据存储在数据库中。

对于订单类测试，具体例如：假设在该示例中，对接商进行针对已生成的订单的结账测试，即，酒店服务器可针对业务平台上已存储在数据库中的订单数据发出结账指令，那么，对于本申请实施例中的业务平台而言，将针对这些订单数据的状态进行更新，换言之，业务平台可将这些订单数据的状态变更为“已结账”的状态。

当然，上述的两种示例仅是如图4a所示的业务平台上的测试功能的举例说明，并不应构成对本申请的限定。

此外，在实际应用中，对接商进行测试的过程可以如图4b所示。具体包括以下步骤：

S401：对接商在测试界面上针对接口测试服务发出选择指令。

S402：业务平台确定所选择的接口测试类别，以及所选择的待测试事件，以确定出测试数据。

S403：将测试数据通过预先保存的对接商的测试地址，发送给对接商。

S404：对接商接收测试数据进行测试，并反馈实际测试结果。

这里需要说明的是，对接商对测试请求的处理，包括对测试订单的下单成功、下单失败等各种订单状态，具体的实际响应结果与待测试事件相关，这里不再过多赘述。

S405：接收实际测试结果，并基于待测试事件预先定义的参考测试结果，判断对接商的接口功能是否运行正常。

S406：将判断结果持久化存储。

具体而言，在图3b所示的测试界面中，左侧区域为需要进行测试的接口，即，待测接口，对接商在选定了相应的待测接口后，便可以选择该待测接口下的各待测试事件。在图中可见待测试事件的选项(图3b中显示为“场景选择”)，对接商可以通过该选项选择不同的待测试事件。当待测试事件选定后，在“试单请求”区域将显示出与该待测试事件相对应的标准测试数据，图中所显示的标准测试数据用于构建测试请求，对接商可以针对该标准测试数据进行调整或改动，以便适应于实际的测试需要。当然，当待测试事件选定后，在“实际响应”区域将显示标准响应结果，该标准响应结果将作为实际响应结果的参考。对接商点击发送按键后，待测试事件和测试数据将生成相应的测试请求，业务平台接收到该测试请求后，便会调用相应的mock测试功能完成对该业务请求的响应(即，基于测试数据对待测试事件进行测试)。实际响应结果将显示在图3b的“实际响应”区域中。

从上述内容可见，业务平台通过mock服务，模拟了实际应用场景下可能出现的各种可能事件，并在测试过程中与对接商进行测试交互，那么，根据对接商的响应结果，便可以得到测试结果(本实施例中，测试结果通常以“成功”或“失败”两种状态表示)。

当然，基于如图3b所示的测试界面，还具有其他功能，其中，如图4c所示的界面中，对接商可以查询已进行测试后的各订单数据，以及订单的详细交互日志。

而在如图4d所示的界面中，对接商可以查询各待测试事件的测试结果。从图4d所示的界面中可见，针对不同的待测接口，分别列出了对应于各待测接口的所有待测试事件，对于还未进行测试的待测试事件，其测试结果展示“为执行”，而对于已进行测试的待测试事件，其测试结果展示“成功/失败”。

以上为本申请实施例提供的测试方法，基于同样的思路，本申请实施例还提供一种测试装置，如图5所示。该装置包括：

测试确定模块501，确定待测试对象和待测试的测试类别；

事件确定模块502，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块503，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块504，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

所述事件确定模块502，确定与所述待测试的测试类别对应的待测试事件集合，从所述待测试事件集合中，确定出与所述待测试的测试类别对应的待测试事件。

所述装置还包括：预处理模块505，针对不同类别的测试服务，分别执行以下操作：确定该种测试类别所包含的至少一个测试事件，并为每个所述测试事件配置测试数据，建立所述测试事件与所述测试数据之间的对应关系。

其中，不同测试事件对应的测试数据进行隔离存储。

所述发送模块504，确定所述待测试对象的地址，根据所述地址，将所述测试数据发送至所述地址对应的服务器。

所述装置还包括：结果处理模块506，接收所述待测试对象发送的测试反馈信息，所述测试反馈信息中包含测试事件标识和实际测试结果，根据测试事件与参考测试结果之间的对应关系，确定与所述测试反馈信息中包含的测试事件标识对应的参考测试结果，根据所述实际测试结果和所述参考测试结果，判断所述待测试对象是否运行正常。

所述装置还包括：查询处理模块507，获取测试结果查询消息，所述测试结果查询消息中包含测试类别，确定与所述测试类别对应的判断结果，并显示。

所述装置还包括：分析处理模块508，在确定与所述测试类别对应的判断结果时，分析判断结果，并确定对所述测试类别进行测试的优化策略。

在本申请实施例中，所述测试对象包括：与所述测试平台通过直连方式进行连接的酒店服务器；

所述测试服务包括：针对酒店进行预订、下单、价格查询、取消订单、结账支付、取消结账、入住状态中的至少一种或者多种测试服务。

本申请实施例还提供一种测试装置，如图6所示。该装置包括：

界面展示模块601，提供测试界面

测试确定模块602，基于所述测试界面确定待测试对象以及待测试的测试类别；

事件确定模块603，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块604，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块605，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

所述界面展示模块601，提供包含测试类别选择区域、待测试事件选择区域的测试界面。

所述测试确定模块602，当在所述测试界面的所述测试类别选择区域中监测到测试服务的选择指令时，根据所述选择指令，确定待测试对象以及待测试的测试类别。

所述界面展示模块601，若测试界面中还包含实际测试结果显示区域，则接收所述测试对象发送的实际测试结果，并将所述实际测试结果显示在所述实际测试结果显示区域。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、 Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL (Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL (RubyHardware Description Language)等，目前最普遍使用的是VHDL (Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (15)

1.一种测试方法，其特征在于，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

确定待测试对象和待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

2.如权利要求1所述的测试方法，其特征在于，确定与所述待测试的测试类别对应的待测试事件，具体包括：

确定与所述待测试的测试类别对应的待测试事件集合；

从所述待测试事件集合中，确定出与所述待测试的测试类别对应的待测试事件。

3.如权利要求1所述的测试方法，其特征在于，通过以下方式建立测试事件与测试数据之间的对应关系，包括：

针对不同类别的测试服务，分别执行以下操作：

确定该种测试类别所包含的至少一个测试事件，并为每个所述测试事件配置测试数据；

建立所述测试事件与所述测试数据之间的对应关系；

其中，不同测试事件对应的测试数据进行隔离存储。

4.如权利要求1所述的测试方法，其特征在于，将所述测试数据发送给所述待测试对象，具体包括：

确定所述待测试对象的地址；

根据所述地址，将所述测试数据发送至所述地址对应的服务器。

5.如权利要求1所述的测试方法，其特征在于，在将所述测试数据发送给所述待测试对象之后，所述方法还包括：

接收所述待测试对象发送的测试反馈信息，所述测试反馈信息中包含测试事件标识和实际测试结果；

根据测试事件与参考测试结果之间的对应关系，确定与所述测试反馈信息中包含的测试事件标识对应的参考测试结果；

根据所述实际测试结果和所述参考测试结果，判断所述待测试对象是否运行正常。

6.如权利要求5所述的测试方法，其特征在于，所述方法还包括：

获取测试结果查询消息，所述测试结果查询消息中包含测试类别；

确定与所述测试类别对应的判断结果，并显示。

7.如权利要求5或6所述的测试方法，其特征在于，所述方法还包括：

在确定与所述测试类别对应的判断结果时，分析判断结果，并确定对所述测试类别进行测试的优化策略。

8.如权利要求1至7任一项所述的测试方法，其特征在于，若待测试对象为酒店业务对应的酒店服务器，所述酒店服务器通过直连方式接入所述业务平台；

通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，包括：

当确定的测试类别为接口类测试服务时，通过第一测试接口，将与所述接口类测试服务对应的测试数据发送给所述酒店服务器，使所述酒店服务器基于所述测试数据进行测试；

其中，所述接口类测试服务包含验证价格库存接口、预订接口、订单查询接口和取消订单接口中的至少一种或者多种。

9.如权利要求8所述的测试方法，其特征在于，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，包括：

当确定的测试类别为订单状态类测试服务时，通过第二测试接口，将与所述订单状态类测试服务对应的测试数据发送给所述酒店服务器，使所述酒店服务器基于所述测试数据进行测试；

其中，所述订单状态类测试服务包含入住状态、离店状态、结账状态、订单状态中的至少一种或者多种。

10.一种测试方法，其特征在于，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

提供测试界面；

基于所述测试界面确定待测试对象以及待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

11.如权利要求10所述的测试方法，其特征在于，提供测试界面，具体包括：

提供包含测试类别选择区域、待测试事件选择区域的测试界面。

12.如权利要求11所述的测试方法，其特征在于，基于所述测试界面确定待测试对象以及待测试的测试类别，具体包括：

当在所述测试界面的所述测试类别选择区域中监测到测试服务的选择指令时，根据所述选择指令，确定待测试对象以及待测试的测试类别。

13.如权利要求11所述的测试方法，其特征在于，所述方法还包括：

若测试界面中还包含实际测试结果显示区域，则接收所述测试对象发送的实际测试结果，并将所述实际测试结果显示在所述实际测试结果显示区域。

14.一种测试装置，其特征在于，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

测试确定模块，确定待测试对象和待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

事件确定模块，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。

15.一种测试装置，其特征在于，应用于接入有不同的业务提供方的业务平台中，以对业务提供方对应的服务器进行测试，所述业务提供方对应的服务器为待测试对象，包括：

界面展示模块，提供测试界面；

测试确定模块，基于所述测试界面确定待测试对象以及待测试的测试类别，所述测试类别包含接口类测试和订单状态类测试中的至少一种或者多种；

事件确定模块，根据测试类别与测试事件之间的对应关系，确定与所述待测试的测试类别对应的待测试事件；

数据确定模块，根据测试事件与测试数据之间的对应关系，确定与所述待测试事件对应的测试数据；

发送模块，通过所述测试类别对应的接口，将所述测试数据发送给所述待测试对象，使所述待测试对象基于所述测试数据对所述待测试事件进行测试。