CN107368411A - 测试方法、装置及*** - Google Patents

Abstract

本公开揭示了一种测试方法、装置及***，属于应用程序测试领域。所述方法包括：通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架；通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架；通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息；通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。本公开实施例中，测试设备利用两种测试工具实现了多端交互场景下的应用测试。

Description

测试方法、装置及***

技术领域

本公开涉及应用程序测试领域，特别涉及一种测试方法、装置及***。

背景技术

应用测试作为应用程序(Application)开发过程中的重要环节，用于发现应用程序中存在的缺陷，以便开发人员对测试过程中发现的缺陷进行及时修正。

为了提高测试效率，开发人员通常采用自动化测试工具对该应用程序进行相关测试。但是，相关技术提供的自动化测试工具只能够对单个终端中安装的应用程序进行测试，对于即时通信应用这类支持多端交互的应用程序，自动化测试工具无法对多端交互的场景进行测试。

发明内容

本公开实施例提供了一种测试方法、装置及***，技术方案如下：

根据本公开实施例的第一方面，提供了一种测试方法，该方法包括：

通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架；

通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD(Behavior DrivenDevelopment，行为驱动开发)自动化测试框架；

通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息；

通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

可选的，通过第二测试工具向待测试客户端对应的服务器发送登陆请求，包括：

通过第二测试工具调用服务器提供的第一API(Application ProgrammingInterface，应用程序编程接口)，向服务器发送登陆请求，第一API用于实现帐号登陆功能。

可选的，通过第二测试工具向服务器发送信息发送请求，包括：

通过第二测试工具调用服务器提供的第二API，向服务器发送信息发送请求，第二API用于实现帐号间信息发送功能。

可选的，该方法，还包括：

通过第一测试工具控制待测试客户端向第二帐号发送反馈信息；

通过第二测试工具向服务器发送信息获取请求，信息获取请求用于请求获取第二帐号接收到的信息。

可选的，该方法，还包括：

若第一帐号接收到预定信息，且第二帐号接收到反馈信息，则确定待测试客户端通过测试。

可选的，第一测试工具包括calabash、Appium或Robolectric中的至少一种；

第二测试工具包括cucumber、RobotFramework、JBehave、RBehave或Fitnesse中的至少一种。

根据本公开实施例的第二方面，提供了一种测试装置，该装置包括：

第一控制模块，被配置为通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架；

第一请求模块，被配置为通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架；

第二请求模块，被配置为通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息；

检测模块，被配置为通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

可选的，第一请求模块，还被配置为通过第二测试工具调用服务器提供的第一API，向服务器发送登陆请求，第一API用于实现帐号登陆功能。

可选的，第二请求模块，还被配置为通过第二测试工具调用服务器提供的第二API，向服务器发送信息发送请求，第二API用于实现帐号间信息发送功能。

可选的，该装置，还包括：

第二控制模块，被配置为通过第一测试工具控制待测试客户端向第二帐号发送反馈信息；

第三请求模块，被配置为通过第二测试工具向服务器发送信息获取请求，信息获取请求用于请求获取第二帐号接收到的信息。

可选的，该装置，还包括：

确定模块，被配置为当第一帐号接收到预定信息，且第二帐号接收到反馈信息时，确定待测试客户端通过测试。

可选的，第一测试工具包括calabash、Appium或Robolectric中的至少一种；

第二测试工具包括cucumber、RobotFramework、JBehave、RBehave或Fitnesse中的至少一种。

根据本公开实施例的第三方面，提供了一种测试装置，该装置包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架；

通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架；

通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息；

通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

根据本公开实施例的第四方面，提供了一种测试***，该***包括：测试设备、与测试设备相连的终端以及服务器；

终端与服务器之间通过有线或无线网络相连，测试设备与服务器之间通过有线或无线网络相连；

测试设备包括如上述第二方面所述的测试装置。

本公开实施例提供的技术方案可以包括以下有益效果：

通过在测试设备中安装采用客户端自动化测试框架的第一测试工具，以及采用BDD自动化测试框架的第二测试工具，从而利用第一测试工具控制终端中的待测试客户端登陆第一帐号，并利用第二测试工具模拟出待测试客户端登陆第二帐号，以及通过第二帐号向第一帐号发送预定信息的行为，最终通过第一测试工具检测第一帐号是否接收到预定信息，实现多端交互场景下的应用测试；整个测试过程由测试设备通过测试工具自动完成，无需人为操作，提高了测试效率；同时，只需要利用一台终端即可完成交互测试，降低了测试成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1示出了本公开一个实施例提供的测试***的***架构图；

图2是根据本公开一示例性实施例示出的测试方法的方法流程图；

图3是图2所示测试方法的实施示意图；

图4是测试***中测试设备、终端以及服务器之间交互过程的流程图；

图5是根据本公开另一示例性实施例示出的测试方法的方法流程图；

图6是根据本公开一示例性实施例示出的测试装置的框图；

图7是根据本公开一示例性实施例示出的测试装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本文提及的“模块”是指存储在存储器中的能够实现某些功能的程序或指令；在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

为了方便理解，下面对本公开实施例中涉及的名词进行解释。

客户端自动化测试框架：或称为UI(User Interface，用户界面)自动化测试框架，是一种通过模拟用户对客户端中元素(比如控件、文字等等)执行的操作，实现对客户端进行功能测试的框架。其中，客户端自动化测试框架通过运行预先编写的自动化测试脚本，模拟出用户对客户端元素执行的操作。常见的采用客户端自动化测试框架的测试工具包括calabash、Appium和Robolectric等等。

BDD自动化测试框架：BDD是一种敏捷软件开发技术，从用户需求出发，强调软件***的行为。BDD自动化测试框架则是一种根据自然语言描述测试用例(用户需求)进行自动化测试的框架。常见的采用BDD自动化测试框架的测试工具包括cucumber、RobotFramework、JBehave、RBehave和Fitnesse等等。

请参考图1，其示出了本公开一个实施例提供的测试***的***架构图，该测试***中包括测试设备110、终端120和服务器130。

测试设备110是具有测试功能的设备，该设备为台式计算机、便携式计算机或测试服务器等等。本公开实施例中，测试设备110中安装有两种采用不同自动化测试框架的测试工具，其中，第一测试工具采用客户端自动化测试框架，第二测试工具采用BDD自动化测试框架。

测试设备110与终端120之间建立数据连接，并进行数据通信。可选的，如图1所示，测试设备110与终端120之间建立USB(Universal Serial Bus，通用串行总线)连接。

终端120中安装有待测试客户端，本公开实施例中，该待测试客户端是支持多端交互的客户端，即不同用户在客户端中登陆各自的帐号后，即可使用客户端进行通信。比如，该待测试客户端为即时通讯客户端、微博客户端等社交应用客户端。本公开实施例中，测试设备110即通过第一测试工具控制终端120中安装的待测试客户端进行测试。

测试设备110和终端120均通过有线或无线网络与服务器130相连。

服务器130是一台服务器、若干台服务器构成的服务器集群或云计算中心。本公开实施例中，服务器130即为待测试客户端对应的后台服务器。比如，当待测试客户端为即时通讯客户端时，服务器130即用于管理不同帐号的登陆状态，并对即时通讯信息进行转发。本公开实施例中，服务器130提供若干API供测试设备110调用，通过调用API，测试设备110在不借助待测试客户端的情况下，也可以完成帐号登陆、信息发送、信息接收等功能。

可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(Extensible MarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(Internet ProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

图2是根据本公开一示例性实施例示出的测试方法的方法流程图。本实施例以该测试方法用于图1所示测试设备110进行说明。该方法可以包括如下步骤。

在步骤201中，通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架。

可选的，测试设备中存储有预先编写的自动化测试脚本，该自动化测试脚本即用于模拟用户在待测试客户端中执行登陆第一帐号的操作。在测试过程中，测试设备即利用第一测试工具运行该自动化测试脚本，从而通过与终端之间的数据连接，控制终端中安装的待测试客户端执行登陆操作。其中，第一测试工具为calabash、Appium或Robolectric。

通过本步骤，测试设备即可完成对待测试客户端登陆功能的测试。

在一种可能的实施方式中，测试设备利用第一测试工具运行自动化测试脚本，从而向终端发送一系列操作指令；终端接收到操作指令后，即根据操作指令模拟出用户开启待测试客户端，在登陆界面输入帐号、密码，以及点击登陆控件等操作。终端完成上述登陆操作后，即通过网络向待测试客户端对应的服务器发送登陆请求，请求服务器将第一帐号设置为登陆状态，其中，该登陆请求中包含第一帐号以及密码。

可选的，登陆成功后，服务器即向终端发送登陆成功指示，并由终端向测试设备进行反馈。当接收到登陆成功反馈时，测试设备继续执行下述步骤202；当未接收到登陆成功反馈(或接收到登陆失败反馈)时，测试设备则停止测试。

在步骤202中，通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架。

为了模拟出多端进行交互的场景，测试设备进一步通过采用BDD自动化测试框架的第二测试工具，向服务器发送登陆请求，该登陆请求中即包含第二帐号以及相应的密码；服务器接收到该登陆请求后，即对第二帐号及密码进行验证，验证通过后，服务器设置第二帐号为登陆状态，并向测试工具返回登陆成功指示，从而模拟出待测试客户端登陆第二帐号的效果。其中，第二测试工具为cucumber、RobotFramework、JBehave、RBehave或Fitnesse。

本步骤中，由于无需通过实际的待测试客户端进行登陆操作，因此，无需在测试***中增加额外的终端，从而降低测试成本。

在一种可能的实施方式中，服务器提供了大量Rest(Representational StateTransfer，表述性状态转移)API以供调用，测试设备通过调用用于实现帐号登陆功能的第一API，在不借助待测试客户端的情况下，向服务器发送登陆请求，请求服务器将第二帐号设置为登陆状态，从而模拟出使用待测试客户端登陆第二帐号的效果。

比如，服务器通过cucumber测试工具调用第一API向服务器发送登陆请求，从而请求服务器将第二帐号设置为登陆状态。

可选的，当接收到服务器返回的登陆成功指示时，测试设备继续执行下述步骤203；当未接收到登陆成功指示(或接收到登陆失败指示)时，测试设备则停止测试。

在步骤203中，通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息。

通过上述步骤201和202，第一帐号和第二帐号均处于登陆状态，为了对待测试客户端的信息交互功能进行测试，测试设备进一步通过第二测试工具向服务器发送信息发送请求，该信息发送请求中，即包含信息发送方标识(第二帐号)、信息接收方标识(第一帐号)以及待发送的预定信息。

在一种可能的实施方式中，服务器提供了大量Rest API以供调用，测试设备通过调用用于实现帐号间信息发送功能的第二API，在不借助待测试客户端的情况下，向服务器发送信息发送请求，请求服务器通过第二帐号向第一帐号发送预定信息，从而模拟出客户端间进行信息交互的场景。

比如，服务器通过cucumber测试工具调用第二API向服务器发送信息发送请求，从而请求服务器通过第二帐号向第一帐号发送预定信息。

服务器接收到信息发送请求后，即向登陆第一帐号的待测试客户端发送该预定信息。示意性的，如图3所示，登陆第二帐号的测试设备110(仅在服务器端处于登陆状态，实际上并未通过客户端登陆)向服务器130发送信息发送请求，服务器130接收到该请求后，即向终端120(运行的待测试客户端登陆有第二帐号)发送预定信息。

在步骤204中，通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

若待测试客户端的信息交互功能正常，登陆第一帐号的待测试客户端即能够接收到预定信息。因此，向服务器发送信息发送请求后，测试设备通过第一测试工具从相连的终端处获取待测试客户端(第一帐号)接收到的信息，并检测接收到信息与预定信息是否一致。

若第一帐号接收到的第二帐号发送的预定信息，测试设备即确定待测试设备信息交互功能通过测试；若第一帐号未接收到的第二帐号发送的预定信息(或接收到的信息与预定信息不同)，测试设备即确定待测试设备信息交互功能未通过测试，并输出相应的测试报告。

综上所述，本实施例中，通过在测试设备中安装采用客户端自动化测试框架的第一测试工具，以及采用BDD自动化测试框架的第二测试工具，从而利用第一测试工具控制终端中的待测试客户端登陆第一帐号，并利用第二测试工具模拟出待测试客户端登陆第二帐号，以及通过第二帐号向第一帐号发送预定信息的行为，最终通过第一测试工具检测第一帐号是否接收到预定信息，实现多端交互场景下的应用测试；整个测试过程由测试设备通过测试工具自动完成，无需人为操作，提高了测试效率；同时，只需要利用一台终端即可完成交互测试，降低了测试成本。

本实施例中，在不借助待测试客户端的情况下，测试设备通过调用服务器提供的第一API，实现帐号登陆功能；通过调用服务器提供的第二API，实现帐号间信息发送功能，从而在测试***中仅包含一个终端的情况下，实现客户端交互测试，降低了测试成本。

在一个示意性的实施例中，当第一测试工具为calabash，第二测试工具为cucumber时，测试设备、终端以及服务器之间的交互过程如图4所示。

在步骤401中，测试设备通过calabash控制终端中的待测试客户端登陆第一帐号。

在步骤402中，终端向服务器发送第一登陆请求。

该第一登陆请求中包含第一帐号和对应的密码。

在步骤403中，服务器向终端返回登陆成功指示。

服务器对第一帐号和密码进行验证后，设置第一帐号为登陆状态，并返回登陆成功指示。

在步骤404中，终端向测试设备反馈登陆成功指示。

在步骤405中，测试设备通过cucumber调用第一API，向服务器发送第二登陆请求。

该第二登陆请求中包含第二帐号和对应的密码。

在步骤406中，服务器向测试设备返回登陆成功指示。

服务器对第二帐号和密码进行验证后，设置第二帐号为登陆状态，并返回登陆成功指示。

在步骤407中，测试设备通过cucumber调用第二API，向服务器发送信息发送请求。

信息发送请求中包含预定信息、第二帐号(发送方标识)和第一帐号(接收方标识)。

在步骤408中，服务器根据信息发送请求向第一帐号发送预定信息。

在步骤409中，测试设备通过calabash获取终端中待测试客户端接收到的信息。

在步骤410中，当待测试客户端接收到的信息与预定信息一致时，测试设备确定待测试客户端通过测试。

通过上述步骤201至204，测试设备仅能够对信息交互过程中，客户端的信息接收功能进行测试，为了进一步对客户端的信息发送功能进行测试，在一种可能的实施方式中，如图5所示，该方法包括如下步骤。

图5是根据本公开另一示例性实施例示出的测试方法的方法流程图。本实施例以该测试方法用于图1所示测试设备110进行说明。该方法可以包括如下步骤。

在步骤501中，通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架。

在步骤502中，通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架。

在步骤503中，通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息。

上述步骤501至503的实施方式与步骤201至203相似，本实施例在此不再赘述。

在步骤504中，通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

若第一帐号接收到预定信息，则确定待测试客户端的信息接收功能通过测试，并执行下述步骤505和506对待测试客户端的信息发送功能进行测试；若第一帐号未接收到预定信息，则确定待测试客户端的信息接收功能未通过测试，并输出测试报告，停止测试。

在步骤505中，若检测到第一帐号接收到预定信息，则通过第一测试工具控制待测试客户端向第二帐号发送反馈信息。

可选的，测试设备中存储有预先编写的自动化测试脚本，该自动化测试脚本即用于模拟用户使用待测试客户端(登陆第一帐号)向其他待测试客户端(登陆第二帐号)发送信息。在测试过程中，测试设备即利用第一测试工具运行该自动化测试脚本，从而通过与终端之间的数据连接，控制终端中安装的待测试客户端执行信息发送操作。

在步骤506中，通过第二测试工具向服务器发送信息获取请求，信息获取请求用于请求获取第二帐号接收到的信息。

为了确定信息是否正确发送，测试设备进一步通过第二测试工具向服务器发送信息获取请求，该信息获取请求中包含第二帐号，请求服务器反馈第二帐号最近接收到的信息。

在一种可能的实施方式中，测试设备通过第二测试工具调用服务器提供的第三API，向服务器发送信息获取请求，该第三API用于提取帐号最近接收到的信息。

在步骤507中，若第一帐号接收到预定信息，且第二帐号接收到反馈信息，则确定待测试客户端通过测试。

当检测到第二帐号接收到第一帐号发送的反馈信息时，测试设备即确定待测试客户端的信息发送功能通过测试。

本实施例中，测试设备通过第一测试工具控制待测试客户端向第二帐号发送反馈信息，并通过第二测试工具向服务器发送信息获取请求，以获取第二帐号接收到的信息，并在检测到第二帐号接收到反馈信息时，确定待测试客户端通过测试，从而实现对待测试客户端信息发送功能的测试，进一步提高了交互测试的准确性。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图6是根据本公开一示例性实施例示出的测试装置的框图。该测试装置可以通过硬件或软硬件结合，实现成为图1所示测试设备110的全部或一部分。该测试装置包括：

第一控制模块610，被配置为通过第一测试工具控制终端中的待测试客户端登陆第一帐号，第一测试工具采用客户端自动化测试框架；

第一请求模块620，被配置为通过第二测试工具向待测试客户端对应的服务器发送登陆请求，登陆请求用于请求服务器设置第二帐号为登陆状态，第二测试工具采用BDD自动化测试框架；

第二请求模块630，被配置为通过第二测试工具向服务器发送信息发送请求，信息发送请求用于请求服务器使用第二帐号向第一帐号发送预定信息；

检测模块640，被配置为通过第一测试工具检测待测试客户端登陆的第一帐号是否接收到预定信息。

可选的，第一请求模块620，还被配置为通过第二测试工具调用服务器提供的第一API，向服务器发送登陆请求，第一API用于实现帐号登陆功能。

可选的，第二请求模块630，还被配置为通过第二测试工具调用服务器提供的第二API，向服务器发送信息发送请求，第二API用于实现帐号间信息发送功能。

可选的，该装置，还包括：

第二控制模块650，被配置为通过第一测试工具控制待测试客户端向第二帐号发送反馈信息；

第三请求模块660，被配置为通过第二测试工具向服务器发送信息获取请求，信息获取请求用于请求获取第二帐号接收到的信息。

可选的，该装置，还包括：

确定模块670，被配置为当第一帐号接收到预定信息，且第二帐号接收到反馈信息时，确定待测试客户端通过测试。

可选的，第一测试工具包括calabash、Appium或Robolectric中的至少一种；

第二测试工具包括cucumber、RobotFramework、JBehave、RBehave或Fitnesse中的至少一种。

综上所述，本实施例中，通过在测试设备中安装采用客户端自动化测试框架的第一测试工具，以及采用BDD自动化测试框架的第二测试工具，从而利用第一测试工具控制终端中的待测试客户端登陆第一帐号，并利用第二测试工具模拟出待测试客户端登陆第二帐号，以及通过第二帐号向第一帐号发送预定信息的行为，最终通过第一测试工具检测第一帐号是否接收到预定信息，实现多端交互场景下的应用测试；整个测试过程由测试设备通过测试工具自动完成，无需人为操作，提高了测试效率；同时，只需要利用一台终端即可完成交互测试，降低了测试成本。

本实施例中，在不借助待测试客户端的情况下，测试设备通过调用服务器提供的第一API，实现帐号登陆功能；通过调用服务器提供的第二API，实现帐号间信息发送功能，从而在测试***中仅包含一个终端的情况下，实现客户端交互测试，降低了测试成本。

本实施例中，测试设备通过第一测试工具控制待测试客户端向第二帐号发送反馈信息，并通过第二测试工具向服务器发送信息获取请求，以获取第二帐号接收到的信息，并在检测到第二帐号接收到反馈信息时，确定待测试客户端通过测试，从而实现对待测试客户端信息发送功能的测试，进一步提高了交互测试的准确性。

图7是根据一示例性实施例示出的一种测试装置700的框图。例如，装置700可以实现成为图1中的测试设备110。

参照图7，装置700可以包括以下一个或多个组件：处理组件702，存储器704，电源组件706，多媒体组件708，输入/输出(I/O)的接口712以及通信组件716。

处理组件702通常控制装置700的整体操作，诸如与显示和测试操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在装置700的操作。这些数据的示例包括用于在装置700上操作的任何应用程序或方法的指令。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为装置700的各种组件提供电力。电源组件706可以包括电源管理***，一个或多个电源，及其他与为装置700生成、管理和分配电力相关联的组件。

多媒体组件708包括在所述装置700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

I/O接口712为处理组件702和***接口模块之间提供接口，上述***接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

通信组件716被配置为便于装置700和其他设备之间有线或无线方式的通信。装置700可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件716经由广播信道接收来自外部广播管理***的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件1316还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置700可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述测试方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器704，上述指令可由装置700的处理器720执行以完成上述测试方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由装置700的处理器执行时，使得装置700能够执行上述测试方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (14)

1.一种测试方法，其特征在于，用于测试设备，所述方法包括：

通过第一测试工具控制终端中的待测试客户端登陆第一帐号，所述第一测试工具采用客户端自动化测试框架；

通过第二测试工具向所述待测试客户端对应的服务器发送登陆请求，所述登陆请求用于请求所述服务器设置第二帐号为登陆状态，所述第二测试工具采用行为驱动开发BDD自动化测试框架；

通过所述第二测试工具向所述服务器发送信息发送请求，所述信息发送请求用于请求所述服务器使用所述第二帐号向所述第一帐号发送预定信息；

通过所述第一测试工具检测所述待测试客户端登陆的所述第一帐号是否接收到所述预定信息。

2.根据权利要求1所述的方法，其特征在于，所述通过第二测试工具向所述待测试客户端对应的服务器发送登陆请求，包括：

通过所述第二测试工具调用所述服务器提供的第一应用程序编程接口API，向所述服务器发送所述登陆请求，所述第一API用于实现帐号登陆功能。

3.根据权利要求1所述的方法，其特征在于，所述通过所述第二测试工具向所述服务器发送信息发送请求，包括：

通过所述第二测试工具调用所述服务器提供的第二API，向所述服务器发送所述信息发送请求，所述第二API用于实现帐号间信息发送功能。

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

通过所述第一测试工具控制所述待测试客户端向所述第二帐号发送反馈信息；

通过所述第二测试工具向所述服务器发送信息获取请求，所述信息获取请求用于请求获取所述第二帐号接收到的信息。

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

若所述第一帐号接收到所述预定信息，且所述第二帐号接收到所述反馈信息，则确定所述待测试客户端通过测试。

6.根据权利要求1至3任一所述的方法，其特征在于，

所述第一测试工具包括calabash、Appium或Robolectric中的至少一种；

所述第二测试工具包括cucumber、RobotFramework、JBehave、RBehave或Fitnesse中的至少一种。

7.一种测试装置，其特征在于，所述装置包括：

第一控制模块，被配置为通过第一测试工具控制终端中的待测试客户端登陆第一帐号，所述第一测试工具采用客户端自动化测试框架；

第一请求模块，被配置为通过第二测试工具向所述待测试客户端对应的服务器发送登陆请求，所述登陆请求用于请求所述服务器设置第二帐号为登陆状态，所述第二测试工具采用行为驱动开发BDD自动化测试框架；

第二请求模块，被配置为通过所述第二测试工具向所述服务器发送信息发送请求，所述信息发送请求用于请求所述服务器使用所述第二帐号向所述第一帐号发送预定信息；

检测模块，被配置为通过所述第一测试工具检测所述待测试客户端登陆的所述第一帐号是否接收到所述预定信息。

8.根据权利要求7所述的装置，其特征在于，所述第一请求模块，还被配置为通过所述第二测试工具调用所述服务器提供的第一应用程序编程接口API，向所述服务器发送所述登陆请求，所述第一API用于实现帐号登陆功能。

9.根据权利要求7所述的方法，其特征在于，所述第二请求模块，还被配置为通过所述第二测试工具调用所述服务器提供的第二API，向所述服务器发送所述信息发送请求，所述第二API用于实现帐号间信息发送功能。

10.根据权利要求7至9任一所述的装置，其特征在于，所述装置，还包括：

第二控制模块，被配置为通过所述第一测试工具控制所述待测试客户端向所述第二帐号发送反馈信息；

第三请求模块，被配置为通过所述第二测试工具向所述服务器发送信息获取请求，所述信息获取请求用于请求获取所述第二帐号接收到的信息。

11.根据权利要求10所述的装置，其特征在于，所述装置，还包括：

确定模块，被配置为当所述第一帐号接收到所述预定信息，且所述第二帐号接收到所述反馈信息时，确定所述待测试客户端通过测试。

12.根据权利要求7至9任一所述的装置，其特征在于，

所述第一测试工具包括calabash、Appium或Robolectric中的至少一种；

所述第二测试工具包括cucumber、RobotFramework、JBehave、RBehave或Fitnesse中的至少一种。

13.一种测试装置，其特征在于，所述装置包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

通过第一测试工具控制终端中的待测试客户端登陆第一帐号，所述第一测试工具采用客户端自动化测试框架；

通过第二测试工具向所述待测试客户端对应的服务器发送登陆请求，所述登陆请求用于请求所述服务器设置第二帐号为登陆状态，所述第二测试工具采用行为驱动开发BDD自动化测试框架；

通过所述第二测试工具向所述服务器发送信息发送请求，所述信息发送请求用于请求所述服务器使用所述第二帐号向所述第一帐号发送预定信息；

通过所述第一测试工具检测所述待测试客户端登陆的所述第一帐号是否接收到所述预定信息。

14.一种测试***，其特征在于，所述测试***包括：测试设备、与所述测试设备相连的终端以及服务器；

所述终端与所述服务器之间通过有线或无线网络相连，所述测试设备与所述服务器之间通过有线或无线网络相连；

所述测试设备包括如权利要求7至12任一所述的测试装置。