CN113918447B - 一种应用测试方法及电子设备 - Google Patents

Abstract

本申请提供一种应用测试方法及电子设备，涉及终端技术领域，可以发现待测应用的更多软件编码问题，有利于提升应用的软件代码质量。具体方案包括：向第一应用的第一活动activity发送第一测试意图；其中，第一测试意图包括第一测试数据，第一测试数据为根据第一待操作数据的数据名称及数据类型构建的，第一待操作数据为第一activity在运行过程中所涉及到的数据；显示第一activity对应的第一界面；其中，第一界面包括多个控件；向多个控件中的第一控件发送模拟操作；基于第一测试数据进行业务处理；监测第一应用在业务处理过程中的运行情况，并根据运行情况得到测试结果。

Description

一种应用测试方法及电子设备

技术领域

本申请涉及终端技术领域，尤其涉及一种应用测试方法及电子设备。

背景技术

随着移动互联网高速发展，移动应用已经渗入到了民众生活的方方面面。例如，在阅读、出行、学习、资讯、生活等领域，都有数量庞大的移动应用，为用户提供各种丰富多彩的服务。而这些移动应用的稳定性、安全性则成为影响用户体验、保护用户隐私的重要因素。

目前，为了给用户提供良好的用户体验，在应用正式上线前，应用厂商对应用进行大量稳定性、安全性的测试。例如，可以利用Fuzz测试方式测试应用的安全性，利用Monkey测试方法测试应用的稳定性。但这些方法可以测出的问题有限，导致测试后的应用仍然存在较多漏洞(bug)，容易出现进程崩溃、无响应或是响应慢等问题，影响用户体验。

发明内容

本申请提供一种应用测试方法及电子设备，以提高检测出应用程序中存在的漏洞的概率。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种应用测试方法，应用于电子设备，电子设备上安装有第一应用，方法包括：向第一应用的第一活动activity发送第一测试意图；其中，第一测试意图包括第一测试数据，第一测试数据为根据第一待操作数据的数据名称及数据类型构建的，第一待操作数据为第一activity在运行过程中所涉及到的数据；显示第一activity对应的第一界面；其中，第一界面包括多个控件；向多个控件中的第一控件发送模拟操作；基于第一测试数据进行业务处理；监测第一应用在业务处理过程中的运行情况，并根据运行情况得到测试结果。

由于本申请可以在向第一activity发送携带有测试数据的第一测试意图后，才对第一控件发送模拟操作，达到对第一activity同时进行安全性测试(Fuzz测试)及稳定性测试(Monkey测试)的效果。如此，可以测试出常规的Fuzz测试和Monkey测试无法检测出的问题，使得测试场景更加广泛，可以发现待测应用(例如，第一应用)的更多软件编码问题，有利于提升应用的软件代码质量。

在一种可选的实施方式中，方法还包括：向多个控件中的第二控件发送模拟操作；显示第二界面。电子设备向控件(例如，第二控件)发送模拟操作后，可以不用根据测试数据进行业务处理，而是直接显示第二界面。这种情况下，便是单纯地对第二控件进行了Monkey测试。可见，本申请提供的应用测试方法可适用于不同的测试场景，可容易检测出第一应用的软件编码问题。

在一种可选的实施方式中，在显示第二界面之后，方法还包括：重新显示第一界面。在未对第一界面上的所有控件完成测试前，若电子设备显示第二界面，可以重新跳转回第一界面，继续对第一界面上的控件进行测试。

在一种可选的实施方式中，向多个控件中的第一控件发送模拟操作后，方法还包括：提取第一activity在运行过程中涉及到的数据信息；其中，数据信息包括第一待操作数据的数据名称及对应的数据类型；根据数据信息生成数据模型；其中，数据模型包括第一activity的标识与数据信息的对应关系。

也即，电子设备可以在第一activity运行期间利用hook提取出涉及到的数据信息(例如，提取出数据名称为bookname，数据类型为list)，生成数据模型。还需要说明的是，若电子设备还采集到其他组件(例如，第一组件)的数据信息，还可以基于该数据信息更新数据模型。也即，数据模型实际上包括各个组件的标识与数据信息的对应关系。

在一种可选的实施方式中，方法还包括：根据第一activity的标识从数据模型提取出第一待操作数据的数据名称及数据类型；根据第一待操作数据的数据名称及数据类型构建第一测试数据。可以理解地，通过从数据模型中找到第一activity运行时会处理的数据名称及其数据类型，达到快速构造测试数据的效果。

在一种可选的实施方式中，第一测试意图包括第一activity的名称、第一activity所需执行的动作、第一activity的类别及第一activity所需处理的数据中的任意一种。也即，电子设备可以根据第一测试意图中携带的名称、动作、类别或是待处理数据(所需处理的数据)查找到第一activity。

在一种可选的实施方式中，方法还包括：向第一应用的第一组件发送第二测试意图；其中，第二测试意图包括第二测试数据，第二测试数据为根据第二待操作数据的数据名称及数据类型构建的，第一组件为服务service、内容提供者及广播接收器中的任意一种，第二待操作数据为第一组件运行过程中所涉及到的数据；基于第二测试数据进行业务处理。也即，本申请还可以对service、内容提供者及广播接收器进行Fuzz测试。

在一种可选的实施方式中，模拟操作包括模拟用户点击、拖拽、长按、滑动第一控件的操作。可见，模拟操作多种多样，可以模拟用户的实际操作。此外，模拟操作还可以不仅限于点击、拖拽、长按、滑动等操作，还可以为用户可能进行的任何操作。

第二方面，本申请提供了一种电子设备，电子设备包括：无线通信模块、存储器和一个或多个处理器；无线通信模块、存储器与处理器耦合；其中，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令；当计算机指令被处理器执行时，使得电子设备执行如第一方面中任一项的应用测试方法。

第三方面，本申请提供了一种计算机可读存储介质，包括计算机指令；当计算机指令在电子设备上运行时，使得电子设备执行如第一方面中任一项的应用测试方法。

第四方面，本申请提供了一种芯片系统，该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。该芯片系统可以应用于包括通信模块和存储器的电子设备。该接口电路可以读取电子设备中存储器中存储的指令，并将该指令发送给处理器。当指令被处理器执行时，可使得电子设备执行如第一方面中任一项的方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如第一方面中任一项的应用测试方法。

可以理解地，上述提供的第二方面的电子设备、第三方面的计算机存储介质、第四方面的芯片系统，以及第五方面的计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

附图说明

图1为电子设备200的一种界面图；

图2为电子设备200的一种界面图；

图3A为电子设备200的界面图切换图；

图3B为电子设备200进行测试的界面图；

图4为电子设备200的硬件结构框图；

图5为电子设备200的软件架构图；

图6为本申请实施例提供的应用测试方法的流程图；

图7为测试过程中的界面图切换图；

图8为测试过程中的界面图切换图；

图9为芯片系统的结构示意图。

具体实施方式

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

下面将结合附图对本实施例的实施方式进行详细描述。

随着移动互联网的高速发展，移动应用的种类和数量越来越多。为了保证用户体验，应用厂商会先对应用进行大量稳定性测试及安全性测试。目前，终端设备的电子设备200主要包括安卓(Android)及IOS。对于运行于安卓系统上的应用，可以利用Fuzz测试方式测试其安全性，利用Monkey测试方法测试其稳定性。

其中，Monkey测试是一种测试应用的稳定性、健壮性的方法。Monkey是Android系统中的一个命令行工具，可以运行在模拟器里或实际设备(例如，手机)中。它可以向Android系统发送伪随机的用户事件流以模拟用户的各种使用场景(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。

Fuzz测试是一种测试应用的安全性的方法。应用在运行期间，会暴露接口组件给其他第三方应用调用，接收其他第三方应用传来的数据并进行业务逻辑处理。进行Fuzz测试时，便可以构造不规则数据并将不规则数据传输至接口组件内，测试应用程序的软件编码问题。

接下来，以钱包应用为例，说明现有技术中对钱包应用进行Monkey测试及Fuzz测试的过程。

请参阅图1，手机可以显示钱包应用的界面101。界面101上可以包括多个控件，例如扫一扫102、收支明细、信用卡、生活特惠103等控件。按照控件的属性分类，多个控件可以包括可操作控件及不可操作控件。其中，可操作控件为可以与用户交互(例如被用户点击、拖拽、滑动)的控件。例如，界面101上的扫一扫102、收支明细、信用卡、借钱等均为可操作控件。用户通过与可操作控件交互，可以开启一个预设功能。示例性的，手机可以接收用户点击扫一扫控件102的操作，响应于该操作，手机可以显示如图2所示的扫一扫界面104，以开启扫描二维码、扫描条码的功能。不可操作控件为无法与用户进行交互的控件。不可操作控件通常用于向用户提示相关信息。例如，界面101中的生活特惠控件103即为一个不可操作控件。

在对钱包应用进行Monkey测试时，可以向钱包应用每个界面上的每个控件发送伪随机的用户事件。例如，手机可以先对界面101上的控件进行测试。测试过程中，手机可以先获取界面101的控件信息。控件信息可以包括多个控件中每个控件的坐标及属性等。其中，控件的坐标用于指示控件在界面101中的位置，控件的属性用于指示控件为可操作控件或不可操作控件。例如，控件的属性为clickable，则表明其为可操作控件；控件的属性为unclickable，则表明其为不可操作控件。接着，手机可以向多个控件中的每个控件分别发送模拟操作(即模拟用户对待测试控件进行点击、拖拽、滑动等操作)，并检查是否存在进程崩溃、无响应、响应慢、显示应用程序无响应(application not responding，ANR)对话框等情况，以得到测试结果。需要说明的是，在对界面101上的所有控件进行过测试以后，手机可以继续对钱包应用其他界面(例如扫一扫界面104)上的控件进行测试，直至对钱包应用包括的所有界面进行过测试。

在一种可能的设计中，多个控件间可以具备排列顺序。手机向多个控件中的每个控件分别发送模拟操作时，可以按照排列顺序的正序依次向多个控件中的每个控件发送模拟操作，或者可以按照排列顺序的倒序依次向多个控件中的每个控件发送模拟操作，又或者可以按照随机顺序向多个控件中的每个控件发送模拟操作。示例性的，界面101中多个控件的排列顺序可以为：扫一扫、收支明细、转账、账户总览、信用卡、他行卡转入等。测试时，手机可以依次向扫一扫、收支明细、转账、账户总览、信用卡、他行卡转入等控件发送模拟操作，直至向界面101上的所有控件发送过模拟操作后，才完成对界面101的测试，可以继续对其他界面进行测试。

在一种可选的设计中，在测试时，手机也可以不选择控件进行点击，而是可以模拟用户对界面101中的任意坐标进行点击操作。

在一种可选的设计中，手机可以只对可操作控件进行测试。

钱包应用可以开放接口组件给第三方应用，接收第三方应用传输的数据，并进行业务逻辑处理。而这种开放给第三方应用的接口组件容易成为攻击对象，存在安全风险。例如，钱包应用进入如图2所示的扫一扫界面104时，可以开放接口组件给照相机，以接收照相机扫描的二维码。钱包应用接收到二维码后，根据二维码携带的信息(例如，商家名称、支付金额等)显示支付界面等。这种情况下，恶意软件可以通过该接口组件传输恶意数据至钱包应用，若钱包应用未对接收到的数据进行校验或者校验过程不规范，容易造成钱包应用崩溃，存在一定安全风险。因此，为了保证应用的安全性，手机可以对应用的接口进行Fuzz测试。

进行Fuzz测试时，手机可以获取钱包应用的组件信息，并向钱包应用的组件注入恶意数据，以测试钱包应用是否会出现崩溃、无响应等问题。但钱包应用的使用场景多种多样，单纯地靠Fuzz测试无法测试出一些场景中存在的问题。示例性的，在用户使用钱包应用给购物应用上的产品进行支付的场景中，如图3A中的(a)所示，手机可以显示购物应用的界面301，界面301中包括订购者的地址、联系方式、购物内容、优惠情况、消费金额等信息。此外，界面301还包括提交订单控件302，手机可以接收用户点击提交订单控件302的操作，响应于该操作，如图3A中的(b)所示，手机可以跳转至钱包应用的支付界面303。支付界面303上可以包括待支付金额(例如11.5元)及立即支付控件304。手机可以接收用户点击立即支付控件304的操作，响应于该操作，钱包应用根据待支付金额进行支付操作。

可以理解地，在上述场景中，若购物应用向钱包应用发送的数据不规范(例如，支付金额为12.399999元)，且钱包应用未成功校验出该数据存在不规范的问题，就容易导致钱包应用出现异常。

在现有技术中，若需对钱包应用进行Monkey测试，手机可以直接启动支付界面303对应的activity，并显示如图3B所示的界面305。界面305可以包括支付控件306。由于activity未接收到任何数据，界面305中的相关数据(例如，支付金额)均为空。在这种情况下，若手机对支付控件306发送模拟操作，虽然可以触发支付控件306所关联的程序代码，但由于不存在任何数据，并不能完整运行该支付控件306所关联的程序代码，达不到测试目的。

若需对钱包应用进行Fuzz测试，则手机可以向该界面305对应的activity发送测试数据。但由于手机未接收到用户对支付控件306发起的操作，手机则并不会根据测试数据进行业务处理，从而也达不到测试目的。

可见，若需要检测出钱包应用在上述应用场景中的异常情况，需要满足两个条件：(1)钱包应用接收到第三方应用(例如，购物应用)传输的数据(例如，待支付金额)；(2)接收到用户对相关控件(例如，立即支付控件304)的点击(滑动、长按、拖拽)操作。也即，若仅向钱包应用传输测试数据(即进行Fuzz测试)，而不点击支付控件304，钱包应用则无法进一步执行支付操作，无法测试出钱包应用是否存在异常。若仅点击支付控件304(即仅进行Monkey测试)，钱包应用可以按照正常逻辑执行支付操作，也无法测试出钱包应用是否存在异常。换句话说，对钱包应用单独进行Monkey测试或者单独进行Fuzz测试，均不能测试出钱包应用存在的问题。

又例如，应用程序的软件代码可以包括：

在上述代码中，若需要导致应用程序在代码“String bookB＝booknames[1]”处造成进程崩溃，需要满足两个条件：(1)该应用从外部获取了类型为字符串(String)、名称为bookList、且字符串内容包括‘/’的数据；(2)接收到用户点击按钮buttonTest的操作。可见，单纯使用Fuzz测试方法，或者Monkey测试方法，均无法造成进程崩溃，从而无法检测出编码漏洞。

有鉴于此，本申请提供了一种应用测试方法，可以在稳定性测试方法和安全测试方法的基础上，将两者结合，从而发现待测应用的更多软件编码问题，提升待测应用的软件代码质量。

本申请实施例提供的应用测试方法可以应用于电子设备。示例性的，本申请实施例中的电子设备例如可以为手机、平板电脑、台式机(桌面型电脑)、手持计算机、笔记本电脑(膝上型电脑)、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备等，本申请实施例对电子设备的具体形态不作特殊限制。

请参阅图4，其示出本申请实施例提供的一种电子设备200的结构示意图。电子设备200可以包括：处理器210，外部存储器接口220，内部存储器221，通用串行总线(universal serial bus，USB)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294，以及SIM卡接口295等。

其中，上述传感器模块280可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。

可以理解的是，本实施例示意的结构并不构成对电子设备200的具体限定。在另一些实施例中，电子设备200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备200的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器210中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备200的结构限定。在另一些实施例中，电子设备200也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块240用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块240为电池242充电的同时，还可以通过电源管理模块241为移动终端供电。

电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，外部存储器，显示屏294，摄像头293，和无线通信模块260等供电。在一些实施例中，电源管理模块241和充电管理模块240也可以设置于同一个器件中。

电子设备200的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。在一些实施例中，电子设备200的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得电子设备200可以通过无线通信技术与网络以及其他设备通信。

天线1和天线2用于发射和接收电磁波信号。电子设备200中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块250可以提供应用在电子设备200上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。

移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的至少部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的至少部分功能模块可以与处理器210的至少部分模块被设置在同一个器件中。

无线通信模块260可以提供应用在电子设备200上的包括WLAN(如(wirelessfidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigationsatellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(nearfield communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

电子设备200通过GPU，显示屏294，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏294和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器210可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏294用于显示图像，视频等。该显示屏294包括显示面板。

电子设备200可以通过ISP，摄像头293，视频编解码器，GPU，显示屏294以及应用处理器等实现拍摄功能。ISP用于处理摄像头293反馈的数据。摄像头293用于捕获静态图像或视频。在一些实施例中，电子设备200可以包括1个或N个摄像头293，N为大于1的正整数。

外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备200的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行电子设备200的各种功能应用以及数据处理。例如，在本申请实施例中，处理器210可以通过执行存储在内部存储器221中的指令，内部存储器221可以包括存储程序区和存储数据区。

其中，存储程序区可存储电子设备200，至少一个功能所需的应用程序(比如拨打电话功能，声音播放功能，图像播放功能等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

电子设备200可以通过音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

按键290包括开机键，音量键等。按键290可以是机械按键。也可以是触摸式按键。马达291可以产生振动提示。马达291可以用于来电振动提示，也可以用于触摸振动反馈。指示器292可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口295用于连接SIM卡。SIM卡可以通过插入SIM卡接口295，或从SIM卡接口295拔出，实现和电子设备200的接触和分离。电子设备200可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口295可以支持Nano SIM卡，Micro SIM卡，SIM卡等。

上述电子设备200的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明电子设备200的软件结构。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，Android runtime和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图5所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图5所示，应用程序框架层可以包括活动管理器、窗口管理器，内容提供器，视图系统，资源管理器，通知管理器等，本申请实施例对此不做任何限制。

活动管理器(Activity Manager)：用于管理每个应用的生命周期。应用通常以activity的形式运行在电子设备200中。对于每一个activity，在活动管理器中都会有一个与之对应的应用记录(Activity Record)，这个Activity Record记录了该应用的activity的状态。活动管理器可以利用这个Activity Record作为标识，调度应用的activity进程。

窗口管理器(Window Manager Service)：用于管理在屏幕上使用的图形用户界面(graphical user interface，GUI)资源，具体可用于：获取显示屏大小、窗口的创建和销毁、窗口的显示与隐藏、窗口的布局、焦点的管理以及输入法和壁纸管理等。

应用程序框架层以下的系统库和内核层等可称为底层系统，底层系统中包括用于提供显示服务的底层显示系统，例如，底层显示系统包括内核层中的显示驱动以及系统库中的surface manager等。并且，本申请中的底层系统还包括用于识别柔性屏幕物理形态变化的识别模块，该识别模块可独立设置在底层显示系统内，也可设置在系统库和/或内核层。

如图5所示，安卓运行时(Android Runtime)包括核心库和虚拟机。Androidruntime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

如图5所示，系统库可以包括多个功能模块。例如：表面管理器(surfacemanager)，媒体库(Media Libraries)，OpenGL ES，SGL等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

OpenGL ES用于实现三维图形绘图，图像渲染，合成，和图层处理等。

SGL是2D绘图的绘图引擎。

如图5所示，内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

本申请实施例提供一种应用测试方法。该应用测试方法可以应用于电子设备200对待测应用进行安全性测试及稳定性测试的过程。如图6所示，该应用测试方法包括：电子设备200确定待测应用的组件信息，其中，组件信息用于指示待测应用包括多个组件；然后向多个组件中的目标组件注入测试Intent；接着显示目标组件对应的第一界面，并获取第一界面的控件信息；最后向多个控件中的目标控件发送模拟操作。从而，电子设备200可以监控待测应用是否存在异常，得到测试结果。

其中，待测应用即为待测试的应用，例如可以为钱包应用、视频应用、图库应用、邮件应用等任意一种安卓应用程序(Application，App)。多个组件可以包括：活动(activity)、服务(service)、内容提供者(Content Provider)及广播接收器(BroadcastReceiver)。

其中，activity用于描述用户界面(user interface，UI)，并可以处理用户与电子设备200屏幕的交互。例如，activity可以描述用户界面上包括的各种Android控件，例如文本框(TextView)，按键(button)等。此外，一个应用可以具备多个activity，每个activity可以标识一个具有用户界面的单一屏幕。示例性的，钱包应用可以包括一个用于显示界面101的activity以及一个用于显示扫一扫界面104的activity。

service用于处理与应用程序关联的后台操作。例如，service可以为用户在使用不同应用时在后台播放音乐。又例如，service可以在用户通过UI与电子设备200正常交互时，通过网络获取数据。

Content Provider用于处理数据和数据库管理方面的问题。具体的，ContentProvider可以请求一个应用为另一个应用提供数据。例如，用户把陌生号码添加至通讯录后，若用户想发送短信，可以直接在短信应用内查找联系人信息。用户在短信应用内查找联系人信息时，短信应用的Content Provider可以向通讯录发送获取联系人信息的请求，以便于用户在短信应用内直接选择联系人。

Broadcast Receiver用于处理Android电子设备200和应用程序间的通信。具体的，Broadcast Receiver可以响应从系统或其他应用程序接收到的广播消息。示例性的，电子设备200连接到WIFI后，可以向其他应用程序发送广播消息，该广播消息用于指示电子设备200已经连接到WIFI。其他应用程序的Broadcast Receiver可以接收广播消息，响应于接收到该广播消息，可以执行预设操作。例如，钱包应用的Broadcast Receiver在接收到广播消息后，可以通知钱包应用的用于执行更新业务的service在后台下载应用更新包。

示例性的，组件信息可以包括组件静态信息及组件动态信息。组件静态信息可以包括多个组件中每个组件的名称、类别、所需执行的动作及所需处理的数据。组件动态信息可以包括组件的状态及完整路径等等。其中，组件的状态用于指示组件是否被其他应用(或组件)调用。

电子设备200可以调用动态接口，以获取组件动态信息。电子设备200可以解析待测应用的静态文件(AndroidManifest.xml文件)得到待测应用的基本信息，进而得到组件静态信息。其中，待测应用的基本信息可以包括应用权限、组件清单及过滤器声明(IntentFilter)。下面分别对应用权限、组件清单及Intent Filter进行说明。

1)应用权限用于声明待测应用访问受保护的API以及与其他应用交互所需具备的权限、应用定义的权限等。示例性的，待测应用可以为钱包应用。钱包应用只有在具备相机权限的情况下，才可以通过相关API接口调用相机进行扫描二维码的操作。此外，应用权限还可以声明其他应用与组件交互所需具备的权限。

2)组件清单可以描述待测应用包括的多个组件(包括activity、service、Broadcast Receiver和Content Provide)的名称。

3)Intent Filter可以说明各个组件被启动条件、各个组件的权限、组件antion(动作)、组件category(类别)及组件data(数据)等信息。其中，组件antion用于表征该组件支持的动作，例如ACTION_VIEW用于表征该组件可以显示信息，ACTION_DIAL用于表示该组件可以拨打电话。组件category用于表征该组件的类别，例如CATEGORY_LAUNCHER表示该组件为任务的初始activity，应该在操作系统的应用启动器中列出。组件data包括待操作数据(即组件需要处理的数据)的统一资源标志符(uniform resource identifier，URI)及数据类型。

可见，从待测应用的基本信息中提取出每个组件的名称、类别、所需执行的动作及所需处理的数据，从而得到组件静态信息。

从而，电子设备200合并待测应用的组件静态信息及待测应用的组件动态信息，即可得到待测应用的组件信息。组件信息可以包括多个组件中每个组件的名称、类型、过滤器声明(Intent Filter)、状态及完整路径等内容。

在电子设备200获取组件信息后，可以从多个组件中选择目标组件，并对目标组件进行测试。需要说明的是，多个组件中的任意一个组件都可以作为目标组件。为了测试的全面性，电子设备200可以将多个组件中的每个组件依次作为目标组件。在选择目标组件时，电子设备200可以按照多个组件的排列顺序的正序依次选择组件作为目标组件，或者可以多个组件的排列顺序的倒序依次选择组件作为目标组件，又或者可以利用随机数生成算法，随机从多个组件中选择组件作为目标组件。

在电子设备200选定目标组件后，可以根据目标组件的类型确定对目标组件的测试方法。具体的，若目标组件为activity(例如，第一activity)，则需要对目标组件进行安全性测试(Fuzz测试)及稳定性测试(Monkey测试)。若目标组件为service、ContentProvider或者Broadcast Receiver(例如，第一组件)，则对目标组件进行安全性测试(Fuzz测试)。可以理解地，Service、Content Provider或者Broadcast Receiver并不用于标识界面，因此在目标组件为Service、Content Provider或者Broadcast Receiver时，目标组件并不存在对应的第一界面，无法对目标组件进行Monkey(稳定性)测试。

为了对目标组件进行安全性测试(Fuzz测试)，电子设备200可以构建测试Intent，并将测试Intent注入目标组件以启动目标组件。其中，Intent是一种运行时绑定(run-timebinding)机制，它可以在程序运行过程中连接两个不同的组件，如实现不同应用程序之间、同一应用程序内部的不同组件之间的数据传递。例如，Intent可以实现两个activity之间的数据传递，可以实现activity与service间的数据传递。通过Intent，应用可以向电子设备200表达某种请求或者意愿(即向电子设备200发送Intent)，电子设备200可以根据Intent的内容选择适当的组件来完成请求。示例性的，有一个activity希望打开网页浏览器查看某一网页的内容，那么这个activity可以发出携带WEB_SEARCH_ACTION的Intent给电子设备200，电子设备200就可以根据Intent的请求内容，查询各组件注册时声明的Intent Filter，找到网页浏览器的activity来浏览网页。

Intent可以包括如表1所示的属性：

表1

其中，component用于定义要启动的组件(即目标组件)的名称。电子设备200可以通过读取Intent中的component查找到目标组件，并将Intent传递给目标组件。action用于指示目标组件需要执行的动作。示例性的，ACTION_VIEW用于指示目标组件所执行的动作为展示信息，ACTION_DIAL用于指示目标组件所执行的动作为拨打电话，ACTION_EDIT用于指示目标组件所执行的动作为编辑文件。category可以作为对处理该Intent的组件的补充信息，可用于表征目标组件的类型信息。示例性的，category可以为CATEGORY_BROWSABLE，其用于表示目标组件可以通过网络浏览器启动，以显示链接引用的数据，如图像或电子邮件。data可以包括待操作数据的统一资源标志符(uniform resource identifier，URI)及数据类型。其中，URI与数据类型均为可选的，也即是说，data可以仅包括待操作数据的URI，或者仅包括待操作数据的数据类型，或者同时包括待操作数据的URI及数据类型。data内容与action关联。例如，action为ACTION_VIEW时，data可以是一个网址或者图片的数据URI。flag用于指示Intent的运行模式。具体的，flag可以指示电子设备200如何启动组件，例如，指示目标组件应属于哪个任务，以及启动目标组件之后如何处理。extra为Intent携带的附加数据，可用于在组件之间传递信息。在一种可选的设计中，extra可以以key-value键值对的形式来存储附加数据。示例性的，key-value键值对可以如表2所示：

表2

名称(key)	数据类型(value)
		bookname	string
price	double
		num	int
booknames	list
		……	……

如表2所示，extra中可以定义bookname这一数据的数据类型为string。示例性的，bookname的值可以为老人与海。又例如，可以定义price的数据类型为double，其值可以为66.5。又例如，可以定义booknames的数据类型为list，示例性的，booknames的值可以为“老人与海|红楼梦”。

测试Intent即为可以对目标组件进行Fuzz测试的Intent，电子设备200可以根据目标组件的名称、action、category及data构建。

在一种可选的实施方式中，电子设备200可以根据目标组件的名称直接构建测试Intent。示例性的，电子设备200可以通过以下代码构建测试Intent：

Intent intent＝new Intent(this,TagerActivity.class)。在该段代码中，电子设备200可以直接将目标组件的名称(TagerActivity.class)作为测试Intent的component，从而构建出测试Intent。

在另一种可选的实施方式中，电子设备200可以根据目标组件的action、category、data等内容构建测试Intent。示例性的，电子设备200可以通过以下代码构建测试Intent：

Intent intent＝new Intent(Intent.ACTION_VIEW)；/设定action为展示内容

intent.setData(Uri.parse("http://www.baidu.com"))；//设置data的uri为一个网址

intent.addCategory(Intent.CATEGORY_LAUNCHER)；/目标组件为某个应用的首页面

intent.setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP)；//目标activity的启动方式为single top

intent.putExtra("extra_my","Tom")；//附加string数据

该测试Intent的内容指示，目标组件为某个应用的首页面，目标组件的启动方式为single top，目标组件需要执行的动作为ACTION_VIEW(展示内容)，目标组件所展示的内容为"http://www.baidu.com"这一页面的内容。此外，代码还说明可以向目标组件发送数据extra_my，数据extra_my的值为Tom，数据extra_my的类型为string。

可见，电子设备200构造测试Intent时，可以直接将目标组件的名称作为测试Intent的component，也可以将目标组件的action、category、data添加至测试Intent内，以便电子设备200可以查找到目标组件。

此外，测试Intent中还包括测试数据，测试数据可以作为extra被添加至测试Intent内。其中，测试数据可以为不规则数据，用于测试待测应用的软件编码问题。在一种可选的实施方式中，电子设备200可以根据预先构造的Intent数据模型构建测试数据。Intent数据模型用于指示各个组件与其所需处理的数据的对应关系。具体的，Intent数据模型包括各组件标识、数据名称及数据类型的对应关系。示例性的，Intent数据模型可以如表3所示：

表3

其中，组件1的标识(即标识1)可以为组件1的名称、组件1的ID等可以标识组件1的信息。组件2的标识(即标识2)同理。根据表3可知，组件1在运行过程中，可能会涉及到3个数据，分别为bookname、price及num，其中，bookname的数据类型为string，price的数据类型为double，num的数据类型为int。若组件1为目标组件，则电子设备200可以根据组件1的标识查找到数据名称为bookname、price及num的三个数据，并根据各自的数据类型构建测试数据。示例性的的，bookname的数据类型为string，正常情况下bookname可以为老人与海。在测试时，可以将“老人与海aaaaa&*”作为测试数据。又例如，num的数据类型为int，正常的num可以为200。在测试时，可以将超长的“2000000000000000000”作为测试数据。

需要说明的是，在Intent数据模型为空(不包括任何数据)时，测试数据也可以为空。电子设备200可以向目标组件携带有extra为空的测试Intent。

电子设备200构造好测试Intent后，可以将测试Intent传递给目标组件。具体的，电子设备200可以将测试Intent传递给电子设备200，电子设备200可以根据测试Intent的内容找到目标组件，并将测试Intent传递给目标组件。示例性的，电子设备200可以直接根据测试Intent中的component查找到目标组件，也可以根据测试Intent中的action、category及data等属性查找到目标组件。

需要说明的是，电子设备200向目标组件传递测试Intent的方式与目标组件的类型对应。示例性的，若目标组件为activity(例如，第一activity)，则电子设备200可以采用Context.startActivity()或Activity.startActivityForResult()向目标组件传递测试Intent，以启动目标组件。若目标组件为Service，则电子设备200可以利用Context.startService()向目标组件传递测试Intent，以启动目标组件。若目标组件为Broadcast Receiver，则电子设备200可以利用Context.sendBroadcast()、Context.sendOrderedBroadcast()或者Context.sendStickyBroadcast()向目标组件传递测试Intent，以启动目标组件。

若目标组件为Service、Content Provider或者Broadcast Receiver，则目标组件接收到测试Intent后，可以直接对测试Intent中携带的测试数据(例如，第二测试数据)进行处理。如此，电子设备200可以通过检查待测应用是否存在异常，得到目标组件的安全性测试结果。

若目标组件为待测应用的activity(例如，第一activity)，电子设备200可以显示目标组件所标识的第一界面。在一种可选的实施方式中，目标组件接收到测试Intent后，可以立刻解析测试Intent得到测试数据(例如，第一测试数据)，并基于测试数据进行业务处理。在另一种可选的实施方式中，目标组件接收到测试Intent后，并不会立刻解析测试Intent，而是会在接收到用户对相关控件的点击(滑动、长按、拖拽)操作后才会解析测试Intent得到测试数据，并基于测试数据进行业务处理(例如，如图3A所示的场景中)。但在上述两种实施方式中的任意一种实施方式中，电子设备200均可以显示目标组件对应的第一界面，并对第一界面上的控件进行测试。

为了对第一界面上的控件进行测试，电子设备200可以获取第一界面的控件信息。其中，控件信息用于指示第一界面包括多个控件，且控件信息包括多个控件中每个控件的名称及属性。在一种可能的设计中，电子设备200可以使用android sdk工具包中的uiautomatorviewer.bat脚本导出第一界面的window_dump.xml描述文件，并从window_dump.xml描述文件中获取第一界面的控件信息。

电子设备200可以直接从多个控件中选择一个控件作为目标控件，并对目标控件发送模拟操作(即模拟用户对目标控件发起点击、拖拽、滑动等操作)。需要说明的是，多个控件中的任意一个控件都可以作为目标控件。为了测试的全面性，电子设备200可以将多个控件中的每个控件依次作为目标控件。多个控件可以具备排列顺序，在选择目标控件时，电子设备200可以按照排列顺序的正序依次选择控件作为目标控件，或者可以按照排列顺序的倒序依次选择控件作为目标控件，又或者可以利用随机数生成算法，随机从多个控件中选择控件作为目标控件。

而一般情况下，用户对不可操作控件(属性为unclickable的控件)发起操作，通常不会引起界面的变化或者应用执行相关操作。也即，对可不点击控件发起操作，不易引起应用发生进程崩溃、无响应或是响应慢等异常情况。因此，为了提高测试效率，电子设备200也可以从所有控件中筛选出可操作控件(属性为clickable的控件)得到可操作控件列表，并从可操作控件列表包括的多个控件中选择目标控件。

电子设备200确定目标控件后，可以向目标控件发送模拟操作。在一种可选的实施方式中，电子设备200在对目标控件(例如，第一控件)发送模拟操作后，可以对测试数据进行业务处理。具体的，若目标控件所关联的业务处理流程包括对测试Intent进行解析以及对测试数据进行业务处理，则目标控件接收到模拟操作后，电子设备200可以解析测试Intent得到测试数据，并基于测试数据进行业务处理。示例性的，第一界面可以为钱包应用的帐号登录界面。如图7中的(a)所示，目标组件启动后，电子设备200可以显示钱包应用的帐号登录界面701(即第一界面)，帐号登录界面701可以包括帐号输入控件、密码输入控件及确认控件等。测试时，帐号及密码作为extra随测试Intent一起注入目标组件。目标控件可以为帐号登录界面701上的登录控件702。则电子设备200对登录控件702发送模拟操作(即用户点击登录控件702的事件)后，可以从测试Intent中解析得到帐号及密码，并验证帐号与密码是否匹配。在一种可选的实施方式中，若验证成功，如图7中的(b)所示，电子设备200可以显示界面703。

可见，上述过程便可以模拟出需要在接收到用户对相关控件的点击(滑动、长按、拖拽)操作后，才会对接收到的数据进行业务处理的场景。也即，通过将Fuzz测试与Monkey测试结合，可以测试待测应用在这种场景下是否存在异常，可以发现待测应用的更多软件编码问题，提升软件代码质量。

此外，在电子设备200对测试数据进行业务处理的过程中，电子设备200可以利用hook获取获取业务处理过程中涉及到的数据类型及数据名称，并存储目标组件与该数据类型及数据名称的对应关系，从而更新Intent数据模型。

在另一种可选的实施方式中，电子设备200在对目标控件(例如，第二控件)发送模拟操作后，可以跳转至第二界面。具体的，若目标控件所关联的业务处理流程包括跳转至第二界面，则目标控件接收到模拟操作后，电子设备200可以至第二界面。示例性的，第一界面可以为图库应用的启动界面。如图8中的(a)所示，目标组件启动后，电子设备200可以显示图库应用的启动界面801(即第一界面)，启动界面801可以包括照片、相册、图标等控。目标控件可以为启动界面801上的相册控件802。则电子设备200对相册按钮802发送模拟操作(即用户点击相册按钮802的事件)后，可以显示如图8中的(b)所示的界面803(即第二界面)。这种场景仅涉及到界面的跳转，并不涉及对待测数据的处理。

在电子设备200对目标控件发送模拟操作后，电子设备200可以进一步检查待测应用是否存在进程崩溃、无响应、响应慢、ANR对话框等，以得到测试结果。需要说明的是，电子设备200跳转至第二界面后，可以返回第一界面，并重新从第一界面中选择目标控件，对目标控件进行测试并得到测试结果，直至完成对第一界面上所有控件的测试以后，才算完成对目标组件的测试。需要说明的是，在电子设备200完成对目标组件的测试后，可以从多个组件中重新选择目标组件，然后重新对另一个目标组件进行安全性测试及稳定性测试，直至对所有组件完成测试。

在一种可选实施方式中，完成测试后，电子设备200可以计算测试过程中的代码覆盖率。其中，代码覆盖率可以指已经被测试过的代码在所有代码中的占比，可用于确认测试是否足够全面。

综上所述，本申请提供的应用测试方法，可以从待测应用的多个组件中选择目标组件，并向目标组件注入携带有测试数据的测试Intent，然后对目标组件所对应的第一界面上的每个控件发起点击操作，以便对目标组件同时进行安全性测试及稳定性测试，得到测试结果。这种应用测试方法可以测出常规的Fuzz测试和Monkey测试无法检测出的问题，测试场景更加广泛，可以发现待测应用的更多软件编码问题，有利于提升应用的软件代码质量，减少待测应用中存在的bug，进而提升用户体验。

本申请一实施例提供一种芯片系统900，如图9所示，该芯片系统900包括至少一个处理器901和至少一个接口电路902。处理器901和接口电路902可通过线路互联。例如，接口电路902可用于从其它装置(例如，电子设备200的存储器)接收信号。又例如，接口电路902可用于向其它装置(例如处理器901)发送信号。

例如，接口电路902可读取电子设备200中存储器中存储的指令，并将该指令发送给处理器901。当所述指令被处理器901执行时，可使得电子设备200执行上述各实施例中的各个步骤。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (9)

1.一种应用测试方法，其特征在于，应用于电子设备，所述电子设备上安装有第一应用，所述方法包括：

获取所述第一应用的组件信息，所述组件信息包括多个组件的名称、类别、所需执行的动作及所需处理的数据，所述多个组件包括第一activity；

根据所述第一activity的名称构建第一测试意图；或者，根据所述第一activity的类别、所需执行的动作及所需处理的数据构建所述第一测试意图；

根据所述第一activity的标识从数据模型提取出第一待操作数据的数据信息，其中，所述数据模型包括所述第一activity的标识与所述数据信息的对应关系，所述数据信息包括所述第一待操作数据的数据名称及对应的数据类型，所述第一待操作数据为所述第一activity在运行过程中所涉及到的数据；

根据所述第一待操作数据的数据名称及所述数据类型构建第一测试数据；

将所述第一测试数据添加至所述第一测试意图的扩展信息字段；

向所述第一activity发送所述第一测试意图；

显示所述第一activity对应的第一界面；其中，所述第一界面包括多个控件；

在所述第一activity接收到第一测试意图后，向所述多个控件中的第一控件发送模拟操作；

响应于接收到所述模拟操作，解析所述第一测试意图得到所述第一测试数据，基于所述第一测试数据进行业务处理；

监测所述第一应用在业务处理过程中的运行情况，并根据所述运行情况得到测试结果。

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

向所述多个控件中的第二控件发送模拟操作；

显示第二界面。

3.根据权利要求2所述的应用测试方法，其特征在于，在所述显示第二界面之后，所述方法还包括：

重新显示所述第一界面。

4.根据权利要求1-3中任意一项所述的应用测试方法，其特征在于，向所述多个控件中的第一控件发送模拟操作后，所述方法还包括：

提取所述第一activity在运行过程中涉及到的数据信息；其中，所述数据信息包括所述第一待操作数据的数据名称及对应的数据类型；

根据所述数据信息生成数据模型；其中，所述数据模型包括所述第一activity的标识与所述数据信息的对应关系。

5.根据权利要求1-3中任意一项所述的应用测试方法，其特征在于，所述第一测试意图包括所述第一activity的名称、所述第一activity所需执行的动作、所述第一activity的类别及所述第一activity所需处理的数据中的任意一种。

6.根据权利要求1-3中任意一项所述的应用测试方法，其特征在于，所述方法还包括：

向所述第一应用的第一组件发送第二测试意图；其中，所述第二测试意图包括第二测试数据，所述第二测试数据为根据第二待操作数据的数据名称及数据类型构建的，所述第一组件为服务service、内容提供者及广播接收器中的任意一种，所述第二待操作数据为所述第一组件运行过程中所涉及到的数据；

基于所述第二测试数据进行业务处理。

7.根据权利要求1-3中任意一项所述的应用测试方法，其特征在于，所述模拟操作包括模拟用户点击、拖拽、长按、滑动所述第一控件的操作。

8.一种电子设备，其特征在于，所述电子设备包括：无线通信模块、存储器和一个或多个处理器；所述无线通信模块、所述存储器与所述处理器耦合；

其中，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；当所述计算机指令被所述处理器执行时，使得所述电子设备执行如权利要求1-7中任一项所述的应用测试方法。

9.一种计算机可读存储介质，其特征在于，包括计算机指令；

当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-7中任一项所述的应用测试方法。

Images