CN107590062A - 一种多客户端交互的测试方法和装置 - Google Patents

Abstract

本申请提供一种多客户端交互的测试方法和装置，该方法包括：确定已经向所述目标客户端发送所述源客户端对应的请求消息；检测所述目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出所述源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。通过本申请的技术方案，可以对源客户端与目标客户端之间的交互逻辑进行测试，测试出源客户端与目标客户端之间的交互逻辑为符合期望或者不符合期望，从而实现多客户端交互的测试，为客户端的开发提供帮助。

Description

一种多客户端交互的测试方法和装置

技术领域

本申请涉及互联网技术领域，尤其是一种多客户端交互的测试方法和装置。

背景技术

UI(User Interface，用户界面)测试的目的是确保UI会通过测试对象的功能，来为用户提供相应的访问或者浏览功能，通过UI测试来核实用户与软件的交互，确保UI向用户提供了适当的访问和浏览测试对象功能的操作。

其中，通过UI测试，可以测试出功能模块的布局是否合理，整体风格是否一致，各个控件的放置位置是否符合用户使用习惯，操作是否便捷，导航是否简单易懂，界面中文字是否正确，命名是否统一，页面是否美观等。

发明内容

本申请实施例提供一种多客户端交互的测试方法，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

确定已经向所述目标客户端发送所述源客户端对应的请求消息；

检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例提供一种多客户端交互的测试方法，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

从所述测试用例中解析出用于生成所述源客户端对应的请求消息的内容；

利用所述内容模拟出所述请求消息；

将所述请求消息发送给所述目标客户端；

检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例提供一种多客户端交互的测试方法，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

向所述源客户端发送指令，以使所述源客户端利用所述指令向所述目标客户端发送请求消息；

在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；

如果在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息，则检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例提供一种多客户端交互的测试装置，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

测试驱动模块，用于确定已经向目标客户端发送源客户端对应的请求消息；

用户界面检测模块，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例提供一种多客户端交互的测试装置，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

请求模拟模块，用于从测试用例中解析出用于生成源客户端对应的请求消息的内容，利用所述内容模拟出请求消息，将所述请求消息发送给目标客户端；

用户界面检测模块，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例提供一种多客户端交互的测试装置，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

异步消息交互模块，用于向源客户端发送指令，以使源客户端利用所述指令向目标客户端发送请求消息；并在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；

用户界面检测模块，用于当在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息时，则检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

基于上述技术方案，本申请实施例中，可以对源客户端与目标客户端之间的交互逻辑进行测试，并测试出源客户端与目标客户端之间的交互逻辑为符合期望或者不符合期望，实现多客户端交互的测试，为客户端的开发提供帮助。

附图说明

为了更加清楚地说明本申请实施例或者现有技术中的技术方案，下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请一种实施方式中的应用场景示意图；

图2是本申请一种实施方式中的多客户端交互的测试方法的流程图；

图3是本申请另一种实施方式中的多客户端交互的测试方法的流程图；

图4是本申请另一种实施方式中的多客户端交互的测试方法的流程图；

图5是本申请一种实施方式中的测试服务器的硬件结构图；

图6是本申请一种实施方式中的多客户端交互的测试装置的结构图；

图7是本申请另一种实施方式中的多客户端交互的测试装置的结构图；

图8是本申请另一种实施方式中的多客户端交互的测试装置的结构图。

具体实施方式

在本申请使用的术语仅仅是出于描述特定实施例的目的，而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例提供一种多客户端交互的测试方法，该方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑。其中，执行测试用例的主体可以为一个逻辑装置，本文中将该逻辑装置称为多客户端交互的测试装置，并简称为测试装置。该测试装置可以运行在移动终端设备上，或者为该测试装置部署一个单独的服务器，本申请中可以将承载测试装置的服务器称为测试服务器。如图1所示，该方法可以应用于包括多个客户端、测试服务器(该测试服务器上部署有上述测试装置)和业务服务器的系统中，各客户端可以部署在移动终端上，测试服务器可以为PC(Personal Computer，个人计算机)、平板电脑、笔记本电脑等，通常情况下，各客户端与测试服务器部署在一个测试环境下，如部署在一个屋子里，这样，客户端与测试服务器之间可以通过有线方式或者无线方式连接。业务服务器是用于为客户端提供服务的服务器，各客户端与业务服务器可以不部署在一个测试环境下。在一个例子中，客户端可以为支付宝客户端，测试服务器可以为一个具有测试功能的PC，且PC上的测试装置用于实现该测试功能，业务服务器可以为提供支付宝功能的服务器。

在一个例子中，交互逻辑可以为交互业务逻辑，本文中以交互逻辑为例。

在一个例子中，该多客户端交互的测试方法用于测试源客户端与目标客户端之间的交互逻辑。如图1所示，为了测试客户端1发出请求消息后，客户端2是否能够正确处理请求消息的交互逻辑，则可以将客户端1称为源客户端，并将客户端2称为目标客户端。如果测试结果为源客户端与目标客户端之间的交互逻辑符合期望，则说明客户端1发出的请求消息，能够被客户端2正确处理，客户端2收到请求消息后的交互逻辑符合期望。如果测试结果为源客户端与目标客户端之间的交互逻辑不符合期望，则说明客户端1发出的请求消息，不能够被客户端2正确处理，客户端2收到请求消息后的交互逻辑不符合期望。同理，为了测试客户端2发出请求消息后，客户端1是否能够正确处理请求消息的交互逻辑，则可以将客户端2称为源客户端，并将客户端1称为目标客户端。为了方便描述，本申请实施例中，以客户端1为源客户端，客户端2为目标客户端为例进行说明。

在介绍本申请实施例提出的多客户端交互的测试方法之前，先介绍单客户端的测试方法。其中，在开发客户端(即客户端软件，即通常所说的APP)时，通常需要对客户端进行测试，如UI测试等，以检测客户端是否可以实现预先设定的功能。例如，客户端都需要具有登录功能(即预先设定的功能)，可以通过对客户端进行测试，以测试出客户端是否具有登录功能。当测试出客户端具有登录功能时，表示客户端的登录功能的开发软件没有问题，可以投入使用。当测试出客户端不具有登录功能时，表示客户端的登录功能的开发软件存在问题，不可以投入使用，需要研发人员对开发软件进行调整，并再次进行测试。

以下结合客户端的登录功能的测试，对单客户端的测试方法进行说明。对于客户端的其它功能的测试方法，与登录功能的测试方法类似，在此不再赘述。

研发人员通过编写用于控制客户端登录的测试用例，使得测试装置可以通过该测试用例控制客户端的登录。例如，第1步，基于测试用例，测试装置控制客户端弹出用户登录界面。第2步，基于测试用例，测试装置控制客户端在用户登录界面输入用户名(测试用例配置的用户名)。第3步，基于测试用例，测试装置控制客户端在用户登录界面输入密码(测试用例配置的密码)。第4步，基于测试用例，测试装置控制客户端点击登录按键，以使客户端向业务服务器发送登录请求。第5步，业务服务器在接收到登录请求后，从登录请求中解析出用户名和密码，并验证用户名和密码是否正确。如果正确，则客户端会弹出登录成功页面。第6步，测试装置检查登录成功页面(UI页面)的展示，如果页面展示符合预设业务规则，说明客户端登录这个交互逻辑符合期望，至此测试出客户端的开发软件没有问题；如果页面展示不符合预设业务规则，说明客户端登录这个交互逻辑不符合期望，至此测试出客户端的开发软件存在问题，需要研发人员对开发软件进行调整。其中，页面展示符合预设业务规则指的是页面的布局、样式、关键元素的内容等展示，符合预设的业务规则。

上述过程是针对单客户端的测试方法的一个示例，但是随着互联网技术的不断发展，业务需求也越来越多样化，多个客户端的交互需求也越来越多，如各种聊天工具等，均涉及多个客户端的交互需求。为了测试出多个客户端交互的交互逻辑，以确定这多个客户端之间是否正常交互，就可以采用本申请实施例中提出的多客户端交互的测试方法，以对源客户端与目标客户端之间的交互逻辑进行测试。进一步的，在测试出交互逻辑不符合期望时，可以对开发软件进行调整，从而避免将存在问题的客户端投入市场使用。

在一个例子中，由于目前的UI自动化测试工具不支持多客户端交互的测试，因此为了实现多客户端交互的测试，可以采用手动方式进行，即由研发人员手工进行多客户端交互的测试。考虑到上述方式的工作量太大，本申请实施例中，可以提供支持多客户端交互的测试的UI自动化测试工具，并可以自动化的完成多客户端交互的测试，不需要研发人员手工进行多客户端交互的测试。

如图2所示，为本申请实施例中提出的多客户端交互的测试方法的流程图，该方法用于测试源客户端与目标客户端之间的交互逻辑。其中，源客户端对应的系统类型与目标客户端对应的系统类型可以相同或者不同；源客户端对应的系统类型包括iOS系统或者Android系统；目标客户端对应的系统类型包括iOS系统或者Android系统。例如，源客户端对应的系统类型为iOS系统，目标客户端对应的系统类型为iOS系统；源客户端对应的系统类型为iOS系统，目标客户端对应的系统类型为Android系统；源客户端对应的系统类型为Android系统，目标客户端对应的系统类型为Android系统；源客户端对应的系统类型为Android系统，目标客户端对应的系统类型为iOS系统。

如图1所示，客户端所在的移动终端需要与测试装置所在的测试服务器建立连接，如可以为有线连接或者无线连接。例如，移动终端1与测试服务器建立有线连接或者无线连接，移动终端2与测试服务器建立有线连接或者无线连接，对于有线连接或者无线连接的建立方式，在此不再详加赘述。基于此有线连接或者无线连接，则客户端可以与测试服务器进行通信，继而完成相关功能。

本申请实施例中，测试装置是通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，即测试装置基于测试用例，执行后续步骤。其中，测试用例是研发人员为了验证客户端的交互逻辑而编制的一组操作集合，通常情况下，一个测试用例可以包含执行环境、预设条件、输入参数、预期结果，并包含若干个操作步骤，可以通过一个测试用例来验证一种特定交互过程。

例如，iOS系统上的客户端1向Android系统上的客户端2发送聊天消息，则一个简单的测试用例如下：预设条件：用户已登录。操作步骤：1、同时启动客户端1和客户端2，其中，客户端2启动后即进入等待状态；2、向客户端1发送指令，以指示客户端1向客户端2发送聊天消息；3、向客户端2发送指令，以指示聊天消息已经发送完毕，客户端2被唤醒，退出等待状态；4、检测客户端2的联系人菜单图标右上角是否有新到消息提醒；5、检测新到消息数量是否为1；6、点击联系人列表；7、检测发送消息的联系人是否在列表的第一项；8、点击联系人列表的第一项，进入聊天页面；9、检测聊天页面是否收到聊天消息。

在上述应用场景下，如图2所示，该多客户端交互的测试方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，并包括以下步骤：

步骤201，确定已经向目标客户端发送源客户端对应的请求消息。

步骤202，检测目标客户端的用户界面展示是否符合预设业务规则。

如果是，则执行步骤203；如果否，则执行步骤204。

步骤203，测试出源客户端与目标客户端之间的交互逻辑符合期望。

步骤204，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，如果源客户端对应的系统类型为iOS系统，目标客户端对应的系统类型为iOS系统，测试结果可以为两个iOS系统的客户端之间的交互逻辑符合期望或者不符合期望。如果源客户端对应的系统类型为Android系统，目标客户端对应的系统类型为Android系统，测试结果可以为两个Android系统的客户端之间的交互逻辑符合期望或者不符合期望。如果源客户端对应的系统类型为iOS系统，目标客户端对应的系统类型为Android系统，测试结果可以为iOS系统的客户端与Android系统的客户端之间的交互逻辑符合期望或者不符合期望。如果源客户端对应的系统类型为Android系统，目标客户端对应的系统类型为iOS系统，测试结果可以为Android系统的客户端与iOS系统的客户端之间的交互逻辑符合期望或者不符合期望。

需要注意的是，两个客户端之间的交互逻辑是单向的，例如，Android系统的客户端(源客户端)与iOS系统的客户端(目标客户端)之间的交互逻辑符合期望时，则iOS系统的客户端(源客户端)与Android系统的客户端(目标客户端)之间的交互逻辑可能为不符合期望。即，Android系统的客户端发出的请求消息，能够被iOS系统的客户端正确处理，iOS系统的客户端收到请求消息后的交互逻辑符合期望。但是，iOS系统的客户端发出的请求消息，不能够被Android系统的客户端正确处理，Android系统的客户端收到请求消息后的交互逻辑不符合期望。基于此，在本申请实施例中，在测试出源客户端与目标客户端之间的交互逻辑符合期望或者不符合期望之后，基于源客户端的系统类型以及目标客户端的系统类型，则可以分析出是哪种系统类型的客户端之间的交互逻辑符合期望或者不符合期望，继而基于客户端的系统类型，更加有针对性的对开发软件进行调整。

在一个例子中，客户端的系统类型可以由研发人员编写在测试用例中，且测试装置可以在运行测试用例时，从测试用例中解析出客户端的系统类型。

在一个例子中，测试装置在执行测试用例时，针对不同的交互逻辑，会预设不同的业务规则，而通过检测目标客户端的用户界面展示是否符合预设业务规则，就可以测试出源客户端与目标客户端之间的交互逻辑符合期望或者不符合期望。其中，页面展示符合预设业务规则指的是页面的布局、样式、关键元素的内容等展示，符合预设的业务规则。

例如，在测试用例中的交互逻辑可以为目标客户端是否正确接收请求消息(如聊天消息)，则测试用例中的预设业务规则可以为联系人菜单图标右上角需要有新到消息提醒、消息数量为1、发送消息的联系人在联系人列表的第一项、聊天页面收到聊天消息等。基于此，以页面展示中的关键元素为例，则判断关键元素是否符合预设的业务规则。具体的，基于测试装置检测到的目标客户端的UI的关键元素，如果获知目标客户端的联系人菜单图标右上角有新到消息(即关键元素)提醒、新到消息数量(即关键元素)为1、发送消息的联系人(即关键元素)在联系人列表的第一项、聊天页面收到聊天消息(即关键元素)，则测试装置可以确定出目标客户端的UI的关键元素符合预设业务规则，并测试出源客户端与目标客户端之间的交互逻辑符合期望。否则，测试装置确定出目标客户端的UI的关键元素不符合预设业务规则，并测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例中，在确定已经向目标客户端发送源客户端对应的请求消息之前，测试装置还可以从测试用例中解析出用于生成源客户端对应的请求消息的内容，并利用该内容模拟出请求消息，并将该请求消息发送给目标客户端。

在上述方式中，由测试装置自身得到源客户端对应的请求消息，而不是由源客户端生成该请求消息。因此，测试装置将该请求消息发送给目标客户端之后，测试装置就可以确定已经向目标客户端发送源客户端对应的请求消息，并开始检测目标客户端的用户界面展示是否符合预设业务规则。

本申请实施例中，上述用于生成源客户端对应的请求消息的内容可以包括但不限于：为源客户端提供服务的业务服务器的域名信息、请求消息的访问路径、请求消息的业务数据等，基于此，利用内容模拟出请求消息的过程，可以包括：将域名信息、访问路径、业务数据拼接在一起，以模拟出请求消息。当然，上述域名信息、访问路径、业务数据只是请求消息中内容的一个示例，在不同的业务场景下，请求消息中的内容可以发生变化，在此不再赘述。

在一个例子中，可以由研发人员在测试用例中编写域名信息、访问路径、业务数据等信息，具体编写方式在此不再赘述。基于此，测试装置可以从测试用例中解析出上述域名信息、访问路径、业务数据等信息。

在一个例子中，测试装置利用域名信息、访问路径、业务数据等信息模拟出的请求消息，就和源客户端向目标客户端发送的请求消息一样。

在一个例子中，源客户端向目标客户端发送的请求消息，实际上就是一个携带业务数据的URL(Uniform Resource Locator，统一资源定位符)，该请求消息需要通过业务服务器将请求消息转发给目标客户端，因此，测试装置模拟的该请求消息也需要先路由到业务服务器，为此，该请求消息中需要携带业务服务器的域名信息，并基于该域名信息，可以将请求消息发送到业务服务器。此外，该请求消息中还携带访问路径，业务服务器可以通过该访问路径将请求消息发送给目标客户端，而且，该访问路径中还会包括源客户端的系统类型，其目的在于：告诉业务服务器，请求消息是何种系统类型的客户端发出的，以使业务服务器进行相应处理，具体处理不再赘述。此外，该请求消息中还携带业务数据，这个业务数据就可以是上述的聊天内容。

本申请实施例中，对于请求消息中的内容，不再详加赘述。

基于上述模拟源客户端对应的请求消息的方案，本申请实施例中，可以直接在测试装置模拟源客户端对应的请求消息，从而简化操作流程，只需要一个目标客户端，就可以完成源客户端与目标客户端之间的交互逻辑的测试。

本申请实施例中，确定已经向目标客户端发送源客户端对应的请求消息的过程，具体可以包括但不限于：测试装置向源客户端发送指令，以使源客户端利用该指令向目标客户端发送请求消息；测试装置在向源客户端发送指令后，向目标客户端发送唤醒消息，以唤醒目标客户端。基于此，如果在预设时间内，测试装置检测到目标客户端已经接收到唤醒消息，则可以确定已经向目标客户端发送源客户端对应的请求消息。此外，如果在预设时间内，测试装置检测到目标客户端未接收到唤醒消息，则关闭目标客户端，并测试出源客户端与目标客户端之间的交互逻辑不符合期望。其中，测试装置启动源客户端和目标客户端，目标客户端启动后即进入等待状态，通过向目的客户端发送唤醒消息，以唤醒目标客户端，目标客户端退出等待状态。在目标客户端退出等待状态时，测试装置才可以开始检测目标客户端的用户界面展示是否符合预设业务规则。

在上述方式中，由源客户端基于测试装置的指令，生成请求消息，并向目标客户端发送请求消息。由于是源服务器向目标客户端发送请求消息，因此，源服务器何时将请求消息发送给目标客户端，测试装置并不知道，那么测试装置何时开始检测目标客户端的用户界面展示是否符合预设业务规则。

针对上述问题，测试装置在向源客户端发送指令后，还可以向目标客户端发送唤醒消息，以唤醒目标客户端。基于此，如果在预设时间内，测试装置检测到目标客户端已经接收到唤醒消息，则确定已经向目标客户端发送源客户端对应的请求消息，并可以开始检测目标客户端的用户界面展示是否符合预设业务规则。如果在预设时间内，测试装置检测到目标客户端未接收到唤醒消息，则关闭目标客户端，并测试出源客户端与目标客户端之间的交互逻辑不符合期望，不再检测目标客户端的用户界面展示是否符合预设业务规则。

在一个例子中，源客户端向目标客户端发送的请求消息，实际上就是一个携带业务数据的URL，该请求消息需要通过业务服务器将请求消息转发给目标客户端。而且，该请求消息的内容可以包括但不限于：为源客户端提供服务的业务服务器的域名信息、请求消息的访问路径、请求消息的业务数据等。

在一个例子中，针对测试装置向目标客户端发送的唤醒消息，可以直接由测试装置发送给目标客户端，而不需要经过业务服务器的转发。

测试装置在确定已经向目标客户端发送源客户端对应的请求消息之后，还可以检测源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，测试人员会编写相应的测试用例(其中会设置预设业务规则)，测试装置在执行这些测试用例时，通过检测源客户端的用户界面展示是否符合预设业务规则，就可测试出源客户端与目标客户端之间的交互逻辑不符合期望符合期望或者不符合期望，对此过程不再详加赘述。

需要注意的是，针对源客户端与目标客户端之间的交互逻辑，通过检测目标客户端的用户界面展示是否符合预设业务规则，可以测试出目标客户端上的处理逻辑是否符合期望。通过检测源客户端的用户界面展示是否符合预设业务规则，可以测试出源客户端上的处理逻辑是否符合期望。

基于上述源客户端直接发送请求消息的技术方案，本申请实施例中，由源客户端本身来发送请求消息，可以适用于所有应用场景，真实完整的执行源客户端与目标客户端的交互操作，能够验证源客户端与目标客户端的业务流。

而且，在本申请实施例中，测试装置可以同时启动源客户端和目标客户端，如果在预设时间内，测试装置检测到目标客户端未接收到唤醒消息，则关闭目标客户端，以表示测试用例执行完毕。

如图3所示，为本申请实施例中提出的一种多客户端交互的测试方法的流程图，该方法可以应用在测试装置上，并通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，该方法具体可以包括以下步骤：

步骤301，从测试用例中解析出用于生成源客户端对应的请求消息的内容，利用该内容模拟出请求消息，并将该请求消息发送给目标客户端。

其中，在将该请求消息发送给目标客户端之后，就可以确定出已经向目标客户端发送源客户端对应的请求消息，并执行后续的步骤302。

步骤302，检测目标客户端的用户界面展示是否符合预设业务规则。

如果是，则执行步骤303；如果否，则执行步骤304。

步骤303，测试出源客户端与目标客户端之间的交互逻辑符合期望。

步骤304，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例中，上述用于生成源客户端对应的请求消息的内容可以包括但不限于：为源客户端提供服务的业务服务器的域名信息、请求消息的访问路径、请求消息的业务数据等，基于此，利用内容模拟出请求消息的过程，可以包括：将域名信息、访问路径、业务数据拼接在一起，以模拟出请求消息。

其中，所述访问路径中包括源客户端的系统类型。

对于图3中各步骤的详细说明，参加图2所示的流程，在此不再赘述。

基于上述模拟源客户端对应的请求消息的方案，本申请实施例中，可以直接在测试装置模拟源客户端对应的请求消息，从而简化操作流程，只存在一个目标客户端，就可以完成源客户端与目标客户端之间的交互逻辑的测试。

如图4所示，为本申请实施例中提出的一种多客户端交互的测试方法的流程图，该方法可以应用在测试装置上，并通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，该方法具体可以包括以下步骤：

步骤401，向源客户端发送指令，以使源客户端利用该指令向目标客户端发送请求消息；并在向源客户端发送指令后，向目标客户端发送唤醒消息，以唤醒目标客户端。

步骤402，如果在预设时间内，检测到目标客户端已经接收到唤醒消息，则检测目标客户端的用户界面展示是否符合预设业务规则。

在一个例子中，测试装置在检测到目标客户端已经接收到唤醒消息之后，就可以确定出已经向目标客户端发送源客户端对应的请求消息，并执行检测目标客户端的用户界面展示是否符合预设业务规则的过程。

如果是，则执行步骤403；如果否，则执行步骤404。

步骤403，测试出源客户端与目标客户端之间的交互逻辑符合期望。

步骤404，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例中，如果在预设时间内，检测到目标客户端未接收到唤醒消息，则关闭目标客户端，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

本申请实施例中，测试装置启动源客户端和目标客户端，目标客户端启动后即进入等待状态，通过向目的客户端发送唤醒消息，以唤醒目标客户端，目标客户端退出等待状态。在目标客户端退出等待状态时，测试装置才可以开始检测目标客户端的用户界面展示是否符合预设业务规则。

本申请实施例中，测试装置检测到目标客户端已经接收到唤醒消息之后，还可以检测源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出源客户端与目标客户端之间的交互逻辑不符合期望。

对于图4中各步骤的详细说明，参加图2所示的流程，在此不再赘述。

基于上述源客户端直接发送请求消息的技术方案，本申请实施例中，由源客户端本身来发送请求消息，可以适用于所有应用场景，真实完整的执行源客户端与目标客户端的交互操作，能够验证源客户端与目标客户端的业务流。

而且，在本申请实施例中，测试装置可以同时启动源客户端和目标客户端，如果在预设时间内，测试装置检测到目标客户端未接收到唤醒消息，则关闭目标客户端，以表示测试用例执行完毕。

目前的UI自动化测试工具(如UIAutomation、Sword等)并不支持多客户端交互的测试，为了实现上述步骤201-步骤204，步骤301-步骤304，步骤401-步骤404的流程，本申请实施例中，开发了支持多客户端交互的测试的UI自动化测试工具，如WUIA(Wireless UIAutomator，无线用户界面自动化)、WUIA Case Editor(用例编辑器)、WRF(Wireless RobotFramework，无线机器框架)等。这些UI自动化测试工具都支持研发人员编写本申请实施例中使用的测试用例，并支持使用这些测试用例来执行本申请实施例的上述功能。而且，这些UI自动化测试工具的使用，可以方便而系统的编写测试用例，提升测试用例编写效率，降低测试用例维护难度。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。基于测试用例，测试装置可以完成上述测试功能，对此不再说明。

其中，WUIA是测试用例的UI自动化执行工具，基于Appium，面向操作，能够将测试用例抽象成若干个互相关联的操作步骤，涉及人机交互的操作被封装成Appium Client的API(Application Programming Interface，应用程序编程接口)。WUIA Case Editor是WUIA的GUI(Graphical User Interface)用例编辑工具，能够方便对测试用例进行编辑、调试和运行。WRF是基于配置的UI自动化集成测试框架，核心组件是任务配置文件和任务调度器。

基于与上述方法同样的申请构思，本申请实施例中还提供一种多客户端交互的测试装置120，该多客户端交互的测试装置120应用在测试服务器10上。该多客户端交互的测试装置120可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在的测试服务器10的处理器11，读取非易失性存储器12中对应的计算机程序指令形成的。从硬件层面而言，如图5所示，为多客户端交互的测试装置120所在的测试服务器10的一种硬件结构图，除了图5所示的处理器11、非易失性存储器12外，测试服务器10还可以包括其他硬件，如负责处理报文的转发芯片、网络接口、内存等；从硬件结构上来讲，该测试服务器10还可能是分布式设备，可能包括多个接口卡，以便在硬件层面进行报文处理的扩展。

如图6所示，为本申请提出的多客户端交互的测试装置的结构图，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，包括：测试驱动模块121，用于确定已经向目标客户端发送源客户端对应的请求消息；用户界面检测模块122，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，所述测试驱动模块121包括(在图中未体现)：请求模拟子模块1211，用于在确定已经向所述目标客户端发送所述请求消息之前，从所述测试用例中解析出用于生成所述源客户端对应的请求消息的内容，利用所述内容模拟出所述请求消息，将所述请求消息发送给所述目标客户端。

在一个例子中，所述测试驱动模块121包括(在图中未体现)：异步消息交互子模块1212，用于在确定已经向所述目标客户端发送请求消息的过程中，向所述源客户端发送指令，以使所述源客户端利用所述指令向所述目标客户端发送请求消息；并在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；如果在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息，则确定已经向所述目标客户端发送所述源客户端对应的请求消息。

在一个例子中，所述用户界面检测模块122，还用于当在预设时间内，检测到所述目标客户端未接收到所述唤醒消息时，则关闭所述目标客户端，并测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，所述用户界面检测模块122，还用于在确定已经向所述目标客户端发送所述源客户端对应的请求消息之后，检测所述源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，所述源客户端对应的系统类型与所述目标客户端对应的系统类型相同或者不同；所述源客户端对应的系统类型包括iOS系统或者Android系统；所述目标客户端对应的系统类型包括iOS系统或者Android系统。

其中，本申请装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

如图7所示，为本申请提出的多客户端交互的测试装置的结构图，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，包括：请求模拟模块123，用于从测试用例中解析出用于生成源客户端对应的请求消息的内容，利用所述内容模拟出请求消息，将所述请求消息发送给目标客户端；用户界面检测模块124，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

其中，本申请装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

如图8所示，为本申请提出的多客户端交互的测试装置的结构图，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：异步消息交互模块125，用于向源客户端发送指令，以使源客户端利用所述指令向目标客户端发送请求消息；并在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；用户界面检测模块126，用于当在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息时，则检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，所述用户界面检测模块126，还用于当在预设时间内，检测到所述目标客户端未接收到所述唤醒消息时，则关闭所述目标客户端，并测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

在一个例子中，所述用户界面检测模块126，还用于在检测到所述目标客户端已经接收到所述唤醒消息之后，检测所述源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

其中，本申请装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

以上公开的仅为本申请的几个具体实施例，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (20)

1.一种多客户端交互的测试方法，其特征在于，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

确定已经向所述目标客户端发送所述源客户端对应的请求消息；

检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

2.根据权利要求1所述的方法，其特征在于，所述确定已经向所述目标客户端发送所述源客户端对应的请求消息之前，所述方法还包括：

从所述测试用例中解析出用于生成所述源客户端对应的请求消息的内容；

利用所述内容模拟出所述请求消息；

将所述请求消息发送给所述目标客户端。

3.根据权利要求1所述的方法，其特征在于，所述确定已经向所述目标客户端发送所述源客户端对应的请求消息的过程，具体包括：

向所述源客户端发送指令，以使所述源客户端利用所述指令向所述目标客户端发送请求消息；

在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；

如果在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息，则确定已经向所述目标客户端发送所述源客户端对应的请求消息。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

如果在预设时间内，检测到所述目标客户端未接收到所述唤醒消息，则关闭所述目标客户端；

测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

5.根据权利要求3所述的方法，其特征在于，所述确定已经向所述目标客户端发送所述源客户端对应的请求消息之后，所述方法还包括：

检测所述源客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述源客户端对应的系统类型与所述目标客户端对应的系统类型相同或者不同；

所述源客户端对应的系统类型包括iOS系统或者Android系统；

所述目标客户端对应的系统类型包括iOS系统或者Android系统。

7.一种多客户端交互的测试方法，其特征在于，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

从所述测试用例中解析出用于生成所述源客户端对应的请求消息的内容；

利用所述内容模拟出所述请求消息；

将所述请求消息发送给所述目标客户端；

检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

8.一种多客户端交互的测试方法，其特征在于，所述方法通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述方法包括：

向所述源客户端发送指令，以使所述源客户端利用所述指令向所述目标客户端发送请求消息；

在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；

如果在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息，则检测所述目标客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

如果在预设时间内，检测到所述目标客户端未接收到所述唤醒消息，则关闭所述目标客户端；

测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

10.根据权利要求8所述的方法，其特征在于，所述检测到所述目标客户端已经接收到所述唤醒消息之后，所述方法还包括：

检测所述源客户端的用户界面展示是否符合预设业务规则；

如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；

如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

11.一种多客户端交互的测试装置，其特征在于，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

测试驱动模块，用于确定已经向目标客户端发送源客户端对应的请求消息；

用户界面检测模块，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

12.根据权利要求11所述的装置，其特征在于，所述测试驱动模块包括：

请求模拟子模块，用于在确定已经向所述目标客户端发送所述请求消息之前，从所述测试用例中解析出用于生成所述源客户端对应的请求消息的内容，利用所述内容模拟出所述请求消息，将所述请求消息发送给所述目标客户端。

13.根据权利要求11所述的装置，其特征在于，所述测试驱动模块包括：

异步消息交互子模块，用于在确定已经向所述目标客户端发送请求消息的过程中，向所述源客户端发送指令，以使所述源客户端利用所述指令向所述目标客户端发送请求消息；并在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；如果在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息，则确定已经向所述目标客户端发送所述源客户端对应的请求消息。

14.根据权利要求13所述的装置，其特征在于，

所述用户界面检测模块，还用于当在预设时间内，检测到所述目标客户端未接收到所述唤醒消息时，则关闭所述目标客户端，并测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

15.根据权利要求13所述的装置，其特征在于，所述用户界面检测模块，还用于在确定已经向所述目标客户端发送所述源客户端对应的请求消息之后，检测所述源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

16.根据权利要求11-15任一项所述的装置，其特征在于，所述源客户端对应的系统类型与所述目标客户端对应的系统类型相同或者不同；

所述源客户端对应的系统类型包括iOS系统或者Android系统；

所述目标客户端对应的系统类型包括iOS系统或者Android系统。

17.一种多客户端交互的测试装置，其特征在于，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

请求模拟模块，用于从测试用例中解析出用于生成源客户端对应的请求消息的内容，利用所述内容模拟出请求消息，将所述请求消息发送给目标客户端；

用户界面检测模块，用于检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

18.一种多客户端交互的测试装置，其特征在于，所述装置通过执行测试用例，来测试源客户端与目标客户端之间的交互逻辑，所述装置包括：

异步消息交互模块，用于向源客户端发送指令，以使源客户端利用所述指令向目标客户端发送请求消息；并在向所述源客户端发送指令后，向所述目标客户端发送唤醒消息，以唤醒所述目标客户端；

用户界面检测模块，用于当在预设时间内，检测到所述目标客户端已经接收到所述唤醒消息时，则检测目标客户端的用户界面展示是否符合预设业务规则；如果是，测试出源客户端与目标客户端之间的交互逻辑符合期望；如果否，测试出源客户端与目标客户端之间的交互逻辑不符合期望。

19.根据权利要求18所述的装置，其特征在于，

所述用户界面检测模块，还用于当在预设时间内，检测到所述目标客户端未接收到所述唤醒消息时，则关闭所述目标客户端，并测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。

20.根据权利要求18所述的装置，其特征在于，

所述用户界面检测模块，还用于在检测到所述目标客户端已经接收到所述唤醒消息之后，检测所述源客户端的用户界面展示是否符合预设业务规则；如果是，则测试出所述源客户端与目标客户端之间的交互逻辑符合期望；如果否，则测试出所述源客户端与目标客户端之间的交互逻辑不符合期望。