CN104050076A - 移动终端上的应用软件测试方法、装置及系统 - Google Patents

Abstract

本申请公开了一种移动终端上的应用软件测试方法、装置及系统，其中，所述方法包括：接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；指示所述目标移动终端启动所述应用软件，并遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；将在目标移动终端上截取到的图片返回到客户端。通过本申请，能够更高效地实现在移动终端上的应用软件测试。

Description

移动终端上的应用软件测试方法、装置及系统

技术领域

本申请涉及移动互联网技术领域，特别是涉及移动终端上的应用软件测试方法、装置及系统。

背景技术

随着手机等智能移动终端的发展，移动互联网逐渐引起人们的关注，从以往的手机只能打电话发信息，到现在可以上网，语音聊天，上网购物，等等，移动终端已经离不开人们的生活。移动互联网也随之快速发展，并且不断地涌现出大量应用于移动终端的应用软件。

一款应用软件在被开发出来之后，首先需要进行测试。移动终端的应用软件测试类型大致可分为：UI测试、功能模块测试、交叉事件测试、压力测试、安全性测试、兼容性测试、易用性/用户体验测试等。而移动终端上的应用软件测试不像PC机上web测试，主流的浏览器只有IE、Fi refox和Chrome等有限的几种，而且任何一个PC机都可以安装所有的浏览器，对于移动终端上的应用软件测试而言，移动终端设备种类众多，测试人员往往需要在所有移动终端上进行测试，而且手机等移动终端的成本也很高，除此之外移动终端的更新速度也非常快，所以能在既节省开支和设备成本的前提下，又能提高的测试的效率显得格外重要。

为了适应这种需要，现有技术中出现了一些自动化测试平台，利用这种测试平台，测试人员可以将开发出的应用软件的安装包以及需要在哪些终端设备上进行测试等信息上传到服务器端，服务器端就可以在测试人员选择的终端设备上安装该应用软件，并将测试结果返回给测试人员。这样，应用软件开发方就不需要为了测试自己的应用软件而购置大量的移动终端设备，这节省了测试成本。

但是，现有技术中，除了需要测试人员上传其安装包等信息之外，一般还需要测试人员根据封装好的方法接口去编写测试用例脚本，根据自己想要判断的方法和想要输入的值进行调试，效率很低，而且执行起来也相对比较繁琐。

发明内容

本申请提供了移动终端上的应用软件测试方法、装置及系统，能够更高效地实现在移动终端上的应用软件测试。

本申请提供了如下方案：

一种移动终端上的应用软件测试方法，包括：

接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

指示所述目标移动终端启动所述应用软件，并遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

将目标移动终端上截取到的图片返回到客户端。

一种移动终端上的应用软件测试方法，包括：

将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。

一种移动终端上的应用软件测试系统，包括：

接收单元，用于接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

安装单元，用于将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

控件触发单元，用于指示所述目标移动终端启动所述应用软件，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

返回单元，用于将目标移动终端上截取到的图片返回到客户端。

一种移动终端上的应用软件测试装置，包括：

上传单元，用于将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

图片信息接收单元，用于接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

图片信息展现单元，用于根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请，应用软件开发商的测试人员只需要将应用软件的安装包上传到测试平台，并选择需要在哪些移动终端上进行测试，测试平台就可以在这些指定的移动终端中安装该应用软件，并在启动应用软件之后，对于该应用软件相关的各个控件进行遍历触发，对各控件被触发后的界面显示情况进行截图，然后再返回给客户端，对截图情况进行显示。这样，测试人员就可以根据截图情况判断出应用软件在各个移动终端上的显示情况，进而确定是否需要进行调整等，以达到测试的目的。由于本申请能够对于一个应用软件相关的各个控件均能遍历触发，因此，能够全面得获得各个显示界面的显示情况。另外，在实现的过程中，能够自动获取各个控件的相关信息，并自动触发各个控件，因此，不再需要测试人员编写测试用例等，提高了测试效率。

在每次触发一个控件时，还可以在该被触发控件所在的显示界面进行截图，并根据被触发控件的坐标，在截得的图片中进行标识，这样可以便于测试人员获知各个显示界面与被触发控件之间的对应情况，更加清晰地展示测试结果。

另外，在展现各个显示界面的截图时，可以分别以移动终端为单位，对截图进行汇总后显示，从而可以按顺序展现出在测试流程中，在触发各个控件之后的界面显示情况。另外，还可以针对同一控件，展现出其分别在各个移动终端上被触发后得到的显示情况，便于在不同的移动终端中进行对比。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的服务器端方法的流程图；

图2是本申请实施例提供的控件树形结构示意图；

图3-1至图3-9是本申请实施例提供的动态栈结构示意图；

图4是本申请实施例提供的客户端方法的流程图；

图5是本申请实施例提供的服务器端系统的示意图；

图6是本申请实施例提供的客户端端装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

参见图1，本申请实施例提供的移动终端上的应用软件测试方法可以包括以下步骤：

S101：接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

本申请实施例具体的应用环境可以是应用软件测试平台，该平台上可以连接多个移动终端，这种移动终端可以是真实的设备产品，也可以是模拟器，可以覆盖多种品牌、多种型号，以满足不同应用软件的测试需要。对于应用软件的开发者而言，在开发出一款应用软件之后，可以通过测试平台的客户端或者登录测试平台的网站等，将应用软件的安装包上传到测试平台，并在确定好需要在哪些目标移动终端上进行测试之后，在客户端或者网站提供的用户界面中选择这些目标移动终端的标识，提交之后，测试平台便可以在这些目标移动终端上对该应用软件进行测试。

S102：将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

在接收到应用软件的安装包，并获知需要在哪些移动终端上进行测试之后，就可以将该安装包分别发送到这些移动终端上，并利用该安装包在这些移动终端上安装该应用软件。

其中，如果目标移动终端装载有Android操作系统，则可以通过HTTP(Hypertext Transfer Protocol，超文本数据传输协议)等协议将所述安装包分发到各个目标移动终端所在的服务器，并由服务器通过调用ADB(AndroidDebug Bridge)命令，在各个目标移动终端上安装该应用软件。其中，ADB命令是一种debug工具，能够起到调试桥的作用。通过ADB，可以在开发平台中方便通过DDMS(Dalvik Debug Monitor Service，Android开发环境中的Dalvik虚拟机调试监控服务)来调试Android程序。

S103：指示所述目标移动终端启动所述应用软件，并遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

在各个目标移动终端上安装了应用软件之后，就可以分别在各个目标移动终端中启动该应用软件。之后，可以在各个目标移动终端中模拟人触发应用软件中的控件操作，例如帮助触发划屏、输入文字和点击等一系列操作，可在每次操作后获取一张移动终端当前界面图片。

其中，所谓控件就是指应用软件界面中可触发的按钮(Button)、文本框(TextView)、图片(ImageView)等，一个界面中可能会包含有多个控件，一个控件被触发之后，可能会得到新的界面，在新的界面中又可能包含有多个控件。本申请实施例中，为实现全面测试，可对全部控件进行遍历触发，每次触发得到新的显示界面时，都进行截图，最终再将得到的截图汇总，然后后返回给应用软件开发方。由于在对应用软件进行测试时，主要的测试指标就是观察各个显示界面在移动终端中的显示情况，包括是否出现留白，或者是否出现横向的滚动条、有无破图、布局是否恰当、是否在所有移动终端都可以顺利触发或者点击、点击跳转界面是否相同等等，因此，在将汇总后的截图返回给应用软件开发者之后，应用软件开发者就可以通过查看这些截图，来直接获知或者进一步分析得到测试结果。

当然，为了使得最终在对截图进行汇总时，便于识别各个显示界面分别是在触发哪个控件时得到的，本申请还可以在每次触发一个控件时，在该被触发控件所在的显示界面进行截图，并根据被触发控件的坐标，在截得的图片中标识出被触发的控件所在的位置。这样，在展现界面显示情况时，便于识别出各个控件与触发后得到的显示界面之间的对应关系，进而便于找出问题所在。

具体实现时，在移动终端装载有Android操作系统的情况下，可以利用Android底层中Instrumentation命令获取移动终端中的控件和相应的Activity数据，通过getActivity()方法，获得当前执行的Activity信息，通过映射捕获相应Activity中各个view的相关信息，判断各个view是否可触发，将可触发的view确定为当前显示界面中包含的控件。之后可以建立一个类似栈的存储，将各个控件的相关信息(包括控件的id、坐标等等)存储到栈的各个数据单元中，然后从栈顶开始触发各个控件，每次触发时得到新的显示界面，如果新的显示界面中包含控件，同样可通过Instrumentation命令获取移动终端中的控件和相应的Activity数据，并将获取到的各个控件的相关信息存储到栈的各个数据单元中。与此同时，将已触发的控件进行标记，逐层深入(这期间可能会触发回到触发过的Activity界面，此时，首先可将该控件从栈中移出，再去触发没有被触发过的控件)，直到显示界面中没有可触发的控件，再一层层返回，先深度后广度地触发移动终端中相对应的控件。每触发一个控件，都可通过ADB进行截图，直到所有控件都被触发一遍。

其中，在操作过程中，已经触发过的控件不会去再次点击，但如果要反复触发某个控件可以通过配置来对该控件进行压力测试，帮助测试人员寻找程序中一些容易引发程序崩溃的bug。此外，每触发的一个控件，都可以通过获得触发控件的坐标展示在当前显示界面上，以便应用软件开发者知道都触发了那些控件，进而便于通过图片找到问题的所在。

需要说明的是，前文所述之所以称为“先深度再广度”地触发移动终端中相对应的控件，是因为，一个应用软件中的各个控件根据触发关系往往能够形成一种树形结构，从树形结构的根节点开始，沿着某一条路径到达某叶子节点，相当于是“深度”，同一级节点之间相当于“广度”。例如，如图2所示，假设某应用软件的初始界面中包含有A、B、C这样三个控件，其中，A控件被触发后，得到的界面中包含有控件A1、A2、A3，B控件被触发后，得到的界面中包含有控件B1、B2、B3，C控件被触发后，得到的界面中包含有控件C1、C2；A1控件被触发后，得到的界面中包含有控件A11、A12；A2控件被触发后，得到的界面中包含有控件A21、A22、A23；A3控件被触发后得到的界面中不再包含控件；B1控件被触发后，得到的界面中包含有控件B11；B2控件被触发后，得到的界面中包含有控件B21、B22；B3控件被触发后，得到的界面中包含有控件B31；C1控件被触发后，得到的界面中包含有控件C11、C12；C2控件被触发后，得到的界面中包含有控件C21；A11控件被触发后，得到的界面中包含有控件A111；A22控件被触发后，得到的界面中包含有控件A221；B11控件被触发后，得到的界面中包含有控件B111、B112；C12控件被触发后，得到的界面中包含有控件C121、C122；C121控件被触发后，得到的界面中包含有控件C1211；A12、A21、B21、B22、B31、C11、C21、A11、A221、B111、B112、C122、C1211这些控件被触发后得到的界面中均不再包含控件。最终由控件之间的父子关系得到的树形结构就可以如图2所示。其中，从A到A1，再到A11，在到A111这条路径就是深度，从A到B再到C就是广度。

相应的，为了实现前述先深度再广度的遍历，就可以借助于动态栈，并通过以下方式实现：在该应用软件被启动之后，首先就可以检测到A、B、C这三个控件，并将其相关信息分别保存在栈中，如图3-1所示，其中，控件C在栈的最底层，控件A在栈顶。接下来就可以从控件A开始触发。控件A被触发之后，在新的到的界面中新检测到控件A1、A2、A3，于是将控件A1、A2、A3写入到栈中，同时将控件A标记为已触发，如图3-2所示，假设“△”为“已触发”标记。在图3-2的状态下，由于A1位于栈顶，因此下次会触发控件A1，检测到新得到的界面中包含控件A11、A12，于是将A11、A12写入到栈中，同时将A1标记为已触发，如图3-3所示。接下来会触发位于栈顶的A11，检测到新得到的界面中包含有控件A111，于是将控件A111写入到栈中，同时将A11标记为已触发，如图3-4所示。接下来触发位于栈顶的A111，检测到新得到的界面中不包含有控件，于是将该控件A111标记为已触发，并向栈的底层遍历。如图3-5所示，当前处于栈顶的是控件A111，但是被标记为已触发，于是就可以将其从栈中移除，再向栈的下一层遍历，发现栈顶的A11也已被标记为已触发，因此也会将该控件从栈中移除；再向栈的向下一层遍历，发现栈顶的A12尚未被触发，于是触发该控件，检测到新得到的界面中不包含有控件，于是直接将控件A12标记为已触发，参见图3-6，并再向栈的下一层遍历；发现栈顶的A12、A1已触发，于是将其移除，再向下一层发现控件A2尚未被触发，于是触发A2，在新得到的界面中检测到控件A21、A22、A23，并分别写入到栈中，参见图3-7；并从位于栈顶的A21开始触发，A21被触发后，检测到界面中不包含有控件，于是将A21从栈中移除，并向下触发控件A22，检测到界面中包含有控件A221，于是写入到栈中，并将A22标记为已触发，参见图3-8；触发位于栈顶的A221，发现界面中不包含有控件，于是将其从栈中移除，发现位于栈顶的A22已触发，于是将其移除，再向下触发A23，检测出得到的界面中不包含有控件，于是将A23从栈中移除，再向下发现位于栈顶的A2已被触发，于是将其从栈中移除，并再向下触发位于栈顶的A3，检测出界面中不包含有控件，于是将A3从栈中移除，发现位于栈顶的A已被触发，于是将A从栈中移除，再向下触发位于栈顶的控件B，检测出得到的界面中包含有控件B1、B2、B3，分别写入到栈中，并将B标记为已触发，如图3-9所示；之后再从位于栈顶的控件B1开始触发，以此类推，后续不再赘述，直到将所有控件全都触发一遍为止。其中，每次触发一个控件，都会进行相应的截图。

也就是说，在获取到一个界面之后，就可以获得相对应的activity和控件的数目，存入到堆栈中，然后按照不同的分配进行去“命令”移动终端去触发相对应的控件，跳转到不同的界面，然后再次获得相对应的activity和控件的数目，再次存入到堆栈中，并将触发过的控件标为visit，再从栈顶逐层访问，每访问一次，将访问过标为visit，然后将获得的新数据再依次从栈顶存入栈，遇到相同的activity再去遍历其没有遍历的标签，这样做到一个动态保存，又可能会循环的保存栈。这与普通的栈还会有很大的区别，可以很好的遍历出全部的activity，并模拟触发很多的控件，还可调用相对应的back键操作，将其触发回去。

当然，在实际应用中，也可以通过其他的方式进行遍历，这里不再详述。总之，本申请实施例可以利用JAVA的反射机制，当Android移动终端执行一个app应用的时候，测试程序可以时时刻刻去监听映射出来当前界面的Activity和其控件的类型与ID值，将信息传递回服务器进行收集。与此同时，也会记录每个控件的是否被触发，当其被触发时候会改变其状态为已触发，然后跳转到其他界面，再次把数据保存，逐个触发，直到所有触发控件点击完成后再逐层返回。这样就可以做到既深度又广度的遍历，从而覆盖到更多的移动终端控制界面。每次触发都会截张图片，并把图片收集回来。这样可以避免测试人员去编写测试用例，覆盖的控件也会很全面。减少测试人员针对每种类型的移动终端都去测试一遍，从而减少了测试人员重复的工作，提高的测试效率。另外，本申请实施例是高并发的让所有移动终端同时执行测试，其较少了测试时间，提高产品更新效率。

S104：将在目标移动终端上截取到的图片返回到客户端。

在各个移动终端上对各个控件全都触发一遍之后，就可以将所有截图进行汇总，向同一移动终端上截取到的图片从前到后显示给测试人员，这样，测试人员就可以看到同一个移动终端在测试流程中各个控件被触发后，界面的显示情况。此外，还可以保存被触发控件与截取到的图片之间的对应关系，将目标移动终端上截取到的图片进行汇总后，展现出同一被触发控件在各个目标移动终端上截取到的图片，以便测试人员能够针对同一显示界面，在各个目标移动终端之间进行对比，然后查看所有相关移动终端在触发此控件后的界面显示情况，包括有无破图，布局是否恰当，是否在所有移动终端都可以顺利触发或者点击，点击跳转界面是否相同，等等。总之，可以将控件触发后的界面显示情况进行一站式汇总展示，从而避免了用户一个个移动终端、一个个控件触发的繁琐的过程，而且通过进行图片对比，可以减少测试人员自己用记忆进行短暂的对比，从而高效率、高性能地解决了多移动终端测试中遇到的适配性的瓶颈问题。真正意义上做到了智能适配性测试，体现出同款应用在不同终端设备上的适配，检测其上面的不同点，便于测试人员很便捷快速的找出不足的所在。并且，遍历的控件涉及的范围比较广，可以有效的触控到移动终端中的测试人员不能全部点击到的地方。

需要说明的是，在进行运行应用软件并进行测试的过程中，移动终端的操作系统可自动生成一个运行日志，从该运行日志中也能够获取到一些软件运行状况的关键信息，包括一些出错的信息，或者Null空指针信息，或者崩溃信息，等等。因此，在实际应用中，除了按照前述实施例中介绍的方式向测试人员返回各个控件被触发后的截图信息之外，还可以提取出目标移动终端的操作系统生成的运行日志，并返回给客户端。这样，测试人员可以将各个控件的截图情况意与运行日志相结合，综合得到应用软件在各个移动终端上的测试结果。

另外需要说明的是，在本申请实施例提供的上述方法中，在首次进行测试时，都可以按照先深度再广度的方式遍历所有的控件，并显示出各个控件被触发后的界面显示情况。但在实际应用中，可能需要针对一些特定的控件对应的界面显示情况进行单独的测试，因此，在本申请实施例中，还可以在完成一次测试、获知到当前应用软件中包含的所有控件(包括起始界面上的控件，以及触发了各个控件之后得到的新的界面中包含的控件)之后，可以在用户界面中展现出各个控件信息，并分别针对各个控件信息提供选择操作入口。这样，如果需要针对一些指定的控件进行测试，则可以在用户界面上进行选择，在提交之后，就可以根据客户端提交的选择信息，在各个目标移动终端上触发各个被选中的控件，并对得到的显示界面进行截图后，返回给客户端进行展现，以满足按照用户指定的路径进行测试的需求。

总之，通过此测试方法可以在较短的时间内将所有移动终端测试完成，这极大节约时间和人力。并且高效地解决了应用软件测试中移动终端种类过多，测试人员重复操作的问题。在技术上，测试人员不需要写测试脚本，也不用通过敲命令行的方式来执行每次的测试。应用软件的开发测试人员无需搭建任何测试环境，只要可以上网，通过平台提交测试应用的安装包，勾选自己想要测试的移动终端就可以帮助用户执行完全部操作，给予移动终端测试新的方案。在显示测试结果时，可以根据移动终端分开展示，每个移动终端都有整个测试过程中的全部截图详情，并且还可以进一步通过运行日志，分析测试过程出现的问题，累计最近测试覆盖情况。另外，还可以显示相同控件在不同移动终端上的截图对比情况，便于在不同的移动终端中进行对比。

为了更好地理解本申请实施例提供的上述方法，下面以装载有Android操作系统的手机为例，通过一个完整的流程，对本申请实施例进行介绍。

首先，当手机可以通过Instrument启动进入相对应的应用软件后，Instrument继承ActivityInstrumentationTestCase2方法调用getActivity()方法，可以获得当前执行的Activity信息。通过映射Class.forName(windowManagerClassName)，调用其获得Class类去映射它的Field方法去捕获相对应的Android手机界面的控件信息。

其中，在获取控件信息的过程中，还做了一些细节的操作，例如，每个映射出来的view都会判断其控件是否是可触发或者点击的，是否是可操作的，针对都会进行true和false的标识，只有被标识为true的view才会被确定为控件。

手机控件和activity信息获取出来之后就是一个存储和模拟人去点击触发该事件。对于存储的方法与操作，可以利用一个动态存储添加遍历信息的方式，实时添加实时进行里面控件的遍历。当进入一个Activity或者其他界面时候，测试程序会去获取当前界面的控件信息，然后把他存入栈中，存入的这部分就在栈顶，之后，测试程序在从栈顶从中选取某个控件进行触发操作，然后界面这时也会跟随跳转，把触发过的控件标为“visited”来表示已经被触发过，下次不去触发，同时又会捕获到新的控件信息，再把这部分信息存入栈中，依次触发下去。但是在操作过程中，跳转的界面可能会会是以前触发过的界面，因此，在存储的同时，还可以与之前的数据进行比较，如果是存在，就不再不存入到栈中，直接到该层去触发没有被标为“visited”的控件进行触发操作，然后继续操作下去，如果该层都被触发过，就向上返回一层，也就是向栈底再深一层遍历，这样就可以保证更多的控件被触发到。

对于模拟人去点击触发控件，可以通知手机去执行每个触发操作，执行赋值和点击事件。通过MotionEvent进行操作，模拟人去出发手机屏幕上的坐标。其中，对于手机控件的坐标可以通过view进行获得。在执行具体的操作是，可以按照不同的操作类型去“命令”手机去触发相对应的控件，跳转到不同的界面，然后再次获得相对应的activity和控件的相关信息，再次存入堆栈中，然后将触发过的控件标为visit，再从栈顶逐层访问，每访问一次，将访问过标为visit，然后将获得的新数据再依次从栈顶存入栈，然后遇到相同的activity然后再去触发其没有触发的标签，这样做到一个动态保存，又会循环的保存栈，这样便可以很好的遍历出全部的界面，并模拟人去尽可能触发所有的控件，同时还会调用相对应的back键操作将其触发回去。

最后，当一个测试流程结束之后，所有的图片都获取好了，接下来就可以将图片返回给测试人员进行分析。通过这些图片信息，可以看到应用软件在同一手机中运行时各个界面的显示情况，还可以看到同一控件在不同手机中展示的效果，来判断其是否布局合理，信息获得是否一致，展示效果是否是预想效果，控件的大小距离会不会随着手机屏幕的大小而影响，等等。

以上所述从服务器的角度对本申请实施例提供的移动终端上的应用软件测试方法进行了介绍，下面从客户端的角度对该方法进行介绍。参见图4，该方法可以包括以下步骤：

S401：将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

S402：接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

S403：根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。

也就是说，对于客户端而言，只需要将测试人员指定的待测试应用软件的安装包，以及目标移动终端的标识信息上传到服务器端，然后就可以等待接收服务器返回的图片信息，并展示给测试人员。具体的测试工作在服务器端来完成，并且服务器在测试的过程中，会分别在各个目标移动终端上遍历触发待测试应用软件中的各个控件，并分别对触发各个控件之后得到的界面进行截图，以便测试人员能够全面的了解所有界面在各个目标移动终端上的显示情况。

其中，服务器在向客户端返回截取的图片信息时，可以同时返回各个截取到的图片与目标移动终端之间的对应关系，以及同一目标移动终端上各个图片的截取顺序，这样，客户端具体在展现待测试应用软件在各个目标移动终端上的测试结果时，可以以目标移动终端为单位对截取到的图片进行展现，其中，对于同一目标移动终端，按照截取的先后顺序对各个图片进行展现，以便展现出在同一目标移动终端中的测试流程各个环节上的各个显示界面。

另外，服务器在向客户端返回截取的图片信息时，还可以同时返回各个被触发控件与截取到的图片之间的对应关系信息，这样，客户端具体在展现待测试应用软件在各个目标移动终端上的测试结果时，可以展现出同一被触发控件在各个目标移动终端上截取到的图片，以便在各个目标移动终端之间进行对比。这样，测试人员通过同一界面在不同目标移动终端上显示情况的对比，可以更容易发现该界面在某个或某些目标移动终端上显示时可能存在的缺陷，进而对缺陷进行弥补。

针对某待测试应用软件，由于服务器端进行测试时，会遍历触发其中包含的各个控件，因此，在第一次收到服务器端返回的完整测试结果之后，就可以获知该待测试应用软件中都包含有哪些控件。此时，可以将各个控件的信息展现出来，并分别为各个控件提供选择入口，这样，测试人员如果需要针对其中一些特定的控件进行重新测试，则可以通过这种选择入口进行选择，选择完成后，客户端就可以将选择信息上传到服务器，由服务器指示各个目标移动终端对这些被选择的控件进行遍历触发，并分别进行截图后返回给客户端，客户端再重新展现截取到的图片。最后需要说明的是，前文所述主要是以Android操作系统为例进行的介绍，但在具体实现时，本申请实施例提供的测试方法与流程也适合于IOS操作系统的移动终端上的测试，也就是说，对于IOS操作系统，也可以应用此测试理念，深度遍历相关移动终端上每个控件对应的界面显示情况，然后将其标示出来，使得用户可以根据图片展示达到预期测试效果

与本申请实施例提供的移动终端上的应用软件测试方法相对应，本申请实施例还提供了一种移动终端上的应用软件测试系统，该系统位于服务器端，参见图5，该系统可以包括：

接收单元501，用于接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

安装单元502，用于将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

控件触发单元503，用于指示所述目标移动终端启动所述应用软件，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

返回单元504，用于将目标移动终端上截取到的图片返回到客户端。

在实际应用中，为了使得用户知晓各个显示界面是在哪个控件被触发后得到的，该系统还可以包括：

被触发控件标识单元，用于指示所述目标移动终端在每次触发一个控件时，在该被触发控件所在的显示界面进行截图，并根据被触发控件的坐标，在截得的图片中标识出被触发的控件所在的位置。

具体实现时，所述控件触发单元403具体可以用于：

获取所述应用软件的相关显示界面中包含的控件的相关信息，根据所述相关信息触发各个控件。

其中，所述控件触发单元403具体可以包括：

动态栈创建子单元，用于创建动态栈；

触发子单元，用于将当前显示界面中包含的各个控件的相关信息分别保存到栈的各个数据单元中，从栈顶开始触发对应的控件，如果触发一个控件后得到新的显示界面，并且新的显示界面中包含控件，则将该新的显示界面中包含的各个控件的相关信息也分别保存到栈的各个数据单元中，并继续从栈顶开始触发对应的控件，直到新的显示界面中不再包含控件时向栈的下一层继续进行触发；其中，当一个控件被触发后，将该控件进行标识，当发现位于栈顶的控件已被触发时，将其移走，从新的栈顶开始触发对应的控件。

具体在返回截图结果时，所述返回单元404可以包括：

汇总子单元，用于将在目标移动终端上截取到的图片进行汇总后，返回到客户端。

其中，所述汇总子单元可以包括：

第一保存子单元，用于保存目标移动终端与截取到的图片之间对应关系，以及同一目标移动终端上各个图片的截取顺序，并返回给客户端，以便客户端以目标移动终端为单位对截取到的图片进行展现。

或者，该系统还可以包括：

第二保存单元，用于保存被触发控件与截取到的图片之间的对应关系，并返回给客户端，以便客户端展现出同一被触发控件在各个目标移动终端上截取到的图片。

当所述目标移动终端装载Android操作系统时，所述安装单元402具体用于：

将所述安装包分发到所述目标移动终端所在服务器，由所述服务器通过调用Android调试桥ADB命令，指示所述目标移动终端通过所述安装包安装所述应用软件；

所述控件触发单元403具体用于：

通过Instrumentation指示所述目标移动终端启动所述应用软件，得到显示界面，通过getActivity()方法，获得当前执行的Activity信息，通过映射捕获相应Activity中各个view的相关信息，判断各个view是否可触发，将可触发的view确定为当前显示界面中包含的控件。

在实际应用中，该系统还可以包括：

选择信息接收单元，用于接收客户端提交的对所述待测试应用软件中包含的控件进行选择的信息；其中，客户端在获取到所述待测试应用软件中包含的所有控件的情况之后，展现所述应用软件中包含的所有控件的信息，并提供选择操作入口，当通过所述选择操作入口确定到被选中的控件；；

选择性触发单元，用于根据客户端提交的选择信息，在各个目标移动终端上触发各个被选中的控件，并对得到的显示界面进行截图后，返回给客户端。

与本申请实施例提供的移动终端上的应用软件测试方法相对应，本申请实施例还提供了一种移动终端上的应用软件测试装置，应用于测试系统的客户端，参见图6，该装置可以包括：

上传单元601，用于将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

图片信息接收单元602，用于接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

图片信息展现单元603，用于根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。

其中，该装置还可以包括：

第一对应关系接收单元，用于接收所述服务器端返回的各个目标移动终端与截取到的图片之间的对应关系信息，以及同一目标移动终端上各个图片的截取顺序信息；

所述图片信息展现单元603具体用于：

以目标移动终端为单位对截取到的图片进行展现，其中，对于同一目标移动终端，按照截取的先后顺序对各个图片进行展现，以便展现出在同一目标移动终端中的测试流程各个环节上的各个显示界面。

或者，该装置还可以包括：

第二对应关系接收单元，用于接收所述服务器端返回的各个被触发控件与截取到的图片之间的对应关系信息；

所述图片信息展现单元603具体用于：

展现出同一被触发控件在各个目标移动终端上截取到的图片，以便在各个目标移动终端之间进行对比。

为了便于测试人员自定义测试路径，该装置还可以包括：

控件信息展现单元，用于展现所述应用软件中包含的所有控件的信息，并分别为各个控件提供选择操作入口；

选择信息上传单元，用于通过所述选择操作入口确定被选中的控件，将所述被选中的控件的信息上传到服务器端，以便所述服务器端根据提交的选择信息，在各个目标移动终端上遍历触发各个被选中的控件，并对得到的显示界面进行截图并返回；

特定展现单元，用于根据服务器端针对被选中的控件返回的截图信息，展现测试结果。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的移动终端上的应用软件测试方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种移动终端上的应用软件测试方法，其特征在于，包括：

接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

指示所述目标移动终端启动所述应用软件，并遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

将在目标移动终端上截取到的图片返回到客户端。

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

指示所述目标移动终端在每次触发一个控件时，在该被触发控件所在的显示界面进行截图，并根据被触发控件的坐标，在截得的图片中标识出被触发的控件所在的位置。

3.根据权利要求1或2所述的方法，其特征在于，所述遍历触发所述应用软件中的各个控件包括：

获取所述应用软件的相关显示界面中包含的控件的相关信息，根据所述相关信息触发各个控件。

4.根据权利要求3所述的方法，其特征在于，所述获取所述应用软件的相关显示界面中包含的控件的相关信息，根据所述相关信息触发各个控件包括：

创建动态栈；

将当前显示界面中包含的各个控件的相关信息分别保存到栈的各个数据单元中，从栈顶开始触发对应的控件，如果触发一个控件后得到新的显示界面，并且新的显示界面中包含控件，则将该新的显示界面中包含的各个控件的相关信息也分别保存到栈的各个数据单元中，并继续从栈顶开始触发对应的控件，直到新的显示界面中不再包含控件时向栈的下一层继续进行触发；其中，当一个控件被触发后，将该控件进行标识，当发现位于栈顶的控件已被触发时，将其移走，从新的栈顶开始触发对应的控件。

5.根据权利要求1或2所述的方法，其特征在于，所述目标移动终端为多个，所述将在目标移动终端上截取到的图片返回到客户端包括：

将在目标移动终端上截取到的图片进行汇总后，返回到客户端。

6.根据权利要求5所述的方法，其特征在于，所述在将目标移动终端上截取到的图片进行汇总后，返回到客户端包括：保存目标移动终端与截取到的图片之间对应关系，以及同一目标移动终端上各个图片的截取顺序，并返回给客户端，以便客户端以目标移动终端为单位对截取到的图片进行展现。

7.根据权利要求5所述的方法，其特征在于，所述在将目标移动终端上截取到的图片进行汇总后，返回到客户端包括：

保存被触发控件与截取到的图片之间的对应关系，并返回给客户端，以便客户端展现出同一被触发控件在各个目标移动终端上截取到的图片。

8.根据权利要求1或2所述的方法，当所述目标移动终端装载Android操作系统时，所述将所述安装包发送到所述目标移动终端，并指示所述目标移动终端安装所述应用软件包括：

将所述安装包分发到所述目标移动终端所在服务器，由所述服务器通过调用Android调试桥ADB命令，指示所述目标移动终端通过所述安装包安装所述应用软件；

所述指示所述目标移动终端启动所述应用软件，得到显示界面包括：

通过Instrumentation指示所述目标移动终端启动所述应用软件，得到显示界面；

所述获取显示界面中包含的控件的相关信息包括：

通过getActivity()方法，获得当前执行的Activity信息，通过映射捕获相应Act ivity中各个view的相关信息，判断各个view是否可触发，将可触发的view确定为当前显示界面中包含的控件。

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

接收客户端提交的对所述待测试应用软件中包含的控件进行选择的信息；其中，客户端在获取到所述待测试应用软件中包含的所有控件的情况之后，展现所述应用软件中包含的所有控件的信息，并提供选择操作入口，当通过所述选择操作入口确定到被选中的控件；

根据客户端提交的选择信息，在各个目标移动终端上触发各个被选中的控件，并对得到的显示界面进行截图后，返回给客户端。

10.一种移动终端上的应用软件测试方法，其特征在于，包括：

将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。

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

接收所述服务器端返回的各个目标移动终端与截取到的图片之间的对应关系信息，以及同一目标移动终端上各个图片的截取顺序信息；

所述根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果包括：

以目标移动终端为单位对截取到的图片进行展现，其中，对于同一目标移动终端，按照截取的先后顺序对各个图片进行展现，以便展现出在同一目标移动终端中的测试流程各个环节上的各个显示界面。

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

接收所述服务器端返回的各个被触发控件与截取到的图片之间的对应关系信息；

所述根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果包括：

展现出同一被触发控件在各个目标移动终端上截取到的图片，以便在各个目标移动终端之间进行对比。

13.根据权利要求10至12任一项所述的方法，其特征在于，还包括：

展现所述应用软件中包含的所有控件的信息，并分别为各个控件提供选择操作入口；

通过所述选择操作入口确定被选中的控件，将所述被选中的控件的信息上传到服务器端，以便所述服务器端根据提交的选择信息，在各个目标移动终端上遍历触发各个被选中的控件，并对得到的显示界面进行截图并返回；

根据服务器端针对被选中的控件返回的截图信息，展现测试结果。

14.一种移动终端上的应用软件测试系统，其特征在于，包括：

接收单元，用于接收客户端上传的待测试应用软件的安装包，以及待测试的目标移动终端的标识；

安装单元，用于将所述安装包发送到所述目标移动终端，并指示所述目标移动终端通过所述安装包安装所述应用软件；

控件触发单元，用于指示所述目标移动终端启动所述应用软件，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

返回单元，用于将目标移动终端上截取到的图片返回到客户端。

15.一种移动终端上的应用软件测试装置，其特征在于，包括：

上传单元，用于将指定的待测试应用软件的安装包，以及待测试的目标移动终端的标识上传到服务器端；

图片信息接收单元，用于接收所述服务器端返回的在各个目标移动终端上截取的图片信息，所述图片信息通过以下方式获得：所述服务器端将所述安装包发送到所述目标移动终端，指示所述目标移动终端通过安装包安装所述应用软件，并在启动所述应用软件后，遍历触发所述应用软件中的各个控件，每次触发控件得到显示界面时，对显示界面进行截图；

图片信息展现单元，用于根据所接收到的图片信息，展现所述待测试应用软件在各个目标移动终端上的测试结果。