CN108509348A - 一种系统老化的测试方法及移动终端 - Google Patents

Abstract

本发明公开了一种系统老化的测试方法及移动终端，该移动终端中存储有一个或多个测试脚本，每个测试脚本包括一个或多个模拟用户操作的执行动作，该方法包括：根据预设的老化测试时间和脚本总执行时间，确定系统老化的测试次数；按照测试次数，运行各测试脚本，测试脚本适于在运行时执行其所包括的执行动作；对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息；对该测试脚本的每一次运行过程，根据该次运行过程中各执行动作的操作信息，生成该测试脚本该次运行时的性能指标；结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势。

Description

一种系统老化的测试方法及移动终端

技术领域

本发明涉及自动化测试领域，特别涉及一种系统老化的测试方法及移动终端。

背景技术

随着移动通信技术的不断发展，以智能手机为典型的移动终端得到大规模推广，移动终端系统的质量越来越受到关注。比如对智能手机来说，当其使用时间较长后，卡顿现象就容易出现，即用户口中的“变卡”。传统的老化测试更多是在于硬件层面的老化，比如屏幕、电池等，这种硬件的老化在高温、高压、高湿度环境下进行，注重的是硬件的老化问题，但手机系统的老化是不一样的软件层老化问题。

目前，测试系统是否老化的方法通常是先使用比较简单的数据填充，然后测试应用启动速度或利用点击、滑动的单一动作性能来进行老化测试。这一测试方法在处理上较为粗略，测试场景与用户实际使用场景不太相同，衡量系统老化的指标单一，说服力不够，且在对老化判断时并不科学准确。比如，测试启动速度时，观察是否变差只是从线性角度，如变大或变小这样的维度出发，而忽略了本身每次启动应用时，其启动速度是有一定波动范围，而且启动的次数对这种波动和线性的对比影响很大。

发明内容

为此，本发明提供一种系统老化的测试方案，以力图解决或者至少缓解上面存在的问题。

根据本发明的一个方面，提供一种系统老化的测试方法，适于在移动终端中执行，移动终端中存储有一个或多个测试脚本，每个测试脚本包括一个或多个模拟用户操作的执行动作，该方法包括如下步骤：首先，根据预设的老化测试时间和脚本总执行时间，确定系统老化的测试次数；按照测试次数，运行各测试脚本，测试脚本适于在运行时执行其所包括的执行动作；对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息；对该测试脚本的每一次运行过程，根据该次运行过程中各执行动作的操作信息，生成该测试脚本该次运行时的性能指标；结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势。

可选地，在根据本发明的系统老化的测试方法中，脚本总执行时间为将所有测试脚本执行一次所耗时间的总和。

可选地，在根据本发明的系统老化的测试方法中，操作信息包括动作相关时间和动作内容。

可选地，在根据本发明的系统老化的测试方法中，性能指标包括应用启动耗时、应用退出耗时、画面流畅度、帧率、CPU占用率和垃圾回收率中的至少一个。

可选地，在根据本发明的系统老化的测试方法中，结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势的步骤包括：基于时间序列分析方法对该测试脚本每次运行时的性能指标进行分析；若分析结果指示无明显变化趋势，则确定移动终端的系统未出现该测试脚本对应的老化趋势；若分析结果指示出现增速趋势，则确定移动终端的系统已出现该测试脚本对应的老化趋势。

可选地，在根据本发明的系统老化的测试方法中，时间序列分析方法为Mann-Kendall趋势检验法。

可选地，在根据本发明的系统老化的测试方法中，还包括：根据预先生成的一个或多个系统测试场景，编写相应测试脚本。

可选地，在根据本发明的系统老化的测试方法中，系统测试场景包括用户常用场景和卡顿易发场景。

可选地，在根据本发明的系统老化的测试方法中，还包括预先生成系统测试场景，预先生成系统测试场景的步骤包括：根据用户调研情况生成用户常用场景，用户调研情况包括用户在预定时间段内使用移动终端的时间、使用移动终端中所安装应用的名称及时间、操作习惯和充电间隔；根据售后反馈情况生成卡顿易发场景，售后反馈情况包括出现卡顿时使用的应用、对应操作、时间、卡顿持续时长和卡顿发生频率。

可选地，在根据本发明的系统老化的测试方法中，在按照测试次数，运行各测试脚本的步骤之前，还包括：对移动终端进行测试数据填充，测试数据包括联系人、短信、相册图片、视频和音乐。

根据本发明的又一个方面，提供一种移动终端，包括一个或多个处理器、存储器以及一个或多个程序，其中一个或多个程序存储在存储器中并被配置为由一个或多个处理器执行，一个或多个程序包括用于执行根据本发明的系统老化的测试方法的指令。

根据本发明的又一个方面，提供一种存储一个或多个程序的计算机可读存储介质，一个或多个程序包括指令，指令当由移动终端执行时，使得移动终端执行根据本发明的系统老化的测试方法。

根据本发明的系统老化的测试方法，按照系统老化的测试次数运行各测试脚本，对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息，根据每次运行过程中各执行动作的操作信息，相应生成该测试脚本每次运行时的性能指标后进行结合分析，最后根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势。在上述方案中，分析性能指标时，是基于时间序列分析方法，如Mann-Kendall趋势检验法来完成的，从而确定该性能指标的变化是自然波动还是呈现出一种变差的趋势，保证了分析结果的科学性和准确性，解决了过程性问题而非只关注于结果性。此外，在生成测试脚本时，利用包含有用户常用场景和卡顿易发场景的系统测试场景来进行测试脚本的编写，以提供多样化且符合用户使用习惯的测试用例，并且将联系人、短信、相册图片、视频和音乐一类的测试数据预先填充到移动终端中，以便测试脚本执行时能够真正模拟出用户的行为，进而提升测试的有效性和可靠性。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了根据本发明的一个实施例的移动终端100的示意图；以及

图2示出了根据本发明的一个实施例的系统老化的测试方法200的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1是移动终端100的结构框图。移动终端100可以包括存储器接口102、一个或多个数据处理器、图像处理器和/或中央处理单元104，以及外围接口106。

存储器接口102、一个或多个处理器104和/或外围接口106既可以是分立元件，也可以集成在一个或多个集成电路中。在移动终端100中，各种元件可以通过一条或多条通信总线或信号线来耦合。传感器、设备和子系统可以耦合到外围接口106，以便帮助实现多种功能。

例如，运动传感器110、光线传感器112和距离传感器114可以耦合到外围接口106，以方便定向、照明和测距等功能。其他传感器116同样可以与外围接口106相连，例如定位系统(例如GPS接收机)、温度传感器、生物测定传感器或其他感测设备，由此可以帮助实施相关的功能。

相机子系统120和光学传感器122可以用于方便诸如记录照片和视频剪辑的相机功能的实现，其中所述相机子系统和光学传感器例如可以是电荷耦合器件(CCD)或互补金属氧化物半导体(CMOS)光学传感器。可以通过一个或多个无线通信子系统124来帮助实现通信功能，其中无线通信子系统可以包括射频接收机和发射机和/或光(例如红外)接收机和发射机。无线通信子系统124的特定设计和实施方式可以取决于移动终端100所支持的一个或多个通信网络。例如，移动终端100可以包括被设计成支持LTE、3G、GSM网络、GPRS网络、EDGE网络、Wi-Fi或WiMax网络以及Bluebooth^TM网络的通信子系统124。

音频子系统126可以与扬声器128以及麦克风130相耦合，以便帮助实施启用语音的功能，例如语音识别、语音复制、数字记录和电话功能。I/O子系统140可以包括触摸屏控制器142和/或一个或多个其他输入控制器144。触摸屏控制器142可以耦合到触摸屏146。举例来说，该触摸屏146和触摸屏控制器142可以使用多种触摸感测技术中的任何一种来检测与之进行的接触和移动或是暂停，其中感测技术包括但不局限于电容性、电阻性、红外和表面声波技术。一个或多个其他输入控制器144可以耦合到其他输入/控制设备148，例如一个或多个按钮、摇杆开关、拇指旋轮、红外端口、USB端口、和/或指示笔之类的指点设备。所述一个或多个按钮(未显示)可以包括用于控制扬声器128和/或麦克风130音量的向上/向下按钮。

存储器接口102可以与存储器150相耦合。该存储器150可以包括高速随机存取存储器和/或非易失性存储器，例如一个或多个磁盘存储设备，一个或多个光学存储设备，和/或闪存存储器(例如NAND，NOR)。存储器150可以存储操作系统172，例如Android、iOS或是Windows Phone之类的操作系统。该操作系统172可以包括用于处理基本系统服务以及执行依赖于硬件的任务的指令。存储器150还可以存储程序174。在移动设备运行时，会从存储器150中加载操作系统172，并且由处理器104执行。程序174在运行时，也会从存储器150中加载，并由处理器104执行。程序174运行在操作系统之上，利用操作系统以及底层硬件提供的接口实现各种用户期望的功能，如即时通信、网页浏览、图片管理等。程序174可以是独立于操作系统提供的，也可以是操作系统自带的。另外，程序174被安装到移动终端100中时，也可以向操作系统添加驱动模块。在一些实施例中，移动终端100被配置为执行根据本发明的系统老化的测试方法。其中，移动终端100的一个或多个程序174包括用于执行根据本发明的系统老化的测试方法200的指令。

图2示出了根据本发明一个实施例的系统老化的测试方法200的流程图。系统老化的测试方法200适于在移动终端(例如图1所示的移动终端100)中执行，移动终端100中存储有一个或多个测试脚本，每个测试脚本包括一个或多个模拟用户操作的执行动作。具体的，这一个或多个测试脚本可存储于移动终端100的存储器150中。测试脚本通常是预先根据系统测试场景编写生成的，关于这一处理过程，后续将予以说明，此处暂且不表。

方法200始于步骤S210，在步骤S210中，根据预设的老化测试时间和脚本总执行时间，确定系统老化的测试次数。其中，脚本总执行时间为将所有测试脚本执行一次所耗时间的总和。根据本发明的一个实施例，移动终端100中存储有5个测试脚本，依次记为测试脚本A、测试脚本B、测试脚本C、测试脚本D和测试脚本E，将这5个测试脚本执行一次所耗时间的总和为3小时，而老化测试时间预设为3天，即72小时。由系统老化的测试次数＝老化测试时间/脚本总执行时间可知，在该实施方式中，系统老化的测试次数为72/3＝24，表明总共执行老化测试24次，每次都将这5个测试脚本运行一遍。对每一次的运行过程，各测试脚本的操作步骤是一样的，这样测试结果就具有了对比性，便于进行指标分析。

随后，进入步骤S220，按照测试次数，运行各测试脚本，测试脚本适于在运行时执行其所包括的执行动作。根据本发明的一个实施例，依次运行测试脚本A～E，完成后再次运行测试脚本A～E，直至运行次数达到测试次数为止，即运行测试脚本A～E共计24次。

接下来，在步骤S230中，对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息。其中，操作信息包括动作相关时间和动作内容。根据本发明的一个实施例，执行动作通常是模拟用户行为的操作动作，比如点击、滑动等操作，具体来说，可以理解成如在系统桌面上点击一个应用图标这一类的行为，这样的行为实际上就是执行动作的动作内容，而行为发生的时间则是执行动作的动作执行时间点，行为从发生到完成的时长是执行动作的动作执行耗时，动作执行时间点和动作执行耗时构成了执行动作的动作相关时间，动作相关时间和动作内容两者共同属于执行动作的操作信息。

在该实施方式中，通过对自动化工具的二次封装，在封装的方法中嵌入输出操作的log(日志文件)以达到记录测试脚本中各执行动作的操作信息。例如，测试脚本A是通过遍历打开移动终端100中安装的所有应用，从而获取各应用启动的时间，以打开“相机”这个应用为例，其对应的脚本语句如下：

auto.openApp(”相机”)

此时，第1次运行测试脚本A，则该脚本语句对应的记录步骤log是：

2018-04-29 09:47:50.140(2)tag:Auto data:打开应用：相机(耗时：ThisTime:763ms TotalTime:ms WaitTime:97ms)

从上述log可知，打开“相机”这一执行动作的动作内容为点击“相机”图标将其启动，而动作相关时间中的动作执行时间点为2018年4月29日上午9点47分50秒140毫秒，动作执行耗时则为763毫秒。监控测试脚本运行过程的关键性代码如下所示：

def monitoring_performance(deviceid):

testdate＝time.strftime('％Y.％m.％d_％H.％M',time.localtime(time.time()))

sheet_name＝testdate

while True:

#监控实时输出的log,判断是否出现卡顿

p＝subprocess.Popen('adb-s'+deviceid+'logcat',stdin＝subprocess.PIPE,stdout＝subprocess.PIPE,stderr＝subprocess.PIPE,shell＝True)

……

#将log中应用启动时间抓取处理

def filter_launch_time(out_log):

if'ActivityManager:Displayed'in out_log:

MyUtil.writeToFile("AllLaunchTime.txt",out_log)

activity_name＝out_log[out_log.find('Displayed')+10:]

activity_name＝activity_name[:activity_name.find(':+')]

launch_time＝out_log[out_log.find(':+')+3:out_log.find('ms')]

MyUtil.writeToFile('launcher//'+activity_name.replace('/','1'),launch_time)

之所以对测试脚本中的各执行动作进行详细的操作信息记录，是为了方便进行溯源处理，一旦出现问题，就可以根据动作执行时间点来确定当时操作的步骤，比如2018年4月30日上午10点12分33秒160毫秒发现有卡顿，那么必须知道这一时间点是发送短消息、拍照还是在看视频或是其他动作，以便下一步的分析处理。

在步骤S240中，对该测试脚本的每一次运行过程，根据该次运行过程中各执行动作的操作信息，生成该测试脚本该次运行时的性能指标。其中，性能指标包括应用启动耗时、应用退出耗时、画面流畅度、帧率、CPU占用率和垃圾回收率中的至少一个。应用启动耗时为应用启动所花费的时间，一般以应用启动耗时的长短来评判应用启动速度的快慢，对Android系统来说，可以通过读取应用的Activity组件的启动时间来确定该应用的应用启动耗时。应用退出耗时则为应用退出所花费的时间，画面流畅度以跳帧来衡量，跳帧也称为丢帧，当屏幕显示器的刷新率跟不上应用，如游戏应用之类的帧率时，只能舍弃一部分画面，这种现象就是跳帧，因此跳帧越大，画面流畅度越差。

帧率是用于测量显示帧数的量度，在移动终端中显卡的处理能力范围内，帧率越大，系统画面越逼真，性能越好。CPU(Central Processing Unit，中央处理器)占用率又称CPU使用率，为当前运行的应用占用的CPU资源，表示移动终端在某个时间点的运行应用的情况，CPU占用率越高，说移动终端在这个时间点上运行的应用越多，但过高的CPU占有率则可能表明系统的承载能力存在问题，表征出老化现象。而垃圾回收(GC，GarbageCollection)率包括垃圾回收频率和消耗在垃圾回收上的时间，可反映出当前内存使用情况，当内存抖动或泄漏时都会导致垃圾回收率的上升，当上升到一定限度时，则会表现出相应的系统老化特征。需要说明的是，对于性能指标的设定，并不限于上述内容，还可以根据实际情况、具体应用场景、系统配置和性能要求等进行适当调整，这些对于了解本发明方案的技术人员来说是可以容易想到的，并且也在本发明的保护范围之内，此处不予以赘述。

根据本发明的一个实施例，对测试脚本A而言，其性能指标以应用启动耗时来衡量。对测试脚本A的每一次运行过程，根据该次运行过程中各执行动作的动作执行耗时，生成测试脚本A该次运行时所启动的各应用的应用启动耗时。在该实施方式中，应用的应用启动耗时即为实现该应用启动的执行动作的动作执行耗时，而测试脚本A共运行了24次，移动终端100中总共安装有10个应用，以其中之一的“相机”应用为例，启动24次对应的应用启动耗时依次为763毫秒、767毫秒、768毫秒、764毫秒、854毫秒、865毫秒、858毫秒、739毫秒、843毫秒、906毫秒、750毫秒、924毫秒、854毫秒、860毫秒、848毫秒、848毫秒、742毫秒、840毫秒、830毫秒、763毫秒、857毫秒、769毫秒、859毫秒和989毫秒。

最后，执行步骤S250，结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势。根据本发明的一个实施例，可通过如下方式来确定移动终端的系统是否出现该测试脚本对应的老化趋势。首先，基于时间序列分析方法对该测试脚本每次运行时的性能指标进行分析，若分析结果指示无明显变化趋势，则确定移动终端的系统未出现该测试脚本对应的老化趋势，若分析结果指示出现增速趋势，则确定移动终端的系统已出现该测试脚本对应的老化趋势。在该实施方式中，时间序列分析方法为Mann-Kendall趋势检验法。

由于得到的性能指标在分布形态上无法做出简单的假设，且呈现一种随机性，还有突变的可能，偶尔还有可能没有采集到数据，使得性能指标本身具有一定的不确定性，则在整个时间序列分析中，也无法确实是否是一种线性趋势，所以选择使用非参数检验的Mann-Kendall分析方法，以保证了趋势结果的科学性。Mann-Kendall趋势检验法的关键性代码如下所示：

def mk_test(x,alpha＝0.05):

n＝len(x)

#calculate S

s＝0

for k in range(n-1):

for j in range(k+1,n):

s+＝np.sign(x[j]-x[k])

#calculate the unique data

unique_x＝np.unique(x)

g＝len(unique_x)

#calculate the var(s)

if n＝＝g:#there is no tie

var_s＝(n*(n-1)*(2*n+5))/18

else:#there are some ties in data

tp＝np.zeros(unique_x.shape)

for i in range(len(unique_x)):

tp[i]＝sum(x＝＝unique_x[i])

var_s＝(n*(n-1)*(2*n+5)-np.sum(tp*(tp-1)*(2*tp+5)))/18

if s>0:

z＝(s-1)/np.sqrt(var_s)

elif s＝＝0:

z＝0

elif s<0:

z＝(s+1)/np.sqrt(var_s)

#calculate the p_value

p＝2*(1-norm.cdf(abs(z)))#two tail test

h＝abs(z)>norm.ppf(1-alpha/2)

if(z<0)and h:

trend＝'decreasing'

elif(z>0)and h:

trend＝'increasing'

else:

trend＝'no trend'

return trend,h,p,z

具体的，对测试脚本A所关联的10个应用中的每个应用，将该应用启动24次对应的应用启动耗时，作为上述Mann-Kendall趋势检验法的关键性代码的输入数据mk_test中的x，以进行趋势分析。这里以“相机”应用启动24次对应的应用启动耗时作为输入数据mk_test中的x，得出分析结果如下：

'no trend',False,0.43522176983359673,-0.78028732823668334

由于no trend表示没有出现明显的趋势，则说明移动终端100的系统在“相册”应用启动上暂未出现老化，若不是no trend而是increasing，则表明趋势在变化，移动终端100的系统在“相册”应用启动上呈现出老化趋势。关于Mann-Kendall趋势检验法的具体实现，可参考现有成熟的技术手段，此处不予以赘述。

值得注意的是，对于性能指标的分析，若性能指标本身是值越高表明系统老化越严重，则分析结果中的increasing指示系统出现老化，若性能指标本身是值越低表明系统老化越严重，则分析结果中的decreasing指示系统出现老化。

进而，对其他9个应用的应用启动耗时进行分析，得到其趋势结果均是no trend，由此可确定移动终端100的系统在应用启动方面暂未出现老化。如果测试脚本A所关联的10个应用中，存在超过预设比例阈值，如30％的应用的性能指标分析结果指示其趋势结果不是no trend，而是increasing或decreas ing，则可确定移动终端100的系统在应用启动方面出现老化趋势。

在该实施方式中，除测试脚本A以外，还有测试脚本B～E这4个测试脚本，参照上述对测试脚本A的处理过程，对测试脚本B～E进行相应处理，以确定移动终端100的系统是否会出现其对应的老化趋势。当然，还可以对测试脚本A～E对应的性能指标分析结果进行组合分析，从整体上确定系统是否在综合层面上存在老化现象，以得到一个概括性的结果，即确定系统整体上是表征为老化还是未老化。

测试脚本是需要预先获取来存储到移动终端100中的，根据本发明的又一个实施例，方法200还包括预先编写测试脚本的步骤，即根据预先生成的一个或多个系统测试场景，编写相应测试脚本。其中，系统测试场景包括用户常用场景和卡顿易发场景。在该实施方式中，还可以通过如下方式预先生成系统测试场景。首先，根据用户调研情况生成用户常用场景，用户调研情况包括用户在预定时间段内使用移动终端的时间、使用移动终端中所安装应用的名称及时间、操作习惯和充电间隔，然后，根据售后反馈情况生成卡顿易发场景，售后反馈情况包括出现卡顿时使用的应用、对应操作、时间、卡顿持续时长和卡顿发生频率。需要说明的是，用户调研情况和售后反馈情况并不限于以上内容，可根据实际应用场景、系统配置和性能要求等进行适当调整，这些对于了解本发明方案的技术人员来说是可以容易想到的，并且也在本发明的保护范围之内，此处不予以赘述。

此外，考虑到尽可能模拟出用户使用移动终端的行为，在运行测试脚本时涉及到移动终端相关数据的调用，如若要打开相册观看图片，则相册中应存储有一定数量的图片，因此根据本发明的又一个实施例，在按照测试次数，运行各测试脚本的步骤之前，先对移动终端进行测试数据填充，测试数据包括联系人、短信、相册图片、视频和音乐，但不限于此。

现有的测试系统是否老化的方法通常是先使用比较简单的数据填充，然后测试应用启动速度或利用点击、滑动的单一动作性能来进行老化测试，处理上较为粗略，测试场景与用户实际使用场景不太相同，衡量系统老化的指标单一，说服力不够，且在对老化判断时并不科学准确。根据本发明实施例的系统老化的测试方法，按照系统老化的测试次数运行各测试脚本，对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息，根据每次运行过程中各执行动作的操作信息，相应生成该测试脚本每次运行时的性能指标后进行结合分析，最后根据分析结果确定移动终端的系统是否出现该测试脚本对应的老化趋势。在上述方案中，分析性能指标时，是基于时间序列分析方法，如Mann-Kendall趋势检验法来完成的，从而确定该性能指标的变化是自然波动还是呈现出一种变差的趋势，保证了分析结果的科学性和准确性，解决了过程性问题而非只关注于结果性。此外，在生成测试脚本时，利用包含有用户常用场景和卡顿易发场景的系统测试场景来进行测试脚本的编写，以提供多样化且符合用户使用习惯的测试用例，并且将联系人、短信、相册图片、视频和音乐一类的测试数据预先填充到移动终端中，以便测试脚本执行时能够真正模拟出用户的行为，进而提升测试的有效性和可靠性。

A9.如A8所述的方法，还包括预先生成系统测试场景，所述预先生成系统测试场景的步骤包括：

根据用户调研情况生成用户常用场景，所述用户调研情况包括用户在预定时间段内使用移动终端的时间、使用移动终端中所安装应用的名称及时间、操作习惯和充电间隔；

根据售后反馈情况生成卡顿易发场景，所述售后反馈情况包括出现卡顿时使用的应用、对应操作、时间、卡顿持续时长和卡顿发生频率。

A10.如A1-9中任一项所述的方法，在按照所述测试次数，运行各测试脚本的步骤之前，还包括：

对所述移动终端进行测试数据填充，所述测试数据包括联系人、短信、相册图片、视频和音乐。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组间可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组间组合成一个模块或单元或组间，以及此外可以把它们分成多个子模块或子单元或子组间。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如软盘、CD-ROM、硬盘驱动器或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

在程序代码在可编程计算机上执行的情况下，计算设备一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的系统老化的测试方法。

以示例而非限制的方式，计算机可读介质包括计算机存储介质和通信介质。计算机可读介质包括计算机存储介质和通信介质。计算机存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在计算机可读介质的范围之内。

如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (10)

1.一种系统老化的测试方法，适于在移动终端中执行，所述移动终端中存储有一个或多个测试脚本，每个测试脚本包括一个或多个模拟用户操作的执行动作，所述方法包括：

根据预设的老化测试时间和脚本总执行时间，确定系统老化的测试次数；

按照所述测试次数，运行各测试脚本，所述测试脚本适于在运行时执行其所包括的执行动作；

对每一个测试脚本，监控该测试脚本的运行过程，并记录其每次运行时各执行动作的操作信息；

对该测试脚本的每一次运行过程，根据该次运行过程中各执行动作的操作信息，生成该测试脚本该次运行时的性能指标；

结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定所述移动终端的系统是否出现该测试脚本对应的老化趋势。

2.如权利要求1所述的方法，所述脚本总执行时间为将所有测试脚本执行一次所耗时间的总和。

3.如权利要求1或2所述的方法，所述操作信息包括动作相关时间和动作内容。

4.如权利要求1-3中任一项所述的方法，所述性能指标包括应用启动耗时、应用退出耗时、画面流畅度、帧率、CPU占用率和垃圾回收率中的至少一个。

5.如权利要求1-4中任一项所述的方法，所述结合该测试脚本每次运行时的性能指标进行分析，根据分析结果确定所述移动终端的系统是否出现该测试脚本对应的老化趋势的步骤包括：

基于时间序列分析方法对该测试脚本每次运行时的性能指标进行分析；

若分析结果指示无明显变化趋势，则确定所述移动终端的系统未出现该测试脚本对应的老化趋势；

若分析结果指示出现增速趋势，则确定所述移动终端的系统已出现该测试脚本对应的老化趋势。

6.如权利要求5所述的方法，所述时间序列分析方法为Mann-Kendall趋势检验法。

7.如权利要求1-6中任一项所述的方法，还包括：

根据预先生成的一个或多个系统测试场景，编写相应测试脚本。

8.如权利要求7所述的方法，所述系统测试场景包括用户常用场景和卡顿易发场景。

9.一种移动终端，包括：

一个或多个处理器；

存储器；以及

一个或多个程序，其中所述一个或多个程序存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行根据权利要求1-8中任一项所述的方法的指令。

10.一种存储一个或多个程序的计算机可读存储介质，所述一个或多个程序包括指令，所述指令当由移动终端执行时，使得所述移动终端执行根据权利要求1-8中任一项所述的方法。