CN110727592A

CN110727592A - 应用程序测试方法、介质、装置和计算设备

Info

Publication number: CN110727592A
Application number: CN201910961669.XA
Authority: CN
Inventors: 姜聪; 涂玉玲; 吴艳初; 崔奇凡
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2019-10-11
Filing date: 2019-10-11
Publication date: 2020-01-24

Abstract

本发明的实施方式提供了一种应用程序测试方法、介质、应用程序测试装置和计算设备。该方法包括：获取带有性能监控脚本的程序源代码，并对所述程序源代码进行编译后形成待测应用程序；在所述待测应用程序的运行过程中，利用所述性能监控脚本实时获取所述待测应用程序的性能信息；当所述性能信息中出现性能问题时，记录与所述性能问题相对应的堆栈信息；根据所述堆栈信息确定所述程序源代码中与所述性能问题相关的函数信息。本发明能够在待测应用程序上线前对其进行自动化地性能监控和测试，在快速发现性能问题和定位问题来源的情况下，能够高效且准确地实现对待测应用程序的修复和优化。

Description

应用程序测试方法、介质、装置和计算设备

技术领域

本发明的实施方式涉及通信及计算机技术领域，更具体地，本发明的实施方式涉及应用程序测试方法、介质、应用程序测试装置和计算设备。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

随着网络和计算机技术的发展，人们在沟通、社交、娱乐等活动中越来越依赖安装于智能手机、平板电脑等终端设备上的应用程序，这些应用程序为人们的日常生活和工作带来了极大的便利。

应用程序一般是由程序开发人员通过预先分析、设计和编码而形成的软件程序，应用程序在上线运行前需要经过各种性能测试，从而保证应用程序上线后的运行稳定性。现有的测试方式通常是由测试人员手工进行操作，这种测试方式不仅需要耗费大量的人力资源，而且仅能针对部分关注功能进行测试，整体测试效果较差。

发明内容

本发明的目的在于提供一种应用程序测试方法、介质、应用程序测试装置和计算设备，至少在一定程度上克服相关技术中存在的测试成本高、测试效果差等技术问题。

根据本发明的第一方面，提供一种应用程序测试方法，该方法包括：

获取带有性能监控脚本的程序源代码，并对所述程序源代码进行编译后形成待测应用程序；

在所述待测应用程序的运行过程中，利用所述性能监控脚本实时获取所述待测应用程序的性能信息；

当所述性能信息中出现性能问题时，记录与所述性能问题相对应的堆栈信息；

根据所述堆栈信息确定所述程序源代码中与所述性能问题相关的函数信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述获取带有性能监控脚本的程序源代码，包括：

从远程代码库中获取待测应用程序的程序源代码；

生成与所述程序源代码相对应的本地测试工程，并将性能监控脚本添加至所述本地测试工程中；

在所述程序源代码中***针对所述性能监控脚本的脚本引入代码和脚本调用代码。

在本发明的一些示例性实施方式中，基于以上技术方案，所述利用所述性能监控脚本实时获取所述待测应用程序的性能信息，包括：

确定待测性能指标，并利用所述性能监控脚本实时监测所述待测性能指标；

按照预设时间间隔获取对应于所述待测性能指标的基本性能数据，并确定获取所述基本性能数据时的时间信息以及程序页面信息；

根据所述基本性能数据、所述时间信息以及所述程序页面信息确定所述待测应用程序的性能信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述待测性能指标包括内存占用率、图像帧率、CPU使用率或者主线程卡顿性能中的至少一种。

在本发明的一些示例性实施方式中，基于以上技术方案，所述记录与所述性能问题相对应的堆栈信息，包括：

获取出现所述性能问题时的函数调用信息；

确定所述性能问题的问题类型；

根据所述函数调用信息以及所述问题类型记录与所述性能问题相对应的堆栈信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述问题类型包括以下类型中的至少一种：

内存占用率高于占用率阈值；

图像帧率低于帧率阈值；

CPU使用率高于使用率阈值；

主线程出现卡顿。

在本发明的一些示例性实施方式中，基于以上技术方案，所述根据所述堆栈信息确定所述程序源代码中与所述性能问题相关的函数信息，包括：

获取由多个所述堆栈信息组成的堆栈日志；

按照所述问题类型对所述堆栈日志中的堆栈信息进行分类以得到对应不同的问题类型的堆栈信息集合；

分别统计各个所述堆栈信息集合中的堆栈信息的函数调用信息；

根据统计结果确定所述程序源代码中与所述性能问题相关的函数信息。

在本发明的一些示例性实施方式中，基于以上技术方案，统计所述堆栈信息的函数调用信息，包括：

根据所述堆栈信息确定与所述性能问题相关的多个线程；

确定每个所述线程的外层函数调用入口以及内层调用函数；

分别统计各个所述外层函数调用入口以及内层调用函数的调用频次。

在本发明的一些示例性实施方式中，基于以上技术方案，所述根据统计结果确定所述程序源代码中与所述性能问题相关的函数信息，包括：

按照所述外层函数调用入口的调用频次对所述外层函数调用入口进行排序以确定一个或者多个目标入口；

按照所述内层调用函数的调用频次对所述内层调用函数进行排序以确定一个或者多个目标函数；

按照对应于不同外层函数调用入口的内层调用函数的调用频次对所述内层调用函数进行排序以确定一个或者多个对应于同一个外层函数调用入口的目标函数。

在本发明的一些示例性实施方式中，基于以上技术方案，所述方法还包括：

在所述待测应用程序的运行过程中，实时获取针对所述待测应用程序的操作信息；

确定与所述性能问题相对应的作用于所述待测应用程序的操作事件，并确定对应于所述操作事件的操作信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述实时获取针对所述待测应用程序的操作信息，包括：

实时截获作用于所述待测应用程序的操作事件；

当所述操作事件为触控事件时，获取所述触控事件的触控时间信息和触控轨迹信息；

根据所述触控时间信息确定所述操作事件的操作时间；

根据所述触控轨迹信息确定所述操作事件的操作位置；

根据所述触控时间信息和所述触控轨迹信息确定所述操作事件的操作类型；

将所述操作时间、所述操作位置以及所述操作类型确定为对应于所述操作事件的操作信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述操作事件包括一个目标操作事件和多个关联操作事件；所述确定与性能问题相对应的作用于待测应用程序的操作事件，包括：

根据出现所述性能问题的时间，确定作用于所述待测应用程序的所述目标操作事件；

将所述目标操作事件之前的多个操作事件确定为所述关联操作事件。

根据本发明的第二方面，提供一种介质，其上存储有程序，该程序被处理器执行时实现如以上各示例性实施方式中任一项所述的方法。

根据本发明的第三方面，提供一种应用程序测试装置，该装置包括：

程序编译模块，被配置为获取带有性能监控脚本的程序源代码，并对所述程序源代码进行编译后形成待测应用程序；

性能监控模块，被配置为在所述待测应用程序的运行过程中，利用所述性能监控脚本实时获取所述待测应用程序的性能信息；

堆栈记录模块，被配置为当所述性能信息中出现性能问题时，记录与所述性能问题相对应的堆栈信息；

函数确定模块，被配置为根据所述堆栈信息确定所述程序源代码中与所述性能问题相关的函数信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述程序编译模块包括：

代码获取单元，被配置为从远程代码库中获取待测应用程序的程序源代码；

脚本添加单元，被配置为生成与所述程序源代码相对应的本地测试工程，并将性能监控脚本添加至所述本地测试工程中；

脚本***单元，被配置为在所述程序源代码中***针对所述性能监控脚本的脚本引入代码和脚本调用代码；

程序编译单元，被配置为对所述程序源代码进行编译后形成待测应用程序。

在本发明的一些示例性实施方式中，基于以上技术方案，所述性能监控模块包括：

性能监测单元，被配置为确定待测性能指标，并利用所述性能监控脚本实时监测所述待测性能指标；

数据获取单元，被配置为按照预设时间间隔获取对应于所述待测性能指标的基本性能数据，并确定获取所述基本性能数据时的时间信息以及程序页面信息；

性能确定单元，被配置为根据所述基本性能数据、所述时间信息以及所述程序页面信息确定所述待测应用程序的性能信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述堆栈记录模块包括：

调用信息获取单元，被配置为获取出现所述性能问题时的函数调用信息；

问题类型确定单元，被配置为确定所述性能问题的问题类型；

堆栈信息记录单元，被配置为根据所述函数调用信息以及所述问题类型记录与所述性能问题相对应的堆栈信息。

内存占用率高于占用率阈值；

图像帧率低于帧率阈值；

CPU使用率高于使用率阈值；

主线程出现卡顿。

在本发明的一些示例性实施方式中，基于以上技术方案，所述函数确定模块包括：

堆栈日志获取单元，被配置为获取由多个所述堆栈信息组成的堆栈日志；

堆栈集合确定单元，被配置为按照所述问题类型对所述堆栈日志中的堆栈信息进行分类以得到对应不同的问题类型的堆栈信息集合；

调用信息统计单元，被配置为分别统计各个所述堆栈信息集合中的堆栈信息的函数调用信息；

函数信息确定单元，被配置为根据统计结果确定所述程序源代码中与所述性能问题相关的函数信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述调用信息统计单元，包括：

线程确定子单元，被配置为根据所述堆栈信息确定与所述性能问题相关的多个线程；

函数确定子单元，被配置为确定每个所述线程的外层函数调用入口以及内层调用函数；

频次统计子单元，被配置为分别统计各个所述外层函数调用入口以及内层调用函数的调用频次。

在本发明的一些示例性实施方式中，基于以上技术方案，所述函数信息确定单元包括：

调用入口确定子单元，被配置为按照所述外层函数调用入口的调用频次对所述外层函数调用入口进行排序以确定一个或者多个目标入口；

第一函数确定子单元，被配置为按照所述内层调用函数的调用频次对所述内层调用函数进行排序以确定一个或者多个目标函数；

第二函数确定子单元，被配置为按照对应于不同外层函数调用入口的内层调用函数的调用频次对所述内层调用函数进行排序以确定一个或者多个对应于同一个外层函数调用入口的目标函数。

在本发明的一些示例性实施方式中，基于以上技术方案，所述装置还包括：

操作信息获取模块，被配置为在所述待测应用程序的运行过程中，实时获取针对所述待测应用程序的操作信息；

操作信息确定模块，被配置为确定与所述性能问题相对应的作用于所述待测应用程序的操作事件，并确定对应于所述操作事件的操作信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述操作信息获取模块包括：

操作事件截获单元，被配置为实时截获作用于所述待测应用程序的操作事件；

触控信息获取单元，被配置为当所述操作事件为触控事件时，获取所述触控事件的触控时间信息和触控轨迹信息；

操作时间确定单元，被配置为根据所述触控时间信息确定所述操作事件的操作时间；

页面位置确定单元，被配置为根据所述触控轨迹信息确定所述操作时间的操作位置；

操作类型确定单元，被配置为根据所述触控时间信息和所述触控轨迹信息确定所述操作事件的操作类型；

操作信息确定单元，被配置为将所述操作时间、所述操作位置以及所述操作类型确定为对应于所述操作事件的操作信息。

在本发明的一些示例性实施方式中，基于以上技术方案，所述操作事件包括一个目标操作事件和多个关联操作事件；所述操作信息确定模块包括：

第一事件确定单元，被配置为根据出现所述性能问题的时间，确定作用于所述待测应用程序的所述目标操作事件；

第二事件确定单元，被配置为将所述目标操作事件之前的多个操作事件确定为所述关联操作事件。

根据本发明的第四方面，提供一种计算设备，包括：处理器和存储器，所述存储器存储有可执行指令，所述处理器用于调用所述存储器存储的可执行指令执行如以上各示例性实施方式中任一项所述的方法。

在本发明提供的技术方案中，通过获取待测应用程序的程序源代码并***性能监控脚本可以得到内置性能监控脚本的待测应用程序，能够在待测应用程序上线前对其进行自动化地性能监控和测试，在快速发现性能问题和定位问题来源的情况下，能够高效且准确地实现对待测应用程序的修复和优化。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

图1示出了应用本发明示例性实施方式的***架构示意图。

图2示意性地示出了本发明在一些示例性实施方式中的应用程序测试方法的步骤流程图。

图3示意性地示出了本发明在一些示例性实施方式中获取程序源代码的步骤流程图。

图4示意性地示出了在一应用场景中向待测应用程序中***性能监控脚本的流程框架。

图5示意性地示出了在一应用场景中向本地测试工程中添加性能监控脚本的步骤流程图。

图6示意性地示出了在一应用场景中集成和调用性能监控脚本的步骤流程图。

图7示意性地示出了在一应用场景中对本地测试工程进行打包安装的步骤流程图。

图8示意性地示出了在本发明的一些示例性实施方式中获取待测应用程序的性能信息的步骤流程图。

图9示意性地示出了在本发明一些示例性实施方式中记录堆栈信息的步骤流程图。

图10示意性地示出了在一应用场景中通过监控性能记录堆栈信息的方案流程框架。

图11示意性地示出了本发明一些示例性实施方式中通过堆栈信息分析确定函数信息的步骤流程图。

图12示意性地示出了在本发明一些示例性实施方式中统计函数调用信息的步骤流程图。

图13示意性地示出了本发明一些示例性实施方式中确定函数信息的步骤流程图。

图14示意性地示出了在一应用场景中对堆栈信息进行分类分析以确定函数信息的流程框架。

图15示意性地示出了在一应用场景中对一个堆栈信息集合进行堆栈分析的流程框架。

图16示意性地示出了本发明一些示例性实施方式中获取操作信息的步骤流程图。

图17示意性地示出了本发明一些示例性实施方式中实时获取操作信息的步骤流程图。

图18示意性地示出了在一应用场景中确定操作事件的步骤流程图。

图19示意性地示出了在一应用场景中确定操作信息的流程框架。

图20示意性地示出了在一应用场景中重现操作事件的逻辑框架。

图21示意性地示出了本发明一些示例性实施方式中的应用程序测试装置的结构框架。

图22示意性地示出了本发明一些示例性实施方式中调用信息统计单元的结构框架。

图23示意性地示出了本发明一些示例性实施方式中函数信息确定单元的结构框架。

图24示意性地示出了本发明一些示例性实施方式中的另一应用程序测试装置的结构框架。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本发明更加透彻和完整，并且能够将本发明的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种***、装置、设备、方法或计算机程序产品。因此，本发明可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

本发明中涉及的技术术语解释如下：

App：移动应用程序(英文：mobile application，简称mobile app、apps)，或称手机软件、手机应用程序、移动应用程序、移动应用、手机app等，是指设计给智能手机、平板电脑或其他移动设备运行的一种应用程序。本发明中的应用程序测试方法主要是以App的性能测试为例，同时也包括了针对笔记本电脑、台式电脑、车载电脑等终端设备开发的除移动应用以外的其他应用程序的测试方法。

服务器：一个管理资源并为用户提供服务的计算机软件，通常包括文件服务器、数据库服务器和应用程序服务器等多种类型。服务器通常以网络作为介质，既可以通过局域网对内提供服务，也可以通过广域网对外提供服务。

堆栈：即栈帧，也就是stack frame，其本质就是一种栈，只是这种栈专门用于保存函数调用过程中的各种信息，例如参数、返回地址、本地变量等。

日志：在计算机领域，日志文件(logfile)是一个记录了发生在运行中的操作***或其他软件中的事件的文件，或者记录了在网络聊天软件的用户之间发送的消息。日志记录(Logging)是指保存日志的行为。最简单的做法是将日志写入单个存放日志的文件。

函数：是一个固定的一个程序段，或称其为一个子程序，它在可以实现固定运算功能的同时，还带有一个入口和一个出口，所谓的入口，就是函数所带的各个参数，我们可以通过这个入口，把函数的参数值代入子程序，供计算机处理；所谓出口，就是指函数的函数值，在计算机求得函数值之后，由出口返回给调用该函数的程序。

git仓库：git是一个分布式版本控制软件，git仓库指远程的代码仓库。

编译打包：利用编译程序从源语言编写的源程序产生目标程序，最后生成可在计算机上安装的应用程序的过程。

FPS：FPS是图像领域中的定义，是指画面每秒传输帧数，通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多，所显示的动作就会越流畅。

内存：内存(Memory)也被称为内存储器和主存储器，其作用是用于暂时存放CPU中的运算数据，以及与硬盘等外部存储器交换的数据。内存占用率指的是当前运行进程所开销的内存。

CPU使用率：指的是当前运行程序占用的CPU资源，表示计算机在某个时间点的运行程序的情况。

卡顿：卡顿现象是出现在手机、笔记本等电子设备中的一种现象，出现状况为：进行各种电子设备操作过程中画面滞帧，也就是通常人们所说的“卡”。

此外，本发明中涉及的相关元素数量仅用于示例而非限制，以及相关元素的命名都仅用于区分，而不具有任何限制含义。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

发明概述

本发明人发现，为了对应用程序进行性能测试，通常可以在应用上线前的测试阶段由测试人员进行手工操作，产生一定量的性能数据，并收集对应的堆栈日志。通过性能数据及堆栈日志，定位导致出现性能问题的业务函数入口。这种测试方式由于需要测试人员手工操作，耗费了大量的人力资源，导致测试成本升高。即便如此，在耗费了大量的人力进行人工操作后，仍然只能产生较少的数据量，在整体测试效果上差强人意。另外，这种测试方式无法直接定位产生性能问题的来源，需要继续花费大量人力进行分析。

为了节省测试阶段的人力成本，一种可选的测试方式是直接取消在测试阶段的部分测试内容，而是采用在App中加入监测代码，以实时收集App运行过程中的堆栈日志。在App上线后，在线上对用户开启监测，获取线上用户使用App过程中的性能数据并收集堆栈日志，通过堆栈日志定位导致出现性能问题的业务函数入口。这种测试方式虽然可以在一定程度上改善测试效果，但是只能在App上线之后才监测用户性能问题，发现问题时便已经影响到了用户的使用体验，具有一定的滞后性。另外，由于性能问题只能定位到业务的函数入口，无法准确定位问题，指导意义不强，分析性能问题同样需要耗费大量的人力。除此之外，监测任务本身会对性能有影响，在一定程度上影响了用户的使用性能体验。

针对以上相关技术中存在的问题和缺陷，本发明提供了一种新型的应用程序测试方法。该方法融合监控脚本、自动化、monkey测试、持续集成等技术手段，使被测应用在测试阶段即可收集到足够的数据，暴露出应用的性能问题，在上线前进行解决。不影响用户体验，也不需要耗费多余的人力。

在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。

应用场景总览

需要注意的是，下述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。

图1示出了应用本发明示例性实施方式的***架构示意图。如图1所示，***架构100可以包括测试终端110、网络120和服务端130。测试终端110可以包括智能手机、平板电脑、笔记本电脑、台式电脑等各种用于运行待测应用程序的终端设备。服务端130可以包括网络服务器、应用服务器、数据库服务器等各种服务器设备，服务端130可以为测试终端110提供网络资源和数据服务。网络120可以是能够在测试终端110和服务端130之间提供通信链路的各种连接类型的通信介质，例如可以是有线通信链路或者无线通信链路。

根据实现需要，本发明示例性实施方式的***架构可以具有任意数目的测试终端、网络和服务端。例如，服务端130可以是由多个服务器设备组成的服务器群组。

举例而言，在一个应用场景下，本发明首先可以将性能监控脚本***至待测应用程序的程序源代码中，然后将该待测应用程序安装于测试终端110上。在测试终端110上自动运行该待测应用程序并模拟用户操作，例如可以随机模拟点击、长按、滑动等操作。在待测应用程序的运行过程中可以实时记录下CPU、内存、FPS、卡顿等性能数据，同时记录相应的堆栈信息。当出现性能问题时，可以将相关性能数据和堆栈信息通过网络120发送至服务端130，在不影响线上用户使用、不需要人力介入的前提下，被测应用程序可以源源不断地***作并上传大量数据到服务端130。服务端130对相关数据进行分析后，可以定位导致出现某类性能问题的最关键的业务函数，大大提高性能问题的解决效率。

示例性方法

下面结合上述的应用场景，参考图2至图20来描述根据本发明示例性实施方式的应用程序测试方法。

图2示意性地示出了本发明在一些示例性实施方式中的应用程序测试方法的步骤流程图。如图2所示，该方法主要可以包括以下步骤：

步骤S210.获取带有性能监控脚本的程序源代码，并对程序源代码进行编译后形成待测应用程序。

针对一个需要进行性能测试的待测应用程序，如音乐APP或者社交APP，本步骤首先获取该程序的程序源代码，该程序源代码中通过插桩技术***了用于进行性能监控和数据收集的性能监控脚本。在对该程序源代码进行编译后可以形成内置有性能监控脚本的待测应用程序。

步骤S220.在待测应用程序的运行过程中，利用性能监控脚本实时获取待测应用程序的性能信息。

编译得到的待测应用程序可以安装在测试终端上，例如可以直接安装在作为测试机的手机上，或者可以安装在具有手机操作***模拟环境的电脑终端或者服务器终端上。由于待测应用程序中内置了性能监控脚本，当待测应用程序在测试终端上运行时，性能监控脚本也将同步运行，实时地获取待测应用程序的性能信息。该性能信息可以是针对某一种特定性能的监控结果，也可以是同时针对多种性能的监控结果。在一些可选的实施方式中，本步骤可以利用monkey测试框架随机产生模拟点击、长按、滑动等各种人为操作的控制指令，从而可以监控待测应用程序在使用状态下的性能。

步骤S230.当性能信息中出现性能问题时，记录与性能问题相对应的堆栈信息。

基于对待测应用程序的性能监控，可以实时地判断待测应用程序的运行状态，当某一种或者某几种性能出现一定的性能问题时，本步骤可以实时地记录与性能问题相对应的堆栈信息。这部分堆栈信息可以实时地通过网络通信上传至服务端，或者也可以记录在堆栈日志中，在满足一定的数据通信条件后再将堆栈日志中的堆栈信息统一进行数据上传，本发明对此不做特殊限定。

步骤S240.根据堆栈信息确定程序源代码中与性能问题相关的函数信息。

服务端根据测试终端上传的堆栈信息，在进行信息的分析和统计后，可以确定程序源代码中与性能问题相关的函数信息，亦即可以定位待测应用程序中引发该性能问题的一段或者多段子程序。这里的函数信息主要可以包括待测应用程序在响应某一操作指令或者执行某一程序功能时所调用的业务函数以及相应的函数调用入口。

以上步骤是以测试终端和服务端共同进行应用程序测试为例进行说明的。需要说明的是，如果测试终端具有足够的计算能力，以上各步骤也可以单独在测试终端上执行。又或者在服务端能够模拟应用程序的真实运行环境的情况下，例如可以在服务端安装用于模拟手机操作***的模拟器，以上各步骤也可以单独在服务端上执行。

在本发明示例性实施方式提供的应用程序测试方法中，通过获取待测应用程序的程序源代码并***性能监控脚本可以得到内置性能监控脚本的待测应用程序，能够在待测应用程序上线前对其进行自动化地性能监控和测试，在快速发现性能问题和定位问题来源的情况下，能够高效且准确地实现对待测应用程序的修复和优化。

图3示意性地示出了本发明在一些示例性实施方式中获取程序源代码的步骤流程图。如图3所示，在以上实施方式的基础上，步骤S110中的获取带有性能监控脚本的程序源代码，可以包括以下步骤：

步骤S310.从远程代码库中获取待测应用程序的程序源代码。

远程代码库中存储有各种应用程序的程序源代码，而且在程序开发阶段，一个指定的待测应用程序一般也会具有多个不同的分支，每个分支可以对应一个程序开发版本，同一个待测应用程序的不同分支在程序源代码上也存在一定的差异。本步骤针对确定的待测应用程序，可以从远程代码库中选择一个被测的分支并获取该分支对应的程序源代码。

步骤S320.生成与程序源代码相对应的本地测试工程，并将性能监控脚本添加至本地测试工程中。

为了不影响远程代码库中存储的原始的程序源代码，本步骤需要将待测应用程序的程序源代码拉取到本地，生成与之对应的本地测试工程，同时将性能监控脚本添加至本地测试工程中。

步骤S330.在程序源代码中***针对性能监控脚本的脚本引入代码和脚本调用代码。

完成性能监控脚本的添加后，本步骤还需要在本地测试工程的程序源代码中***针对性能监控脚本的脚本引入代码和脚本调用代码，以实现性能监控脚本与程序源代码的融合，使得运行程序的同时能够顺利地同步运行性能监控脚本。

图4示意性地示出了在一应用场景中向待测应用程序中***性能监控脚本的流程框架。如图4所示，首先从远程代码库410(如远程git仓库)将需要测试的程序源代码拉取到本地，形成本地测试工程420。然后可以通过shell脚本和ruby脚本将性能监控脚本430自动化地***到本地测试工程的程序源代码中，最后对***性能监控脚本的程序源代码进行编译打包后即可得到内置性能监控脚本的待测应用程序440。

在该应用场景下，利用基于Java开发的持续集成工具Jenkins可以配置远程git仓库的分支，在选择某一个被测分支(对应于一个待测应用程序的版本)后，通过git插件可以将最新的远程代码更新到本地。性能监控脚本被打包放置在一个文件夹中，然后通过ruby脚本将性能监控脚本添加至本地测试工程中。

图5示意性地示出了在一应用场景中向本地测试工程中添加性能监控脚本的步骤流程图。如图5所示，利用ruby脚本添加性能监控脚本的方法包括以下步骤：

步骤S510.打开本地测试工程；

步骤S520.在本地测试工程中指定一个测试目标target，该测试目标一般可以是待测试应用程序本身。

步骤S530.判断用于存放性能监控脚本的group是否存在。若该group不存在，则执行步骤S540。若该group已存在，则执行步骤S550。

步骤S540.创建group。

步骤S550.判断性能监控脚本的文件是否存在。若group中不存在相应的文件，则执行步骤S560。若group中已存在相应的文件，则直接保存本地测试工程。

步骤S560.向group中添加性能监控脚本的文件。

步骤S570.添加framework/.a的引用，并保存本地测试工程。

步骤S580.添加bundle的引用，并保存本地测试工程。

步骤S590.修改buildsettings，并保存本地测试工程。

性能监控脚本的文件添加至本地测试工程后，需要在本地测试工程中集成和调用该性能监控脚本，这里主要可以使用shell脚本的sed命令。

图6示意性地示出了在一应用场景中集成和调用性能监控脚本的步骤流程图。如图6所示，利用shell脚本集成性能监控脚本的方法包括以下步骤：

步骤S610.指定需要***代码的工程文件；

步骤S620.通过sed命令在指定行***针对性能监控脚本的脚本引入代码；

步骤S620.通过sed命令在指定行***针对性能监控脚本的脚本调用代码。

经过图5和图6所示的以上方法步骤，实现了将远程git仓库指定分支的最新代码拉取到本地，在本地自动化***性能监控脚本，并实现了对性能监控脚本的引入及开启调用。这种做法可以在不影响其他用户，不污染远程git仓库的基础上，实现对待测应用程序的插桩。在此之后，可以将***了性能监控脚本的本地测试工程编译打包安装到测试终端上，以运行ios操作***的手机作为测试终端为例，图7示意性地示出了在一应用场景中对本地测试工程进行打包安装的步骤流程图。如图7所示，打包安装本地测试工程主要包括以下步骤：

步骤S710.使用xcodebuild命令archive出.app。

步骤S720.通过增加swift支持将.app压缩成ipa。

步骤S730.使用ideviceinstaller命令将ipa包安装到手机上。

完成本地测试工程的打包安装后，即可在测试终端上开始运行内置了性能监控脚本的待测应用程序，并在其运行过程中进行性能监控和测试。

图8示意性地示出了在本发明的一些示例性实施方式中获取待测应用程序的性能信息的步骤流程图。如图8所示，在以上各实施方式的基础上，步骤S220中的利用性能监控脚本实时获取待测应用程序的性能信息，可以包括以下步骤：

步骤S810.确定待测性能指标，并利用性能监控脚本实时监测待测性能指标。

根据用户的实际测试需求，本步骤可以确定一个或者多个待测性能指标，同时利用性能监控脚本实时地监测所选择或者指定的待测性能指标。在一些可选的实施方式中，待测性能指标可以包括内存占用率、图像帧率、CPU使用率或者主线程卡顿性能中的至少一种。

步骤S820.按照预设时间间隔获取对应于待测性能指标的基本性能数据，并确定获取基本性能数据时的时间信息以及程序页面信息。

针对每种待测性能指标，可以配置相同的或者不同的预设时间间隔，从而可以周期性地获取对应于各种待测性能指标的基本性能数据。例如，预设时间间隔为1s，那么每隔1s便可以获取一次内存占用率、图像帧率等基本性能数据。在获取基本性能数据的同时，可以确定获取当前数据的时间信息以及程序页面信息。程序页面信息例如可以是当前页面的页面名称或者当前页面的页面路径。

步骤S830.根据基本性能数据、时间信息以及程序页面信息确定待测应用程序的性能信息。

在由步骤S820周期性地获取基本性能数据、时间信息以及程序页面信息的基础上，本步骤可以确定待测应用程序在运行过程中的每个时间节点下的性能信息。利用这些按照时间顺序记录的性能信息，可以对待测应用程序的运行状态做出判断，从而能够及时地发现性能问题并记录对应时间节点下的堆栈信息，以供后续进行分析优化。

图9示意性地示出了在本发明一些示例性实施方式中记录堆栈信息的步骤流程图。如图9所示，在以上各实施方式的基础上，步骤S230中的记录与性能问题相对应的堆栈信息，可以包括以下步骤：

步骤S910.获取出现性能问题时的函数调用信息。

待测应用程序在运行过程中不管是打开页面还是关闭页面，或者在多个页面之间跳转，又或者在某一页面内实现某种程序功能，这些操作事件的实现都是通过底层函数调用来控制的，因此获取函数调用信息是分析性能问题出现原因的关键所在。

步骤S920.确定性能问题的问题类型。

当待测应用程序中的性能监控脚本同时监测多种待测性能指标时，不同的待测性能指标即对应了不同类型的性能问题。例如，本步骤中确定的性能问题的问题类型可以包括内存占用率高于占用率阈值、图像帧率低于帧率阈值、CPU使用率高于使用率阈值以及主线程出现卡顿等多种类型中的至少一种。

步骤S930.根据函数调用信息以及问题类型记录与性能问题相对应的堆栈信息。

针对每个监控后确定的性能问题，均可以获取相应的函数调用信息并确定其问题类型，从而可以针对每个性能问题记录与之对应的堆栈信息。

图10示意性地示出了在一应用场景中通过监控性能记录堆栈信息的方案流程框架。在该应用场景中，可以采用轮询的方式监控各个主要的性能指标数据以及当前所在页面，当出现性能问题时，可以获取并记录当前的堆栈信息。

如图10所示，在该应用场景中的性能监控主要从页面信息获取、性能数据监测和主线程卡顿监测三个方面进行，具体包括以下步骤：

步骤S1010.开启监测。

步骤S1020.截获页面方法初始化。

步骤S1021.获取当前页面名称。

步骤S1030.打开性能数据监测开关。

步骤S1031.启用定时器。

步骤S1032.获取FPS监控数据。

步骤S1033.获取CPU监控数据。

步骤S1034.获取内存监控数据。

步骤S1040.打开RunLoop卡顿监测开关。

步骤S1041.监测主线程是否出现卡顿。

步骤S1050.记录所有性能监控数据及当前时间。

步骤S1060.当任意性能数据超出阈值或者主线程出现卡顿时，记录当前堆栈信息。

在该应用场景中，通过配置定时器可以周期性地对FPS、CPU以及内存等相关的基本性能数据进行监控，例如可以每隔1秒获取一次相关数据。这里使用了同一个定时器为各种性能数据配置了相同的数据获取周期，而在其他应用场景中，也可以使用多个定时器分别对各种性能数据按照不同的时间周期进行数据监控。

在该应用场景中，针对主线程是否卡顿这一性能是通过RunLoop卡顿监测来实现的。RunLoop即运行循环，是保持程序运行和处理应用程序中各种事件的逻辑处理对象，每一个线程都有与之对应的RunLoop对象，当有任务处理时，线程的RunLoop会保持忙碌，而在没有任何任务处理时，会让线程休眠，从而让出CPU。当再次有任务需要处理时，RunLoop会被唤醒，来处理事件，直到任务处理完毕，再次进入休眠。通过监控RunLoop的运行状态可以确定单个任务的处理时间，如果该时间超过某一阈值即可判断线程出现卡顿。

基于监控性能数据得到的堆栈信息可以在后续的分析处理过程中准确地定位出现性能问题的问题类型和问题原因，尤其可以对记录的大量堆栈信息数据进行统计分析，从中分析得到对性能影响程度最大的若干函数信息。

图11示意性地示出了本发明一些示例性实施方式中通过堆栈信息分析确定函数信息的步骤流程图。如图11所示，在以上各实施方式的基础上，步骤S240.根据堆栈信息确定程序源代码中与性能问题相关的函数信息，可以包括以下步骤：

步骤S1110.获取由多个堆栈信息组成的堆栈日志。

按照发现性能问题以及形成堆栈信息的时间顺序对一段时间周期内的堆栈信息进行记录即形成堆栈日志。在一些可选的实施方式中，测试终端可以在满足一定预设条件时向服务端上传堆栈日志，例如可以按照预设时间间隔定期地向服务端上传堆栈日志，或者可以在本地存储的堆栈日志达到一定数据量时向服务端上传堆栈日志。

步骤S1120.按照问题类型对堆栈日志中的堆栈信息进行分类以得到对应不同的问题类型的堆栈信息集合。

堆栈日志中记录了待测应用程序在出现各种性能问题时的堆栈信息，本步骤按照问题类型的不同可以对堆栈日志中的所有堆栈信息进行分类，从而得到对应不同问题类型的堆栈信息集合。

步骤S1130.分别统计各个堆栈信息集合中的堆栈信息的函数调用信息。

在完成堆栈信息的分类后，针对每个堆栈信息集合分别进行函数调用信息的统计。例如由步骤S1120分类得到对应于FPS过低、CPU使用率过高、内存占用率过高和主线程卡顿等四种问题类型的四个堆栈信息集合后，本步骤可以通过统计得到对应于不同性能问题的四组函数调用信息。

步骤S1140.根据统计结果确定程序源代码中与性能问题相关的函数信息。

根据步骤S1130中对函数调用信息的统计结果，本步骤可以确定程序源代码中分别与各种性能问题相关的函数信息。这里的函数信息可以包括具体的业务函数以及业务函数的调用入口。

图12示意性地示出了在本发明一些示例性实施方式中统计函数调用信息的步骤流程图。如图12所示，在以上各实施方式的基础上，步骤S1130中的统计堆栈信息的函数调用信息，可以包括以下步骤：

步骤S1210.根据堆栈信息确定与性能问题相关的多个线程。

每一个性能问题的出现对应了一个或者多个线程的运行异常，根据堆栈信息集合中的堆栈信息可以确定与同一类型的性能问题相关的多个线程。

步骤S1220.确定每个线程的外层函数调用入口以及内层调用函数。

每个线程通过逐层调用业务函数的方式来实现相应的业务功能。在确定对应于同一种性能问题的多个线程后，本步骤将继续获取每个线程的外层函数调用入口以及内层调用函数。一般而言，一个线程可以对应确定一个外层函数调用入口，而一个外层函数调用入口又可以对应确定多个不同层次的内层调用函数。相应地，一个内层调用函数也可以通过多个不同的外层函数调用入口而被多个不同的线程所调用。

步骤S1230.分别统计各个外层函数调用入口以及内层调用函数的调用频次。

基于步骤S1220针对每个线程进行函数调用信息的分析后，本步骤可以统计每个外层函数调用入口的调用频次以及每个内层调用函数的调用频次。调用频次越高，则说明对应的外层函数调用入口或者内层调用函数引发性能问题的次数越多，进而也说明了这些外层函数调用入口或者内层调用函数对待测应用程序运行性能的影响程度越高。而如果某一外层函数调用入口或者内层调用函数的调用频次较低，则说明这些函数信息导致的性能问题是偶发性的，是相对而言较为次要的影响因素。换言之，通过确定调用频次较高的外层函数调用入口以及内层调用函数可以确定对引发性能问题起到主要作用的函数信息。

图13示意性地示出了本发明一些示例性实施方式中确定函数信息的步骤流程图。如图13所示，在以上各实施方式的基础上，步骤S1140.根据统计结果确定程序源代码中与性能问题相关的函数信息，可以包括以下步骤：

步骤S1310.按照外层函数调用入口的调用频次对外层函数调用入口进行排序以确定一个或者多个目标入口。

外层函数调用入口可以按照调用频次由高到低的顺序进行排序，按照排序结果选取一个或者多个目标入口。例如，本步骤可以选取调用频次最高的10个或者20个外层函数调用入口作为目标入口。又例如，本步骤可以选取调用频次超过某一阈值的一个或者多个外层函数调用入口作为目标入口。

步骤S1320.按照内层调用函数的调用频次对内层调用函数进行排序以确定一个或者多个目标函数。

内层调用函数也可以按照调用频次由高到低的顺序进行排序，按照排序结果选取一个或者多个目标函数。例如，本步骤可以选取调用频次最高的10个或者20个内层调用函数作为目标函数。又例如，本步骤可以选取调用频次超过某一阈值的一个或者多个内层调用函数作为目标函数。在本步骤中，对应于不同外层函数调用入口的内存调用函数可以合并进行排序。例如，某个内层调用函数被两个不同的外层函数调用入口分别调用了3次和5次，那么该内层调用函数的调用频次为8。

步骤S1330.按照对应于不同外层函数调用入口的内层调用函数的调用频次对内层调用函数进行排序以确定一个或者多个对应于同一个外层函数调用入口的目标函数。

步骤S1320中直接对所有内层调用函数的调用频次进行排序，与之不同的是，本步骤需要区分每一次内层调用函数的调用所对应的外层函数调用入口，对应于不同外层函数调用入口的内层调用函数需要分别进行排序。例如，某个内层调用函数被两个不同的外层函数调用入口分别调用了3次和5次，那么该内层调用函数的调用频次分别为3次和5次，该内层调用函数在本步骤的排序结果中的最高调用频次即为5次，而非8次。本步骤通过这种排序方式可以确定一个或者多个对应于同一个外层函数调用入口的目标函数。

图11至图13提供了根据监控得到的堆栈信息确定函数信息的方法步骤，下面结合一具体应用场景对如何确定函数信息的相关细节进行说明。

图14示意性地示出了在一应用场景中对堆栈信息进行分类分析以确定函数信息的流程框架。如图14所示，在具有全量数据的堆栈日志中包括有各种对应不同问题类型的堆栈信息，同时这些堆栈信息也标记有相应问题类型的类型标签。通过遍历堆栈日志中的堆栈信息，可以将这些堆栈信息分类至对应于“内存占用率过高”、“FPS过高”、“CPU使用率过高”以及“卡顿”等四种性能问题的四个堆栈信息集合。然后再对每个堆栈信息集合中的堆栈信息进行堆栈分析可以确定相应的函数信息。

例如，针对“内存占用率过高”的堆栈信息集合，通过堆栈分析可以确定出现内存占用率过高的调用频次最高的内层调用函数top_n、调用频次最高的外层函数调用入口top_n、对应于同一调用入口的调用频次最高的内层调用函数top_n。这里的n可以根据实际需要进行配置，例如当n可以取值为10时，通过堆栈分析可以确定出现内存占用率过高的调用频次最高的10个内层调用函数、调用频次最高的10个外层函数调用入口以及对应于同一调用入口的调用频次最高的10个内层调用函数。以此类推，可以分别确定对应于“FPS过高”、“CPU使用率过高”以及“卡顿”等其他堆栈信息集合的函数信息。

图15示意性地示出了在一应用场景中对一个堆栈信息集合进行堆栈分析的流程框架。如图15所示，以“内存占用率过高”的堆栈信息集合为例，逐个线程进行堆栈分析的方法包括以下步骤：

步骤S1510.判断是否已经分析完所有线程。如果所有线程都已完成分析，则可以结束当前堆栈信息集合的堆栈分析。如果还有线程没有完成分析，则继续执行步骤S1520。

步骤S1520.分析下一个线程。

步骤S1530.获取当前线程的最外层的外层函数调用入口，并将外层函数调用入口的相关数据存放在文件A中。

步骤S1540.逐层获取当前线程的内层调用函数，且最多获取内部三个层次的内层调用函数，同时将内层调用函数的相关数据存放在文件B中。文件A中的外层函数调用入口与文件B中的内层调用函数通过线程ID建立关联关系。

步骤S1550.从文件A中统计出调用频次最高的外层函数调用入口top_n。

步骤S1560.从文件B中统计出调用频次最高的内层调用函数top_n。

步骤S1570.结合文件A和文件B，统计出对应于同一外层函数调用入口的调用频次最高的内层调用函数top_n。

基于以上实施方式以及应用场景中的通过堆栈分析确定函数信息的方法实现了自动定位出导致某一类性能问题(比如内存占用率过高)的最有影响的外层函数调用入口及内层调用函数。可以帮助应用程序开发人员准确地定位到程序源代码中的业务函数，极大地提高了开发人员定位问题的效率，节省了大量的人力排查成本。

如果监测到某一次测试终端上传的性能数据特别糟糕，或者某一类性能问题频繁出现，那么需要对某一特定时刻或者某一时间段内上传的性能问题及堆栈日志做更深入的分析，如果能够重现当次的用户操作轨迹，将会极大地节省分析的人力及时间成本。基于这一考虑，本发明还提供了重现操作事件的方法。图16示意性地示出了本发明一些示例性实施方式中获取操作信息的步骤流程图。如图16所示，在以上各实施方式的基础上，应用程序测试方法还可以包括以下步骤：

步骤S1610.在待测应用程序的运行过程中，实时获取针对待测应用程序的操作信息。

为了模拟用户使用待测应用程序的场景，本发明可以利用Monkey测试框架随机产生点击、滑动等各种操作事件，在本步骤中将对这些操作事件的操作信息进行实时记录，操作信息的记录内容主要可以包括操作时间、操作页面、操作位置、操作类型等等。

步骤S1620.确定与性能问题相对应的作用于待测应用程序的操作事件，并确定对应于操作事件的操作信息。

通过步骤S220可以对待测应用程序的性能信息进行监控，一旦待测应用程序在运行过程出现性能问题，本步骤便可以确定与该性能问题相对应的作用于待测应用程序的操作事件，同时可以确定与该操作事件相对应的操作信息。

通过实时监控操作事件并获取相应的操作信息可以准确定位待测应用程序在出现性能问题时的操作页面，从程序源代码以及应用界面两个层面定位出产生性能问题的原因并重现出导致产生性能问题的操作事件。

图17示意性地示出了本发明一些示例性实施方式中实时获取操作信息的步骤流程图。如图17所示，在以上各实施方式的基础上，步骤S1610中的实时获取针对待测应用程序的操作信息，可以包括以下步骤：

步骤S1710.实时截获作用于待测应用程序的操作事件。

本步骤可以利用hook技术(钩子函数)截获待测应用程序在响应操作事件时的函数调用信息，即可以截获作用于待测应用程序的操作事件。基于这一技术，在待测应用程序尚未做出响应之前便可以先对操作事件进行判断和分析以及加工处理。

步骤S1720.当操作事件为触控事件时，获取触控事件的触控时间信息和触控轨迹信息。

触控时间信息可以包括触控操作的开始时间StartTime和结束时间EndTime，触控轨迹信息可以包括触控操作的起始位置BeginPoint和结束位置EndPoint，另外，触控轨迹信息还可以包括触控操作的多个中间位置。

步骤S1730.根据触控时间信息确定操作事件的操作时间。

操作事件的操作时间可以表示为每次触控操作的时间戳。对于一个瞬时性的操作事件，如点击操作，可以确定一个与之对应的时间戳作为操作时间。而对于一个持续性的操作事件，如长按操作或者滑动操作，可以确定与之对应的多个时间戳作为操作时间。

步骤S1740.根据触控轨迹信息确定操作事件的操作位置。

操作事件的操作位置可以表示为每次触控操作在应用程序交互界面上的位置坐标。对于一个固定位置的操作事件，如点击操作或者长按操作，可以确定一个与之对应的位置坐标作为操作位置。而对于一个位置变化的操作事件，如滑动操作，可以确定与之对应的一组位置坐标作为操作位置。

步骤S1750.根据触控时间信息和触控轨迹信息确定操作事件的操作类型。

结合触控时间信息和触控轨迹信息可以确定操作事件的操作类型，具体可以根据触控操作的开始时间、结束时间、起始位置和结束位置等信息判断触控操作的操作类型，该操作类型例如可以包括点击、长按、滑动等等。

步骤S1760.将操作时间、操作位置以及操作类型确定为对应于操作事件的操作信息。

由以上步骤获得的操作时间、操作位置以及操作类型可以确定为对应于操作事件的操作信息，而且由于操作时间的唯一性，利用操作时间也可以唯一确定与之对应的操作事件。

由于一些操作事件具有一定的连贯性，而且有些性能问题的出现也具有一定的时间滞后性，在步骤S1620中确定的与性能问题相对应的操作事件可以包括一个目标操作事件和多个关联操作事件。图18示意性地示出了在一应用场景中确定操作事件的步骤流程图，如图18所示，步骤S1620中的确定与性能问题相对应的作用于待测应用程序的操作事件，可以进一步包括以下步骤：

步骤S1810.根据出现性能问题的时间，确定作用于待测应用程序的目标操作事件。

步骤S1820.将目标操作事件之前的多个操作事件确定为关联操作事件。

在本示例性实施方式中，可以按照时间顺序在目标操作事件之前选取预设数量的多个操作事件作为关联操作事件。

图16至图18提供了获取操作信息以重现与性能问题相关的操作事件的方法步骤。下面结合一具体应用场景对如何确定操作信息和重现操作事件的细节进行说明。

图19示意性地示出了在一应用场景中确定操作信息的流程框架。如图19所示，在待测应用程序运行过程中实时获取操作信息的方法包括以下步骤：

步骤S1910.通过hook技术截获操作事件。

步骤S1920.判断截获到的操作事件是否为触控事件。如果判断一个操作事件不是触控事件，则认为该操作事件不属于手势交互行为，忽略此次操作事件的监控。如果判断一个操作事件是触控事件，则继续执行步骤S1930。

步骤S1930.记录此次触控事件所携带的信息，具体可以包括开始时间StartTime、结束时间EndTime、起始位置BeginPoint和结束位置EndPoint。

步骤S1940.根据记录的信息判断BeginPoint是否等于EndPoint。如果判断二者相等，则继续执行步骤S1950。如果判断二者不等，则跳转至步骤S1970。

步骤S1950.判断StartTime与EndTime的时间差是否小于预设阈值。如果判断二者的时间差小于预设阈值，则继续执行步骤S1960。如果判断二者的时间差大于或者等于预设阈值，则跳转至步骤S1980。

步骤S1960.判定当前触控事件的操作类型为点击操作，同时记录该触控事件的事件时间、起始位置和结束位置。

步骤S1970.判定当前触控事件的操作类型为滑动操作或者拖拽操作，同时记录该触控事件的事件时间、滑动/拖拽时长、起始位置和结束位置。

步骤S1980.判定当前触控事件的操作类型为长按操作，同时记录该触控事件的事件时间、按压时长、起始位置和结束位置。

图20示意性地示出了在一应用场景中重现操作事件的逻辑框架。如图20所示，由以上各示例性实施方式提供的技术方案可以获得记录操作信息的操作步骤文件2010以及记录堆栈信息的堆栈日志文件2020。其中，操作步骤文件2010中记录了每个触控事件对应的操作时间2011、操作类型2012和操作位置2013，堆栈日志文件2020中记录了每个性能问题对应的时间戳2021、基本性能数据2022、堆栈信息2023和程序页面2024。通过操作步骤文件2010中操作时间2011可以准确查找堆栈日志文件2020中与之对应的一个时间戳2021，而根据一个时间戳2021也可以准确查找到与之对应的一个操作时间2011。

另外，根据时间戳2021还可以在堆栈日志文件2020中查找到出现性能问题时的程序页面2024，而根据操作时间2011则可以在操作步骤文件2010中确定与之对应的操作类型2012和操作位置2013。利用程序页面2024结合操作时间2011、操作类型2012和操作位置2013即可以重现出在某个指定的时间节点上，待测应用程序在某个程序页面内触发了在某一坐标位置上实施的某一操作类型的操作事件2030。更进一步地，在确定操作时间2011的基础上，可以通过重现在操作时间2011之前的多个操作事件而获得在出现性能问题时的一段时间内所触发的操作事件序列，从而可以提高性能问题分析的可靠性。

示例性介质

在介绍了本发明示例性实施方式的方法之后，接下来，对本发明示例性实施方式的介质进行说明。

在一些可能的实施方式中，本发明的各个方面还可以实现为一种介质，其上存储有程序代码，当所述程序代码被设备的处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的应用程序测试方法中的步骤。

在本发明的一些示例性实施方式中，所述设备的处理器执行所述程序代码时可以用于实现如图2所示的以下步骤：步骤S210.获取带有性能监控脚本的程序源代码，并对程序源代码进行编译后形成待测应用程序。步骤S220.在待测应用程序的运行过程中，利用性能监控脚本实时获取待测应用程序的性能信息。步骤S230.当性能信息中出现性能问题时，记录与性能问题相对应的堆栈信息。步骤S240.根据堆栈信息确定程序源代码中与性能问题相关的函数信息。

在本发明的其他一些实施方式中，所述设备的处理器执行所述程序代码时也可以用于实现如图3至图20中所示的各个方法步骤。

需要说明的是：上述的介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线、光缆、RF等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

示例性装置

在介绍了本发明示例性实施方式的介质之后，接下来，参考图21至图24对本发明示例性实施方式的应用程序测试装置进行说明。

图21示意性地示出了本发明一些示例性实施方式中的应用程序测试装置的结构框架，如图21所示，应用程序测试装置2100主要可以包括：

程序编译模块2110，被配置为获取带有性能监控脚本的程序源代码，并对程序源代码进行编译后形成待测应用程序；

性能监控模块2120，被配置为在待测应用程序的运行过程中，利用性能监控脚本实时获取待测应用程序的性能信息；

堆栈记录模块2130，被配置为当性能信息中出现性能问题时，记录与性能问题相对应的堆栈信息；

函数确定模块2140，被配置为根据堆栈信息确定程序源代码中与性能问题相关的函数信息。

在本发明的一些示例性实施方式中，程序编译模块2110可以进一步包括：

代码获取单元2111，被配置为从远程代码库中获取待测应用程序的程序源代码；

脚本添加单元2112，被配置为生成与程序源代码相对应的本地测试工程，并将性能监控脚本添加至本地测试工程中；

脚本***单元2113，被配置为在程序源代码中***针对性能监控脚本的脚本引入代码和脚本调用代码；

程序编译单元2114，被配置为对程序源代码进行编译后形成待测应用程序。

在本发明的一些示例性实施方式中，性能监控模块2120可以进一步包括：

性能监测单元2121，被配置为确定待测性能指标，并利用性能监控脚本实时监测待测性能指标；

数据获取单元2122，被配置为按照预设时间间隔获取对应于待测性能指标的基本性能数据，并确定获取基本性能数据时的时间信息以及程序页面信息；

性能确定单元2123，被配置为根据基本性能数据、时间信息以及程序页面信息确定待测应用程序的性能信息。

在本发明的一些示例性实施方式中，待测性能指标包括内存占用率、图像帧率、CPU使用率或者主线程卡顿性能中的至少一种。

在本发明的一些示例性实施方式中，堆栈记录模块2130可以进一步包括：

调用信息获取单元2131，被配置为获取出现性能问题时的函数调用信息；

问题类型确定单元2132，被配置为确定性能问题的问题类型；

堆栈信息记录单元2133，被配置为根据函数调用信息以及问题类型记录与性能问题相对应的堆栈信息。

在本发明的一些示例性实施方式中，问题类型包括以下类型中的至少一种：

内存占用率高于占用率阈值；

图像帧率低于帧率阈值；

CPU使用率高于使用率阈值；

主线程出现卡顿。

在本发明的一些示例性实施方式中，函数确定模块2140可以进一步包括：

堆栈日志获取单元2141，被配置为获取由多个堆栈信息组成的堆栈日志；

堆栈集合确定单元2142，被配置为按照问题类型对堆栈日志中的堆栈信息进行分类以得到对应不同的问题类型的堆栈信息集合；

调用信息统计单元2143，被配置为分别统计各个堆栈信息集合中的堆栈信息的函数调用信息；

函数信息确定单元2144，被配置为根据统计结果确定程序源代码中与性能问题相关的函数信息。

图22示意性地示出了本发明一些示例性实施方式中调用信息统计单元的结构框架。如图22所示，调用信息统计单元2143可以进一步包括：

线程确定子单元2210，被配置为根据堆栈信息确定与性能问题相关的多个线程；

函数确定子单元2220，被配置为确定每个线程的外层函数调用入口以及内层调用函数；

频次统计子单元2230，被配置为分别统计各个外层函数调用入口以及内层调用函数的调用频次。

图23示意性地示出了本发明一些示例性实施方式中函数信息确定单元的结构框架。如图23所示，函数信息确定单元2144可以进一步包括：

调用入口确定子单元2310，被配置为按照外层函数调用入口的调用频次对外层函数调用入口进行排序以确定一个或者多个目标入口；

第一函数确定子单元2320，被配置为按照内层调用函数的调用频次对内层调用函数进行排序以确定一个或者多个目标函数；

第二函数确定子单元2330，被配置为按照对应于不同外层函数调用入口的内层调用函数的调用频次对内层调用函数进行排序以确定一个或者多个对应于同一个外层函数调用入口的目标函数。

图24示意性地示出了本发明一些示例性实施方式中的另一应用程序测试装置的结构框架。如图24所示，应用程序测试装置2100还可以包括：

操作信息获取模块2150，被配置为在待测应用程序的运行过程中，实时获取针对待测应用程序的操作信息；

操作信息确定模块2160，被配置为确定与性能问题相对应的作用于待测应用程序的操作事件，并确定对应于操作事件的操作信息。

在本发明的一些示例性实施方式中，操作信息获取模块2150可以进一步包括：

操作事件截获单元2151，被配置为实时截获作用于待测应用程序的操作事件；

触控信息获取单元2152，被配置为当操作事件为触控事件时，获取触控事件的触控时间信息和触控轨迹信息；

操作时间确定单元2153，被配置为根据触控时间信息确定操作事件的操作时间；

页面位置确定单元2154，被配置为根据触控轨迹信息确定操作时间的操作页面和操作位置；

操作类型确定单元2155，被配置为根据触控时间信息和触控轨迹信息确定操作事件的操作类型；

操作信息确定单元2156，被配置为将操作时间、操作页面、操作位置以及操作类型确定为对应于操作事件的操作信息。

在本发明的一些示例性实施方式中，操作事件包括一个目标操作事件和多个关联操作事件；操作信息确定模块2160可以进一步包括：

第一事件确定单元2161，被配置为根据出现性能问题的时间，确定作用于待测应用程序的目标操作事件；

第二事件确定单元2162，被配置为将目标操作事件之前的多个操作事件确定为关联操作事件。

以上各示例性实施方式中的应用程序测试装置的具体细节已在相应的示例性方法部分做出详细说明，因此此处不再赘述。

示例性计算设备

在介绍了本发明示例性实施方式的方法、介质和装置之后，接下来，介绍根据本发明的另一示例性实施方式的计算设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为***、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

在一些可能的实施方式中，根据本发明实施方式的计算设备可以至少包括至少一个处理器、以及至少一个存储器。其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的应用程序测试方法中的步骤。

例如，所述处理器可以执行如图2中所示的以下方法步骤：步骤S210.获取带有性能监控脚本的程序源代码，并对程序源代码进行编译后形成待测应用程序。步骤S220.在待测应用程序的运行过程中，利用性能监控脚本实时获取待测应用程序的性能信息。步骤S230.当性能信息中出现性能问题时，记录与性能问题相对应的堆栈信息。步骤S240.根据堆栈信息确定程序源代码中与性能问题相关的函数信息。

又如，所述处理器也可以执行如图3至图20中所示的各个方法步骤。

应当注意，尽管在上文详细描述中提及了应用程序测试装置的若干模块或单元，但是这种划分仅仅是示例性的，并非是强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或单元的特征和功能可以在一个模块或单元中具体化。反之，上文描述的一个模块或单元的特征和功能可以进一步划分为由多个模块或单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所发明的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims

1.一种应用程序测试方法，包括：

2.根据权利要求1所述的应用程序测试方法，所述获取带有性能监控脚本的程序源代码，包括：

从远程代码库中获取待测应用程序的程序源代码；

3.根据权利要求1所述的应用程序测试方法，所述利用所述性能监控脚本实时获取所述待测应用程序的性能信息，包括：

4.根据权利要求3所述的应用程序测试方法，所述待测性能指标包括内存占用率、图像帧率、CPU使用率或者主线程卡顿性能中的至少一种。

5.根据权利要求1所述的应用程序测试方法，所述记录与所述性能问题相对应的堆栈信息，包括：

获取出现所述性能问题时的函数调用信息；

确定所述性能问题的问题类型；

6.根据权利要求5所述的应用程序测试方法，所述问题类型包括以下类型中的至少一种：

内存占用率高于占用率阈值；

图像帧率低于帧率阈值；

CPU使用率高于使用率阈值；

主线程出现卡顿。

7.根据权利要求5所述的应用程序测试方法，所述根据所述堆栈信息确定所述程序源代码中与所述性能问题相关的函数信息，包括：

获取由多个所述堆栈信息组成的堆栈日志；

8.一种介质，其上存储有程序，该程序被处理器执行时实现如权利要求1至7中任一项所述的方法。

9.一种应用程序测试装置，包括：

10.一种计算设备，包括：处理器和存储器，所述存储器存储有可执行指令，所述处理器用于调用所述存储器存储的可执行指令执行如权利要求1至7中任一项所述的方法。