CN116383054A - 一种静态分析和动态探索结合的移动应用模型构建方法 - Google Patents

Abstract

本发明公开了一种静态分析和动态探索结合的移动应用模型构建方法，包括以下步骤：统计和分析主流的动态组件类型；静态分析应用app获取应用基于动态组件的静态模型，再在动态测试过程中与静态模型进行匹配得到应用的当前状态，利用状态节点和事件序列构建应用模型状态图，最后使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果。本发明采用了静态分析和动态探索结合构建应用模型状态图，很好地利用静态分析获取应用的动态组件信息，更加合理地表示页面的状态情况的优势，以及动态探索获取事件完整性的优势，构建更加准确的应用状态模型。

Description

一种静态分析和动态探索结合的移动应用模型构建方法

技术领域

本发明涉及软件移动应用测试领域，特别是涉及一种静态分析和动态探索结合的移动应用模型构建方法。

背景技术

手机在我们生活中扮演着重要的角色，通过使用移动应用app能够满足我们日常的学习娱乐办公等等方面的要求。对于各式各样的app，在上架前的功能测试是保证app质量的重要方法。而由于应用中事件的多样性以及页面的变化性，能否快速有效全面地测试app仍然是一项挑战，现有主流的自动化测试方法主要有如下三种：

随机测试，随机测试通过随机生成事件对app进行测试，例如对设备上某一个位置进行click。随机测试方法的优势在于事件选择快，产生的事件数量多，但是事件选择缺乏指导性，可能会产生许多对测试有效性无用的事件，例如对设备屏幕上无可执行组件的位置进行点击，此时页面没有产生任何变化，此外随机测试也很难测试到需要特定事件序列才能达到的功能页面

基于静态分析构建模型的测试，通过分析app源代码或中间代码的方式，构建应用的状态模型图，再根据该状态模型图产生测试序列对app进行测试。对于传统的纯静态分析构建模型的方法，由于app代码中组件和事件处理接口的多样性，纯静态分析构建应用模型对作者的静态分析能力要求过高。缺点在于构建的模型粒度一般较粗，例如采用一个state对应唯一一个activity的方式，忽略了在一个activity中会有许许多多的动态组件，而动态组件往往对测试完整性和覆盖率的提升有重要的作用，而传统纯静态的模型则很难匹配到动态测试过程中这些动态组件的事件信息，另外一个问题在于模型中的事件信息不准确，会导致依据模型未分析到这些动态组件的事件信息导致测试覆盖率低，或者分析到了这些事件信息但是动态测试的过程中由于动态组件并未加载导致找不到相应的组件事件出现测试出错。

基于动态测试信息构建状态模型的测试，依据动态测试的页面信息例如截图或者hierarchy信息进行模型构建，这种方式在事件的获取上会比较完整，但随着测试的进行，页面信息不断增多，如何对这些页面进行合理的状态划分则十分重要，而往往影响页面变化的原因是不同的activity加载或者一个activity中的动态组件的加载，而仅根据动态测试的hierarchy信息是没有办法知道哪一部分是动态组件的。因此动态信息划分状态只能够通过整体hierarchy中的结构，组件节点的resourceid，text等信息进行划分，划分过细会导致状态爆炸，影响测试的效率，例如q-testing，划分过粗，多个页面进行合并，则会可能会导致将原本两个完全不同的事件进行合并，影响测试事件执行的准确性。

为了解决上述测试方法中模型构建的问题，我们提出将静态分析信息和动态测试信息结合起来更加合理的构建状态模型的方法，并使用该模型对app进行了测试实验。

发明内容

目前针对代码覆盖率的工具较少，且多数存在结构复杂、不利调试、通用性差、无法快速适用不同语言和后续人工分析工作量巨大等问题，为解决上述问题，本发明通过以下技术方案来实现。

一种静态分析和动态探索结合的移动应用模型构建方法，其特征在于，包括如下步骤：

步骤1)统计和分析主流的动态组件类型；

步骤2)静态分析应用获取应用基于动态组件的静态模型；

步骤3)动态测试过程中匹配应用的当前状态；

步骤4)构建应用模型状态图；

步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果。

上述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤1)统计和分析主流的动态组件类型。

上述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤2)静态分析应用获取应用基于动态组件的静态模型具体包括以下步骤：

步骤21)使用apktool和soot工具静态分析apk，得到应用的动态组件信息；

步骤22)利用应用的动态组件信息进行基于动态组件的静态模型构建。

上述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤3)动态测试过程中匹配应用的当前状态具体包括以下步骤：

步骤31)uiautomator工具获取应用当前页面hierarchy信息；

步骤32)通过分析hierarchy信息，与应用的静态模型进行匹配，得到每个动态组件的状态组件，从而得到整体的状态字典；

步骤33)获取事件并存到对应的状态组件当中。

上述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤4)构建应用模型状态图具体包括以下步骤：

步骤41)构建状态图结构；

步骤42)将状态组件中的事件储存到state中；

步骤43)根据测试过程中的事件序列构建应用的状态模型图；

步骤44)利用状态模型进行测试。

上述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果具体包括以下步骤：

步骤51)强化学习q-learning算法中reward的设定和value的更新规则设定；

步骤52)设定事件的选择算法；

步骤53)应用的插桩和覆盖率的获取。

本发明采用以上技术方案，具有以下有益效果：

静态分析过程使用反编译apk的中间代码，因此无需app源码，另外采用静态分析信息和动态探索信息进行app的应用状态模型构建，模型的准确性和完整性较高。

附图说明

图1为本发明实施例基于静态分析和动态探索结合的移动应用模型状态图构建方法流程图。

图2为本发明实施例静态模型中动态组件类型和关系图。

图3为本发明实施例应用app静态模型示例图。

图4为本发明实施例应用app GUI状态模型示例图。

具体实施方式

下面结合附图和具体实施例对本发明做进一步详细的说明。

本发明的目的在于解决移动应用测试中对app的状态模型构建不准确的问题，并提出了一种新的状态模型的构建方法，我们引入了动态组件的概念，将应用页面划分为多个动态组件的状态，例如viewpager，viewpager中可能加载不同的fragment，我们认为动态组件的加载是页面变化的重要因素也能够很好地表示一个页面的状态信息，并且动态组件的加载往往会伴随应用中许多api的执行和res的加载，因此会有更加丰富多样的页面信息和功能场景，而这些动态组件信息能够通过对应用进行静态分析很好地获取但却很难仅通过动态测试过程中的页面信息得到，我们希望通过以动态组件模型为指导的状态构建能够更加有效地辅助动态测试，避免测试过程中的状态爆炸，有效发现不同页面中的相同事件，帮助测试事件序列准确地制定和指导事件的选择。我们同时结合静态分析能够很好地找到动态组件，构建状态的优势，以及动态测试信息事件获取完整性的优势，通过将该模型引入到其他只使用动态信息的构建状态模型的工具中，提升他的测试效果，目前我们尝试q-Learning算法与模型结合进行app的测试并且取得了不错的测试效果。本发明基于静态分析和动态探索结合的移动应用模型状态图构建方法流程如图1所示，主要包括以下步骤：

步骤1)统计和分析主流的动态组件类型；

步骤2)静态分析应用获取应用基于动态组件的静态模型；

步骤3)动态测试过程中匹配应用的当前状态；

步骤4)构建应用模型状态图；

步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果；

以下对上述步骤进行详细描述。

上述的一种静态分析和动态探索结合的移动应用模型构建方法，其特征在于步骤1)中统计和分析主流的动态组件类型，之所以引入动态组件的概念，是因为我们发现导致动态测试过程中页面变化的主要原因为活动的替换和动态组件的加载，而动态组件是无法从动态测试的hierarchy信息中得到的。因此为了更加合理的构建状态，我们想利用静态分析的方式构建应用的可能状态组成情况。经过了解我们发现主流应用的动态组件类型有以下：activitywidget，fragmentwidget，view pagerwidget，drawerwidget，actionbarwidget，menu，dialog，listviewwidget，recyclerviewwidget等，那么页面的状态可以由每一个动态组件的状态组合进行表示，这样做的好处在于一方面在于能够很好地应对页面的变化情况，以此来减少状态数量，避免状态爆炸，例如listview中item的增加，或者toolbar中控件的变化，我们可以将这些变化的事件放在一个组件内，避免新状态的不断增加，另一方面某一组件中的事件变化并不会影响到其他组件的事件，例如某一个fragmentwidget中fragment的替换，也就是fragmentwidget状态改变时，其所在activity中的toolbarwidget的状态并不会改变，通过这种方式我们能够避免一些已知事件被判断为新事件，提升测试的效率。

图2是为本发明实施例静态模型中动态组件类型和关系图，动态组件类型以及他们的层级关系如图2所示。

了解了主流的动态组件类型以及动态组件的加载方式后，在步骤2)中通过静态分析静态分析应用app获取应用基于动态组件的静态模型，具体步骤是：

步骤21)使用apktool和soot工具静态分析apk，得到应用的动态组件信息。Apktool是常用的apk反编译工具，利用apktool可以将应用app的安装包apk的resource，layout布局文件获取到，方便后续分析，注意apktool工具只获取resource文件。之后利用soot工具对apk再反编译获取应用中间代码，中间代码为jimple格式，从而对jimple格式的中间代码进行静态分析获取到该应用的动态组件信息。不同的动态组件有不同的加载方式，因而分析的算法也不同，有以下三类：

(1)通过动态组件对应的加载接口函数进行分析，例如activity布局文件通常是在activity类的oncreate生命周期函数中调用setcontentview方法的方式加载，从而我们可以通过该函数的参数分析出加载的布局文件名称，然后通过名称在apktool反编译的res文件夹中寻找到对应的加载布局文件，同理fragment和actionbar也是通过这种方式进行分析；

(2)通过对布局文件进行分析，例如drawer，drawer组件在源码中没有对应的加载api，只有绑定api，加载是在activity的布局文件中进行的，当activity的布局文件中是以drawerlayout作为父布局时，说明有drawer的加载，在通过分析子节点中存在layout_gravity属性的节点即为drawer组件，寻找该节点的menu属性则可以分析出drawer对应加载的menu布局文件名称，从而从resource文件中获取到对应加载的布局文件；

(3)通过对应用代码中的动态配置的动态组件进行分析，例如dialog，dialog组件是在代码中动态设定titile，message等，具体方法与第一点相似，都是通过分析出加载接口对应的参数获取，区别在于寻找的目标不是布局文件，而是title，message等条目的具体内容。注意到各个动态组件其实是有包含关系的，例如activity下包含fragment，fragment下包含listview，因此在分析的过程中也是依照顺序进行扩展分析，例如先分析出所有的activity，再分析出各个activity下的fragment，再分析所有的activity和fragment下的listview。此外，相比于其他静态分析工具，我们对viewbinding等等新型的布局问价加载方式进行了分析。最后能够提取出应用中所有的动态组件信息。

步骤22)利用应用的动态组件信息进行基于动态组件的静态模型构建。静态模型和状态图主要有5个重要的组成元素，{dynamicwidgets,widget，actions，state，transition，state_actions}，dynamicwidgets为动态组件，而widget是动态组件的可能状态组件，状态组件下又可能包括多个子动态组件，例如Activitywidget中包括activity状态组件，而activity中又会有fragmentwidget，drawerwidget等动态组件，所以静态模型是一个树形的结构，利用静态模型和动态获取的页面hierarchy信息，我们可以获取到各个动态组件的状态字典以及每个状态组件包括的事件Actions，每个状态字典对应一个唯一的State，stateactions为该状态下所有的保存的事件，一个状态组件可能会出现在不同的state中，因此一个action会对应一个或多个stateaction，在测试的过程中我们根据执行的stateaction序列以及状态信息构建transition，以此来表示整个AUT的状态图。在本步骤我们主要将动态组件信息用于静态模型的构建，也就是{dynamicwidgets，widget,}两个部分的内容。

以应用“antennapod”为例，对该应用进行静态模型构建。静态模型结果示例如图3所示。

步骤3)动态测试过程中匹配应用的当前状态，也就是将当前页面的信息与静态模型进行匹配，得到所有动态组件的状态组件，从而获取到当前的state，具体步骤包括：

步骤31)uiautomator工具获取应用当前页面hierarchy信息。通过uiautomator工具，可以将应用当前页面的hierarchy以xml文件的方式dump下来，之后可以对hierarchy结构进行分析匹配。

步骤32)通过分析hierarchy信息，与应用的静态模型进行匹配，得到每个动态组件的状态组件。在动态测试的过程中，通过动态测试过程获取当前页面的hierarchy信息来对静态模型中的每一个动态组件的状态进行匹配，最终的状态为所有动态组件状态构成的字典，如图3所示，依据gui页面的所在activity，静态模型中对应的activitywidget进行匹配，匹配的过程采取广度优先，自上而下，不同的组件有不同的匹配规则，例如fragmentwidget，首先我们静态分析出了fragmentwidget加载的对应resource-id，然后从hierarchy信息中去寻找对应resource-id的节点，再通过静态分析出的每一个可能加载的fragment类和其layout文件与hierarchy中的节点信息进行匹配，寻找到匹配率最大的fragment作为该fragment widget的当前状态。匹配率通过将layout文件中的各个控件的resource-id、class name以及动态组件在hierarchy中的整体出现情况获取。而对于actionbarwidget和drawerwidget，我们则是通过静态模型中获取的菜单item文本以及动态测试中对应的resource-id节点获取的菜单文本进行比对，得到他们的当前状态组件。如果动态组件中所有可能的状态组件都没有匹配上，说明可能出现静态分析中未分析到的新的状态组件，这时我们会匹配到dyanmic_exploration_widget当中，避免状态爆炸，同时保证事件的完整性。在匹配到对应的状态组件后，我们会将页面中的事件储存到对应的状态组件当中。

步骤33)获取事件并存到对应的状态组件当中。动态组件的状态匹配成功后，我们对其在hierarchy中对应的节点进行遍历分析，获取到所有的叶子节点，也就是executable_node(事件通过与executable_node交互来执行)，以及executable_node的事件执行类型信息，例如click，longclick，将这些事件存储到对应的状态组件当中。而一个状态组件可能出现多次，因此良好的事件储存方式是避免状态爆炸和事件爆炸的关键，这就涉及到事件的比对规则，将新出现的事件与之前存入的事件进行比对。对于之前动态建模的工具，事件的比对规则是控制状态数量的关键因素，例如之前有的工作将事件的比对分为5种粒度，有的依据测试情况动态地调整比对粒度，对于本工具同样如此，虽然对状态数量进行了控制，但是如果事件数量不断膨胀同样会对基于模型的测试过程有很大影响，因此我们注意到不同的动态组件能够使用不同的事件比对粒度，最初我们已较细粒度的方式进行事件的比对获取，当组件中的新事件次数产生超过阈值时，也就是说不断有新事件产生，有可能是新增事件，有可能是相同事件位置的变化，我们就会将该组件的事件比对规则粗化，例如menu open，drawer等组件中的事件节点对于text，description信息标识较强，而位置index信息时常变化的情况，我们采用{resource-id：，text：，description：}的规则，而例如日历dialog中日期事件text信息不断变化，但是对测试效率帮助不大的组件，我们采用{resource-id：，index：，classname：}的规则，而activity，fragment等组件可能会有新未分析到的动态组件加载导致事件不断增多，我们采用{resource-id：，index：，classname：}的规则来避免组件中的事件过度膨胀，总之利用组件的特性变化事件比对的规则，相同效果的事件被过度地判断为新事件，导致测试过程陷入循环或者瓶颈。

步骤4)依据测试过程的事件信息和状态信息构建应用模型状态图，具体步骤包括：

步骤41)构建状态图结构。如上述所说，状态图由{state，transition，state_actions}三个元素组成，state为节点，state中包括其所有的state_actions，transition为边，这样我们能够将应用的状态模型以状态图的方式进行表示。一个state与一组动态组件的状态字典唯一对应。

步骤42)将状态组件中的事件储存到state中。当获取到当前state的动态组件状态字典后，将该state中出现的状态组件中获取的action提取出来，与原本state中存储的state_action进行比对，对新出现的action以state_action进行存储。

步骤43)根据测试过程中的事件序列构建应用的状态模型图。经过一系列的事件选择，应用页面不断地变化，匹配到的state数量和事件数量以及transition不断增多，状态模型图不断扩展完善，最终获取到比较准确的应用状态模型。

以应用“antennapod”为例，对所述应用进行静态模型构建，所述静态模型结果示例如图4所示。

步骤44)利用状态模型进行测试。对于之前的自动化测试工具，依赖状态信息以及基于模型的测试工具都可以使用本工具的状态模型进行测试指导，例如stoat工具，其测试过程分为利用动态测试过程构建状态图以及依据状态图来产生事件序列指导测试，以尽可能遍历状态图所有状态，来达到高覆盖率的目的，但是由于stoat仅通过动态hierarchy信息获取state，以及其事件比对规则不够灵活的原因可能产生状态爆炸测试效率低或者事件序列无法完整正常执行导致测试效率低的情况。因此借用本工具状态模型，以及stoat的遍历状态图的测试算法，能够有产生更加简便和稳定的测试事件序列，区别在于，利用我们的状态模型，更直接的目的是能够遍历更多的动态组件的状态，因为我们认为动态组件的状态组件加载能够触发应用执行指定的组件加载API和res文件，对覆盖率提升有更加直接的影响。例如q-testing，采用好奇心的思想，使测试过程能够测试到AUT更多的更多功能场景或者说更加丰富多样的页面，利用q-learning的算法，以基于功能场景的状态信息作为reward进行测试，借用我们的模型，同样可以采用q-learning的算法，以发现更多的动态组件和状态组件加载作为reward来指导测试，因为我们可以认为每一个动态组件和状态组件的加载都会包括更多丰富的功能场景，再而相比于q-tesing的q-table中以hierarchy信息作为状态可能会出现状态爆炸的情况，使用本工具状态模型能够很好地避免，此外不同状态中的相同事件也能够很好地识别到，以此来加快强化学习过程的收敛，提升测试的效率。

步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果。我们将静态模型和q-learing算法结合，构建了一套测试工具，取得了不错的测试效果。测试的流程具体包括以下步骤：

步骤51)强化学习q-learning算法中reward的设定和value的更新规则设定。Q-learing算法是一种强化学习算法，利用强化学习算法指导测试过程在许多测试工具中取得了不错的效果，q-learing中q-table结构由state和actiont组成，能够很好地与状态模型契合。q-table由key为state，value为action table的字典组成，action table由key为action，value为action value的字典组成，与原本actiontable储存了当前状态所有的state action，而新增的stateaction的actionvalue会被设定为INITvalue，通过分析nextstate的获取reward，利用q-learning算法对q table也就是被选择的事件value进行更新。强化学习会指导测试不断向reward最大的方向进行，因此reward的设定规则是十分重要的。q-table使用memory保存探索过记录的状态的场景向量，利用LSTM模型判断场景相似度获取reward，相似度越小，说明nextstate发现的页面更加丰富多样，reward越高，反之越低，而reward的值为+-500两种情况。而利用本状态模型，可以通过分析nextstate探索到的新的状态组件和新的事件情况来更加灵活地设定reward，当发现地新的状态组件层级越高reward越高，比如activity一般在顶层，说明相比于之前探索过的状态变化页面变化更大，所以有更高地reward，而对于同等层级我们依据动态组件的类别来获取reward，例如drawer，menuopen组件会相较list更高，因为drawer和menuopen会更多的伴随一些应用的功能切换或者设置信息，会有更高的发现新页面的潜力，因此reward会更高，总之当nextstate出现了新的状态组件那么reward值会在0-500之间。reward的主要依据新增状态组件来获取，而本状态模型是将事件储存在状态组件当中，因此在测试的过程中会伴随同一状态有新事件产生的情况，例如这些新事件可能是list组件新增了条目，也有可能是未匹配上的而被保存在dynamic exploration中的状态组件，也有可能是未保存在静态模型中而被存储在父组件的动态测试过程中的动态组件，因此我们也会依据新事件被保存的组件类型和新事件的数量来设定reward，但由于未产生新的状态组件，因此reward的值在-500-0之间。相比于q-testing，我们对reward的设定会更加依据静态模型产生的新的状态组件来设定，正如之前所说，我们认为新的状态组件的加载往往以为这新的功能场景的加载，而更值得被探索和测试。

步骤52)设定事件的选择算法。按照q-learning算法，选取当前状态action-table中value最高的action作为测试事件，而与q-testing不同的是，由于actiontable保存的是该状态中所有发现过的事件，而当前页面获取的可执行事件也就是pending action为saved action的子集，因此我们依据actiontable选择pendingaction中value最高的action作为测试事件。

步骤53)应用的插桩和覆盖率的获取。通过对应用的apk或者源码进行插桩，通过jacoco工具能够获取到被测试应用的测试覆盖率，当测试到达指定测试事件或者事件数量后，停止测试过程并计算被测应用的测试覆盖率。

以上所述仅为本发明的较佳实施例，但此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。任何熟悉本专业的技术人员，在不脱离本发明的原理和精神的情况下依据本发明的技术实质对以上实施例所做的任何简单修改，等同变化与修饰，均应包含在本发明的保护范围之内。

Claims (6)

1.一种静态分析和动态探索结合的移动应用模型构建方法，其特征在于，包括如下步骤：

步骤1)统计和分析主流的动态组件类型；

步骤2)静态分析应用获取应用基于动态组件的静态模型；

步骤3)动态测试过程中匹配应用的当前状态；

步骤4)构建应用模型状态图；

步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果。

2.根据权利要求1所述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤1)统计和分析主流的动态组件类型，我们阅读移动应用平台的开发文档统计了目前主流的动态组件类型，并分析应用开发代码了解了动态组件的常用加载方式。

3.根据权利要求1所述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤2)静态分析应用获取应用基于动态组件的静态模型具体包括以下步骤：

步骤21)使用apktool和soot工具静态分析apk，得到应用的动态组件信息；

步骤22)利用应用的动态组件信息进行基于动态组件的静态模型构建。

4.根据权利要求1所述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤3)动态测试过程中匹配应用的当前状态具体包括以下步骤：

步骤31)uiautomator工具获取应用当前页面hierarchy信息；

步骤32)通过分析hierarchy信息，与应用的静态模型进行匹配，得到每个动态组件的状态组件，从而得到整体的状态字典；

步骤33)获取事件并存到对应的状态组件当中。

5.根据权利要求1所述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤4)构建应用模型状态图具体包括以下步骤：

步骤41)构建状态图结构；

步骤42)将状态组件中的事件储存到state中；

步骤43)根据测试过程中的事件序列构建应用的状态模型图；

步骤44)利用状态模型进行测试。

6.根据权利要求1所述的基于静态分析和动态探索结合的移动应用模型状态图构建方法，其特征在于，所述步骤5)使用静态模型和状态图，引入强化学习算法指导测试，统计测试覆盖率结果具体包括以下步骤：

步骤51)强化学习q-learning算法中reward的设定和value的更新规则设定；

步骤52)设定事件的选择算法；

步骤53)应用的插桩和覆盖率的获取。

Images