一种用于应用程序的测试方法、电子设备及系统的制作方法_2

文档序号:9787309阅读:来源:国知局
情况数据。
[0081] 优选地,所述监测单元,具体用于:
[0082] 在对所述N个控件进行遍历操作过程中,实时对所述待测试应用程序是否出现应 用程序无响应ANR进行监测,获得所述N个控件控件中每个控件对应的ANR数据。
[0083] 优选地,所述电子设备,还包括:
[0084] 第一接收单元,用于所述将所述N个控件中每个控件对应的监测数据发送给第二 电子设备之后,接收所述第二电子设备发送的所述P个异常控件中每个异常控件的回放路 径;其中,所述回放路径用于在所述UI上再次找到所述P个异常控件中每个异常控件;
[0085] 回放单元,用于基于所述P个异常控件中每个异常控件的回放路径,再次对所述P 个异常控件进行操作。
[0086] 基于同一发明构思,本发明的第四方面,提供了一种电子设备(即:第二电子设 备),包括:
[0087] 第二接收单元,用于接收第一电子设备发送的N个控件中每个控件对应的监测数 据,其中,所述N个控件为待测试应用程序的用户界面UI上的全部可操作控件,N为正整数; [0088]第三确定单元,用于基于所述N个控件中每个控件对应的监测数据,从所述N个控 件中确定出P个异常控件,P为小于等于N的正整数。
[0089]优选地,所述第三确定单元,具体用于:
[0090] 基于所述N个控件中每个控件对应的CPU占用率数据,判断所述N个控件中每个控 件对应的CPU占用率是否大于第一预设值;将所述N个控件中对应的CPU占用率大于所述第 一预设值的控件确定为所述异常控件。
[0091] 优选地,所述第三确定单元,具体用于:
[0092 ]基于所述N个控件中每个控件对应的内存占用率数据,判断所述N个控件中每个控 件对应的内存占用率是否大于第二预设值;将所述N个控件中对应的内存占用率大于所述 第二预设值的控件确定为所述异常控件。
[0093]优选地,所述第三确定单元,具体用于:
[0094]基于所述N个控件中每个控件对应的耗电情况数据,判断所述N个控件中每个控件 对应的耗电速率是否大于第三预设值;将所述N个控件中对应的耗电速率大于所述第三预 设值的控件确定为所述异常控件。
[0095]优选地,所述第三确定单元,具体用于:
[0096] 基于所述N个控件控件中每个控件对应的应用程序无响应ANR数据,将所述N个控 件中导致所述待测应用程序出现ANR的控件作为所述异常控件。
[0097]优选地,所述第三确定单元,具体用于:
[0098]基于所述N个控件中每个控件对应的崩溃情况数据,将所述N个控件中导致所述待 测应用程序崩溃的控件作为所述异常控件。
[0099] 优选地,所述电子设备,还包括:
[0100] 第四确定单元,用于所述基于所述N个控件中每个控件对应的监测数据,从所述N 个控件中确定出P个异常控件之后,确定所述P个异常控件中每个异常控件的回放路径;其 中,所述回放路径用于在所述UI上再次找到所述P个异常控件中每个异常控件。
[0101] 优选地,所述第四确定单元,具体用于:
[0102] 获取所述P个异常控件中每个异常控件的全部操作路径;从所述每个异常控件的 全部操作路径中,选择出路径最短的操作路径作为所述每个异常控件的回放路径。
[0103] 优选地,所述电子设备,还包括:
[0104] 第二发送单元,用于所述确定所述P个异常控件中每个异常控件的回放路径之后, 将所述P个异常控件中每个异常控件的回放路径发送给所述第一电子设备,以使所述第一 电子设备基于所述P个异常控件中每个异常控件的回放路径,再次对所述P个异常控件进行 操作。
[0105] 基于同一发明构思,本发明的第五方面,提供了一种用于应用程序的测试系统,包 括:
[0106] 第一电子设备;以及
[0107] 第二电子设备。
[0108] 本申请实施例中提供的一个或多个技术方案,至少具有如下技术效果或优点:
[0109] 根据本发明的一种用于应用程序的测试方法、电子设备及系统,对待测试应用程 序的UI上的N个控件进行遍历操作;其中,N个控件为UI上的全部可操作控件,N为正整数,在 对N个控件进行遍历操作过程中,实时对待测试应用程序的性能和/或稳定性进行监测,获 得N个控件中每个控件对应的监测数据,将N个控件中每个控件对应的监测数据发送给第二 电子设备,以使第二电子设备基于N个控件中每个控件对应的监测数据,从N个控件中确定 出P个异常控件,P为小于等于N的正整数。由于通过对待测试应用程序的UI上的全部可操作 控件进行遍历操作,来模拟待测试应用程序实际的运行情况,并在遍历过程中实时监测待 测试的性能和/或稳定性,从而确定出异常的控件,所以能够最大程度上发现产品发布后在 用户机器上出现的问题,大大提升了问题发现的科学性,避免了因为测试涉及局限性带来 的测试不合理,同时,不用针对场景进行脚本转换,所以大大减小了自动化过程中编码代 价,大大提高了测试效率。
[0110]上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段, 而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够 更明显易懂,以下特举本发明的【具体实施方式】。
【附图说明】
[0111] 通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通 技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明 的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
[0112] 图1示出了根据本发明一个实施例的用于应用程序的测试系统的架构图;
[0113] 图2示出了根据本发明一个实施例(从第一电子设备和第二电子设备的交互侧)的 用于应用程序的测试方法的流程图;
[0114] 图3示出了根据本发明一个实施例(从第一电子设备侧)的一种用于应用程序的测 试方法的流程图;
[0115] 图4示出了根据本发明一个实施例(从第二电子设备侧)的一种用于应用程序的测 试方法的流程图;
[0116] 图5示出了根据本发明一个实施例的一种电子设备(即:第一电子设备)的结构图。
[0117] 图6示出了根据本发明一个实施例的一种电子设备(即:第二电子设备)的结构图。
【具体实施方式】
[0118] 本发明实施例提供了一种用于应用程序的测试方法、电子设备及系统,用以解决 现有技术中的软件测试方法,测试人员需要针对不同的场景进行自动化脚本转换,存在编 码代价较大,且设计出来的场景并不能最大程度上发现产品发布后在用户机器上出现的问 题等技术问题。
[0119] 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开 的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例 所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围 完整的传达给本领域的技术人员。
[0120] 首先,本文中出现的术语"和/或",仅仅是一种描述关联对象的关联关系,表示可 以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情 况。另外,本文中字符7",一般表示前后关联对象是一种"或"的关系。
[0121]其次,在正式介绍本实施例中的用于应用程序的测试方法之前,先对用于实现该 测试方法的测试系统的进行介绍。如图1所示,该用于应用程序的测试系统主要由第一电子 设备和第二电子设备组成。其中,所述第一电子设备可以是移动终端,例如,智能手机、或平 板电脑、或车载电脑等智能终端;所述第二电子设备可以是PC) (Personal Computer,个人 电脑)。且,所述移动终端内安装有一0S(0perating System,操作系统),例如:I0S系统、 Andorid系统、Windows 8系统、或Windows 10系统,等等,此处不做具体限定。在第二电子设 备侧安装有一测试脚本,在第一电子设备侧安装有一测试APP(Applicati 〇n,应用程序),本 实施例提供的用于应用程序的测试方法,即主要由第二电子设备侧的测试脚本和第一电子 设备侧的测试APP完成。
[0122] 实施例一
[0123] 从第一电子设备和第二电子设备的交互侧考虑,本实施例提供了一种用于应用程 序的测试方法,如图2所示,包括:
[0124] 步骤S101:第一电子设备对待测试应用程序的UI(User Interface,用户界面)上 的N个控件进行遍历操作;其中,N个控件为UI上的全部可操作控件,N为正整数。
[0125] 在具体实施过程中,在步骤SlOl之前,还包括:在第一电子设备的系统上安装待测 试应用程序。
[0126] 具体来讲,第一电子设备可以通过数据线与第二电子设备连接,第二电子设备侧 的测试脚本可以获得测试人员提供的待测试应用程序的安装包,并基于该安装包将待测试 应用程序安装到第一电子设备中。具体的安装过程有以下两种方式:
[0127] 第一种,第二电子设备侧测试脚本可以将待测试应用程序的安装包解压,并将解 压后的安装数据通过数据线发送给第一电子设备;第一电子设备侧测试APP接收到该安装 数据后,基于安装数据将待测试应用程序安装在第一电子设备的系统上。
[0128] 第二种,第二电子设备侧测试脚本可以将待测试应用程序的安装包通过数据线直 接发送给第一电子设备侧测试APP;第一电子设备侧测试APP接收到该安装包后,运行该安 装包,以将待测试应用程序安装在第一电子设备的系统上。
[0129] 在具体实施过程中,该待测试应用程序可以是:游戏类APP、视频类APP、音乐类 APP、购物类APP、安全类APP、拍照类APP、炒股类APP、社交类APP、团购类APP、点餐类APP、支 付类APP,浏览器类APP等等,对于所述待测试APP具体是何种APP,本实施例不做具体限定。 [0130]在具体实施过程中,该待测试应用程序包含一UI界面,在这个UI界面上设置有多 个控件(例如:命令按钮控件、文本框控件等等),一般这些控件会分层级显示,每个控件可 以触发不同的功能。以手机浏览器为例,在手机浏览器的UI界面上,一般设置有"前进"按 钮、"后退"按钮、"菜单"按钮、"Home"按钮,等等;在点击"菜单"按钮后,会弹出一菜单,其中 设置有"收藏夹"按钮、"历史"按钮、"设置"按钮、"下载"按钮、"退出"按钮,"截图"按钮,等 等;在点击"设置"按钮后,又会弹出一菜单,其中设置有"登录"按钮、"消息推送设置"按钮、 "检查更新"按钮,等等。这些控件一般采用树状结构分布,当然,也可以采用网状结构分布。 对于采用树状结构分布的控件,每个控件仅有一条操作路径;对于采用网状结构分布的控 件,每个控件可能具有多条操作路径。
[0131] 本实施例就是模拟用户对待测试APP的实际使用情景,通过对待测试应用程序中 的UI界面上的N个控件进行遍历操作,来确定异常控件,从而确定存在问题的区域。其中,所 述N个控件为待测试应用程序中的UI界面上的全部可操作控件。
[0132] 在具体实施过程中,由于在待测试应用程序的UI上存在很多的控件,但其中包括 一些不可操作的控件(例如:标签控件、图片控件等),而在步骤SlOl中,需要模拟用户对待 测试应用程序的实际使用场景,对UI界面上的可操作控件(例如:命令按钮控件、文本框控 件等)进行遍历操作,所以在步骤SlOl之前,应该先从待测试应用程序的UI上的全部控件中 确定出N个控件(即:可操作控件)。
[0133] 具体来讲,可以利用Hierarchy Viewer(层级观察器)获取待测试应用程序UI上的 全部控件中每个控件的属性信息,再基于全部控件中每个控件的属性信息,确定全部控件 中每个控件的类型(例如:是标签控件,还是图片控件、还是命令按钮控件,还是文本框控 件),再基于全部控件中每个控件的类型,从全部控件中确定出属于预设类型(例如:命令按 钮控件、或文本框控件)的控件为所述N个控件。
[0134] 在具体实施过程中,为了清楚的区分所述N个控件中的每个控件,在步骤SlOl之 前,还包括:生成用于表示N个控件中每个控件的标识信息,即,全局唯一Trace ID(跟踪标 识)。具体来讲,可以基于遍历操作的顺序,依次对所述N个控件进行编号(例如:Con_l、Con_ 2、Con_3、Con_4......Con_N),来对所述N个控件中的每个控件进行区分。
[0135] 在具体实施过程中,由于每种类型的控件的操作方式不同,所以在步骤SlOl之前, 还包括:基于N个控件中每个控件的类型,确定N个控件中每个控件的操作方式。例如:对于 命令按钮控件,确定其操作方式是点击;对
当前第2页1 2 3 4 5 6 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1