CN110580222A - 一种软件测试用例生成方法及系统 - Google Patents

Abstract

本发明实施例提供一种软件测试用例生成方法及系统，所提供的方法包括：获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；执行所述事件，获取所述事件的执行结果。本发明实施例提供的方法及系统，以安卓应用执行过程中的历史状态信息，通过随机方式生成事件，在生成UI事件的同时兼顾系统事件，最终生成更有价值的测试用例。

Description

一种软件测试用例生成方法及系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种软件测试用例生成方法及系统。

背景技术

移动通信技术的不断完善推动了移动设备的迅速发展，其灵活、方便、易携带的特点，使人们对移动设备依赖程度日益提高。智能手机成为当下最重要的移动平台。

相较传统功能手机，移动操作系统及良好的用户界面赋予了智能手机非同一般用户体验和应用扩展性。智能手机基于高清触摸屏，能随时进行触控、输入、多任务等操作，并拥有强大的多媒体、邮件、网络功能，为软件开发商开发功能各异，便捷实用的移动应用提供了无限可能。庞大的用户数量和需求吸引着越来越多的IT企业涉足移动应用领域，移动应用市场规模迅速扩大，已经渗透到社交、购物、资讯等社会活动的各个方面。当下，移动应用数量庞大，每天都有大量的新应用进入市场。截至2017年，安卓手机以87.7％的市场占有量成为最受欢迎的智能手机操作系统，而作为安卓平台最大的移动应用商店，Google Play用户可下载的应用数量已达350万个。

然而，无限商机中也伴随着巨大风险。一方面，应用来源驳杂，既有知名企业推出的明星应用，也充斥着大量由未知开发者发布的应用汇，这给鉴别应用是否恶意，是否安全带来很大挑战。此外，已发布应用的质量参差不齐，由功能出错、运行不流畅、响应速度慢、经常崩溃闪退等带来的用户体验和安全问题也屡见不鲜。这些潜在风险促使开发者愈发重视应用的测试，而采用高效的移动应用测试方法确保其应用的正确性和可靠性成为企业的必然选择。

移动应用的用户界面逻辑与业务逻辑耦合十分紧密，这些移动应用来源迥异，除需考虑各种复杂的硬件和软件运行环境外，企业开发者更面临着缩短开发周期，快速投入市场的压力。因而安卓应用的测试和传统测试相比，技术和理论层面都需要面临新的挑战。

传统的移动应用测试方法主要依靠大量专业测试人员手动测试，人工方法能有效利用测试人员的专业知识，短时间内快速提升被测应用的代码覆盖率。然而，随着应用复杂度和多样化的快速提升，测试人员的培训成本更高，成长周期更长，过度依赖专业测试员的传统方法不得不面对人力成本增长，测试周期长，测试方法难通用等问题。因此，考虑到移动应用在兼容性、移动性(对网络状况的影响)、耐用性(节省电量)以及稳定性等多方面的新需求，移动应用自动化测试，尤其是面向安卓系统的应用自动化测试应运成为测试研究的新方向。

相关企业和研究人员提出了多种应用测试用例生成方法，同时，设计并实现了相应的应用自动化测试工具，这些工具已经能适应数千个应用程序的规模。现有算法按照事件选择的方式可划分为三个类别：模糊测试，基于搜索的测试以及基于模型的测试。

模糊测试(Fuzz testing)是一种有效的软件测试技术，模糊测试通常将随机，意外或无效数据用作目标的输入，因而常用于测试软件和操作系统的安全问题。在其他测试对象或场景中，研究人员已经使用模糊测试工具成功发现了大量的错误和漏洞，证明了模糊测试的有效性，而针对安卓应用进行模糊测试则刚刚开始。

模糊测试思想首先应用在事件选择算法中。Monkey是最早的，已经在工业界广泛使用的安卓应用模糊测试工具。Monkey工具由Google推出，并内置于安卓系统中。Monkey既可以运行在安卓平台，也可以运行在PC上，通过adb与应用交互。用户可以以命令行方式启动Monkey，设置事件生成数量、速度、概率等参数后启动被测应用程序开始测试。过程中，Monkey持续发送事件给被测应用，模拟点击按钮，输入文本等用户操作，若监听到崩溃数，未响应数或事件数量达到停止条件，则停止测试。

基于搜索的测试(Search-based testing,SBT)又称系统测试，是指采用特定的搜索算法，系统性地分析、测试一个应用程序。是安卓应用推出前必须经历的阶段，如果一个应用没有进行较全面的系统测试，一些潜在问题就很有可能导致应用程序运行故障。大部分测试也要求批量地采用安卓真机设备而非模拟设备进行测试，以确保功能的完善性。已有工具包括EvoDroid，A3E，ACTEve等。

基于模型的测试(Model-based testing,MBT)是另一种自动化GUI测试的流行方法。通过开发时建模或运行时持续建模，测试人员获取被测应用的模型，根据模型生成测试用例和相应的期望输出。然后，在安卓应用上执行该用例，观察并记录运行和输出信息作为反馈，最终又帮助改进需求及其模型。基于模型的工具有GUITAR，EXSYST，Stoat。

然而，在现有技术中，模糊测试方法无法获取或只能部分获取被测应用的界面状态，因而随机生成的事件缺乏针对性，存在大量冗余，且不容易触发深层次状态。基于搜索的方法过分依赖对UI控件，若遇到难以识别的控件(如用户自定义控件)，则难以保障搜索的完备性。此外，基于搜索的测试对系统事件的生成考虑不足，遍历过程也容易受到影响。基于模型的测试则依据应用模型生成测试用例，以期望彻底验证程序行为，但路径爆炸问题的限制使该方法难以适用大型应用的测试验证，此外，模型若由测试人员抽象构建，则通用性不强，难以推广，若由工具自动构建，则面临着UI探索不完整的限制。

发明内容

为解决上述现有技术中存在的问题，本发明实施例提供一种软件测试用例生成方法及系统。

第一方面，本发明实施例提供一种软件测试用例生成方法，包括：

获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；

根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；

执行所述事件，获取所述事件的执行结果。

其中，所述获取待测试安装包之前的步骤，还包括：对原始安装包进行反编译，生成原始安装包对应的Java字节码；通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

其中，所述获取所述测试安装包对应的应用程序在任一页面的历史状态信息的步骤，具体包括：在一个测试周期内，获取所述应用程序所处页面状态和代码覆盖率。

其中，所述根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行的步骤具体包括：若判断获知所述事件类型为系统事件，则直接将所述事件发送至安卓设备进行执行；若判断获知所述事件为UI事件，则根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重；根据所述有效控件的权重，选择任一有效控件作为所述事件的执行控件，并将所述事件发送至安卓设备进行执行。

其中，所述根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重的步骤，具体包括：根据动态权重算法，计算获得控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子；根据所述控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子的权重，计算获所述有效控件的权重。

其中，所述执行所事件，获取所述事件的执行结果之后的步骤，具体包括：若所述事件执行后出现崩溃或未响应状态，则生成漏洞报告。

第二方面，本发明实施例提供一种软件测试用例生成系统，包括：

历史状态信息生成模块，用于获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；

事件生成模块，用于根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；

执行模块，用于执行所事件，获取所述事件的执行结果。

其中，所述系统还包括预处理模块，用于对原始安装包进行反编译，生成原始安装包对应的Java字节码；通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

第三方面，本发明实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面所提供的软件测试用例生成方法的步骤。

第四方面，本发明实施例提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面所提供的软件测试用例生成方法的步骤。

本发明实施例提供的软件测试用例生成方法及系统，以安卓应用执行过程中的历史状态信息，通过随机方式生成事件，在生成UI事件的同时兼顾系统事件，最终生成更有价值的测试用例。

附图说明

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

图1为本发明一实施例提供的软件测试用例生成方法的流程示意图；

图2为本发明一实施例提供的软件测试用例生成方法中，被测程序页面示意图；

图3为本发明一实施例提供的软件测试用例生成方法中动态权重算法伪代码示意图；

图4为本发明一实施例提供的软件测试用例生成系统的结构示意图；

图5为本发明一实施例提供的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参考图1，图1为本发明一实施例提供的软件测试用例生成方法的流程示意图，所提供的方法包括：

S1，获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息。

S2，根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行。

S3，执行所事件，获取所述事件的执行结果。

具体的，本实施例中，以被测应用的安卓安装包(Android Package,APK)为输入，自动运行被测应用。测试过程中，一旦发现崩溃，未响应等预定义问题，系统将自动提单(提醒开发者)。在具体实现中，首先将APK安装在安卓设备上，在每一个测试周期中，获取应用程序当前所处页面状态，代码覆盖率加入到历史测试数据，例如，窗口控件被点击的次数等，并将此保存为历史记录。

随后根据历史记录，生成特定类型的事件，如果生成的事件是UI类型事件，则选择一个特定的控件后发送给执行模块，否则，若为系统事件，则直接发送给执行设备，以供执行设备执行该事件，并生成事件的执行结果。

通过此方法，以安卓应用执行过程中的历史状态信息，通过随机方式生成事件，在生成UI事件的同时兼顾系统事件，最终生成更有价值的测试用例。

在上述实施例的基础上，所述获取待测试安装包之前的步骤，还包括：对原始安装包进行反编译，生成原始安装包对应的Java字节码；通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

具体的，由于在事件生成的过程中需要使用实时代码覆盖率作为反馈，因此APK插桩成为必要的技术选择，本发明实施例中，使用Enjarify工具将原始APK反编译为Java字节码。这里没有使用著名的反编译工具dex2jar工具是因为许多边缘情况会导致其失败或者产生不正确的结果，同时，dex2jar已经有近三年没有维护更新了。反编译后，使用Jacoco工具插桩Java字节码，然后使用dx工具将插桩后的源码重新编译分包，得到多个dex文件，并使用aapt,apks igner工具进行重打包和重签名，得到待测APK。

值得注意的是，由于插桩方法需要对APK进行修改，所以必须采取措施应对APK的防反编译和防篡改机制(如签名验证，运行时签名验证等)。为此，本发明实施例首先保存原始APK的签名信息，然后使用apksigner对APK重签名以通过签名验证。为通过运行时签名校验，本发明实施例通过修改AndroidManifest.xml将APK的原始启动类替换为自定义启动类。自定义启动类初始化了漏洞检测模块和钩子函数模块和APK的原始启动类，从而实现了对原始APK启动类的代理。其中，漏洞检测模块用于应用发生崩溃，未响应等错误的自动检测和报告，钩子函数模块用于在运行时替换PackageManager.getPackageInfo()方法返回值为保存的签名信息，从而通过运行时签名验证。

在上述实施例的基础上，所述获取所述测试安装包对应的应用程序在任一页面的历史状态信息的步骤，具体包括：在一个测试周期内，获取所述应用程序所处页面状态和代码覆盖率。

具体的，生成的APK将安装在安卓设备上。在每个测试周期中，历史记录步骤通过获取应用程序的当前所处页面状态，代码覆盖率加入到历史测试数据，例如，窗口控件被点击的次数等。

图2示出了在本实施例中，被测程序页面示意图，该图片为某程序在注册账户时的国家和地区选择页面，在安卓应用中，这样的图形页面是由一个一个图形元素组成的，图2同时示出了该页面对应的部分控件树信息。可以看到，图2中Albania,Algeria,Andorra等图形元素对应着一个个TextView类型的代码单元，称为控件。每个页面的控件以树状结构组织，可以包含一定的层级关系，如Albania,Algeria,Andorra三个控件都是类型为ListView的控件的子控件。此外，除TextView,ListView,EditText等类型标志外，每个控件还有可点击，可长按等属性信息，从而表明了与该控件相关的事件类型。

在上述实施例的基础上，所述根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行的步骤具体包括：若判断获知所述事件类型为系统事件，则直接将所述事件发送至安卓设备进行执行；若判断获知所述事件为UI事件，则根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重；根据所述有效控件的权重，选择任一有效控件作为所述事件的执行控件，并将所述事件发送至安卓设备进行执行。

其中，所述根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重的步骤，具体包括：根据动态权重算法，计算获得控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子；根据所述控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子的权重，计算获所述有效控件的权重。

具体的，为了选择更可能提升被测应用覆盖率的控件，本发明实施例设计了动态权重算法，该算法的核心为四种权重因子：控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子。

当用户进入应用页面时，页面上一般会有几十个控件可供用户操作。精心设计的应用程序会充分考虑用户习惯和设计目标，因此常通过调整控件面积的方式合理调度用户的注意力。在真实应用中，面积较大的控件往往与应用程序的核心功能或推荐功能相关，因此应当作为重点控件首先进行测试。这促使我们将控件面积作为一个选择控件的重要标准，记为F_a。F_a计算方式如下：

其中，S_w表示控件的面积，S_s表示此控件所属的页面状态。显然，对于特定控件而言，因子F_a在测试中持续不变。

控件测试程度因子用于平衡每个控件的实际测试程度，该因子记为F_d。在测试期间，F_d会根据控件的实际测试程度而变化。对于特定控件w，假设控件的选择时间记为w_t，控件测试程度记为w_d，控件的面积依旧记为S_w，则单个控件的测试程度由以下公式计算：

显然，控件测试程度为控件已经被选择的次数与其面积的比率。显然，每单位面积的执行次数越多，这个控件的测试就越高。随着测试过程的进行，控件的实际测试程度可能会有很大差异。为了平衡每个控件的测试程度，本实施例设计了如下控件测试程度因子，记为F_d：

如果控件的测试程度低于当前页面所有控件测试程度的平均值，则F_d增大，优先选择该控件。

与测试度因子的概念类似，本发明实施例定义了目标页面测试度因子F_n，以鼓励算法选择能够进入低测试程度的状态状态的控件。首先，本发明实施例定义特定页面状态的测试程度为s_d，计算方法如下。

s_t表示在此页面状态下已经执行的事件的总数。s_t既包括返回，滑动，截取屏幕截图等系统事件，也包括了UI事件。设当前被测应用为A，点击控件后进入的目标页面状态为s，则该控件的目标页面测试程度因子F_n为

如前所述，Monkey工具生成的大量测试事件集中在浅层页面状态，难以进入并保持在深层压面状态，F_n将有助于避免这种情况。上式表明，如果目标页面状态的测试程度低于平均值，选择该控件的概率将增加。

为了使算法知道已选择的控件的有效性，本发明实施例通过该控件是否引起整体代码覆盖率的增加来调整控件权重。本发明使用被测应用的方法覆盖率而不是行覆盖作为反馈，因为该指标足够精细并且对应用的运行性能影响较小。

在测试期间，每分钟获得被测应用程序的代码覆盖率。假设应用程序在此时间段内执行了k(k＞＝0)个事件，按照执行顺序，可记录为一个事件序列Seq{e1，e2，e3，e4...ek}。当工具获取到被测应用最新的实时覆盖率时，将本次获取的覆盖率去前次获取的覆盖率对比，根据覆盖率增加或不变的不同状况返回不同的覆盖率奖励值，并采用Q-learning算法更新权重。具体而言，记该事件序列的第i个事件为e_i，本次执行该事件的覆盖率奖励值为r_i。则事件序列中相邻两个事件的覆盖率奖励值的关系为：

r_i＝γr_i+1

其中，γ为覆盖率奖励的衰减系数。记序列的最后一个事件e_k的奖励值为r_k。当该序列引发覆盖率增长时，r_k取固定值r_b，否则取0。因此，可以通过递归计算出序列中所有事件的覆盖率奖励值。

测试过程中，每个事件可能多次得到覆盖率奖励，假设F′_c表示事件之前的覆盖率提升因子，F_c表示当前的覆盖率提升因子，r表示本轮覆盖率奖励，则通过以下方式更新F_c：

F_c＝rλ+F′_c(1-λ)

对于UI事件，如果执行某控件后被测应用的方法覆盖率增加，则其覆盖增长因子F_c也将增加，否则，它将随着测试的进行而衰减。

在获得每个控件的上述四个权重因子之后，还需要考虑如何综合使用四个因子以合理的选择空间。最终所得的动态权重算法如图3所示。

在第1行中，算法随机选择事件类型。通过验证，确保本步骤生成的事件e的类型一定是有效的(若当前页面状态确实能够执行该事件，则称该事件对当前页面而言是有效的。举例而言，若该事件为点击事件，那么当前页面必须具有能被点击的控件)。此外，为避免陷入无意义的循环，返回事件的概率计算如下

该式意义为，若当前页面的测试程度高于所有页面的平均测试程度，则增加返回事件的选择概率，否则减少。

在第4行中，本发明实施例根据四个因子的实际意义设计了不同的权重m，n，p，q。测试初始阶段，大量控件未经过测试，使得F_a较为重要，其有助于算法首先采用重要的控件。随着测试的进行，F_d和F_n越来越重要，这两个因子分别有助于平衡单个页面内控件的测试程度以及各个页面之间的测试程度。当各个页面的所有有效事件都至少被执行一次之后，仅通过已执行的事件数量无法准确衡量控件对覆盖率增长的影响，此时F_c将成为重要的因子。因此，算法分别取m,n,p,q为0.1,0.2,0.3,0.4，取四个因子的加权和为控件的最终权重。

最后，若e为系统事件，则下发设备直接执行，若为UI事件，则按控件权重随机选择一个控件作为该事件的执行控件。

在上述实施例的基础上，所述执行所事件，获取所述事件的执行结果之后的步骤，具体包括：若所述事件执行后出现崩溃或未响应状态，则生成漏洞报告。

具体的，所生成的事件e下发到安卓设备上执行。若事件执行后被测应用出现崩溃或未响应等问题，则工具自动生成漏洞报告并提醒开发人员。

综上所述，本发明实施例提供的方法，为在生成UI事件的同时兼顾系统事件，以随机方式生成事件。为系统的遍历控件以触发深层次事件，以覆盖率作为反馈，设计奖励函数不断修改控件选择权重，提升触发深层次应用状态的可能性。最后，设计了通用的Apk插桩框架，能实时获取应用的方法覆盖率。

参考图4，图4为本发明一实施例提供的软件测试用例生成系统的结构示意图，所提供的系统包括：历史状态信息生成模块41、事件生成模块42和执行模块43。

其中，历史状态信息生成模块41用于获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；

事件生成模块42用于根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；

执行模块43用于执行所述事件，获取所述事件的执行结果。

具体的，本实施例中，以被测应用的安卓安装包(Android Package,APK)为输入，自动运行被测应用。测试过程中，一旦发现崩溃，未响应等预定义问题，系统将自动提单(提醒开发者)。在具体实现中，首先将APK安装在安卓设备上，在每一个测试周期中，获取应用程序当前所处页面状态，代码覆盖率加入到历史测试数据，例如，窗口控件被点击的次数等，并将此保存为历史记录。

随后根据历史记录，生成特定类型的事件，如果生成的事件是UI类型事件，则选择一个特定的控件后发送给执行模块，否则，若为系统事件，则直接发送给执行设备，以供执行设备执行该事件，并生成事件的执行结果。

通过此方法，以安卓应用执行过程中的历史状态信息，通过随机方式生成事件，在生成UI事件的同时兼顾系统事件，最终生成更有价值的测试用例。

在上述实施例的基础上，所述系统还包括预处理模块，用于对原始安装包进行反编译，生成原始安装包对应的Java字节码；通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

由于在事件生成的过程中需要使用实时代码覆盖率作为反馈，因此APK插桩成为必要的技术选择，本发明实施例中，使用Enjarify工具将原始APK反编译为Java字节码。这里没有使用著名的反编译工具dex2jar工具是因为许多边缘情况会导致其失败或者产生不正确的结果，同时，dex2jar已经有近三年没有维护更新了。反编译后，使用Jacoco工具插桩Java字节码，然后使用dx工具将插桩后的源码重新编译分包，得到多个dex文件，并使用aapt,apksigner工具进行重打包和重签名，得到待测APK。

图5为本发明一实施例提供的电子设备的结构示意图，如图5所示，电子设备包括：处理器(processor)510、通信接口(Communications Interface)520、存储器(memory)530和总线540，其中，处理器510，通信接口520，存储器530通过总线540完成相互间的通信。处理器510可以调用存储器530中的逻辑指令，以执行如下方法，例如包括：获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；执行所事件，获取所述事件的执行结果。

本发明实施例公开一种计算机程序产品，计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；执行所事件，获取所述事件的执行结果。

本实施例提供一种非暂态计算机可读存储介质，非暂态计算机可读存储介质存储计算机指令，计算机指令使计算机执行上述各方法实施例所提供的方法，例如包括：获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；执行所事件，获取所述事件的执行结果。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种软件测试用例生成方法，其特征在于，包括：

获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；

根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；

执行所事件，获取所述事件的执行结果。

2.根据权利要求1所述的方法，其特征在于，所述获取待测试安装包之前的步骤，还包括：

对原始安装包进行反编译，生成原始安装包对应的Java字节码；

通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

3.根据权利要求1所述的方法，其特征在于，所述获取所述测试安装包对应的应用程序在任一页面的历史状态信息的步骤，具体包括：

在一个测试周期内，获取所述应用程序所处页面状态和代码覆盖率。

4.根据权利要求1所述的方法，其特征在于，所述根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行的步骤具体包括：

若判断获知所述事件类型为系统事件，则直接将所述事件发送至安卓设备进行执行；

若判断获知所述事件为UI事件，则根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重；

根据所述有效控件的权重，选择任一有效控件作为所述事件的执行控件，并将所述事件发送至安卓设备进行执行。

5.根据权利要求4所述的方法，其特征在于，所述根据所述事件所有有效控件的集合中，根据预设的控件权重因子，计算所述有效控件的权重的步骤，具体包括：

根据动态权重算法，计算获得控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子；

根据所述控件面积因子，测试程度因子，目标页面测试程度因子和覆盖率提升因子的权重，计算获所述有效控件的权重。

6.根据权利要求1所述的方法，其特征在于，所述执行所事件，获取所述事件的执行结果之后的步骤，具体包括：

若所述事件执行后出现崩溃或未响应状态，则生成漏洞报告。

7.一种软件测试用例生成系统，其特征在于，包括：

历史状态信息生成模块，用于获取待测试安装包，将所述测试安装包安装在安卓设备中，获取所述测试安装包对应的应用程序在任一页面的历史状态信息；

事件生成模块，用于根据所述历史状态信息，生成所述历史状态信息对应的特定类型的事件并将所述事件发送至安卓设备执行；

执行模块，用于执行所事件，获取所述事件的执行结果。

8.根据权利要求7所述的系统，其特征在于，所述系统还包括预处理模块，用于对原始安装包进行反编译，生成原始安装包对应的Java字节码；

通过预设工具插桩所述Java字节码，将插桩后的字节码进行编译分包，并进行打包和签名操作，生成所述待测试安装包。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述软件测试用例生成方法的步骤。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1至6任一项所述软件测试用例生成方法的步骤。