一种业务系统的测试方法及装置与流程

本发明涉及信息测试技术领域，尤其涉及一种业务系统的测试方法及装置。

背景技术：

目前，在线购物平台、在线金融平台等业务系统中，通常都会集成订单系统、购物车系统等服务化系统，这些服务化系统对前端的门户网站提供能力接口，但大都无操作界面，可视化的操作界面基本都是门户网站向用户终端展示的界面。同时，能力接口连接后端系统，且涉及对后端系统接口的整合，如寻源、促销等后端运行的功能。

在实际应用中，对于服务化系统进行接口联调测试，对测试环境的完整性要求较高，需要将前端门户网站和后端系统全部参与到接口联调测试的过程中，若只是将服务化系统单独进行测试，对于BUG的排除效果很不理想。而且随着业务系统的愈发复杂化，业务系统所采用的服务化系统的接口也越来越多，接口逻辑也越来越复杂，在实际工作中组要组织很多开发人员并耗费大量的时间和精力为测试编写各个接口的代码，每一次测试的人工成本很高。因此一般都是在一些价值较高的、新的业务系统上线运营前，才会对其中的服务化系统进行测试并进行BUG排查。

但是对于已经上线运营并且需要频繁更新的业务系统，出于经营收益和运营成本的考虑，无法同时停运前端门户网站和后端系统并参与到测试过程中。因此，难以对已经运行的服务化系统的更新、升级，进行接口联调测试，只能在在上线使用后再进行BUG排查，因此在服务化系统每一次的更新、升级后，往往都会出现一个BUG爆发的高峰期，严重影响了业务系统运行的稳定性，尤 其是遇到“双十一”、“双十二”等大型的营销活动时，不稳定的业务系统会给运营商造成损失。

技术实现要素：

本发明的实施例提供一种业务系统的测试方法，能够缓减由于不稳定的业务系统给运营商造成损失的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明的实施例提供的方法，包括：

接收登录信息和配置信息，根据所述登录信息读取对应所述登录信息的案例集合；

从所述案例集合中提取案例，并依据所述配置信息创建测试模块，所述测试模块包括至少一个案例，其中，一个案例包括至少一个执行步骤；

运行所述测试模块，并根据所述测试模块中的案例的各执行步骤，生成测试消息并向待测试系统的服务接口发送；

接收所述待测试系统的返回的结果报文，并检测所述返回的结果报文是否符合预期，若是则判定测试成功。

结合第一方面，在第一方面的第一种可能的实现方式中，所述并根据所述测试模块中的案例的各执行步骤，生成测试消息并向待测试系统的服务接口发送，包括：

读取所述测试模块中的案例的各执行步骤的类型标识，并确定各执行步骤的类型，其中，执行步骤的类型包括：用于表示请求的R类和用于表示埋桩的S类；

运行R类执行步骤，生成R类测试消息并向所述待测试系统与前端相连的服务接口发送；

运行S类执行步骤，生成S类测试消息；在接收所述待测试系统发送的对应所述R类测试消息的反馈报文后，向所述待测试系统与后端相连的服务接口发送所述S类测试消息。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，还包括：

执行步骤运行消息队列(MQ)类执行步骤，生成MQ类测试消息；向所述待测试系统与后端相连的服务接口发送所述MQ类测试消息，并接收所述待测试系统发送的对应所述MQ类测试消息的反馈报文，其中，执行步骤的类型还包括：用于表示MQ消息的MQ类。

结合第一方面的第一、二种可能的实现方式,在第三种可能的实现方式中，所述检测所述返回的结果报文是否符合预期，若是则判定测试成功，包括：

运行Y类执行步骤并得到预期报文，其中，执行步骤的类型还包括：用于表示预期报文的Y类；

检测当前的案例中，所述待测试系统发送的反馈报文是否符合所述预期报文，若是则判定当前的案例测试成功。

结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述检测所述返回的结果报文是否符合预期，包括：

在接收到所述待测试系统发送的对应一个执行步骤的反馈报文后，检测对应这一个执行步骤的反馈报文中各字段的值，是否与对应这一个执行步骤的预期报文的相一致，若是则判定符合。

第二方面，本发明的实施例提供的装置，包括：

接收单元，用于接收登录信息和配置信息，根据所述登录信息读取对应所 述登录信息的案例集合；

测试创建单元，用于从所述案例集合中提取案例，并依据所述配置信息创建测试模块，所述测试模块包括至少一个案例，其中，一个案例包括至少一个执行步骤；

测试运行单元，用于运行所述测试模块，并根据所述测试模块中的案例的各执行步骤，生成测试消息并向待测试系统的服务接口发送；

检测单元，用于接收所述待测试系统的返回的结果报文，并检测所述返回的结果报文是否符合预期，若是则判定测试成功。

结合第二方面，在第二方面的第一种可能的实现方式中，所述测试运行单元，具体用于读取所述测试模块中的案例的各执行步骤的类型标识，并确定各执行步骤的类型，并运行R类执行步骤，生成R类测试消息并向所述待测试系统与前端相连的服务接口发送；和，运行S类执行步骤，生成S类测试消息；在接收所述待测试系统发送的对应所述R类测试消息的反馈报文后，向所述待测试系统与后端相连的服务接口发送所述S类测试消息；其中，执行步骤的类型包括：用于表示请求的R类和用于表示埋桩的S类。

结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述测试运行单元，还用于执行步骤运行消息队列(MQ)类执行步骤，生成MQ类测试消息；向所述待测试系统与后端相连的服务接口发送所述MQ类测试消息，并接收所述待测试系统发送的对应所述MQ类测试消息的反馈报文，其中，执行步骤的类型还包括：用于表示MQ消息的MQ类。

结合第二方面的第一、二种可能的实现方式,在第三种可能的实现方式中，所述检测单元，具体用于运行Y类执行步骤并得到预期报文，其中，执行步骤的类型还包括：用于表示预期报文的Y类；并检测当前的案例中，所述待测试系统 发送的反馈报文是否符合所述预期报文，若是则判定当前的案例测试成功。

结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述检测单元，具体用于在接收到所述待测试系统发送的对应一个执行步骤的反馈报文后，检测对应这一个执行步骤的反馈报文中各字段的值，是否与对应这一个执行步骤的预期报文的相一致，若是则判定符合。

本发明实施例提供的业务系统的测试方法及装置，能够自动对服务化系统进行接口联调测试，使得技术人员方便的调取案例集合，并自动建立测试模块执行测试，从而减少技术人员可以在功能测试环境对服务化系统进行一轮或多轮功能测试时的代码编写的工作量。相对于只在简单的代码错误排查后就直接上线，并在上线使用后再进行BUG排查的现有手段，本实施例实现了快速进行接口联调测试，减少了在功能测试环境对服务化系统进行一轮或多轮功能测试时的人力成本，减少了服务化系统上线后出现的BUG，从而缓减了由于不稳定的业务系统给运营商造成的经济损失。

附图说明

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

图1为本发明实施例提供的一种系统架构示意图；

图2为本发明实施例提供的业务系统的测试方法的流程示意图；

图3a、图3b、图3c为本发明实施例提供的具体实例中的操作界面示意图；

图4a、图4b为本发明实施例提供的场景示意图；

图5为本发明实施例提供的具体实例中的结果界面示意图；

图6为本发明实施例提供的业务系统的测试装置的结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本发明实施例具体可以实现在一种如图1所示的系统中，其中包括：测试服务器、待测试系统、由向技术人员提供操作界面并接收技术人员操作的用户设 备。其中：

测试服务器，具体可以是单独作成的服务器设备，比如：机架式、刀片、塔式或者机柜式的服务器设备，也可以采用工作站、大型计算机等具备较强计算能力硬件设备，也可以是由多个服务器设备组成的服务器集群。测试服务器与待测试系统的服务接口建立连接，其中服务接口包括所述待测试系统与前端相连的服务接口和所述待测试系统与后端相连的服务接口。

待测试系统具体指的是用于在线交易业务、金融业务或者物流业务等业务系统中的服务化系统，这些服务化系统用于承担一些具体的业务功能或者业务场景，比如订单系统、货架系统、购物车系统、下单系统和结算系统等。其中，业务场景，具体可以理解为一种由业务数据和一系列的业务执行流程组成的数据集合，比如：商品信息(在一些具体领域中，商品信息也可称为单品)、URL(Uniform Resource Locator，统一资源定位符)信息、页面地址信息等，通常的这些业务数据有业务系统存储并维护，业务执行流程由业务系统上运行的执行模块(比如业务系统上建立的虚拟机)执行；在业务系统上同时也可以生成对应业务执行流程中各个环节的页面，并在展示页面中添加相应的业务数据；根据用户设备的访问请求和用户操作，用户设备可以向业务系统请求访问相应的业务执行流程中的某一个环节的页面，并将所访问的页面展示在用户设备的显示单元上(比如显示在智能手机的触摸屏)；在业务执行流程的执行过程中，由于用户操作或者自动触发等原因，使的用户设备所显示的当前所在业务环节的页面跳转至下一个业务环节的页面。

用户设备具体可以实做成单独一台装置，或整合于各种不同的媒体数据播放装置中，诸如智能手机、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)、个人电脑(PC机)等。用户设备上可以通过安装的应 用程序或者APP，显示测试服务器所展示的交互界面，并接收技术人员向用户设备输入的登录信息、配置信息等信息。

在本实施例中，待测试系统具体可以是订单系统、货架系统、购物车系统、下单系统和结算系统等承担一些具体的业务功能或者业务场景的服务化系统。

上游系统具体可以是在线购物网站、前台购物车系统、电话销售系统等前端系统，通常的这些前端系统通过互联网、无线网络、电话网络等于访客的终端设备进行通讯，终端设备具体可以实做成单独一台装置，或整合于各种不同的媒体数据播放装置中，诸如智能手机、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)、个人电脑(PC机)等。

下游系统具体可以是物流服务系统、商品寻源系统、价格管理系统等由上游系统的运营商或者第三方提供的后端系统，后端系统具体还应该连接数据库系统，并向服务化系统提供具体的数据，所提供的具体的数据对应了访客通过终端设备在上游系统的操作行为。

为了便于区分，本实施例中的“访客”具体可以理解为通过个人终端设备访问上游系统人员，比如：访问在线购物网站的消费者；本实施例中的“用户”具体可以理解为通过用户设备访问测试服务器并调用测试服务器对服务化系统进行测试的技术人员。

本发明实施例提供一种业务系统的测试方法，如图2所示，包括：

S1、接收登录信息和配置信息，根据所述登录信息读取对应所述登录信息的案例集合。

其中，用户可以操作用户设备，输入登录信息并向测试服务器进行在线登录，同时将用户输入用户设备的配置信息或者是预存在用户设备中的配置信息，向测试服务器发送，由测试服务器完成该用户的登录并做登录后相应的初始化 配置。案例集合可以是用户预先设定好的，对应当前的待测试系统的案例的集合，案例集合可以由技术人员自定义配置，可以是在测试服务器中预存多个典型、常用的案例集合，并提供给用户直接使用、

用户设备上可以运行客户端，客户端用于向用户展示可视化的操作界面，用户可以操作用户设备从案例集合中挑选案例并通知测试服务器，并在操作界面中输入配置信息，配置信息的类型可以依据待测试系统进行设定，从而进行初始化配置，如功能测试环境的地址，执行步骤的模板配置等。在本实施例中，执行步骤具体可以理解为：指定的消息、报文的，比如：根据标识的不同具体可以分为四类：R类表示请求消息，S类表示埋桩(埋桩是指预先准备好后端接口的返回报文)，MQ类表示消息队列消息，Y类表示预期报文，以及对消息、报文的处理方式，比如：包括了接口名称、接口服务码(接口服务码作为该接口的唯一标示)，用于模拟上游系统请求的URL，上游系统的标识(如标示flag)等用于表示消息、报文的发送方向的信息，还可以包括延时时间等用于表示消息、报文的具体发送方式的信息。在本实施例中，执行步骤的具体内容可以通过模板配置，并可以将执行步骤的配置模板通过预设的时间顺序或逻辑关系排列并组成所述的案例。一个案例具体可以用于模拟业务实际业务场景中的一次交互过程，若实际业务场景可能包括多次的交互过程，则可以在测试模块中配置对应各次交互过程的案例。

例如：如图3a所示的，用户可以在操作界面中修改测试服务器与待测试系统之间的上游系统的接口的信息模板，其中，上游系统的接口可以理解为所述待测试系统与前端相连的服务接口，则这些接口的配置信息包括了：接口名称、接口服务码(接口服务码作为该接口的唯一标示)，用于模拟上游系统请求的URL，上游系统的标识(如标示flag)、接口延时时间和报文模板。

再例如：如图3b所示的，用户可以在操作界面中修改测试服务器与待测试系统之间的下游系统的接口的信息模板，其中，下游系统的接口可以理解为所述待测试系统与后端相连的服务接口，则配置信息包括了：接口名称、接口服务码(接口服务码作为该接口的唯一标示)，用于模拟下游系统请求的URL，下游系统的标识(如标示flag)、接口延时时间和报文模板。还包括了关键值KEY，关键值KEY的内容可以是一些对应后端设备各个桩点的关键字，关键字用于查询预先埋好的桩点(即埋桩的操作，其中埋桩具体是是指预先准备好后端接口的返回报文)。

在本实施例中，报文模板可以预存在用户设备中或者测试服务器中，用户可以直接调取使用，或者根据当待测试系统的具体接口情况在报文模板中进行修改。在实际应用中，除了由测试服务器初始提供的报文模板，还可以由各个技术人员自定义修改出符合特定待测试系统的报文模板，并上传至测试服务器的公共模板库中，以便于其他的技术人员可以直接调取新上传的报文模板。相对于现有技术中各技术人员需要根据服务化系统的具体情况重新编写报文，本实施例中可以直接提供报文模板以便于技术人员直接使用或者在此基础上进行修改，从而节省了技术人员在测试过程中需要消耗在报文编写上的时间。

S2、从所述案例集合中提取案例，并依据所述配置信息创建测试模块，所述测试模块包括至少一个案例，其中，一个案例包括至少一个执行步骤。

其中，一个模块下可以对应多个案例，一个案例下可以对应多个执行步骤。

S3、运行所述测试模块，并根据所述测试模块中的案例的各执行步骤，生成测试消息并向待测试系统的服务接口发送。

其中，执行步骤的类型包括：用于表示请求的R类和用于表示埋桩的S类。具体的，根据所述测试模块中的案例的各执行步骤生成测试消息并向待测试系 统的服务接口发送的具体方式，包括：

读取所述测试模块中的案例的各执行步骤的类型标识，并确定各执行步骤的类型。

运行R类执行步骤，生成R类测试消息并向所述待测试系统与前端相连的服务接口发送。以及运行S类执行步骤，生成S类测试消息。在接收所述待测试系统发送的对应所述R类测试消息的反馈报文后，向所述待测试系统与后端相连的服务接口发送所述S类测试消息。

例如：如图4a所示的，测试服务器生成测试消息并向待测试系统的服务接口发送，使得待测试系统接收到的是测试服务器发送的消息，而非再与真实场景中的上游系统或者下游系统进行交互，即通过测试服务器代替了真实场景中的上游系统或者下游系统与待测试的服务化系统进行了交互，待测试的服务化系统可以不再真正调用后端系统，而从测试服务器获得预先埋好的模拟报文作为后端系统的返回报文等类型的报文。在实际应用中，上游系统和下游系统都可以保持在线运行，而不再参与服务化系统的测试过程。而在服务化系统建设或者更新完毕后，则可以直接接入正在运行的上游系统和下游系统。并且，本实施例中还提供一种在线维护服务化系统的方式，比如图4b所示的，建设多条具有相同服务功能的服务化系统，如：结算系统1、结算系统2和结算系统3需要进行更新升级。可以对其中一条结算系统进行更新升级并通过测试服务器进行，在对第一条结算系统进行更新升级的过程中，可以由技术人员团队监控并调整测试过程，并形成最终的案例集合。在测试完毕后，新的结算系统上线运行，并在测试服务器保存所用的案例集合。之后可以自动对其他的结算系统进行更新升级，并自动读取所保存的案例集合进行测试，从而减少了其他的结算系统在更新升级时的人力投入。

S4、接收所述待测试系统的返回的结果报文，并检测所述返回的结果报文是否符合预期，若是则判定测试成功。

本发明实施例提供的业务系统的测试方法，能够自动对服务化系统进行接口联调测试，使得技术人员方便的调取案例集合，并自动建立测试模块执行测试，从而减少技术人员可以在功能测试环境对服务化系统进行一轮或多轮功能测试时的代码编写的工作量。相对于只在简单的代码错误排查后就直接上线，并在上线使用后再进行BUG排查的现有手段，本实施例实现了快速进行接口联调测试，减少了在功能测试环境对服务化系统进行一轮或多轮功能测试时的人力成本，减少了服务化系统上线后出现的BUG，从而缓减了由于不稳定的业务系统给运营商造成经济损失的问题。

在本实施例中，每个根据标识的不同具体可以分为四类：R类表示请求，S类表示埋桩，MQ类表示消息队列消息，Y类表示预期报文。埋桩是指预先准备好后端接口的返回报文。

即在本实施例中，执行步骤的类型还包括：用于表示MQ消息的MQ类。以及，本实施例中的执行步骤的类型还包括：用于表示预期报文的Y类。

根据所述测试模块中的案例的各执行步骤生成测试消息并向待测试系统的服务接口发送的具体方式，还包括：执行步骤运行消息队列(MQ)类执行步骤，生成MQ类测试消息。向所述待测试系统与后端相连的服务接口发送所述MQ类测试消息，并接收所述待测试系统发送的对应所述MQ类测试消息的反馈报文。

例如：如图3c所示的，用户可以在操作界面中修改测试服务器与待测试系统之间的上/下游系统的接口的信息模板。其中的接口服务码中输入队列名称，主机IP、端口通道等暂时可以写死在代码中的信息，并在标识flag写入MQ，即 标示出该接口用于MQ类测试消息的发送。

所述检测所述返回的结果报文是否符合预期，若是则判定测试成功，包括：运行Y类执行步骤并得到预期报文。检测当前的案例中，所述待测试系统发送的反馈报文是否符合所述预期报文，若是则判定当前的案例测试成功。

其中，检测所述返回的结果报文是否符合预期的具体方式，包括：

在接收到所述待测试系统发送的对应一个执行步骤的反馈报文后，检测对应这一个执行步骤的反馈报文中各字段的值，是否与对应这一个执行步骤的预期报文的相一致，若是则判定符合。若不一致则说明此案例未执行成功。并可以向用户设备输出如图5所示的测试结果界面，并还可以通过EXCEL统计并记录成功案例的和失败案例的名称和标号。

由于服务化系统在开发阶段和测试阶段存在以下问题：在开发阶段，需要编写不同代码，在代码编写完成后，由开发人员进行冒烟测试。而在冒烟测试之前，开发人员需要针对服务化系统的不同的接口逻辑，手动编写用于发起请求的代码，并根据接口的被调用情况调整这些用于发起请求的代码，在所有的接口的代码调整完毕后再进行冒烟测试。而随着业务系统的愈发复杂化，所采用的服务化系统的接口也越来越多，接口逻辑也越来越复杂，并且随着系统的升级愈发频繁，在实际工作中开发人员需要耗费大量的时间和精力为冒烟测试编写各个接口的代码，极大地增加了人工成本。并且又对测试环境要求较高，比如：目前冒烟测试的测试环境分为两种：功能测试环境和集成测试环境。

集成测试环境可进行上下游系统的联调测试，可以操作上游系统的页面对服务化系统发起请求调用；但功能测试环境是不与上下游系统联通的、是独立的环境，无法使用操作上游系统页面的方式来调用，导致测试人员无法在功能 测试环境中对目标系统进行测试。如果系统只进行冒烟测试就进入到集成测试阶段，系统BUG相对较多，一处有问题即会导致整个测试链路被堵塞，不光会影响本系统的测试效率，同时也会影响其它相关系统的测试效率。采用本实施例，则减少了开发人员进行冒烟测试所需编写的代码量，节省了开发人员写代码做冒烟测试的时间。

到了性能测试阶段，因各系统联合压测配合难度较大，为了保证效率，联合压测前一般要对各系统进行单系统压测，单系统压测都无性能问题后再进行联合压测。但因服务化系统内部需要调用大量外部系统的接口，所以一般还需要技术人员对压测的代码进行修改。再次进行性能测试时因接口有变化，或有新增接口等原因，又需要修改一次代码。同样需要耗费大量的时间和精力。采用本实施例，则在性能测试阶段开发人员则无须再修改代码，节省压测时间。

本实施例中，案例集合具体可以对应不同的测试设定执行步骤，比如：冒烟测试、功能测试和性能测试分别配置不同的执行步骤。由于能够自动对服务化系统进行接口联调测试，使得技术人员方便的调取案例集合，并自动建立测试模块执行测试。相对于只在简单的代码错误排查后就直接上线，并在上线使用后再进行BUG排查的现有手段，本实施例实现了快速进行接口联调测试，使得服务化系统在上线前就完成接口联调测试，在实际应用中80％的bug在功能测试阶段通过工具模拟测试去发现，20％的少量bug在集成测试阶段发现，降低了集成测试阶段的风险，降低上线风险，加速版本迭代速度。从而缓减了服务化系统上线后出现一个BUG爆发的高峰期的问题。

本发明实施例还提供一种业务系统的测试装置，具体可以运行在如图1所示的测试服务器上，如图6所示包括：

接收单元，用于接收登录信息和配置信息，根据所述登录信息读取对应所述登录信息的案例集合；

测试创建单元，用于从所述案例集合中提取案例，并依据所述配置信息创建测试模块，所述测试模块包括至少一个案例，其中，一个案例包括至少一个执行步骤；

测试运行单元，用于运行所述测试模块，并根据所述测试模块中的案例的各执行步骤，生成测试消息并向待测试系统的服务接口发送；

检测单元，用于接收所述待测试系统的返回的结果报文，并检测所述返回的结果报文是否符合预期，若是则判定测试成功。

其中，所述测试运行单元，具体用于读取所述测试模块中的案例的各执行步骤的类型标识，并确定各执行步骤的类型，并运行R类执行步骤，生成R类测试消息并向所述待测试系统与前端相连的服务接口发送；和，运行S类执行步骤，生成S类测试消息；在接收所述待测试系统发送的对应所述R类测试消息的反馈报文后，向所述待测试系统与后端相连的服务接口发送所述S类测试消息；其中，执行步骤的类型包括：用于表示请求的R类和用于表示埋桩的S类。

所述测试运行单元，还用于执行步骤运行消息队列(MQ)类执行步骤，生成MQ类测试消息；向所述待测试系统与后端相连的服务接口发送所述MQ类测试消息，并接收所述待测试系统发送的对应所述MQ类测试消息的反馈报文，其中，执行步骤的类型还包括：用于表示MQ消息的MQ类。

所述检测单元，具体用于运行Y类执行步骤并得到预期报文，其中，执行步骤的类型还包括：用于表示预期报文的Y类；并检测当前的案例中，所述待测试系统发送的反馈报文是否符合所述预期报文，若是则判定当前的案例测试成功。

所述检测单元，具体用于在接收到所述待测试系统发送的对应一个执行步 骤的反馈报文后，检测对应这一个执行步骤的反馈报文中各字段的值，是否与对应这一个执行步骤的预期报文的相一致，若是则判定符合。

本发明实施例提供的业务系统的测试装置，能够自动对服务化系统进行接口联调测试，使得技术人员方便的调取案例集合，并自动建立测试模块执行测试，从而减少技术人员可以在功能测试环境对服务化系统进行一轮或多轮功能测试时的代码编写的工作量。相对于只在简单的代码错误排查后就直接上线，并在上线使用后再进行BUG排查的现有手段，本实施例实现了快速进行接口联调测试，减少了在功能测试环境对服务化系统进行一轮或多轮功能测试时的人力成本，减少了服务化系统上线后出现的BUG，从而缓减了由于不稳定的业务系统给运营商造成的经济损失。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。