CN114579421A - 一种卡顿测试方法及装置 - Google Patents

Abstract

本申请实施例公开了一种卡顿测试方法及装置，涉及终端人工智能(artificial intelligence，AI)领域，能够提高卡顿测试的准确性。所述方法包括：确定第一滑动事件中实际滑动的时长和实际滑动的过程中的屏幕刷新总帧数；第一滑动事件为待测试应用程序的界面上的滑动事件；还可以根据实际滑动的时长和屏幕刷新总帧数确定实际滑动的过程中的屏幕刷新频率。还可以根据目标图像的绘制时长和屏幕刷新频率判断第一滑动事件中是否出现卡顿，目标图像为实际滑动的过程中目标应用程序绘制的任意一帧图像。

Description

一种卡顿测试方法及装置

技术领域

本申请实施例涉终端人工智能(artificial intelligence，AI)领域，尤其涉及一种卡顿测试方法及装置。

背景技术

软件产品的流畅度是衡量软件产品用户体验的关键因素，可以通过提高软件产品的流畅度来提升用户体验，针对软件流畅度的分析与测试已逐渐成为软件开发团队的一项重要工作。

现有技术中，可以控制机械手在设备的屏幕上滑动，机械手可以对待测设备的屏幕实时摄像。通过机械手可以获取到滑动过程中的屏幕录像，对比连续两帧图片之间的差异值，根据所得的差异值确定待测设备是否出现卡顿点。例如，如果连续两帧图片差异值小于一个阈值，即确定卡顿了一帧。

实际上软件绘制的动画效果可能导致相邻两帧图片相似度较高，现有技术依靠相邻两帧图片间的相似度来判定卡顿点，依靠判定结果评价软件流畅度，可能将软件绘制的相邻两帧图片误识别为卡顿点，准确率不高。

发明内容

本申请实施例提供一种卡顿测试方法及装置，能够提高卡顿测试的准确性。

第一方面提供了一种卡顿测试方法，包括：确定第一滑动事件中实际滑动的时长和实际滑动的过程中的屏幕刷新总帧数；第一滑动事件为待测试应用程序的界面上的滑动事件；还可以根据实际滑动的时长和屏幕刷新总帧数确定实际滑动的过程中的屏幕刷新频率。最后，还可以根据目标图像的绘制时长和屏幕刷新频率判断第一滑动事件中是否出现卡顿，目标图像为实际滑动的过程中目标应用程序绘制的任意一帧图像。

本申请实施例提供的方法中，计算滑动过程中屏幕的刷新频率，结合滑动事件中该软件的绘制信息对该软件的运行流畅度进行测试，不再依赖图像相似度进行卡顿测试，能够避免将软件绘制的相邻两帧相似度较高的图像误识别为卡顿点，利用软件绘制信息能够区分不同的图像，包括软件绘制的相邻两帧相似度较高的图像，从而提高卡顿测试的准确性。

结合第一方面，在第一方面的第一种可能的实现方式中，确定第一滑动事件中实际滑动的时长，包括：确定第一滑动事件持续过程中屏幕刷新的N帧图像，N为大于等于1的整数；从N帧图像中确定与实际滑动对应的M帧图像；按照绘制时间先后顺序确定M帧图像中的首帧图像和M帧图像中的尾帧图像，根据首帧图像的绘制时间以及尾帧图像的绘制时间，确定实际滑动的时长。

本申请实施例提供的方法能够确定实际滑动产生的图像，以便根据实际滑动产生的图像更准确地确定实际滑动过程中的屏幕刷新频率。

结合第一方面的第一种可能的实现方式，从N帧图像中确定与实际滑动对应的M帧图像，确定N帧图像按照绘制时间先后顺序排列后的相邻两帧图像的相似度；若相似度小于阈值，则确定相邻两帧图像为实际滑动对应的图像。

本申请实施例提供的方法可以基于相邻图像的相似度确定实际滑动产生的图像，以便根据实际滑动产生的图像更准确地确定实际滑动过程中的屏幕刷新频率。

结合第一方面的第一或第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述方法还包括：确定实际滑动的时段，实际滑动的时段的起始时刻为首帧图像的绘制时间，实际滑动的时段的结束时刻为尾帧图像的绘制时间；确定与实际滑动的时段对应的软件性能信息，软件性能信息包括M帧图像中每一帧图像的绘制时长以及每一帧图像的绘制时间。

本申请实施例提供的方法可以确定实际滑动的时段，以便准确获取相应时段的软件性能信息。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，软件性能信息为systrace信息。

本申请实施例提供了软件性能信息的一种可能实现。

结合第一方面或以上第一方面的任意一种可能的实现方式，在第一方面的第五种可能的实现方式中，所述根据目标图像的绘制时长和屏幕刷新频率判断第一滑动事件中是否出现卡顿，包括：若目标图像的绘制时长大于每帧刷新时长，则确定出现卡顿；每帧刷新时长为屏幕刷新频率的倒数。

本申请实施例提供了根据软件性能信息判断是否出现卡顿的一种可能实现方式。当屏幕刷新频率大于软件绘制帧率，即某帧图像的绘制时长大于每帧刷新时长，表明出现丢帧，用户可能产生卡顿的视觉感受。

第二方面，提供了一种装置，包括：图像处理单元，用于确定第一滑动事件中实际滑动的时长和实际滑动的过程中的屏幕刷新总帧数；第一滑动事件为待测试应用程序的界面上的滑动事件；计算单元，用于根据实际滑动的时长和屏幕刷新总帧数确定实际滑动的过程中的屏幕刷新频率；测试单元用于，根据目标图像的绘制时长和屏幕刷新频率判断第一滑动事件中是否出现卡顿，目标图像为实际滑动的过程中目标应用程序绘制的任意一帧图像。

结合第二方面，在第二方面的第一种可能的实现方式中，图像处理单元具体用于，确定第一滑动事件持续过程中屏幕刷新的N帧图像，N为大于等于1的整数；从N帧图像中确定与实际滑动对应的M帧图像；按照绘制时间先后顺序确定M帧图像中的首帧图像和M帧图像中的尾帧图像，根据首帧图像的绘制时间以及尾帧图像的绘制时间，确定实际滑动的时长。

结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，图像处理单元具体用于，确定N帧图像按照绘制时间先后顺序排列后的相邻两帧图像的相似度；若相似度小于阈值，则确定相邻两帧图像为实际滑动对应的图像。

结合第二方面的第一或第二种可能的实现方式，在第二方面的第三种可能的实现方式中，计算单元还用于，确定实际滑动的时段，实际滑动的时段的起始时刻为首帧图像的绘制时间，实际滑动的时段的结束时刻为尾帧图像的绘制时间；确定与实际滑动的时段对应的软件性能信息，软件性能信息包括M帧图像中每一帧图像的绘制时长以及每一帧图像的绘制时间。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，软件性能信息为systrace信息。

结合第二方面或以上第二方面任意一种可能的实现方式，在第二方面的第五种可能的实现方式中，测试单元具体用于，若判断目标图像的绘制时长大于每帧刷新时长，则确定出现卡顿；每帧刷新时长为屏幕刷新频率的倒数。

第三方面，提供了一种装置，包括至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合；所述存储器，用于存储计算机程序；

所述至少一个处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如上述第一方面以及第一方面任意一种实现方式所述的方法。

第四方面，提供了一种计算机可读存储介质，包括：计算机可读存储介质中存储有指令；当计算机可读存储介质在上述第二方面以及第二方面任意一种实现方式所述的装置上运行时，使得装置执行如上述第一方面以及第一方面任意一种实现方式所述的通信方法。

第五方面，提供了一种无线装置，该装置包括处理器，例如，应用于装置中，用于实现上述第一方面以及第一方面任意一种实现方式所述的方法，该装置例如可以是芯片系统。在一种可行的实现方式中，所述芯片系统还包括存储器，所述存储器，用于保存实现上述第一方面所述方法的功能必要的程序指令和数据。

上述方面中的芯片系统可以是片上系统(system on chip，SOC)，也可以是基带芯片等，其中基带芯片可以包括处理器、信道编码器、数字信号处理器、调制解调器和接口模块等。

附图说明

图1为本申请实施例提供的系统架构图；

图2为本申请实施例提供的待测试设备的框架结构图；

图3为本申请实施例提供的卡顿测试方法的流程示意图；

图4为本申请实施例提供的滑动操作示意图；

图5为本申请实施例提供的图像绘制、渲染示意图。

图6为本申请实施例提供的卡顿测试方法的另一流程示意图；

图7为本申请实施例提供的测试界面的示意图；

图8为本申请实施例提供的秒表计时器的示意图；

图9为本申请实施例提供的systrace文件的示意图；

图10～图13为本申请实施例提供的装置的结构框图。

具体实施方式

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

本申请的实施例提供一种卡顿测试方法可以应用于图1所示的系统。参考图1，该系统包括待测试设备10和分析服务器20。其中，待测试设备10可以运行软件的应用程序，在滑动事件持续过程中待测试设备10还可以获取滑动事件中的屏幕图像，分析服务器20可以根据待测试设备10获取的图像以及滑动事件中该软件的绘制信息对该软件的运行流畅度进行测试，能够区分软件绘制的相邻两帧相似度较高的图像，避免将软件绘制的相邻两帧相似度较高的图像误识别为卡顿点，提高卡顿测试的准确性。

具体地，待测试设备10包括图像获取单元101、滑动事件触发单元102以及计时单元103。分析服务器20包括图像处理单元201以及计算单元202。

其中，滑动事件触发单元102用于触发待测试设备10中安装的目标软件的用户界面(user interface，UI)上的滑动事件。具体地，滑动事件触发单元102运行自动化滑动脚本触发测试软件UI上的滑动事件。另一种可能的实现方式中，由测试人员在待测试设备10的屏幕上滑动，触发目标软件的UI上的滑动事件。

图像获取单元101用于获取滑动事件持续过程中待测试设备10的屏幕图像。例如，图像获取单元101可以开启手机的录屏功能，对滑动事件持续的整个过程进行录屏，获得滑动事件过程中待测试设备10的屏幕图像。图像获取单元101还可以将录屏获得的视频传输到分析服务器20，分析服务器20的视频分帧单元201可以将录屏视频划分成多帧图像，并用时间戳命名每一帧图像。其中，图像对应的时间戳可以是目标软件绘制该图像时对应的系统时间。一种可能的实现方式中，图像获取单元101通过adb pull命令将录屏视频传输到分析服务器20。

计时单元103用于在滑动事件过程中计时。具体地，待测试设备可以维护一个秒表计时器，计时单元103可以在记录每一帧图像的绘制信息时记录秒表计时器当前的时间。例如，在生成每一帧图像Systrace信息时记录秒表计时器当前的时间，对应记录这帧图像的Systrace信息和当前的时间。一种可能的实现方式中，通过Systrace标记函数Trace.beginSection()记录当前的时间。

软件性能信息获取单元203用于获取目标软件的性能信息，软件的性能信息包含了滑动过程中每帧图像绘制时长、方法调用栈，线程对每帧图像的渲染关系等。一种可能的实现方式中，软件性能信息获取单元203可以获取系统级别的Systrace文件，Systrace文件包括了各个软件的性能信息，例如，滑动事件进行过程中目标软件的性能信息，包括目标软件绘制每帧图像的时长。同时，在绘制图像时还可以抓取秒表计时器的进程，在Systrace文件中增加目标软件绘制每帧图像的时间戳。

图像处理单元201，用于将录屏视频分解成多帧图像，还可以计算相邻两帧图像的相似度，从而可以确定滑动事件对应的首帧图像和尾帧图像。其中，首帧图像是实际滑动过程的第一帧图像，尾帧图像是实际滑动过程的最后一帧图像。

计算单元202，用于根据首帧图像的时间戳和尾帧图像的时间戳计算滑动总时长，还可以确定滑动过程中的总渲染帧数，根据滑动总时长和总渲染帧数计算滑动过程中的实际帧率，即滑动过程中目标软件每绘制一帧图像消耗的时长。

具体实现中，待测试设备10可以是手机、可穿戴设备、AR(增强现实)\VR(虚拟现实)设备、平板电脑、笔记本电脑、UMPC(超级移动个人计算机)、上网本、PDA(个人数字助理)等可以运行APP的任意终端；分析服务器20可以是服务器，本申请实施例对此不作任何限制。

如图2所示，本申请实施例中的待测试设备10可以为手机30。下面以手机30为例对实施例进行具体说明。应该理解的是，图示手机30仅是终端的一个范例，并且手机30可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。

如图2所示，手机30具体可以包括：处理器301、射频(RF)电路302、存储器303、触摸屏304、蓝牙装置305、一个或多个传感器306、Wi-Fi装置307、定位装置308、音频电路309、外设接口310以及电源系统311等部件。这些部件可通过一根或多根通信总线或信号线(图2中未示出)进行通信。本领域技术人员可以理解，图2中示出的硬件结构并不构成对手机的限定，手机30可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图2对手机30的各个部件进行具体的介绍：

处理器301是手机30的控制中心，利用各种接口和线路连接手机30的各个部分，通过运行或执行存储在存储器303内的应用程序(以下可以简称App)，以及调用存储在存储器303内的数据，执行手机30的各种功能和处理数据。在一些实施例中，处理器301可包括一个或多个处理单元；举例来说，处理器301可以是华为技术有限公司制造的麒麟960芯片。

射频电路302可用于在收发信息或通话过程中，无线信号的接收和发送。特别地，射频电路302可以将基站的下行数据接收后，给处理器301处理；另外，将涉及上行的数据发送给基站。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路302还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。

存储器303用于存储应用程序以及数据，处理器301通过运行存储在存储器303的应用程序以及数据，执行手机30的各种功能以及数据处理。存储器303主要包括存储程序区以及存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)；存储数据区可以存储根据使用手机30时所创建的数据(比如音频数据、电话本等)。此外，存储器303可以包括高速随机存取存储器，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。存储器303可以存储各种操作系统，例如，苹果公司所开发的iOS操作系统，谷歌公司所开发的Android操作系统等。

触摸屏304可以包括触控板304-1和显示器304-2。其中，触控板304-1可采集手机30的用户在其上或附近的触摸事件(比如用户使用手指、触控笔等任何适合的物体在触控板304-1上或在触控板304-1附近的操作)，并将采集到的触摸信息发送给其他器件例如处理器301。虽然在图1中，触控板304-1与显示屏304-2是作为两个独立的部件来实现手机30的输入和输出功能，但是在某些实施例中，可以将触控板304-1与显示屏304-2集成而实现手机30的输入和输出功能。可以理解的是，触摸屏304是由多层的材料堆叠而成，本申请实施例中只展示出了触控板(层)和显示屏(层)，其他层在本申请实施例中不予记载。另外，在本申请其他一些实施例中，触控板304-1可以覆盖在显示器304-2之上，并且触控板304-1的尺寸大于显示屏304-2的尺寸，使得显示屏304-2全部覆盖在触控板304-1下面，或者，上述触控板304-1可以以全面板的形式配置在手机30的正面，也即用户在手机30正面的触摸均能被手机感知，这样就可以实现手机正面的全触控体验。在其他一些实施例中，触控板304-1以全面板的形式配置在手机30的正面，显示屏304-2也可以以全面板的形式配置在手机30的正面，这样在手机的正面就能够实现无边框的结构。

在本申请实施例中，手机30还可以具有指纹识别功能。例如，可以在手机30的背面(例如后置摄像头的下方)配置指纹识别器312，或者在手机300的正面(例如触摸屏304的下方)配置指纹识别器312。又例如，可以在触摸屏304中配置指纹采集器件212来实现指纹识别功能，即指纹采集器件312可以与触摸屏304集成在一起来实现手机300的指纹识别功能。在这种情况下，该指纹采集器件312配置在触摸屏304中，可以是触摸屏304的一部分，也可以以其他方式配置在触摸屏304中。本申请实施例中的指纹采集器件312的主要部件是指纹传感器，该指纹传感器可以采用任何类型的感测技术，包括但不限于光学式、电容式、压电式或超声波传感技术等。

在本申请实施例中，手机30还可以包括蓝牙装置305，用于实现手机300与其他短距离的终端(例如手机、智能手表等)之间的数据交换。本申请实施例中的蓝牙装置可以是集成电路或者蓝牙芯片等。

Wi-Fi装置307，用于为手机30提供遵循Wi-Fi相关标准协议的网络接入，手机30可以通过Wi-Fi装置307接入到Wi-Fi接入点，进而帮助用户收发电子邮件、浏览网页和访问流媒体等，它为用户提供了无线的宽带互联网访问。在其他一些实施例中，该Wi-Fi装置307也可以作为Wi-Fi无线接入点，可以为其他终端提供Wi-Fi网络接入。

手机30还可以包括至少一种传感器306，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节触摸屏304的显示器的亮度，接近传感器可在手机30移动到耳边时，关闭显示器的电源。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机30还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

定位装置308，用于为手机30提供地理位置。可以理解的是，该定位装置308具体可以是全球定位系统(GPS)或北斗卫星导航系统、俄罗斯GLONASS等定位系统的接收器。定位装置308在接收到上述定位系统发送的地理位置后，将该信息发送给处理器301进行处理，或者发送给存储器303进行保存。在另外的一些实施例中，该定位装置308还可以是辅助全球卫星定位系统(AGPS)的接收器，AGPS系统通过作为辅助服务器来协助定位装置308完成测距和定位服务，在这种情况下，辅助定位服务器通过无线通信网络与终端例如手机300的定位装置308(即GPS接收器)通信而提供定位协助。在另外的一些实施例中，该定位装置308也可以是基于Wi-Fi接入点的定位技术。由于每一个Wi-Fi接入点都有一个全球唯一的MAC地址，终端在开启Wi-Fi的情况下即可扫描并收集周围的Wi-Fi接入点的广播信号，因此可以获取到Wi-Fi接入点广播出来的MAC地址；终端将这些能够标示Wi-Fi接入点的数据(例如MAC地址)通过无线通信网络发送给位置服务器，由位置服务器检索出每一个Wi-Fi接入点的地理位置，并结合Wi-Fi广播信号的强弱程度，计算出该终端的地理位置并发送到该终端的定位装置308中。

音频电路309、扬声器313、麦克风314可提供用户与手机30之间的音频接口。音频电路309可将接收到的音频数据转换后的电信号，传输到扬声器313，由扬声器313转换为声音信号输出；另一方面，麦克风314将收集的声音信号转换为电信号，由音频电路309接收后转换为音频数据，再将音频数据输出至RF电路302以发送给比如另一手机，或者将音频数据输出至存储器303以便进一步处理。

外设接口310，用于为外部的输入/输出设备(例如键盘、鼠标、外接显示器、外部存储器、用户识别模块卡等)提供各种接口。例如通过通用串行总线(USB)接口与鼠标连接，通过用户识别模块卡卡槽上的金属触点与电信运营商提供的用户识别模块卡(SIM)卡进行连接。外设接口310可以被用来将上述外部的输入/输出外围设备耦接到处理器301和存储器303。

手机30还可以包括给各个部件供电的电源装置311(比如电池和电源管理芯片)，电池可以通过电源管理芯片与处理器301逻辑相连，从而通过电源装置311实现管理充电、放电、以及功耗管理等功能。

尽管图2未示出，手机30还可以包括摄像头(前置摄像头和/或后置摄像头)、闪光灯、微型投影装置、近场通信(NFC)装置等，在此不再赘述。

进一步地，上述手机30中可以运行在Android或IOS等操作系统中，本申请实施例对此不作任何限制。

本申请实施例提供一种卡顿测试方法，执行主体为图1所示的待测试设备10或分析服务器20，如图3所示，所述方法包括以下步骤：

401、确定第一滑动事件中实际滑动的时长和所述实际滑动的过程中的屏幕刷新总帧数；所述第一滑动事件为待测试应用程序的界面上的滑动事件。

本申请实施例提供的方法可以对待检测设备10安装的应用程序(以下简称为待测试应该程序)进行卡顿测试，具体地，可以通过测试该应用程序的UI在用户操作时是否出现画面卡顿。例如，测试人员可以触摸、滑动待测试应用程序的某个界面，生成滑动事件，例如，前文所述的第一滑动事件。在滑动事件中设备所检测到的电容(或电阻)的变化趋势符合一定规律，待测试设备10的滑动事件触发单元102可以通过自动化脚本模拟出符合一定规律的电容变化，从而模拟滑动事件。

参考图4，用户在设备屏幕上的一次滑动操作可以包括操作1、操作2以及操作3。其中，操作1是指点物(例如，用户手指)靠近并触摸屏幕的操作，操作2是用户手指在屏幕上滑动的操作，操作3是用户手指离开屏幕的操作。

从用户触摸屏幕到实际开始滑动时的时间间隔，为软件的响应时间，因此不能认定用户执行操作1就是滑动事件中实际滑动的开始，也就是说滑动事件中实际滑动产生的图像可以不包括操作1发生时产生的图像。另外，用户在屏幕快速滑动的时候会有惯性滑动效果，因此不能认定用户松开手就是滑动过程的结束，即滑动事件中实际滑动产生的图像包括操作3发生后由于惯性产生的图像。滑动事件过程中屏幕刷新图像包括软件响应时间内屏幕刷新的图像以及实际滑动产生的图像。

参考图5，应用程序绘制图像后，将图像信息送入缓存(buffer)，应用程序还可以从缓存中以先进先出的原则读取图像信息，并在显示屏上渲染图像。通常，应用程序绘制图像的频率可以称为每秒传输帧数(frames per second，FPS)，还可以称为软件绘制帧率。应用程序在显示屏上渲染图像的频率可以称为屏幕刷新频率。当软件绘制帧率小于屏幕刷新频率，会发生丢帧，用户可能会产生卡顿的视觉感受。例如，应用程序每秒刷新屏幕60HZ，应用程序每秒绘制59FPS，会发生丢帧，用户可能会产生卡顿的视觉感受。

本申请实施例提供的卡顿测试方法旨在根据图像的软件绘制时长和屏幕刷新频率来测试滑动事件持续过程中是否出现卡顿点。因此，需要获取滑动事件过程中屏幕刷新的所有图像，以便计算实际活动过程中屏幕的刷新频率。

一种可能的实现方式中，在测试场景下，当待测试设备10检测到操作1，则启动录屏功能，对滑动事件进行记录。可以对滑动事件持续过程中待测试设备10的录屏视频进行分帧处理，获得在滑动事件持续过程中屏幕刷新的所有图像，以从中确定滑动事件中实际滑动产生的首帧图像以及实际滑动产生的尾帧图像。

例如，待测试设备10可以确定所述第一滑动事件持续过程中屏幕刷新的N帧图像，所述N为大于等于1的整数。其中，根据录屏视频分帧所得的N帧图像可以认为是滑动过程中屏幕刷新的N帧图像。

待测试设备10还可以对分帧处理所得的图像进行图像相似度处理，以确定滑动事件中实际滑动产生的首帧图像以及实际滑动产生的尾帧图像。其中，首帧图像是滑动事件持续过程中实际滑动产生的第一帧，例如是前文所述操作2产生的第一帧图像。尾帧图像是实际滑动产生的第一帧，例如，可以是前文所述操作3后由于惯性产生的最后一帧图像。

具体地，待测试设备可以将分帧处理所得的所有图像按照时间先后顺序，依次比较相邻两帧图片的相似度，如果相似度低于一定阈值，则认为这两帧图片不相似，即存在滑动。取首个与上一帧图片不相似的图片为滑动的首帧。同样的，设定一个门槛值，例如设定门槛值为10，如果连续10张图片都是相似度高于阈值的，则按照时间顺序，在这十张图片内，第一张图片确定为滑动过程尾帧，对应图片的时间戳为滑动过程尾帧的时间戳。

示例的，待测试设备10从所述N帧图像中确定与所述实际滑动对应的M帧图像；按照绘制时间先后顺序确定所述M帧图像中的首帧图像和所述M帧图像中的尾帧图像，根据所述首帧图像的绘制时间以及所述尾帧图像的绘制时间，确定所述实际滑动的时长。

其中，所述从所述N帧图像中确定与所述实际滑动对应的M帧图像，包括：确定所述N帧图像按照绘制时间先后顺序排列后的相邻两帧图像的相似度；若所述相似度小于阈值，则确定所述相邻两帧图像为所述实际滑动对应的图像。

一种可能的实现方式中，相邻两帧图像相似度等于所述阈值，则确定所述相邻两帧图像为所述实际滑动对应的图像。或者，相邻两帧图像相似度等于所述阈值，则确定所述相邻两帧图像不是实际滑动对应的图像。

具体实现中，确定第一滑动事件中实际滑动过程中的屏幕刷新总帧数，包括：编写html解析脚本，利用html解析脚本解析systrace文件，统计实际滑动的时间段内的总渲染帧数，即实际滑动过程中的屏幕刷新总帧数。其中，html解析脚本可以是BeautifulSoup、xpath等。

402、根据所述实际滑动的时长和所述屏幕刷新总帧数确定所述实际滑动的过程中的屏幕刷新频率。

具体实现中，所述实际滑动的过程中的屏幕刷新频率等于所述屏幕刷新总帧数除以所述实际滑动的时长得到的结果。

403、根据目标图像的绘制时长和所述屏幕刷新频率判断所述第一滑动事件中是否出现卡顿，所述目标图像为所述实际滑动的过程中所述目标应用程序绘制的任意一帧图像。

具体实现中，待测试设备10确定所述实际滑动的时段，所述实际滑动的时段的起始时刻为所述首帧图像的绘制时间，所述实际滑动的时段的结束时刻为所述尾帧图像的绘制时间。

待测试设备10还可以获取该时段系统记录的软件性能信息，示例的，所述软件性能信息包括所述M帧图像中每一帧图像的绘制时长以及所述每一帧图像的绘制时间。

针对所述M帧图像中每一帧图像，从该时段对应的软件性能信息中获取该图像的绘制时长。还可以比较该图像的绘制时长与每帧刷新时长，以确定是否出现卡顿。其中，每帧刷新时长是实际滑动过程中待测试设备10的屏幕刷新一帧图像的时长，可以是所述屏幕刷新频率的倒数。

一种可能的实现方式中，所述软件性能信息为systrace信息。

具体实现中，待测试设备10在滑动事件开始时启动秒表计时器，例如，在检测到触摸操作1时开启秒表计时器。滑动事件持续过程中当待测试的应用程序绘制UI图像时，待测试设备10可以在记录各个应用程序软件性能信息的文件(例如，systrace文件)中写入当前绘制图像的信息，例如，当前图像的绘制时长。本申请实施例中，待测试设备10在绘制图像时还可以抓取秒表计时器的进程，以获取当前的时间戳，即待测试设备10当前绘制图像的时间戳。待测试设备10还可以在systrace文件中写入当前绘制图像的时间戳。

待测试设备10确定首帧图像和尾帧图像后，可以确定滑动事件中实际滑动的时段，从而可以根据时间戳在systrace文件中抓取待测试的应用程序在该时段的软件性能信息，包括待测试的应用程序绘制实际滑动产生的每一帧图像的时长。

前文所述的实现方式中，由待测试设备10完成卡顿测试的整个流程，得出卡顿测试的结果。另一种可能的实现方式中，待测试设备10在滑动事件持续过程中对应用程序的界面进行录屏，在滑动事件开始时启动秒表计时器，渲染每一帧图像时在应用程序的systrace信息中写入绘制时长、绘制时间(即图像的时间戳)等。待测试设备10还可以将录屏视频传输给分析服务器20。

分析服务器20可以执行步骤401～403，进行卡顿测试。例如，分析服务器20可以从待测试设备10接收录屏视频，对录屏视频进行分帧处理，获得滑动事件中屏幕刷新的所有图像。分析服务器20还可以从屏幕刷新的所有图像中确定实际滑动产生的首帧图像和尾帧图像，根据显示(刷新)首帧图像和尾帧图像的时间确定实际滑动的时间段，从而可以在待测试设备10的systrace文件中抓取这个时间内该应用程序的systrace信息。还可以根据该应用程序的systrace信息记录的某帧图像的绘制时长判断是否出现卡顿。

本申请实施例还提供一种卡顿测试方法，如图6所示，所述方法包括以下步骤：

S1a、触发滑动事件，待测试设备10开启录屏功能。

具体实现中，测试人员触摸屏幕触发滑动事件，或者运行自动化脚本，触发待测试应用程序界面上的滑动事件。滑动事件开始时，待测试设备10开启录屏功能，获取滑动事件持续过程的视频。

S1b、滑动事件开始时，待测试设备10启动秒表计时器。

S2、记录待测试应用程序的软件性能信息。

示例的，待测试设备10在绘制图像时，抓取秒表计时器的进程，获取绘制图像的时间，在systrace文件应用程序的systrace信息包括待测试应用程序绘制图像的时长以及时间。

S3、确定滑动事件中实际滑动的首帧图像以及尾帧图像。

具体实现中根据相邻图像的相似度确定实际滑动的首帧图像以及尾帧图像，具体方式参考前文所述，在此不做赘述。

S4、根据首帧图像以及尾帧图像确定实际滑动过程中屏幕刷新频率。

具体地，根据首帧图像的时间以及尾帧图像的时间确定实际滑动的时长，其中，首帧图像的时间可以是分帧处理时确定的该图像的刷新时间，尾帧图像的时间可以是分帧处理时确定的该图像的刷新时间。

还可以解析systrace文件确定应用程序在实际滑动的时段内屏幕刷新总帧数，根据实际滑动的时长以及屏幕刷新总帧数确定实际滑动过程中屏幕刷新频率。

S5、抓取实际滑动时间段的systrace信息，逐一判断每一帧图像的刷新时长，得出测试结果。

具体地，systrace文件记录了该应用程序对应的systrace信息，包括图像绘制时长和图像绘制时间戳。还可以从该应用程序对应的systrace信息中确定与首帧图像的时间最接近的时间戳，以及与尾帧图像的时间最接近的时间戳，抓取这两个时间戳之间的systrace信息。

再对抓取到的systrace信息中记录的每一帧图像的刷新时长进行判断，若图像的刷新时长大于实际滑动过程中每帧刷新时长，则确定发生卡顿。其中，每帧刷新时长为实际滑动过程中屏幕刷新频率的倒数。

本申请实施例提供的卡顿测试方法中，实现测试过程中的图像信息与软件性能信息融合，以解决当前技术方法不能区分测试过程中由于软件动画效果造成相邻两张图片相似度过高，误识别为卡顿点的问题。同时能够拥有软件性能信息，帮助软件开发者快速定位卡顿点对应的代码逻辑，实现卡顿测试的准确率以及测试的自动化。

需要说明的是，每一帧图像序列在渲染到屏幕之前，都是通过缓冲机制存储于一个Buffer缓冲区中，当屏幕准备好后，就会从硬件帧缓冲区读取数据并渲染出来。具体的读取过程为：从Buffer的起始地址开始，从上往下，从左往右读取整个Buffer的数据。

一种可能的实现方式中，当每次缓冲区准备完成时，读取软件中的FrameBuffer数据，并将Buffer中的数据保存到服务端。滑动过程完全结束时，在服务端对保存的buffer数据重新渲染成静态图片，并按照保存时的时间戳命名。通过上述步骤可以直接得到滑动过程中的图像序列，省去了录屏或录像操作。这种实现方式中能够得到准确的首帧图像的时间、尾帧图像的时间。

在得到实际滑动的首帧图像后，还可以设定一个最小时间间隔，利用该时间间隔加快尾帧图像的计算速度。其中，最小时间间隔的计算是图像的时间戳(刷新时间)与Systrace文件中的绘制时间戳之间的时间间隔。若图像的时间戳与对应的绘制时间戳直接的间隔超过了最小时间间隔，则可以丢弃该图像帧，从而加快尾帧图像的计算速度。

本申请实施例提供的方法中，无需通过对视频进行分帧处理就可以获得实际滑动的产生的图像。在测量过程中无需进行录屏视频从待测试设备10到分析服务器20的传输，在一定程度上更加降低了外部测试环境对目标测试软件的干扰。另外，能够提前将缓存中的图像序列与Systrace文件信息进行关联，在判断实际滑动尾帧图像时，剔除一些误差较大的冗余分帧图像，加快了滑动过程尾帧的识别。

以下以手机上安装的聊天应用A为例，结合附图详细介绍本申请实施例提供的卡顿测试方法，具体如下：

首先，手机运行滑动脚本(例如，adb shell input swipe命令)触发聊天应用A某个UI上的滑动事件。示例的，参考图7，在聊天应用A的用户列表界面进行测试，手机可以运行滑动脚本触发用户列表界面上的滑动。

另外，当滑动事件开始时，手机可以在用户列表界面上显示秒表计时器。示例的，参考图8，在用户列表界面的上方显示秒表计时器。具体实现中，毫秒消息发送器Handler在每毫秒切换时更新秒表计时器上数字，实现秒表计时器的时间更新。手机还可以在每毫秒切换时将当前的毫秒时间用Tarce.beginSection()、Trace.endSection()方法记录秒表计时器当前的毫秒时间，即本申请实施例所述的时间戳。需要说明的是，本申请实施例对时间戳的记录方案不做限制，前文所述只是其中一种实现方法，手机还可以利用其他方案也是可以作为生成时间戳。

手机在滑动开始时启动秒表计时器后，还可以使用Systrace抓取脚本抓取滑动事件持续过程中聊天应用A的Systrace信息，即聊天应用A的软件性能信息。抓取脚本可以是“systrace.py执行自动化脚本python systrace.py–o fileName.html gfx am inputview wm res idle load freq sched–a timer，target”，其中，fileName.html为抓取的Systrace信息所属文件的名称，timer秒表定时器的进程名，target为目标测试软件(例如，聊天应用A)的进程名。Systrace抓取脚本的运行时长，即获取Systrace信息的时长可以是预设数值，可以与滑动时长的阈值相同。例如，一般滑动过程的时长在6秒以内，6秒可以是Systrace抓取脚本的运行时长。需要说明的是，抓取秒表定时器的进程后可以确定滑动事件中每一帧图像的绘制时间戳，在该图像的Systrace信息中写入绘制时间戳以及绘制时长等。通过运行抓取脚本可以获取滑动事件持续过程中联通应用A的软件性能信息。

手机还可以从滑动时间开始时启动录屏功能，记录滑动过程的视频。进一步，还可以对视频图像进行分帧处理，将滑动过程中的录屏视频划分为多帧图像。手机还可以按照时间顺序，计算相邻两帧图像的相似度，以确定滑动过程的首帧和尾帧。具体实现中，可以采用的图像相似度算法包括但不限于图像直方图比较方法、感知哈希算法、特征点匹配算法等。以特征点匹配算法为例，计算每帧图像的特征点，对相邻两帧图像的特征点进行匹配。例如，计算特征点间的欧式距离，如果欧式距离小于阈值则认为两个特征点是匹配的。如果相邻两帧图像匹配的特征点总数所占比例小于指定的阈值(例如，95％、99％等)，则确定相邻两帧图像不相似，这两帧图像对应用户列表界面上的真实滑动。将判定为用户列表界面上真实滑动对应的所有图像按照时间先后顺序排序，将第一张图像作为滑动过程的首帧，最后一张图像作为滑动过程的尾帧。需要说明的是，图像的特征点可以是SIFT特征点、SURF特征点或FAST特征点等。

确定滑动过程的首帧图像、尾帧图像后，还可以根据首帧图像、尾帧图像的时间确定实际滑动过程中聊天应用A的Systrace信息。具体地，Systrace信息记录滑动过程中聊天应用A实际对每帧图像进行渲染的时间戳，将确认的首帧时间与尾帧时间与Systrace文件中的每帧图像实际渲染完成的时间进行比较，在Systrace文件中与图像首帧时间最近的时间节点为滑动首帧的实际时间，与图像尾帧时间最近的时间节点为滑动尾帧的实际时间。

Systrace信息的分析结果如图9所示。一个圆点代表一帧图像的Systrace性能信息。其中第一根分割线穿过的第一个圆点代表实际滑动的首帧图像的Systrace性能信息，第二根分割线穿过的圆点代表实际滑动的尾帧图像的Systrace性能信息。

进一步，还可以根据首帧图像的时间戳、尾帧图像的时间戳确定实际滑动的时长。具体地，通过首帧与尾帧的时间相减能够得到软件滑动过程总的时间。还可以通过html解析库如：BeautifulSoup、xpath解析Systrace文件，确定出实际滑动过程中渲染完成(屏幕刷新)的总帧数。通过总帧数与滑动总时长就能计算出滑动过程的帧率。

如果滑动过程的帧率为60FPS，则表示需要在16.6ms内软件需要渲染刷新一帧新的图像。假设从Systrace信息中记录某帧的渲染时长超过16.6ms，表示该帧是卡顿点。另外，该帧渲染耗时除以16.6ms得到该帧的丢帧率。滑动总时间除以总帧数得到数据预设帧率60FPS情况下，测试软件滑动总帧率。

本申请实施例中，针对目标测试软件，可以通过自动化的滑动脚本快速模拟滑动操作，以满足大量测试的场景，同时在帮助软件开发分析定位时候，支持软件人员实际滑动并测试，满足多维度的输入场景。滑动事件开始后，通过录屏或者录像装置就能够获取到滑动过程的视频，解决了依赖高速摄像机进行摄像造成测试成本较高的问题，同时能够对视频按照不同的预设帧率进行分帧成图像，比如可以测试90FPS、60FPS等预设帧率，满足了多业务场景下的帧率分析测试。

在根据预设帧率对滑动过程录屏的视频进行分帧处理后，能够判断出实际滑动的首帧图像与尾帧图像，以及及首帧图像的时间戳和尾帧图像的时间戳。利用图像的时间戳对Systrace信息中记录的图像绘制时间戳进行校正，能够提升帧率测量的准确性，依靠Systrace软件性能信息进行卡顿测试的结果具有更高的公正性。因此，通过融合滑动过程的图像信息与滑动过程的性能软件信息，能够实现移动端软件滑动过程的帧率自动化分析和测试，能够解决现有方案中不能区分滑动过程由于软件的动画效果误识别为卡顿的问题，使得测试结果更加准确与公正。

在采用对应各个功能划分各个功能模块的情况下，图10示出上述实施例中所涉及的装置一种可能的结构示意图。图10所示的装置90可以是本申请实施例所述的待测试设备或分析服务器，也可以是待测试设备或分析服务器中实现上述方法的部件，或者，也可以是应用于待测试设备或分析服务器中的芯片。其中，所述芯片可以是片上系统(System-On-a-Chip，SOC)或者是具备通信功能的基带芯片等。如图10所示，所述装置包括图像处理单元901、计算单元902、测试单元903以及通信单元904。处理单元可以是一个或多个处理器，通信单元可以是收发器或者通信接口。

图像处理单元901，例如可以用于支持所述装置90进行图像处理，例如对录屏视频进行分帧处理，或者，根据图像相似度确定实际滑动的首帧图像和尾帧图像，和/或用于本文所描述的技术的其它过程。

计算单元902，用于支持所述装置90计算实际滑动的过程中的屏幕刷新频率，和/或用于本文所描述的技术的其它过程。

测试单元903，用于支持所述装置90获取实际滑动时段所对应的软件性能信息，根据获取到的软件性能信息以及实际滑动的过程中的屏幕刷新频率进行卡顿测试，和/或用于本文所描述的技术的其它过程。

通信单元904，用于支持所述装置90与其他设备之间的通信，和/或用于本文所描述的技术的其它过程。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

如图11所示，所述装置90还可以包括存储单元905，存储单元905用于所述装置的程序代码和/或数据。

示例性的，在采用集成的单元的情况下，本申请实施例提供的装置的结构示意图如图12所示。在图12中，该装置110包括：处理模块1101和通信模块1102。处理模块1101用于对装置的动作进行控制管理，例如，执行上述图像处理单元901、计算单元902以及测试单元903执行的步骤，和/或用于执行本文所描述的技术的其它过程。通信模块1102用于执行上述通信单元904执行的步骤。可选的，如图13所示，装置110还可以包括存储模块1103，存储模块1103用于存储装置的程序代码和数据。

处理模块1101可以包括至少一个处理器，通信模块1102可以为收发器或者通信接口，存储模块1103可以包括存储器。

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

本申请实施例中的处理器，可以包括但不限于以下至少一种：中央处理单元(central processing unit，CPU)、微处理器、数字信号处理器(DSP)、微控制器(microcontroller unit，MCU)、或人工智能处理器等各类运行软件的计算设备，每种计算设备可包括一个或多个用于执行软件指令以进行运算或处理的核。该处理器可以是个单独的半导体芯片，也可以跟其他电路一起集成为一个半导体芯片，例如，可以跟其他电路(如编解码电路、硬件加速电路或各种总线和接口电路)构成一个SoC(片上系统)，或者也可以作为一个ASIC的内置处理器集成在所述ASIC当中，该集成了处理器的ASIC可以单独封装或者也可以跟其他电路封装在一起。该处理器除了包括用于执行软件指令以进行运算或处理的核外，还可进一步包括必要的硬件加速器，如现场可编程门阵列(field programmablegate array，FPGA)、PLD(可编程逻辑器件)、或者实现专用逻辑运算的逻辑电路。

本申请实施例中的存储器，可以包括如下至少一种类型：只读存储器(read-onlymemory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmabler-only memory，EEPROM)。在某些场景下，存储器还可以是只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

本申请中，“至少一个”是指一个或者多个。“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

在本申请所提供的几个实施例中，应该理解到，所揭露的数据库访问装置和方法，可以通过其它的方式实现。例如，以上所描述的数据库访问装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，数据库访问装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

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

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

Claims (16)

1.一种卡顿测试方法，其特征在于，包括：

确定第一滑动事件中实际滑动的时长和所述实际滑动的过程中的屏幕刷新总帧数；所述第一滑动事件为待测试应用程序的界面上的滑动事件；

根据所述实际滑动的时长和所述屏幕刷新总帧数确定所述实际滑动的过程中的屏幕刷新频率；

根据目标图像的绘制时长和所述屏幕刷新频率判断所述第一滑动事件中是否出现卡顿，所述目标图像为所述实际滑动的过程中所述目标应用程序绘制的任意一帧图像。

2.根据权利1所述的方法，其特征在于，所述确定第一滑动事件中实际滑动的时长，包括：

确定所述第一滑动事件持续过程中屏幕刷新的N帧图像，所述N为大于等于1的整数；

从所述N帧图像中确定与所述实际滑动对应的M帧图像；

按照绘制时间先后顺序确定所述M帧图像中的首帧图像和所述M帧图像中的尾帧图像，根据所述首帧图像的绘制时间以及所述尾帧图像的绘制时间，确定所述实际滑动的时长。

3.根据权利要求2所述的方法，其特征在于，所述从所述N帧图像中确定与所述实际滑动对应的M帧图像，

确定所述N帧图像按照绘制时间先后顺序排列后的相邻两帧图像的相似度；

若所述相似度小于阈值，则确定所述相邻两帧图像为所述实际滑动对应的图像。

4.根据权利要求2或3所述方法，其特征在于，所述方法还包括：

确定所述实际滑动的时段，所述实际滑动的时段的起始时刻为所述首帧图像的绘制时间，所述实际滑动的时段的结束时刻为所述尾帧图像的绘制时间；

确定与所述实际滑动的时段对应的软件性能信息，所述软件性能信息包括所述M帧图像中每一帧图像的绘制时长以及所述每一帧图像的绘制时间。

5.根据权利要求4所述的方法，其特征在于，所述软件性能信息为systrace信息。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述根据目标图像的绘制时长和所述屏幕刷新频率判断所述第一滑动事件中是否出现卡顿，包括：

若所述目标图像的绘制时长大于每帧刷新时长，则确定出现卡顿；所述每帧刷新时长为所述屏幕刷新频率的倒数。

7.一种装置，其特征在于，包括：

图像处理单元，用于确定第一滑动事件中实际滑动的时长和所述实际滑动的过程中的屏幕刷新总帧数；所述第一滑动事件为待测试应用程序的界面上的滑动事件；

计算单元，用于根据所述实际滑动的时长和所述屏幕刷新总帧数确定所述实际滑动的过程中的屏幕刷新频率；

测试单元用于，根据目标图像的绘制时长和所述屏幕刷新频率判断所述第一滑动事件中是否出现卡顿，所述目标图像为所述实际滑动的过程中所述目标应用程序绘制的任意一帧图像。

8.根据权利要求7所述的装置，其特征在于，所述图像处理单元具体用于，

确定所述第一滑动事件持续过程中屏幕刷新的N帧图像，所述N为大于等于1的整数；

从所述N帧图像中确定与所述实际滑动对应的M帧图像；

按照绘制时间先后顺序确定所述M帧图像中的首帧图像和所述M帧图像中的尾帧图像，根据所述首帧图像的绘制时间以及所述尾帧图像的绘制时间，确定所述实际滑动的时长。

9.根据权利要求8所述的装置，其特征在于，所述图像处理单元具体用于，确定所述N帧图像按照绘制时间先后顺序排列后的相邻两帧图像的相似度；

若所述相似度小于阈值，则确定所述相邻两帧图像为所述实际滑动对应的图像。

10.根据权利要求8或9所述的装置，其特征在于，所述测试单元还用于，

确定所述实际滑动的时段，所述实际滑动的时段的起始时刻为所述首帧图像的绘制时间，所述实际滑动的时段的结束时刻为所述尾帧图像的绘制时间；

确定与所述实际滑动的时段对应的软件性能信息，所述软件性能信息包括所述M帧图像中每一帧图像的绘制时长以及所述每一帧图像的绘制时间。

11.根据权利要求10所述的装置，其特征在于，所述软件性能信息为systrace信息。

12.根据权利要求7-11任一项所述的装置，其特征在于，所述测试单元具体用于，若判断所述目标图像的绘制时长大于每帧刷新时长，则确定出现卡顿；所述每帧刷新时长为所述屏幕刷新频率的倒数。

13.一种装置，其特征在于，包括处理器，所述处理器与存储器耦合；

存储器，用于存储计算机程序；

处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如权利要求1至6中任一项所述的方法。

14.一种计算机可读存储介质，包括程序或指令，当所述程序或指令被处理器运行时，如权利要求1至6中任意一项所述的方法被执行。

15.一种计算机程序产品，其特征在于，所述计算机程序产品包括指令，当所述指令被运行时，使得如权利要求1至6任一项所述的方法被执行。

16.一种芯片，其特征在于，所述芯片包括处理器和接口电路，所述接口电路和所述处理器耦合，所述处理器用于运行计算机程序或指令，使得如权利要求1至6任一项所述的方法被执行。

Images