录制测试脚本的方法和装置与流程

本公开总体上涉及移动信息处理设备上运行的移动应用的测试，具体地，涉及一种为移动信息处理设备上运行的移动应用录制测试脚本的方法和装置。

背景技术：

近来，诸如手机、平板计算机等的移动信息处理设备越来越普及。各种各样的移动应用(程序)在这些移动信息处理设备上运行。在应用商店每天都会出现很多新发布的移动应用。为了保证新发布的移动应用的质量，需要在对移动应用的测试上花费很多工作。

移动应用的测试人员已开始使用自动化测试框架来测试移动应用。然而，大多数测试者并不能非常容易地生成测试脚本。

传统的方法中，测试者手工地编写测试代码。这将花费测试者大量的时间去学习脚本编程技术。而且，当测试者想要对新的移动应用进行测试或者对新的功能模块进行测试，他必须花费很多精力来编写新的测试代码，因此效率非常低。

最近，应用遍历测试被提出来用于自动生成脚本，但是效果并不好。

另一方面，脚本录制工具也被提出来用于生成测试脚本。但是当前的录制工具仅仅能够对基本的操作进行录制，而且录制到的信息也不完整。此外，当前录制工具生成的测试脚本的准确率也不高。

技术实现要素：

在下文中将给出关于本公开的简要概述，以便提供关于本公开的某些方面的基本理解。应当理解，此概述并不是关于本公开的穷举性概述。它并不是意图确定本公开的关键或重要部分，也不是意图限定本公开的范围。其目的仅仅是以简化的形式给出某些概念，以此作为稍后论述的更详细描述的前序。

根据本公开的一个方面，提供了为移动信息处理设备上运行的移动应用录制测试脚本的方法，包括：获取在用户操作移动应用期间发生的事件的最终事件流，包括：通过跨进程的事件监测方法获得与操作相关的第一事件流，通过应用注入机制获得与操作相关的第二事件流，通过合并第一事件流和第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得最终事件流。

根据本公开的另一方面，提供了为移动信息处理设备上运行的移动应用录制测试脚本的装置，包括：获取单元，其被配置成获取在用户操作移动应用期间发生的事件的最终事件流；其中，获取在用户操作移动应用期间发生的事件的最终事件流包括：通过跨进程的事件监测方法获得与操作相关的第一事件流，通过应用注入机制获得与操作相关的第二事件流，通过合并第一事件流和第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得最终事件流。

另外，根据本发明的又一方面，还提供了一种存储介质。存储介质中存储有移动信息处理设备可读的程序代码，当在移动信息处理设备上执行程序代码时，程序代码使得移动信息处理设备执行根据本发明的上述方法。

此外，根据本发明的再一方面，还提供了一种程序产品。程序产品包括信息处理设备可执行的指令，当在移动信息处理设备上执行指令时，指令使得移动信息处理设备执行根据本发明的上述方法。

通过根据本发明的脚步录制方法和装置，可以生成准确、有效的测试脚本。

附图说明

本公开可以通过参考下文中结合附图所给出的描述而得到更好的理解，附图连同下面的详细说明一起包含在本说明书中并且形成本说明书的一部分。在附图中：

图1是根据本公开的一个实施例的为移动信息处理设备上运行的移动应用录制测试脚本的方法的示例性流程图；

图2是根据本公开的另一实施例的为移动信息处理设备上运行的移动应用录制测试脚本的方法的示例性流程图；

图3是根据本公开的一个实施例的获取第一事件流的方法的示例性流程图；

图4是根据本公开的一个实施例的重要操作推荐方法的示例性流程图；

图5是根据本公开的一个实施例的操作的层级深度的示意图；

图6是根据本公开的一个实施例的生成用户操作的断言的方法的示例性流程图；

图7是根据本公开的一个实施例的自动生成测试脚本步骤的示例性流程图；

图8是根据本公开的一个实施例的对最终事件流中一个操作生成测试代码的方法的示例性流程图；

图9是根据本公开的一个实施例的测试移动应用的方法的示例性流程图；

图10是根据本公开的一个实施例的为移动信息处理设备上运行的移动应用录制测试脚本的装置的示例性框图；

图11是根据本公开的另一实施例的为移动信息处理设备上运行的移动应用录制测试脚本的装置的示例性框图；以及

图12是根据本公开的一个实施例的用于执行录制测试脚本的方法的设备的示意性结构框图。

具体实施方式

在下文中将结合附图对本公开的示例性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实施例的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中可以做出很多特定于实施例的决定，以便实现开发人员的具体目标，并且这些决定可能会随着实施例的不同而有所改变。

在此，还需要说明的一点是，为了避免因不必要的细节而模糊了本公开，在附图中仅仅示出了与根据本公开的方案密切相关的装置结构，而省略了与本公开关系不大的其他细节。

应理解的是，本公开并不会由于如下参照附图的描述而只限于所描述的实施形式。在本文中，在可行的情况下，实施例可以相互组合、不同实施例之间的特征替换或借用、在一个实施例中省略一个或多个特征。

图1是根据本公开的一个实施例的为移动信息处理设备上运行的移动应用录制测试脚本的方法100的示例性流程图。

在用户操作移动应用期间，用户会进行各种操作。在方法100中，与这些操作相关的事件流通过两种方法被记录，然后两种方法记录的事件流被合并成最终事件流。

具体而言，在步骤101处，启动移动应用。该移动应用是指能够在诸如智能手机的移动信息处理设备上运行的应用程序。

在步骤103处，获取在用户操作移动应用期间发生的事件的最终事件流，该步骤包括以下子步骤：通过跨进程的事件监测方法获得与操作相关的第一事件流，通过应用注入机制获得与操作相关的第二事件流，通过合并第一事件流和第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得所述最终事件流。用两种方式记录事件流，可以获得更丰富的事件信息，弥补单元事件流记录方法的不足，有利于生成更有效的最终事件流。

可选地：应用注入机制不支持跨进程；跨进程的事件监测方法包括uiautomator，应用注入机制包括使用instrumentation。

在步骤105处，自动生成测试脚本。具体是基于步骤103所获取的最终事件流来生成测试脚本。

表1

在用户操作移动应用期间，在录制第一事件流的同时，还同时录制了第二事件流。如表1所示，这两种事件流中的事件有不同的特点，它们各自都有优点和缺点。如表1所示，第一事件流中的事件支持跨进程，但是录制的事件类型不是很完整。第二事件流中的事件不支持跨进程，但是录制的事件类型更加完整。通过比较这两种事件流的时间戳信息，将两者中的发生时间间隔小于预定时间间隔的事件进行合并，从而获取最终事件流。由于这两种方法各自具有不同的特点导致记录的事件流有各自的优点和缺点，合并后事件流可包含更加复杂的操作，可包含的事件类型将更加全面，弥补合并前两个事件流的不足，有利于基于合并事件流生成的测试脚本更加准确和有效，有利于选择合适的测试框架以及回放后的测试结果分析。

例如，传统的移动应用脚本录制方法，录制工具仅仅录制移动应用的事件流。而且它仅仅支持一些基本的操作录制，例如点击，滑动。对于更加复杂的操作，例如手势，它无法支持。此外，它不支持跨进程录制。将事件流转化成测试脚本的时候，准确率很低。而方法100则可以克服上述问题。

图2是根据本公开的另一实施例的为移动信息处理设备上运行的移动应用录制测试脚本的方法200的示例性流程图。

相对于方法100，方法200在步骤203中可以实施多种处理，包括获取最终事件流和记录上下文信息。获取最终事件流、启动移动应用及自动生成测试脚本和方法100中的相同。

对于记录上下文信息，其通过在移动信息处理设备中部署上下文监控服务来实现。在用户操作移动应用期间，上下文监控服务能够实时地监测上下文信息，并实时地记录，即，在多个时刻记录上下文信息以作为要生成的测试脚本的配置信息。其中，可以选择每隔相同时间段记录上下文信息，也可以按预定规则，在多个非规则时刻记录上下文信息。在本文中，上下文信息包括移动信息处理设备的设备信息以及测试环境信息，其中，设备信息包括移动信息处理设备的屏幕尺寸、移动信息处理设备的操作系统的版本和移动信息处理设备的内存配置中的至少一个；测试环境信息包括实时网速、移动信息处理设备的操作系统的语言和移动信息处理设备的实时地理位置中的至少一个。

下文对获取图1、2中的第一事件流的示例性方法进行描述。

图3是根据本公开的一个实施例的获取第一事件流的方法300的示例性流程图。方法300使用有利于丰富记录的事件信息。在步骤301，通过uiautomator获得与操作相关的第三事件流。在步骤303，通过第一命令获得与操作相关的第四事件流。在步骤305，通过合并第三事件流和第四事件流得到第一事件流；其中第四事件流为基于坐标的原始事件流。第一命令可以为adbgetevent命令。

可以通过uiautomator事件流监听器记录与各操作相关的第三事件流。可以通过getevent监听器记录与各操作相关的第四事件流。可以通过instrumentation事件监听器记录与各操作相关的第二事件流。具体而言，在移动信息处理设备中部署了uiautomator录制脚本、instrumentation录制脚本，并启动adbgetevent命令。这里，adbgetevent命令能够监控基于坐标的原始事件流。由于不同的记录机制，uiautomator事件包括自动触发的事件和用户主动操作触发的事件，adb事件则是用户主动操作触发的事件，例如，单击、滑屏。

其中，通过合并第三事件流和第四事件流得到第一事件流可以包括采用以下合并方式中的至少一种合并方式来合并事件：

(1)将发生时刻相邻的第三事件流中的点击事件和第四事件流中的点击事件合并成新的点击事件；

(2)将发生时刻相邻的第三事件流中的点击事件和第四事件流中的点击-拖动事件合并成新的拖动加点击事件；

(3)将发生时刻相邻的第三事件流中的编辑事件和第四事件流中的点击-拖动事件合并成新的编辑事件或者新的拖动加编辑事件；

(4)将发生时刻相邻的第三事件流中的滚动事件和第四事件流中的拖动事件合并成新的滚动事件；

(5)将发生时刻相邻的第三事件流中的滚动事件和第四事件流中的空事件合并成空事件。

对于合并方式5，uiautomator的滚动事件是被移动应用自动触发的，而不是用户操作主动触发的，因此这种事件不被包括在录制的第一事件流中。

因此，获取的第一事件流中已经包括了所有adb事件的信息。

在一个实施例中，获取最终事件流步骤还包括重要操作推荐。例如，使方法100或200进一步包括重要操作推荐。下文将对重要操作推荐进行描述。

当用户在录制测试脚本的时候，他可能不知道哪个操作更加重要。如果他进行了更多的重要操作，那么录制出的测试脚本将会更加有用。为此，当移动应用运行到一页面(当前页面或当前用户界面)时，方法100、200中获取最终事件流步骤还可以包括基于移动应用的当前页面内的各候选操作的重要度得分，向用户推荐对重要度得分最高的前n个候选操作进行操作，n为自然数。

图4是根据本公开的一个实施例的重要操作推荐方法400的示例性流程图。

在步骤401，获取当前候选操作。通常情况下，在当前页面，候选操作有多个。

在步骤403，计算控件特征得分controlfeaturescore、错误率得分bugratescore和层级深度得分leveldepthscore。

对于控件特征得分，可按公式(1)计算。

其中，controlfeaturescroe(opi)是候选操作opi的控件特征得分，j基于的信息的类型(如控件类型、大小、位置信息)的索引，vj是指示j型信息的重要程度的量值，wj是j型信息的权重。权重wj根据经验预先定义，越重要的信息类型则权重越大。信息的值vj，根据经验预先定义的取值规则来确定，若控件类型是常用的(例如按钮)、控件尺寸比较大或控件位置处于屏幕中央，则对应的信息的值vj设置为较高。

对于错误率得分，基于对该移动应用已生成的多个历史测试脚本，对每个候选操作计算它在历史版本中发生错误的概率，如公式(2)所示。

其中，bugratescore(opi)表示候选操作opi的错误率得分，totalscriptnum表示历史版本的总脚本数，count(errorscriptforopi)表示候选操作opi在历史版本中发生的错误脚本数。

这里层级深度的含义可参考图5来理解。图5是根据本公开的一个实施例的操作的层级深度的示意图。对于层级深度得分，基于该候选操作所处的层级深度计算它的层级深度得分，其中，操作的层级深度按照如下方式确定：每个页面有自己的操作树，点击控件会使操作树被更新，导致添加新节点，将根节点的层级深度定义为0，和根节点最近邻的并排的操作的层级深度被定义为1(例如op1-op3)，依照这样的规则，层级深度逐级增加。操作所处的层级越低(即，层级深度大)，则该操作越重要。

其中，leveldepthscore(opi)表示候选操作opi的层级深度得分，leveldepthi表示候选操作opi所处的层级深度，depth表示操作树的总深度。

在步骤405，计算重要度得分。具体而言是为每个候选操作计算出重要度得分importancescore。

importancescore(opi)＝controlfeaturescore(opi)*α+bugratescore(opi)*β+leveldepthscore(opi)*γ(4)

其中，α+β+γ＝1；α、β、γ根据经验来预先设定，importancescore(opi)为候选操作opi的重要度得分。即，各候选操作的重要度得分为各候选操作所操作的控件的控件特征得分、各候选操作的错误率得分和各候选操作的层级深度得分的加权和。

在步骤407，推荐重要操作。即，基于移动应用的当前页面内的各候选操作的重要度得分，向用户推荐对重要度得分最高的前n个候选操作进行操作，n为自然数。从而，用户可以根据推荐的候选操作，选定要测试的操作。

n通过以下规则来选择。为了保证当前界面的测试操作覆盖率，提供一个操作覆盖率阈值th。n/(总的候选操作数目)>th。

在用户录制脚本的过程中，当操作覆盖率(在当前界面内，已进行的操作的数目与总的候选操作数目的比)大于阈值th的时候，则当前界面的录制过程允许被终止。通过这种方法，可以保证录制得到的测试脚本的覆盖率。因此录制出的脚本也将更加有用。

在一个实施例中，获取最终事件流步骤还包括功能验证，即对移动应用的一操作的功能是否正常进行断言。例如，使方法100或200中进一步包括功能验证。下文将对功能验证进行描述。

当用户在录制测试脚本的时候，他需要在脚本中加入一些断言来验证移动应用是否运行正常。本公开的测试脚本录制方法能够基于用户操作自动地生成功能验证断言，其中，功能验证断言包括系统服务断言及操作验证断言。具体而言，获取在用户操作移动应用期间发生的事件的最终事件流还包括：基于操作中的第一操作自动地生成操作验证断言；以及监测移动信息处理设备中的系统弹窗消息，若收到系统弹窗消息，则对系统弹窗消息自动生成系统服务断言。并且系统服务断言及操作验证断言(统称验证断言)将被包括在测试脚本中。

图6是根据本公开的一个实施例的生成操作验证断言的方法600示例性流程图。在步骤601，用户执行一操作(可以是根据操作的重要度得分而被推荐的操作)。在步骤603，分析用户界面操作树。在步骤605，计算此次该操作的哈希值作为第二哈希值ht。在步骤607，判断h0是否为0，其中，h0表示该操作上次被执行时所计算得到的哈希值，h0的初始值为零，即在该操作未被执行过时，h0为零。若h0为零，即步骤607的判断结果为“是”，进行步骤613，将ht的值赋值给h0，即更新h0。若h0不为零，即步骤607的判断结果为“否”(该操作被执行了至少2次，已经存在一个旧的哈希值)，则进行步骤609。在步骤609，确定ht和h0是否相等，即确定哈希值是否发生了改变，若不相等，则说明当前操作的用户界面属性已经发生了变化，进行步骤611。在步骤611，自动生成断言。

例如，当用户第一次在首页的时候，页面内有文本“hello”，然后第二次到达首页的时候，该文本变成了“helloworld”。于是，自动对文本“helloworld”进行断言。在回放测试脚本时，若用户执行了相同操作，而未出现文本“helloworld”，则在错误日志中记录该错误(即，断言错误)。

本发明的实施例还可以包括对自动生成测试脚本进行的改进。在下文中将对自动生成测试脚本的示例性实施方式进行描述。

在生成最终事件流之后，需要根据最终事件流，或最终事件流和上下文信息，或最终事件流、上下文信息和验证断言、或最终事件流和验证断言自动生成测试脚本。在生成测试脚本时使用了上下文信息的情况下，生成的测试脚本包括：使用上下文信息来配置另一移动信息处理设备(即，回放测试脚本时被测试的移动信息处理设备)的指令。其中，可以只使用一部分上下文信息来配置该另一移动信息处理设备，优选，在可能的情况下，使用尽可能多的上下文信息来配置另一移动信息处理设备。

如图7所示，在本发明一个实施例中，自动生成测试脚本步骤包括两个子步骤：框架推荐步骤701和代码生成步骤703。

在框架推荐步骤701中，基于各测试框架对最终事件流的框架适配度得分，将具有最高框架适配度得分的测试框架推荐给用户。

下面介绍框架适配度得分的确定方法。

将最终事件流和操作定义分别定义为公式(5)和公式(6)。这里操作的特征的类型可以更多或更少，公式(6)仅为示例。

eventflow＝(op1,op2,op3,......)(5)

opi＝(idi,typei,texti,coordinatei,xpathi)(6)

其中，coordinate表示操作所对应的坐标。

然后，取得操作的特征的权重。表2给出了一种示例性的权重设置方式。

表2

按公式(7)，对于操作的每个特征，计算特征对各框架(即，测试框架)的特征适配度得分。

其中，k是候选框架的索引，i是操作opj的特征索引，若按表2选用特征，则i取1至4。公式(7)给出了操作opj的特征featurei对框架k的特征适配度得分。

计算各个操作对各框架的操作适配度得分。

公式(8)给出了操作opj对框架k的操作适配度得分。可见，操作适配对度得分为操作的各特征关于相应测试框架的特征适配度得分的加权和。

按公式(9)计算最终事件流对各框架的框架适配度得分。

其中，若取用表2中给出的4种框架，则k可以取1至4；若最终事件流eventflow中有30个操作，则j取1至30。公式(9)给出了最终事件流对框架k的框架适配度得分。可见，各测试框架对最终事件流的框架适配度得分为相应测试框架对最终事件流中的各操作的操作适配得分的和。

最后，根据计算出的框架适配度得分，将具有最高框架适配度得分的测试框架推荐给用户。用户可以选择该推荐的测试框架、选择其他测试框架、或调整候选测试框架后重新计算框架适配度得分。

选定测试测试框架后，就可以进行测试脚本的代码生成步骤703。

在本发明的一个实施例中，代码生成步骤703包括：对于最终事件流中的操作，过滤掉那些不被所选定的测试框架支持的特征，将剩下的特征按照权重进行降序排序，对每个剩下的特征进行逐个检测，直到匹配该特征的值的控件个数为1，使用该特征定位控件，并且基于该操作生成测试代码。

图8是根据本公开的一个实施例的对最终事件流中一个操作生成测试代码的方法的示例性流程图。

在步骤801，滤除不被支持的特征，具体而言：对于最终事件流中的一个操作，分析该操作的所有特征，例如id，text，xpath，过滤掉那些不被测试框架支持的特征。例如，若选择了uiautomator测试框架，它不支持xpath特征，则通过过滤，保留了id和text特征。

在步骤803，将剩下的特征按照权重进行降序排序。设剩下的特征的总数为n。

在步骤805，设定i＝1，其中i表示要用于定位控件的特征的索引。可见，i的可能的最大取值为n。

在步骤807，设定当前特征为fi。具体而言，在剩下的特征(进行过滤后剩下的且未进行过定位检测的特征)中，选择权重最高的特征以进行定位检测。

在步骤809，进行检测，确定当前特征是否能准确地定位操作所对应的控件。若确定结果为否，则进行步骤813；若确定结果为是，则进行至步骤811，使用当前特征定位控件，并且基于该操作生成测试代码。例如，如果当前用户界面拥有id为“com.fujitsu.app:button1”的控件个数多于1个，则该特征不能用于定位控件，于是尝试第二个特征text。直到匹配特征值的控件个数有且仅有1个的时候，则使用该特征定位控件，并基于该操作生成测试代码。

在步骤813，i增加1。

在步骤815，判断i是否等于n+1。若判断结果为“是”，则方法800结束，即未对当前操作生成测试代码。若判断结果为“否”，则进行步骤807。需要说明的是：大部分情况下，都能找到该操作的能够准确定位控件的特征，因此会生成该操作的测试代码；但为了逻辑的严密性，设置了i＝n+1时，方法800结束的逻辑，以防止出现极个别的例外情况。当然，可选的，也可以在i＝n+1时，提示用户，由用户作出处理，如用户根据实际情况，手动输入合适的测试代码。

对每个操作都使用这种方法800，以根据最终事件流生成测试脚本代码。

上述脚本录制方法的实施例可以进行组合。例如，本发明的一个脚本录制方案除了事件流录制、合并，还包括上下文记录、重要操作推荐和功能验证。

在录制好测试脚本后，就可以在其它移动信息处理设备上回放该测试脚本，来验证移动应用是否能正常运行、查找移动应用的缺陷。

图9是根据本公开的一个实施例的测试移动应用的方法900的示例性流程图。

在步骤901，录制测试脚本。该步骤可以使用图1或图2所示的方法100或200来实现。

在步骤903，回放测试脚本以获得测试日志。当测试脚本中包含了上下文信息时，在该步骤除了回放最终事件流，还包括使用上下文信息配置移动信息处理设备。配置时，应保证上下文信息和操作的对应关系。这样，回放的环境能够和录制环境更加贴近，回放的效果也会更好。若测试脚本中含功能验证语句，则回放过中，还会进行功能验证。

测试结束后，可以通过测试日志分析测试结果。测试结果中包括错误位置，错误路径和错误原因。错误日志中将错误原因分为4种类型，分别是断言错误、测试框架错误、上下文不一致导致的错误和用户界面不一致导致的错误。

图10是根据本公开的一个实施例的为移动信息处理设备上运行的移动应用录制测试脚本的装置1000的示例性框图。

装置1000包括获取单元1001，其被配置成获取在用户操作所述移动应用期间发生的事件的最终事件流；其中，获取在用户操作移动应用期间发生的事件的最终事件流包括：通过跨进程的事件监测方法获得与操作相关的第一事件流，通过应用注入机制获得与操作相关的第二事件流，通过合并第一事件流和第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得最终事件流。

装置1000还包括生成单元1003，其被配置成基于所获得的最终事件流自动生成所述测试脚本。

获取单元1001、生成单元1003的进一步的配置情况可参照图1中方法100设置。

图11是根据本公开的另一实施例的为移动信息处理设备上运行的移动应用录制测试脚本的装置1200的示例性框图。

装置1100包括：获取单元1101、生成单元1103以及上下文记录单元1105，其中，获取单元1101包括：操作推荐单元11011、事件流录制单元11013、功能验证单元11015、合并单元11017。生成单元1103包括框架推荐单元11031和代码生成单元11033。获取单元1101被配置成执行图2中的获取最终事件流的步骤。生成单元1103被配置成执行图2中的生成测试脚本的步骤。上下文记录单元1105被配置成执行图2中的生成记录上下文信息的步骤。操作推荐单元11011被配置成执行图4中的方法400。事件流录制单元11013被配置成录制图1、2、4中的第二事件流、第三事件流和第四事件流。合并单元11017被配置成合并图3中的第三事件流和第四事件流以得到第一事件流，以及合并第一事件流和第二事件流获得最终事件流。功能验证单元11015被配置成执行图6中的方法600，以及监测移动信息处理设备中的系统弹窗消息，若收到系统弹窗消息，则对系统弹窗消息自动生成系统服务断言。框架推荐单元11031被配置成执行图7中的步骤701。代码生成单元11033被配置成执行图7中的步骤703。

图12是根据本公开的一个实施例的用于执行录制测试脚本的方法的设备1200的示意性结构框图。在图12中，中央处理单元(cpu)1201根据存储在只读存储器(rom)1202中的程序或从存储部分1208加载到随机存取存储器(ram)1203的程序来进行各种处理。在ram1203中，也根据需要来存储在cpu1201执行各种处理时所需的数据等。

cpu1201、rom1202以及ram1203经由总线1204彼此连接。输入/输出接口1205也连接至总线1204。

下述部件连接至输入/输出接口1205：包括软键盘等的输入部分1206；包括诸如液晶显示器(lcd)等的显示器以及扬声器等的输出部分1207；包括硬盘等的存储部分1208；以及包括网络接口卡如lan卡、调制解调器等的通信部分1209。通信部分1209经由诸如英特网、局域网的网络执行通信处理。

驱动器1210根据需要也连接至输入/输出接口1205。可拆卸介质1211如半导体存储器等根据需要安装在驱动器1210上，使得从其中读取的计算机程序根据需要被安装到存储部分1208。

在通过软件来实现上述录制测试脚本的方法的情况下，构成该软件的程序从网络如因特网或存储介质如可拆卸介质1211被存储在设备1200中。cpu1201执行该录制测试脚本的方法。

在一个实施例中，本公开内容还提供一种程序产品。程序产品包括机器可执行的指令，当在移动信息处理设备上执行指令时，指令使得移动信息处理设备执行录制测试脚本的方法。

在一个实施例中，本公开内容还提供一种存储介质。存储介质中存储有移动信息处理设备可读的程序代码，当在移动信息处理设备上执行程序代码时，程序代码使得移动信息处理设备执行上述录制测试脚本的方法。存储介质包括但不限于软盘、光盘、磁光盘、存储卡、存储棒等。

当上述录制测试脚本的方法为软件时，可以将移动信息处理设备和通用计算机连接，在通用计算机侧通过接口软件启动移动信息处理设备上该录制测试脚本软件、操控该录制测试脚本软件，完成测试脚本的录制。

本发明所公开的录制测试脚本的方法、装置至少具有以下有益效果之一：自动生成测试脚本；测试脚本中包括自动生成的功能验证断言；能够推荐重要操作，从而提高测试效率、效果；能够推荐测试框架；测试脚本准确、有效、全面；有利于发现移动应用的潜在缺陷。

尽管上面已经通过对本发明的具体实施例的描述对本发明进行了披露，但是，应该理解，本领域的技术人员可在所附权利要求的精神和范围内设计对本发明的各种修改(包括在行的情况下，各实施例之间特征的组合或替换)、改进或者等同物。这些修改、改进或者等同物也应当被认为包括在本发明的保护范围内。

应该强调，术语“包括/包含”在本文使用时指特征、要素、步骤或组件的存在，但并不排除一个或更多个其它特征、要素、步骤或组件的存在或附加。

此外，本发明的各实施例的方法不限于按照说明书中描述的或者附图中示出的时间顺序来执行，也可以按照其他的时间顺序、并行地或独立地执行。因此，本说明书中描述的方法的执行顺序不对本发明的技术范围构成限制。

附记

1.一种为移动信息处理设备上运行的移动应用录制测试脚本的方法，包括：

获取在用户操作所述移动应用期间发生的事件的最终事件流，包括：

通过跨进程的事件监测方法获得与所述操作相关的第一事件流，通过应用注入机制获得与所述操作相关的第二事件流，通过合并所述第一事件流和所述第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得所述最终事件流。

2.根据附记1所述的方法，还包括：

在所述用户操作所述移动应用期间，在多个时刻记录上下文信息以作为所述测试脚本的配置信息。

3.根据附记2所述的方法，其中，所述上下文信息包括所述移动信息处理设备的设备信息以及测试环境信息。

4.根据附记3所述的方法，其中，所述设备信息包括所述移动信息处理设备的屏幕尺寸、所述移动信息处理设备的操作系统的版本和所述移动信息处理设备的内存配置中的至少一个。

5.根据附记1所述的方法，其中，获取在用户操作所述移动应用期间发生的事件的最终事件流还包括：

基于所述移动应用的当前页面内的各候选操作的重要度得分，向所述用户推荐对重要度得分最高的前n个候选操作进行操作，其中，n为自然数。

6.根据附记5所述的方法，其中，各候选操作的重要度得分为各候选操作所操作的控件的控件特征得分、各候选操作的错误率得分和各候选操作的层级深度得分的加权和。

7.根据附记6所述的方法，其中，各候选操作的错误率得分为各候选操作在多次历史测试中发生错误的概率。

8.根据附记6所述的方法，其中，各候选操作所处的层级越低，则该候选操作的层级深度得分越高。

9.根据附记1所述的方法，其中，所述跨进程的事件监测方法包括uiautomator，所述应用注入机制包括使用instrumentation。

10.根据附记9所述的方法，其中，通过跨进程的事件监测方法获得与所述操作相关的第一事件流包括：通过uiautomator获得与所述操作相关的第三事件流，通过第一命令获得与所述操作相关的第四事件流，以及通过合并所述第三事件流和所述第四事件流得到所述第一事件流；其中第四事件流为基于坐标的原始事件流。

11.根据附记10所述的方法，其中，所述第一命令为adbgetevent命令。

12.根据附记11所述的方法，其中，通过合并所述第三事件流和所述第四事件流得到所述第一事件流包括采用以下合并方式中的至少一种合并方式来合并事件：

将发生时刻相邻的所述第三事件流中的点击事件和所述第四事件流中的点击事件合并成新的点击事件；

将发生时刻相邻的所述第三事件流中的点击事件和所述第四事件流中的点击-拖动事件合并成新的拖动加点击事件；

将发生时刻相邻的所述第三事件流中的编辑事件和所述第四事件流中的点击-拖动事件合并成新的编辑事件或者新的拖动加编辑事件；

将发生时刻相邻的所述第三事件流中的滚动事件和所述第四事件流中的拖动事件合并成新的滚动事件；

将发生时刻相邻的所述第三事件流中的滚动事件和所述第四事件流中的空事件合并成空事件。

13.根据附记1所述的方法，其中，获取在所述用户操作所述移动应用期间发生的事件的最终事件流还包括：基于所述操作中的第一操作自动地生成操作验证断言；

所述方法还包括自动生成所述测试脚本，其中，所述测试脚本中包括所述操作验证断言。

14.根据附记13所述的方法，其中，基于所述第一操作自动地生成功能验证断言包括：

当所述用户执行第二次执行所述第一操作时，实时分析ui操作树结构，计算第二次执行的所述第一操作的第二哈希值，比较所述第二哈希值和第一次执行所述第一操作时的第一哈希值，若所述第一哈希值和所述第二哈希值不同，则基于当前ui和所述第一操作所针对的控件的图像自动生成断言。

15.根据附记1所述的方法，其中，获取在所述用户操作所述移动应用期间发生的事件的最终事件流还包括：监测所述移动信息处理设备中的系统弹窗消息，若收到所述系统弹窗消息，则对所述系统弹窗消息自动生成系统服务断言；

所述方法还包括自动生成所述测试脚本，其中，所述测试脚本中包括所述系统服务断言。

16.根据附记1所述的方法，还包括：

基于所述最终事件流自动生成所述测试脚本；

其中，基于所述最终事件流自动生成所述测试脚本包括：

基于各测试框架对所述最终事件流的框架适配度得分，将具有最高框架适配度得分的测试框架推荐给所述用户。

17.根据附记16所述的方法，其中，各测试框架对所述最终事件流的框架适配度得分为相应测试框架对所述最终事件流中的各操作的操作适配度得分的和，所述操作适配度得分为所述操作的各特征关于相应测试框架的特征适配度得分的加权和。

18.根据附记16所述的方法，其中，基于所述最终事件流自动生成所述测试脚本包括：

对于所述最终事件流中的操作，过滤掉那些不被所选定的测试框架支持的特征，将剩下的特征按照权重进行降序排序，对每个剩下的特征进行逐个检测，直到匹配该特征的值的控件个数为1，使用该特征定位控件，并且基于该操作生成测试代码。

19.一种为移动信息处理设备上运行的移动应用录制测试脚本的装置，包括：

获取单元，其被配置成获取在用户操作所述移动应用期间发生的事件的最终事件流；

其中，获取在用户操作所述移动应用期间发生的事件的最终事件流包括：

通过跨进程的事件监测方法获得与所述操作相关的第一事件流，通过应用注入机制获得与所述操作相关的第二事件流，通过合并所述第一事件流和所述第二事件流中发生时间间隔小于预定时间间隔的事件，从而获得所述最终事件流。

20.一种测试移动应用的方法，包括：

使用前述附记2-4之一所述的方法生成所述测试脚本；以及

执行所述测试脚本以获得测试日志；

其中，执行所述测试脚本包括：

使用所述上下文信息来配置另一移动信息处理设备；以及

回放所述最终事件流。