客户端自动测试方法及系统与流程

1.本技术涉及软件测试技术领域，具体而言，涉及一种客户端自动测试方法及系统。


背景技术：

2.软件测试是确保软件质量的重要手段之一。在互联网时代，随着软件功能越来越丰富，版本迭代越来越频繁，对软件测试效率提出了更高的要求。
3.目前的软件测试方案只能实现对单个客户端实例的测试，测试实例之间相互独立；并且，传统测试方案普遍基于界面交互进行人工测试，一旦软件界面改版，需要重新编写测试用例。因此，现有测试方案的测试用例维护困难，测试效率低下，测试成本高。


技术实现要素：

4.本技术的实施例提供了一种客户端自动测试方法及系统，进而至少在一定程度上可以有效提高测试用例的可维护性及测试效率，降低测试成本。
5.本技术的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本技术的实践而习得。
6.根据本技术实施例的一个方面，提供了一种客户端自动测试方法，所述方法包括：获取测试用例；根据所述测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各所述客户端发送与各所述客户端对应的控制指令，以控制所述多个客户端的行为，其中，所述多个客户端中至少两个客户端接收到的控制指令不同；获取各所述客户端基于所述行为而产生的状态信息；根据所述状态信息确定对所述多个客户端的测试结果。
7.根据本技术实施例的一个方面，提供了一种客户端自动测试系统，所述系统包括：生成工具，用于获取远程过程调用指令描述文件，并根据所述远程过程调用指令描述文件生成第一接口代码文件和第二接口代码文件；多个客户端，所述客户端包括所述第一接口代码文件；后台程序，用于为所述多个客户端提供服务端；测试控制运行组件，包括所述第二接口代码文件和测试用例，所述测试控制运行组件用于根据所述测试用例执行以下操作：生成与所述多个客户端分别对应的控制指令，并以远程过程调用方式向各所述客户端发送与各所述客户端对应的控制指令，以控制所述多个客户端的行为，其中，所述多个客户端中至少两个客户端接收到的控制指令不同；获取各所述客户端基于所述行为而产生的状态信息；根据所述状态信息确定对所述多个客户端的测试结果。
8.在本技术的一些实施例中，基于前述方案，所述客户端包括第一远程过程调用服务端，所述第一远程过程调用服务端用于以远程过程调用方式获取所述控制指令；所述测试控制运行组件包括第二远程过程调用服务端，所述第二远程过程调用服务端用于获取各所述客户端的状态信息。
9.根据本技术实施例的一个方面，提供了一种客户端自动测试装置，所述装置包括：第一获取单元，用于获取测试用例；控制单元，用于根据所述测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各所述客户端发送与各所述客户端对应的控
制指令，以控制所述多个客户端的行为，其中，所述多个客户端中至少两个客户端接收到的控制指令不同；第二获取单元，用于获取各所述客户端基于所述行为而产生的状态信息；确定单元，用于根据所述状态信息确定对所述多个客户端的测试结果。
10.在本技术的一些实施例中，基于前述方案，在获取测试用例之前，所述第一获取单元还用于：获取远程过程调用指令描述文件；根据所述远程过程调用指令描述文件生成接口代码文件，并根据所述接口代码文件对多个原始客户端进行代码嵌入操作，得到所述多个客户端，其中，所述测试用例是根据所述接口代码文件编写的。
11.在本技术的一些实施例中，基于前述方案，所述控制单元配置为：通过调用所述客户端中所述接口代码文件提供的接口，向各所述客户端发送与各所述客户端对应的控制指令。
12.在本技术的一些实施例中，基于前述方案，所述接口代码文件包括远程过程调用协议实现文件和代码框架文件，所述第一获取单元配置为：将所述远程过程调用协议实现文件和所述代码框架文件分别嵌入多个原始客户端中，得到多个客户端，以在所述客户端中执行所述代码框架文件时调用所述远程过程调用协议实现文件。
13.在本技术的一些实施例中，基于前述方案，所述控制单元配置为：根据所述测试用例生成与多个客户端分别对应的客户端启动指令；以远程过程调用方式向所述多个客户端分别发送与各客户端对应的客户端启动指令，以启动所述多个客户端。
14.在本技术的一些实施例中，基于前述方案，所述多个客户端是同一软件产品的多个客户端实例，所述客户端自动测试方法是在对所述软件产品进行版本迭代时进行的。
15.在本技术的一些实施例中，基于前述方案，所述软件产品为各客户端之间存在交互行为的互联网软件。
16.在本技术的一些实施例中，基于前述方案，在根据所述状态信息确定对所述多个客户端的测试结果之后，所述确定单元还用于：获取包括所述测试结果在内的多个测试结果，所述多个测试结果是基于多个测试用例分别对所述多个客户端进行测试而得到的；对所述多个测试结果进行统计，并根据统计结果生成测试报告。
17.在本技术的一些实施例中，基于前述方案，所述状态信息为客户端状态或客户端事件。
18.根据本技术实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的客户端自动测试方法。
19.根据本技术实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的客户端自动测试方法。
20.根据本技术实施例的一个方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如上述实施例中所述的客户端自动测试方法。
21.在本技术的一些实施例所提供的技术方案中，通过在获取到测试用例之后，根据测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各客户端发送相应的控制指令，从而实现了对各客户端的并行分布式控制；在各客户端被控制的基础上，
便可以获取到受控的各客户端的状态信息，进而可以根据状态信息分析出相应的测试结果。由此可见，本技术实施例的方案能够基于单个测试用例同时实现对多个客户端的自动化测试，并且由于整个测试方案与界面无关，因而即使界面改版，也可以不需要重新编写测试用例。因此，采用本技术实施例的方案会使得测试用例的编写和维护更加简单，显著提高了测试效率，降低了测试成本。
22.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
23.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
24.图1示出了可以应用本技术实施例的技术方案的示例性系统架构的示意图；
25.图2示出了根据本技术的一个实施例的客户端自动测试系统的框图；
26.图3示出了根据本技术的一个实施例的rpc通信模型的框图；
27.图4示出了根据本技术的一个实施例的rpc运行机制的框图；
28.图5示出了根据本技术的一个实施例的客户端自动测试方法的流程图；
29.图6示出了根据本技术的一个实施例的图5中步骤530之前步骤以及步骤540的细节的流程图；
30.图7示出了根据本技术的一个实施例的客户端自动测试装置的框图；
31.图8示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
具体实施方式
32.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本技术将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
33.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本技术的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本技术的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本技术的各方面。
34.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
35.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
36.自动化测试是提高测试效率和覆盖率的重要手段。在互联网时代，随着软件功能
越来越丰富，要缩短开发周期，提高版本迭代速度，测试的自动化程度至关重要。合适的自动化测试工具，可以在保证软件质量的前提下大幅缩短软件开发周期，只需要前期投入工具链的搭建和开发，因此人力投入较少。
37.在相关技术中，可以基于界面或测试脚本的自动完成测试，测试时能够大部分覆盖软件功能。但是，在这些方案中，测试实例之间相互独立，只能覆盖单个实例或单个用户的场景，无法应对多用户交互的测试用例和场景。
38.具体而言，传统的自动化工具qtp、winrunner、phoenix framework等，这些方案主要支持有界面的软件，能以录制的方式和脚本的方式编写测试用例。这些方案的主要应用场景为有界面的客户端软件和web应用的自动化测试，然后通过以下方式编写测试用例：
39.1、录制界面的操作序列，录制的操作序列可以包括鼠标、键盘、web控件触发等；
40.2、捕获屏幕输出信息，屏幕输出信息可以包括像素颜色判断结果、控件扫描结果、dom识别结果等；
41.3、编写规则，用特定屏幕输出作为判断条件，声明预期结果；
42.最后，通过如下方式来运行测试用例：运行测试用例，重复执行操作序列；根据规则和屏幕输出信息，判断是否测试通过。
43.因此，相关技术方案都是基于单个运行实例的界面交互进行测试的，存在以下问题：
44.1、测试用例编写和维护复杂，软件界面升级后几乎要重写全部测试用例。
45.2、基于操作序列的录制和屏幕输出的捕获来进行测试，场景覆盖困难且不全面。比如，对于不同用户身份登录的测试场景，即使相同操作序列，屏幕输出也有差异，因此，该测试场景难以覆盖。
46.3、缺乏运行实例之间通信手段，无法实现多用户交互测试，导致只能进行低效的人工测试。
47.为此，本技术首先提供了一种客户端自动测试系统。基于本技术实施例提供的客户端自动测试系统可以克服上述缺陷，基于进行运行实例远程操作控制，测试用例在控制端编写，测试过程不依赖于界面，可以有效解决上述问题，并能够对大规模客户端实现分布式自动化测试。rpc(remote procedure call，远程过程调用)是一种通过网络从远程计算机程序上请求服务的方式。
48.图1示出了可以应用本技术实施例的技术方案的示例性系统架构的示意图。
49.如图1所示，该系统架构100包括控制终端110、第一用户终端120、第二用户终端130、第三用户终端140以及服务器150，其中，控制终端110可以为台式计算机，各用户终端可以为智能手机。控制终端110通过网络与各用户终端通信连接，各用户终端通过网络与服务器150通信连接。各用户终端上均部署并运行有客户端，控制终端110上部署并运行有测试控制运行组件，测试控制运行组件可以以远程过程调用方式与各客户端通信；服务器150上则部署并运行有为各用户终端的客户端提供服务的后台程序。
50.该系统架构的运行过程如下：首先，测试人员在控制终端110上编写好用于对各用户终端上的客户端进行测试的测试用例，并将测试用例输入至控制终端110上的测试控制运行组件中；然后，测试控制运行组件会根据测试用例生成与各客户端分别对应的控制指令，并通过网络以远程过程调用方式将各控制指令发送至相应的客户端；接着，客户端会执
行接收到的控制指令，从而使得客户端的行为受到测试控制运行组件的控制，在此过程中客户端可能会与服务器150上后台程序进行交互；接下来，测试控制运行组件会通过网络获取到各客户端的状态信息；最后，测试控制运行组件根据获取到的客户端的状态信息得到相应的测试结果。
51.在本技术的一个实施例中，各用户终端上的客户端为同一软件产品的客户端实例。
52.在本技术的一个实施例中，软件产品为社交软件。
53.应该理解，图1中的用户终端和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的用户终端和服务器。比如还可以设置更多数量的用户终端，服务器150可以是多个服务器组成的服务器集群等。
54.需要说明的是，图1示出的仅为本技术的一个实施例，虽然在图1实施例中，用户终端为智能手机，控制终端为台式计算机，但在本技术的其他实施例中，控制终端和用户终端均可以是各种类型的终端设备，且各用户终端的设备类型可以不同；比如，用户终端还可以是可穿戴设备，控制终端可以是笔记本电脑等。虽然在图1实施例中，各客户端分别运行在不同的终端设备上，但在本技术的其他实施例中，各客户端还可以运行在同一终端设备上；虽然在图1实施例中，测试控制运行组件与各客户端分别部署在不同的终端设备上，但在本技术的其他实施例中，测试控制运行组件与各客户端均可以部署在同一终端设备上，例如，测试控制运行组件与各客户端可以均作为不同进程运行在台式计算机上。本技术实施例对此不作任何限定，本技术的保护范围也不应因此而受到任何限制。
55.如前所述，可以通过终端与服务器的交互来实现本技术实施例的方案。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(content delivery network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术在此不做限制。
56.本技术实施例可以应用于云计算技术领域中，具体地，可以将为客户端提供服务的后台程序部署在云服务器中。云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。
57.作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为iaas(infrastructure as a service，基础设施即服务))平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。
58.按照逻辑功能划分，在iaas(infrastructure as a service，基础设施即服务)层上可以部署paas(platform as a service,平台即服务)层，paas层之上再部署saas(software as a service,软件即服务)层，也可以直接将saas部署在iaas上。paas为软件运行的平台，如数据库、web容器等。saas为各式各样的业务软件，如web门户网站、短信群发
器等。一般来说，saas和paas相对于iaas是上层。
59.以下对本技术实施例的技术方案的实现细节进行详细阐述：
60.本技术提供了一种客户端自动测试系统，该系统包括：多个客户端、后台程序以及测试控制运行组件。
61.图2示出了根据本技术的一个实施例的客户端自动测试系统的框图。请参见图2所示，客户端自动测试系统包括app客户端a(app client a)、app客户端b(app client b)、app客户端c(app client c)、测试控制运行组件(test runner)、测试框架(test framework)以及app后台(app backend)，其中，app客户端a、app客户端b和app客户端c为三个app客户端，app后台是为三个app客户端提供服务端的后台程序，测试框架与各app客户端分别对应设置，并由测试控制运行组件和各app客户端引用，使得测试控制运行组件能够以远程过程调用(remote procedure call，rpc)方式与各app客户端通信；各app客户端能够访问后台程序。测试控制运行组件和app客户端为不同的进程，它们可以位于同一机器上，也可以位于不同机器上。测试控制运行组件可以远程启动各app客户端。
62.图3示出了根据本技术的一个实施例的rpc通信模型的框图；图4示出了根据本技术的一个实施例的rpc运行机制的框图。请结合图2并参见图3和图4所示，可以看到，测试控制运行组件还包括多个test case，test case即为测试用例，测试控制运行组件用于根据测试用例执行以下操作：生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各客户端发送与各客户端对应的控制指令，以控制多个客户端的行为，其中，多个客户端中至少两个客户端接收到的控制指令不同；获取各客户端基于行为而产生的状态信息；根据状态信息确定对多个客户端的测试结果。
63.关于测试控制运行组件执行的这些操作将在后续实施例中进行介绍，此处暂不详述。
64.测试框架是app客户端与测试控制运行组件中与rpc相关的接口和对象的封装。各app客户端与测试控制运行组件进行通信时，需要使用测试框架提供的接口。因此，还可以将测试框架视为app客户端的接口部分与测试控制运行组件的接口部分的整体，即测试框架可以分别位于客户端与测试控制运行组件中。请继续参见图4所示，位于app客户端中的callshander.cpp、eventhandler.cpp、calls.rpc.h/.cpp以及event.rpc.h/.cpp等文件便可以是测试框架的一部分，位于测试控制运行组件中的calls.rpc.py、eventcalls.rpc.py以及eventhandler.py等文件也可以是测试框架的一部分。
65.客户端自动测试系统还包括生成工具，其用于获取远程过程调用指令描述文件，并根据远程过程调用指令描述文件生成第一接口代码文件和第二接口代码文件，第一接口代码文件位于客户端中，第二接口代码文件位于测试控制运行组件中。
66.在图4实施例中，生成工具即gen tool，生成工具可以与app客户端位于同一机器上，也可以位于不同机器上远程过程调用指令描述文件即rpc definition file，在将远程过程调用指令描述文件输入至生成工具之后，从生成工具伸出三个箭头，这些箭头指向由生成工具根据远程过程调用指令描述文件而生成的接口代码文件。其中，两个箭头指向app客户端中的文件，这些文件为第一接口代码文件；另外一个箭头指向测试控制运行组件中文件，这些文件即为第二接口代码文件。即callshander.cpp、eventhandler.cpp、calls.rpc.h/.cpp、event.rpc.h/.cpp为第一接口代码文件，而calls.rpc.py和
eventcalls.rpc.py为第二接口代码文件。通过第一接口代码文件和第二接口代码文件，使得app客户端与测试控制运行组件之间可以以远程过程调用方式通信。
67.在本技术的一个实施例中，客户端包括第一远程过程调用服务端，第一远程过程调用服务端用于以远程过程调用方式获取控制指令；测试控制运行组件包括第二远程过程调用服务端，第二远程过程调用服务端用于获取各客户端的状态信息。
68.测试控制运行组件和app客户端之间的数量关系是1:n的关系，测试控制运行组件需要能随时给app客户端发送指令，因此在每个app客户端启动时，其测试框架内置的rpc服务端会启动并监测来自测试控制运行组件的rpc调用。
69.此外，由于app客户端在状态发生变化或产生某些关键事件时，需要及时将app客户端的事件或状态作为状态信息通知给测试控制运行组件，因此测试控制运行组件也有一个内置的rpc服务端用于接收app客户端的通知。
70.请参见图3所示，测试框架中内置rpc服务端(built-in rpc server)可以视为app客户端中的第一远程过程调用服务端，而测试控制运行组件中的内置rpc服务端为第二远程过程调用服务端。在图3中，测试控制运行组件向测试框架中的内置rpc服务端发出request请求，该request请求即为rpc调用请求；测试控制运行组件从测试框架接收到的notify event即为通知的事件这一状态信息。
71.请继续参见图4所示，app客户端中的rpc服务端为第一远程过程调用服务端，测试控制运行组件中的rpc服务端为第二远程过程调用服务端，可以看到测试控制运行组件向app客户端中的rpc服务端发送了rpc call，rpc call即为rpc调用请求。
72.根据本技术实施例的一个方面，本技术还提供了一种客户端自动测试方法。该客户端自动测试方法可以由各种具备运算和处理功能的设备来执行，比如可以由笔记本电脑执行。
73.图5示出了根据本技术的一个实施例的客户端自动测试方法的流程图。请参照图5所示，该客户端自动测试方法至少包括以下步骤：
74.在步骤530中，获取测试用例。
75.测试用例即为测试用例脚本，测试用例可以由图4中的app客户端的开发者或者测试人员编写而成，可以将测试用例添加至测试控制运行组件中。
76.在步骤540中，根据测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各客户端发送与各客户端对应的控制指令，以控制多个客户端的行为，其中，多个客户端中至少两个客户端接收到的控制指令不同。
77.多个客户端所包括的客户端的数量可以是任何不小于2的整数。在测试控制运行组件运行时，会自动运行其中的测试用例。
78.对于每一个客户端，根据获取到的测试用例都能生成与该客户端对应的控制指令，然后可以将生成控制指令发送至对应的客户端，从而实现对各客户端的独立控制。客户端执行控制指令，会产生相应的行为，这些行为相当于用户对客户端的操作行为。由于控制指令是根据测试用例生成的，控制指令着客户端的行为，因此，测试用例中会定义着客户端的行为。
79.在本技术的一个实施例中，多个客户端是同一软件产品的多个客户端实例，该客户端自动测试方法是在对该软件产品进行版本迭代时进行的。
80.具体地，多个客户端中的每一客户端都是软件产品的一个客户端实例。例如，多个客户端可以是安装在多个智能终端上的微信app。可以将图4中的测试控制运行组件配置到ci(continuous integration，持续集成)流水线中，每次对软件产品进行版本迭代时可以通过执行本技术实施例提供的客户端自动测试方法来完成全自动化测试。
81.在本技术实施例中，通过在对具有多个客户端实例的软件产品进行版本迭代时执行客户端自动测试方法来完成全自动化测试，大幅提高了测试效率，能够在保证软件产品质量的前提下，缩短版本迭代时间。
82.在本技术的一个实施例中，软件产品为各客户端之间存在交互行为的互联网软件。
83.互联网软件可以是移动端app、pc软件等各种场景的互联网软件，具体可以是具有用户交互功能的软件。具体地，软件产品可以是游戏客户端，也可以是具有社交、社区、支付或资讯功能的软件，例如，可以是微信、qq等即时通讯软件。借助于互联网软件提供的交互功能，用户可以使用各客户端进行通信等交互行为。
84.在本技术实施例中，可以通过基于测试用例控制多个互联网软件的客户端，能够对各客户端之间的多用户交互功能进行测试，完整实现了多用户交互场景的自动化测试。
85.根据测试用例为各客户端生成的控制指令不会完全相同。在各客户端之间存在交互行为的互联网软件中，由于不同客户端的功能和用户操作行为不同，所以为不同客户端生成的控制指令也基本不同，即至少两个客户端接收到的控制指令不同，当然，这并不排除存在为若干客户端生成相同控制指令的情形。通过为每一客户端生成特定于该客户端的控制指令，能够实现对各客户端的并行测试。app客户端的开发者或测试人员通过编写测试用例，可实现对相应的控制指令的定义。
86.在本技术的一个实施例中，根据测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各客户端发送与各客户端对应的控制指令，以控制多个客户端的行为，包括：根据测试用例生成与多个客户端分别对应的客户端启动指令；以远程过程调用方式向多个客户端分别发送与各客户端对应的客户端启动指令，以启动多个客户端。在本技术实施例中，客户端启动指令也是根据测试用例生成的一种控制指令，测试用例还能够用于启动客户端。在图4所示实施例中，测试控制运行组件会根据测试用例远程自动启动任意数量的app客户端，并与这些app客户端建立rpc双向通道，一旦rpc双向通道建立完成，就可以继续执行测试用例，从而对各app客户端进行测试。app客户端无需手动启动。
87.图6示出了根据本技术的一个实施例的图5中步骤530之前步骤以及步骤540的细节的流程图。请参见图6所示，在步骤530之前，还可以包括以下步骤：
88.在步骤510中，获取远程过程调用指令描述文件。
89.请参见图4所示，远程过程调用指令描述文件被输入至生成工具中。
90.在步骤520中，根据远程过程调用指令描述文件生成接口代码文件，并根据接口代码文件对多个原始客户端进行代码嵌入操作，得到多个客户端，其中，测试用例是根据接口代码文件编写的。
91.为了使得图4中的测试控制运行组件能够以远程过程调用方式与app客户端进行通信，需要原始客户端进行修改，以满足rpc通信的需要。只有根据接口代码文件编写测试用例，才能顺利地根据测试用例来实现远程过程调用。
92.请继续参见图4所示，从生成工具向app客户端中延伸的箭头所指向的文件为生成工具根据远程过程调用指令描述文件生成的接口代码文件，app client core为原始客户端，接口代码文件嵌入在app client core上，使得这些接口代码文件成为了app客户端的一部分。
93.在本技术的一个实施例中，接口代码文件包括远程过程调用协议实现文件和代码框架文件，根据接口代码文件对多个原始客户端进行代码嵌入操作，得到多个客户端，包括：将远程过程调用协议实现文件和代码框架文件分别嵌入多个原始客户端中，得到多个客户端，以在客户端中执行代码框架文件时调用远程过程调用协议实现文件。
94.为了各客户端均能够以远程过程调用方式来与测试控制运行组件信，每一app客户端都要包含相应的接口代码文件。在图4中，位于app客户端中的callshander.cpp和eventhandler.cpp即为代码框架文件，这些文件是根据远程过程调用指令描述文件中的接口描述信息而自动生成的代码框架；可以看到，生成工具还会根据远程过程调用指令描述文件生成calls.rpc.h/.cpp和event.rpc.h/.cpp，这些文件是rpc协议实现文件，这些rpc协议实现文件用来提供给包括callshander.cpp和eventhandler.cpp在内的代码框架文件进行调用。这些rpc协议实现文件的具体内容与选择的rpc规范和技术有关，此处不详述。eventhandler.cpp可以用来向测试控制运行组件发送状态信息。
95.不仅客户端可以包括接口代码文件，测试控制运行组件也可以包括接口代码文件。请继续参见图4所示，测试控制运行组件中还包括由生成工具根据远程过程调用指令描述文件生成的calls.rpc.py和eventcalls.rpc.py，这些文件是rpc协议实现文件，是提供给测试用例编写者调用的库。
96.上述的所有接口代码文件可以基于任何脚本语言构建的。
97.请继续参阅图6，步骤540具体可以包括以下步骤：
98.在步骤540'中，通过调用客户端中接口代码文件提供的接口，向各客户端发送与各客户端对应的控制指令。
99.测试控制运行组件通过调用客户端中接口代码文件提供的接口，基于rpc远程调用的方式与客户端通信。
100.请继续参见图5，在步骤550中，获取各客户端基于行为而产生的状态信息。
101.当客户端按照相应的行为来运行时，会产生相应的状态信息。
102.在本技术的一个实施例中，状态信息为客户端状态或客户端事件。
103.在图3实施例中测试控制运行组件接收到的notify event便是客户端事件类型的状态信息。
104.在步骤560中，根据状态信息确定对多个客户端的测试结果。
105.对某一客户端的状态信息进行分析和处理，就能够得到对该客户端的测试结果。具体地，可以根据客户端的状态信息判断客户端是否测试通过，并将判断结果作为对客户端的测试结果。
106.在本技术的一个实施例中，测试用例包括以下部分：初始化客户端；启动客户端；调用rpc接口控制多个客户端的行为；获取客户端状态或捕获客户端事件；根据客户端状态或客户端事件判断是否通过测试。
107.因此，根据本实施例可知，不仅步骤540需要根据测试用例来执行，步骤步骤550和
步骤560也需要基于测试用例来执行。
108.在本技术的一个实施例中，在根据状态信息确定对多个客户端的测试结果之后，该客户端自动测试方法还包括：获取包括该测试结果在内的多个测试结果，多个测试结果是基于多个测试用例分别对多个客户端进行测试而得到的；对多个测试结果进行统计，并根据统计结果生成测试报告。
109.多个测试结果中的每个测试结果都是根据获取的一个测试用例，通过执行本技术实施例的客户端自动测试方法对多个客户端进行测试而得到的。
110.如图4所示，通过在测试控制运行组件中设置多个测试用例，运行测试控制运行组件，其中的所有测试用例将自动运行，每运行一个测试用例，都将得到相应的测试结果；所有测试用例运行完毕之后，通过对测试结果进行统计和分析，能够得到相应的测试报告。最后，可以以弹窗、页面等方式将测试报告输出，以提供给开发人员或者测试人员。
111.综上所述，根据本技术实施例提供的客户端自动测试方案，允许测试人员在单个测试用例脚本中启动任意数量的远程客户端，在测试用例脚本中定义客户端的行为，对有彼此之间交互关系的大规模软件客户端实现了并行分布式自动化测试，满足了多用户交互场景的测试需求；由于整体方案与界面无关，而且测试用例可同时控制多个客户端实例进行交互测试，因此极大降低了测试用例的编写和维护成本，显著提高了测试效率，降低了测试成本。
112.以社交软件的一个版本进行测试为例，本技术方案至少可以产生以下收益：
113.(1)测试周期：人工测试需要耗时2～3天；而基于本技术方案，通过测试控制运行组件进行自动测试，将测试耗时缩短为1小时。
114.(2)人力投入：人工测试需要投入3～5人天；而基于本技术方案，通过将测试控制运行组件部署到ci环境中进行测试，只需投入0人天，而且项目管理人员可直接查看测试报告。
115.(3)软件迭代周期：整体减少2～3天。
116.(4)测试用例可维护性：从人工编写用例文档，转变为用代码编写测试用例。
117.(5)界面改版后的投入：人工测试时，界面改版后再进行测试需要重新编写测试用例；使用本技术方案后，无需重新编写测试用例。
118.以下介绍本技术的装置实施例，可以用于执行本技术上述实施例中的客户端自动测试方法。对于本技术装置实施例中未披露的细节，请参照本技术上述的客户端自动测试方法的实施例。
119.图7示出了根据本技术的一个实施例的客户端自动测试装置的框图。
120.参照图7所示，根据本技术的一个实施例的客户端自动测试装置700，包括：第一获取单元710、控制单元720、第二获取单元730以及确定单元740。其中，第一获取单元710用于获取测试用例；控制单元720用于根据所述测试用例生成与多个客户端分别对应的控制指令，并以远程过程调用方式向各所述客户端发送与各所述客户端对应的控制指令，以控制所述多个客户端的行为，其中，所述多个客户端中至少两个客户端接收到的控制指令不同；第二获取单元730用于获取各所述客户端基于所述行为而产生的状态信息；确定单元740用于根据所述状态信息确定对所述多个客户端的测试结果。
121.在本技术的一些实施例中，基于前述方案，在获取测试用例之前，第一获取单元
710还用于：获取远程过程调用指令描述文件；根据所述远程过程调用指令描述文件生成接口代码文件，并根据所述接口代码文件对多个原始客户端进行代码嵌入操作，得到所述多个客户端，其中，所述测试用例是根据所述接口代码文件编写的。
122.在本技术的一些实施例中，基于前述方案，控制单元720配置为：通过调用所述客户端中所述接口代码文件提供的接口，向各所述客户端发送与各所述客户端对应的控制指令。
123.在本技术的一些实施例中，基于前述方案，所述接口代码文件包括远程过程调用协议实现文件和代码框架文件，第一获取单元710配置为：将所述远程过程调用协议实现文件和所述代码框架文件分别嵌入多个原始客户端中，得到多个客户端，以在所述客户端中执行所述代码框架文件时调用所述远程过程调用协议实现文件。
124.在本技术的一些实施例中，基于前述方案，控制单元720配置为：根据所述测试用例生成与多个客户端分别对应的客户端启动指令；以远程过程调用方式向所述多个客户端分别发送与各客户端对应的客户端启动指令，以启动所述多个客户端。
125.在本技术的一些实施例中，基于前述方案，所述多个客户端是同一软件产品的多个客户端实例，所述客户端自动测试方法是在对所述软件产品进行版本迭代时进行的。
126.在本技术的一些实施例中，基于前述方案，所述软件产品为各客户端之间存在交互行为的互联网软件。
127.在本技术的一些实施例中，基于前述方案，在根据所述状态信息确定对所述多个客户端的测试结果之后，确定单元740还用于：获取包括所述测试结果在内的多个测试结果，所述多个测试结果是基于多个测试用例分别对所述多个客户端进行测试而得到的；对所述多个测试结果进行统计，并根据统计结果生成测试报告。
128.在本技术的一些实施例中，基于前述方案，所述状态信息为客户端状态或客户端事件。
129.图8示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
130.需要说明的是，图8示出的电子设备的计算机系统800仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
131.如图8所示，计算机系统800包括中央处理单元(central processing unit，cpu)801，其可以根据存储在只读存储器(read-only memory，rom)802中的程序或者从存储部分808加载到随机访问存储器(random access memory，ram)803中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在ram 803中，还存储有系统操作所需的各种程序和数据。cpu 801、rom 802以及ram 803通过总线804彼此相连。输入/输出(input/output，i/o)接口805也连接至总线804。
132.以下部件连接至i/o接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。
133.特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(cpu)801执行时，执行本技术的系统中限定的各种功能。
134.需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
135.附图中的流程图和框图，图示了按照本技术各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
136.描述于本技术实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
137.作为一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
138.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单
元，但是这种划分并非强制性的。实际上，根据本技术的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
139.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本技术实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本技术实施方式的方法。
140.可以理解的是，在本技术的具体实施方式中，涉及到与视频处理相关的数据，当本技术以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
141.本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。
142.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求来限制。