脚本性能测试方法、装置和设备及计算机存储介质与流程

本申请涉及计算机技术领域，特别涉及一种脚本性能测试方法、装置和设备及计算机存储介质。

背景技术：

目前，应用于移动终端平台上的应用(application，app)中的许多功能都是通过脚本(script)实现的，例如对于手机游戏应用而言，在一个场景内，可以包括多个不同的脚本，用于实现不同的功能，在需要利用相应功能时则可以游戏进程调用相应脚本执行以实现相应功能，可见，脚本的性能可以直接影响到用户对于应用的使用体验，因而，找出使得脚本的性能不佳的性能瓶颈对象，从而对性能瓶颈对象进行优化，进而才能够提升用户的使用体验。因此，准确的对应用的脚本进行性能分析是对于应用优化而言是十分必要的。

技术实现要素：

本申请实施例提供一种脚本性能测试方法、装置和设备及计算机存储介质，用于提供一种脚本的性能测试方式，实现对脚本进行更准确的性能分析。

一方面，提供一种脚本性能测试方法，应用于移动终端平台中，所述方法包括：

监测到需进行脚本性能测试的目标应用的目标进程已启动时，将测试逻辑函数注入所述目标进程；

调用所述测试逻辑函数，以对性能监控函数进行编译，并在编译完成时执行所述性能监控函数；

监测到所述目标进程调用脚本包括的目标函数时，触发所述性能监控函数采集所述目标函数的性能数据；

根据所述性能监控函数采集的所述性能数据，对所述目标应用的脚本进行性能分析。

一方面，提供一种脚本性能测试装置，应用于移动终端平台中，所述装置包括：

注入单元，用于监测到需进行脚本性能测试的目标应用的目标进程已启动时，将测试逻辑函数注入所述目标进程；

调用单元，用于调用所述测试逻辑函数，以对性能监控函数进行编译，并在编译完成时执行所述性能监控函数；

数据采集单元，用于监测到所述目标进程调用脚本包括的目标函数时，触发所述性能监控函数采集所述目标函数的性能数据；

数据分析单元，用于根据所述性能监控函数采集的所述性能数据，对所述目标应用的脚本进行性能分析。

可选的，所述装置还包括确定单元；

所述确定单元，用于响应于在测试工具页面中进行的选择操作指示，将至少一个应用中被选中的应用确定为所述目标应用；

所述调用单元，还用于响应于对所述目标应用进行脚本性能测试的测试操作指示，调用所述目标应用的初始化程序，以启动所述目标进程。

可选的，所述注入单元，具体用于：

调用注入函数修改所述目标进程的函数执行逻辑，以使得在所述目标进程调用所述脚本编译函数时，触发所述测试逻辑函数的调用。

可选的，所述测试逻辑函数的执行过程包括：

调用所述脚本编译函数对所述性能监控函数进行编译；

监测到所述性能监控函数编译完成时，调用所述性能监控函数，以使得所述性能监控函数开始执行。

可选的，所述装置还包括页面控制单元；

所述页面控制单元，用于从所述测试工具页面跳转至所述目标应用的显示页面；其中，所述显示页面上包括控制所述性能监控函数开始或者停止采集性能数据的可操作按钮；以及响应于对所述可操作按钮进行的操作，控制所述性能监控函数开始或者停止采集性能数据。

可选的，

所述调用单元，还用于调用java本地接口将采集的性能数据发送给java层；

所述数据分析单元，还用于根据java层接收的性能数据，在测试工具页面上展示性能数据；或者，将java层接收的性能数据发送给网页服务器，以在打开所述网页服务器对应网页时，在所述网页上展示所述性能数据；或者，将java层接收的性能数据通过数据传输接口发送给其他显示设备，以通过所述其他显示设备展示所述性能数据。

可选的，所述数据分析单元，具体用于：

根据各所述目标函数的开始执行和执行结束时的时间戳数据，获取各所述目标函数的执行时长；

根据各所述目标函数的执行时长，确定所述目标应用的脚本中的性能瓶颈对象。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方面所述的方法。

一方面，提供一种计算机可读存储介质，存储有处理器可执行指令，所述处理器可执行指令用于执行上述方面所述的方法。

本申请实施例中，在需要进行测试的目标进程启动时，则可以将测试逻辑函数注入到目标进程，通过测试逻辑函数对目标进程调用脚本函数情况进行监控的性能监控函数进行编译，进而通过性能监控函数来采集脚本函数的性能数据，基于性能数据对脚本进行性能分析，从而实现脚本的性能分析。由于性能监控函数所采集的均为脚本真实执行时的性能数据，从而最终基于该性能数据进行性能分析所得到的结果更为准确可靠。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种场景示意图；

图2为本申请实施例提供的另一种场景示意图；

图3为本申请实施例提供的移动终端侧的逻辑架构图；

图4为本申请实施例提供的脚本性能测试方法的流程示意图；

图5为本申请实施例提供的选择目标应用的操作示意图；

图6为本申请实施例提供的目标应用的显示页面示意图；

图7为本申请实施例提供的目标应用的显示页面的另一种显示示意图；

图8为本申请实施例提供的在测试工具的测试结果显示页面上显示统计后的性能数据的示意图；

图9为本申请实施例提供的对手游进行lua脚本性能测试的流程示意图；

图10为本申请实施例提供的脚本性能测试装置的一种结构示意图；

图11为本申请实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

应用：本申请实施例中，应用主要是需要调用脚本实现一定功能的应用，例如可以为游戏应用、浏览器应用或者即时通讯应用，当然，也可以是其他可能的应用，本申请对此不做限制。

脚本：是一种通过脚本语言编写的纯文本保存的程序，脚本通常可以由应用程序临时调用并执行，各类脚本被广泛地应用于各个应用中，例如当点击网页上的电子邮箱(email)地址时就可以自动调用outlookexpress或者foxmail这类邮箱软件，就可以是通过脚本功能来实现的。脚本语言例如可以为lua脚本语言、js(javascript)脚本语言、c#脚本语言或者ue脚本语言等。

编译：一般而言，脚本函数需要通过编译函数被编译为可执行代码之后，才能被终端设备执行，以实现相应功能。

钩子(hook)：一种计算机技术，在没有源码的情况下，通过汇编的跳转指令实现修改目标函数的执行流程。

移动终端平台：一般是指搭载了移动终端的操作系统的移动终端，例如安卓(android)操作系统、ios操作系统或者塞班(symbian)操作系统。移动终端平台例如可以为手机平台或者平板(pad)平台，当然，除可以为手机或者pad等实体设备直接运行移动终端的操作系统之外，还可以为在pc端中虚拟出的移动终端设备。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。此外，对于本文中涉及的“第一”或者“第二”等仅用于区分类似的对象，而不是用于描述特定的顺序或者先后次序。

脚本性能测试是指通过脚本运行的运行数据确定出脚本的性能瓶颈对象的过程。目前在对移动终端平台的应用的脚本进行性能测试时，以手机应用为例，通常需要将应用从手机版本编辑成为窗口(windows)操作系统可支持的版本，以在个人计算机(personalcomputer，pc)端上使用脚本测试工具进行脚本性能测试，采集脚本执行时的数据，从而基于数据进行脚本性能分析。但是，这种测试方案具有如下缺点：

第一，在pc端上运行得到的测试结果并不能真实反映在移动终端中执行的结果。具体而言，由于pc端的中央处理器(centralprocessingunit，cpu)与移动终端的cpu通常区别较大，例如pc端的cpu通常为基于x86架构的处理器，移动终端的cpu通常为基于arm(advancedriscmachines)架构的处理器；并且pc端的运行环境与移动终端区别也较大，pc端的操作系统一般为windows操作系统，其运行环境通常是基于directx的，而移动终端平台一般为android操作系统、ios操作系统或者symbian操作系统等，例如对于android操作系统而言，其运行环境通常为基于opengl的运行环境，因而上述的区别等使得应用在pc端中执行时，并不能够与移动终端中执行完全相同，因而只能够针对pc端上的测试结果进行参考，而无法真实反映在移动终端中执行的结果。

第二，由于需要编译成为windows操作系统可支持的版本，但若是应用引擎不支持pc版本，那么也无法进行测试，并且版本的转换需要应用开发人员的支持，需要消耗较多的人力资源以及时间成本。

本申请人对现有技术进行分析后发现，现有技术由于测试均是在pc端上进行的，因而才会存在上述问题，那么若是可以将脚本性能测试直接在移动终端平台中进行，一方面无需进行版本的转换，另一方面可以直接在移动终端平台中运行需测试的应用，那么也就不存在cpu与运行环境所造成的运行结果不准确的问题，即上述的问题则可以一一得以解决。

鉴于上述的分析和考虑，本申请实施例提供一种脚本性能测试方法，该方法可以应用于移动终端平台中，即提供了一种基于移动终端平台的脚本性能测试方法，在该方法中，在需要进行测试的目标进程启动时，则可以将测试逻辑函数注入到目标进程，通过测试逻辑函数对目标进程调用脚本函数情况进行监控的性能监控函数进行编译，进而通过性能监控函数来采集脚本函数的性能数据，基于性能数据对脚本进行性能分析，从而实现脚本的性能分析。由于性能监控函数所采集的均为脚本在移动终端平台中真实执行时的性能数据，从而最终基于该性能数据进行性能分析所得到的结果更为准确可靠。

此外，为便于测试人员进行测试，本申请实施例还提供了相应的在移动终端平台中进行测试的测试工具，通过该测试工具，测试人员可通过可视化界面进行测试相关操作，更为方便直观。

本申请实施例中，在测试完成之后，可以通过java层将性能数据转发至后台服务器或者其他显示设备等，以方便性能数据的存储以及展示。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参见图1所示，为本申请实施例中的技术方案能够适用的一种应用场景，在该场景中，可以包括终端101、服务器102以及终端103。

终端101可以是手机、平板电脑(pad)、掌上电脑(personaldigitalassistant，pda)或者智能穿戴式设备(例如智能手表和智能手环)等搭载有移动终端操作系统的移动终端设备。终端101中可以安装测试工具以及待测试的应用，该测试工具可以实现本申请实施例提供的脚本性能测试方法的功能，以对待测试的应用进行脚本性能测试。其中，移动终端操作系统例如可以为android操作系统、ios操作系统或者symbian操作系统。

终端101可以包括一个或多个处理器1011、存储器1012、i/o接口1013以及显示面板1014等。其中，终端101的存储器1012中可以存储上述应用的程序指令(包括本申请实施例提供的脚本性能测试方法以及待测试应用的程序指令)，这些程序指令被处理器1011执行时能够用以实现本申请实施例提供的脚本性能测试方法的功能以及待测试应用的功能，以及在显示面板1014显示相应显示页面。其中，处理器1011例如可以为arm架构的处理器。

服务器102可以为能够与上述测试工具进行通信的服务器。服务器102可以包括一个或多个处理器1021、存储器1022、i/o接口1023以及与数据库1024等。其中，数据库1024可以存储通过本申请实施例提供的脚本性能测试方法得到的性能数据。终端103可以是个人计算机(personalcomputer，pc)或者笔记本电脑等终端设备，终端103可以包括一个或多个处理器1031、存储器1032、i/o接口1033以及显示面板1034等。其中，处理器1021和处理器103均可以为x86架构的处理器，服务器102和终端103中搭载的操作可以为windows操作系统，例如windowsxp、windows7或者windowsxp或者windows7以上的windows操作系统。

其中，终端101通过本申请实施例的提供的脚本性能测试方法得到待测试的应用的脚本性能数据之后，除了可以通过终端101对该应用进行脚本性能分析之外，还可以将性能数据发送给服务器102，服务器102可以将性能数据存储至数据库1024中，终端103可以访问数据库1024获取性能数据并进行相应处理，并将处理后的性能数据通过显示面板1034进行显示，以便测试人员进行脚本性能分析以及查看测试结果。

上述各设备之间可以通过一个或者多个网络104进行通信连接，该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(wireless-fidelity，wifi)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。

其中，终端101与终端103之间还可以直接进行通信，例如可以通过通用串行总线(universalserialbus，usb)进行连接，或者通过其他通信方式进行连接，例如蓝牙(bluetooth)等，终端101可以将测试得到性能数据直接发送给终端103，终端103可以对性能数据进行分析处理以及显示性能数据，以便测试人员进行脚本性能分析以及查看测试结果。

请参见图2所示，为本申请实施例中的技术方案能够适用的另一种应用场景，在该场景中，可以包括移动终端201、数据库服务器202、万维网(worldwideweb，web)服务器203以及终端204。

移动终端201中可以安装用于对应用进行脚本性能测试的测试工具，通过测试工具获取到性能数据之后，可以将性能数据上传至数据库服务器202中，web服务器203可以从数据库服务器202获取到性能数据，并通过web网页的形式进行显示，终端204中可以安装能够打开web网页的应用，例如浏览器，当通过浏览器打开web网页之后，则可以看到上传的脚本性能数据，用户可通过web网页提供的数据处理功能，例如数据对比(compare)和数据分析(analysis)等功能，辅助找出应用中的性能瓶颈对象。

其中，移动终端201和终端204例如可以分别为图1所示场景中的终端101、和终端103，数据库服务器202和web服务器203例如可以通过图1所示场景中的服务器102来实现，因此对于移动终端201、数据库服务器202、web服务器203以及终端204的介绍可参见图1所示场景部分的介绍，在此不再过多赘述。

请参见图3所示，为本申请实施例中提供移动终端侧的逻辑架构图，该架构是以对手游进行脚本性能测试为例示出的架构图。其中，在该架构中，可以包括游戏端和测试工具端。

其中，该手游可以为基于unity引擎以及lua脚本的手游，在基于lua脚本的手游中，游戏开发人员通过lua脚本语言开发脚本完成生成lua文件后，通过词法分析lua文件生成lua的字节码文件，当游戏客户端运行时，客户端会通过lua虚拟机(lvm)将lua字节码文件加载到内存中，并进行解析，然后调用其中的函数执行，以实现相应的功能。当然，在游戏开发时，也可以利用其它脚本语言进行开发，则可以利用其它相应的执行逻辑进行脚本的执行。

测试工具端包括ui(userinterface)展示单元、浮动窗口(floatwindow)单元、测试逻辑单元以及数据传输(datatranslation)单元。其中，ui展示单元用于提供测试工具端的ui界面展示，为测试人员提供可操作ui界面；浮动窗口单元用于在测试时，在游戏界面上展示一浮动窗口，通过该浮动窗口，可展示测试人员可操作的按钮，以及展示测试相关的信息；测试逻辑单元用于在游戏端启动后，将测试逻辑注入(inject)游戏进程后，执行测试逻辑，以进行测试；数据传输单元用于负责性能数据的传输。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

请参见图4，为本申请实施例提供的脚本性能测试方法的流程示意图，该方法例如可以应用于如图1或者2所示的场景中，该方法的流程描述如下。

步骤401：响应于在测试工具页面中进行的选择操作指示，将至少一个应用中被选中的应用确定为目标应用。

本申请实施例中，测试人员在需要进行测试时，可以在测试工具页面中进行应用的选择，被选中的应用则为目标应用，即需要进行脚本性能测试的应用。

如图5所示，为测试人员选择目标应用的操作示意图。其中，启动测试工具进入测试工具主页之后，则可以查看到该测试工具包括的测试功能，其中测试人员可以选择脚本性能测试功能，从而进入到应用选择页面。在应用选择页面中，可以展示包括可以进行测试的至少一个应用的可选择列表，测试人员可以对目标应用进行选择操作，当应用选择页面中未包括目标应用时，测试人员还可以自行将目标应用添加到可选择列表中，再对目标应用进行选择操作，相应的，终端可以检测到的选择操作，并将相应的选择操作指示发送给测试工具，测试工具响应于测试人员的选择操作指示，则可以将至少一个应用中被选中的应用确定为目标应用。

步骤402：响应于对目标应用进行脚本性能测试的测试操作指示，调用目标应用的初始化程序，以启动目标应用。

本申请实施例中，当测试人员选定目标应用之后，则可以指示开始测试。

具体的，如图5所示，测试人员可以对应用选择页面的“开始测试”按钮进行操作，以指示开始对目标应用进行脚本性能测试，相应的，测试工具可以获取到测试人员的测试操作指示，并响应于测试操作指示，调用目标应用的初始化程序，以启动目标应用。

步骤403：监测目标进程是否启动。

在测试人员指示开始测试之后，测试工具则会调用目标应用的初始化程序，以启动目标应用，并在目标应用的目标进程启动之后，才执行后续的测试逻辑，因此测试工具可以对目标进程是否启动进行监测。

具体的，测试工具可以在开始测试之后，则启动监测进程，用于监测目标进程是否启动，也就是监测正在运行的进程是否存在与目标应用对应的目标进程的进程标识符(processid，pid)相同的进程，若是有，则表明目标进程已经启动并运行，否则表明目标进程还未启动。

步骤404：若步骤404的结果为是，则将测试逻辑函数注入目标进程。

本申请实施例中，为了能够采集到目标进程调用脚本函数执行时的性能数据，可以向目标进程的内存空间中插入用于监控脚本性能数据的性能监控函数，但是由于目标进程在执行时，一般是按照自身的执行逻辑来执行的，那么为了能够插入性能监控函数，并且让其在目标进程的内存空间中正常执行，必然要修改目标进程的执行逻辑，因此，可以通过注入的方式来改变目标进程的执行逻辑。

其中，可以通过调用注入函数修改目标进程的函数执行逻辑，以使得在目标进程调用脚本编译函数时，触发测试逻辑函数的调用。具体的，注入函数可以将测试逻辑函数替换原本的脚本编译函数，这样，在目标进程调用脚本编译函数时，则可以执行测试逻辑函数，其中，可以在测试逻辑函数执行完成之后返回到脚本编译函数执行，这样，相当于在脚本编译函数执行之前插入了测试逻辑函数的执行；或者，还可以通过注入函数将测试逻辑函数注入值目标进程的内存空间中，测试逻辑函数可以通过钩子(hook)的方式来使得自身被执行，具体的，可以通过hook脚本编译函数，这样，在脚本编译函数被调用执行时，就可以触发执行测试逻辑函数。

以通过lua脚本语言编写的游戏脚本为例，目标进程想要执行脚本中的函数时，需要加载lua支持文件，以使得能够支持的lua脚本函数运行，例如，lua支持文件的文件名为libxlua.so，其中包括用于对lua脚本进行编译的脚本编译函数，因此只要注入到相应的lua支持文件则可以获取到相关的函数调用权限。在进行注入时，则可以通过注入函数替换原来libxlua.so中的脚本编译函数，替换为自己的函数逻辑myfunc，那么在游戏进程在执行脚本编译函数逻辑时，会先执行myfunc，从而通过myfunc插入对全局进行性能监控的脚本逻辑profile，进行编译，继而通过profile采集性能数据。

步骤405：调用测试逻辑函数，以对性能监控函数进行编译，并在编译完成时执行性能监控函数。

在上述步骤中以将对测试逻辑函数的调用进行了介绍，因此在此不再过多赘述。

本申请实施例中，测试逻辑函数的执行逻辑可以为调用脚本编译函数对需要插入的性能监控函数进行编译，并在编译完成时，调用一次性能监控函数，从而使得性能监控函数开始执行，在后台监控目标应用的各脚本函数的执行情况。

在测试逻辑函数执行完成之后，则目标进程才能可以返回原本的执行逻辑，继续调用脚本编译函数对各脚本进行编译；当然，在测试逻辑函数执行的同时，目标进程也可以继续执行原本的执行逻辑，即调用脚本编译函数对各脚本进行编译，也就是说，本申请实施例中，只要使得目标进程能够触发一次测试逻辑函数的调用执行即可。

本申请实施例中，在测试逻辑函数调用脚本编译函数对性能监控函数进行编译之后，即完成了插桩操作，相当于在各个脚本函数的插桩点进行插桩，当脚本函数被调用时，并执行至插桩点时，则会触发性能监控函数进行性能数据的记录。

其中，性能监控函数可以通过与待测试脚本相同的语言进行编写。

步骤406：响应于对可操作按钮进行的操作，控制性能监控函数开始采集性能数据。

本申请实施例中，在目标进程启动之后，移动终端上的界面则会从测试工具页面跳转至目标应用的显示页面，如图6所示，为目标应用的显示页面示意图。其中，图6所示的显示页面上，被选中的应用a正在加载中，因而图6所示的显示页面为应用a的加载界面，在目标应用的显示页面之上，可以包括控制性能监控函数开始或者停止采集性能数据的可操作按钮。如图6所示，在应用a的加载页面之上，显示有测试工具浮窗，测试工具浮窗内包括控制性能监控函数开始或者停止采集性能数据的可操作按钮，即图6所示的“开始采集”按钮，当对该按钮进行操作之后，则可以控制性能监控函数开始采集性能数据；当然，在对该按钮进行操作之后，相应的，采集状态也会随之发生改变，如从“停止采集”状态改变为“正在采集”状态，相应的“开始采集”按钮也可以改变为“停止采集”按钮，对该按钮进行操作之后，则可以控制性能监控函数停止采集性能数据。除可操作按钮之外，测试工具浮窗内还可以包括测试相关的信息显示，如图6所示的可显示测试持续时长(testduration)、目标应用包名(packagename)、采集状态(status)以及显示采集的性能数据(caseinfo)等信息。图6所示的测试工具浮窗在目标应用的显示页面的位置时可调整的，以便测试人员在对目标应用进行操作时，可以调整测试工具浮窗的位置，避免遮挡目标应用的显示画面，影响操作。

或者，由于测试工具浮窗所需占据的空间较大，因而为了避免影响测试人员对目标应用的操作，除图6所示的显示测试工具浮窗之外，还可以以显示悬浮球的形式，来显示可操作按钮。如图7所示，为目标应用的显示页面的另一种显示示意图，其中，通过悬浮球发的方式，为测试人员提供了一种可操作按钮的显示方式，同样的，在对该可操作按钮进行操作之后，相应的，采集状态也会随之发生改变，如从“停止采集”状态改变为“正在采集”状态，相应的“开始采集”按钮也可以改变为“停止采集”按钮，再次对可操作按钮进行操作之后，则可以控制性能监控函数停止采集性能数据。

针对目标应用而言，脚本性能测试可以是针对目标应用的特定场景进行性能测试，因此在进入目标应用之后，即目标应用加载完成之后，测试人员可以控制目标应用进入相应的待测试场景之后，再对“开始采集”按钮进行操作，这样，在对“开始采集”按钮进行操作之前的性能数据，性能监控函数不会进行采集，或者即使采集也不会进行保存等，而在对“开始采集”按钮进行操作之后，测试工具则可以响应于对可操作按钮进行的操作，控制性能监控函数开始采集性能数据并保存性能数据。

具体的，测试工具可以向运行于目标进程的内存空间的性能监控函数发送采集指令，基于该采集指令，性能监控函数开始采集性能数据并保存性能数据。其中，测试工具可以通过修改指示是否采集的变量的值，例如“0”可以指示“停止采集”状态，“1”可以指示“正在采集”状态，那么测试工具在额可以将该变量的值从“0”修改为“1”，当性能监控函数被触发执行时，首先会检查该变量的值，当确认该变量的值为“1”时，性能监控函数则会采集性能数据并保存性能数据。

步骤407：在监测目标进程调用脚本包括的目标函数时，触发性能监控函数采集目标函数的性能数据。

本申请实施例中，性能监控函数的执行逻辑可以是在有目标进程存在特定的调用之时，则会触发执行一次性能监控函数，从而可以给予性能监控函数一次记录性能数据的机会。具体的，可以是在有目标进程调用一个函数或者函数执行完返回之后，触发性能监控函数的调用，这样性能监控函数则可以在函数被调用以及函数执行完返回时记录该函数的执行情况。

其中，性能数据例如可以包括函数的函数信息(如函数名)、调用标识以及函数的开始执行和执行结束时的时间戳数据，当然，还可以包括其他可能的数据，例如占用内存、执行次数等。

例如，针对于lua脚本而言，lua的调试(debug)库中提供一种lua_debug接口，可以用于跟踪函数的执行情况，lua_debug库的可以通过注册一个handler函数，用来在目标进程在进行lua脚本的某个调用，触发handler函数被调用。因此，可以通过这种机制来使得handler函数在lua脚本的一个函数被调用时，即存在call事件时，触发handler函数记录函数的开始执行的时间戳数据，以及在每次函数返回的时候，即存在return事件时，触发handler函数记录函数的执行结束时的时间戳数据。

本申请实施例中，需测试的场景中涉及的脚本函数均可以作为目标函数，也就是说，当测试人员指示开始采集之后，后续调用的脚本函数均为目标函数，对于这些函数而言，均会触发性能监控函数采集性能数据。

步骤408：根据性能监控函数采集的性能数据，对目标应用的脚本进行性能分析。

本申请实施例中，性能监控函数所采集的性能数据，可以存储在处理队列中，以供数据统计线程进行排序处理。数据统计线程可以是运行于目标进程的内存空间的新线程，用于性能数据的记录统计，由于该线程不会占用目标应用自身和lua虚拟机的资源，因而对目标应用的性能影响微弱，提高性能测试的可信度。

具体的，数据统计线程可以根据各目标函数的开始执行和执行结束时的时间戳数据，获取各目标函数的执行时长，进而可以根据各目标函数的执行时长，确定目标应用的脚本中的性能瓶颈对象。当然，还可以进行其他数据的统计，例如调用次数、嵌套关系的计算和统计等。

其中，由于目标应用执行通常是在native层进行的，不方便性能数据的显示以及数据传输，因而数据统计线程处理之后的性能数据可以通过java本地接口(jni)发送给java层。

java层获取的性能数据，可以通过图形绘制之后在移动终端上进行展示，例如，可以在测试工具的测试结果显示页面上显示统计后的性能数据。如图8所示，为在测试工具的测试结果显示页面上显示统计后的性能数据的示意图。其中，在测试结果显示页面上，测试人员可以选取需要查看的测试场景的数据，相应的，页面上可以显示测试人员选择的场景的性能数据。如图8所示，性能数据可以按照各脚本函数执行时间长短进行排序进行显示，这样，测试人员便可以很直观的找到耗时较长脚本函数，即性能瓶颈函数，从而后续可以针对这几个函数进行优化。

例如，4527：[lua]:framework/schedule.lua:82中4527为该函数执行的时长，“[lua]:framework/schedule”为函数名，“lua:82”是指该函数在lua脚本中的行数，170：[lua]tickpostprocess.lua:77为“[lua]:framework/schedule”的嵌套函数，其执行时长为170，在lua脚本中的行数为77

java层获取的性能数据，还可以在对数据进行整理之后，将数据打包通过与数据库的通信接口发送至数据库中进行存储和分析，数据块可基于接收的性能数据进行对比分析，形成测试报告。为方便测试人员查看测试报告，还可以通过web服务器提供的网页页面查看测试报告，以帮助测试人员进行分析整理，找出测试场景中的性能瓶颈函数，例如测试场景中过高、过多的异常脚本调用。其中，网页页面的展示可以与移动终端的测试结果页面展示类似，因此，网页页面可以参见移动终端的测试结果页面展示部分的介绍，这里不再过多赘述。

java层获取的性能数据，还可以发送给网页服务器，以在打开网页服务器对应网页时，在网页上展示性能数据；或者，java层接收的性能数据还可以通过数据传输接口发送给其他显示设备，以通过其他显示设备展示性能数据，例如可以通过usb数据线将移动终端连接值pc端，这样，java层接收的性能数据就可以通过usb接口发送给pc端，以在pc端进行数据展示和分析。

下面以对手游进行lua脚本性能测试为例，对本申请实施例的方案进行介绍。请参见图9，为对手游进行lua脚本性能测试的流程示意图。

步骤901：选中待测游戏开始测试时，在游戏端运行的进程空间中，启动一个监测进程mainproc。

步骤902：监测进程mainproc持续监测是否有待测游戏对应的目标游戏进程被启动。

步骤903：监测进程mainproc监测到目标游戏进程被启动时，通过注入函数将测试逻辑函数myfunc注入目标游戏进程。

监测进程mainproc监测到目标游戏进程被启动时，通过注入函数将so函数库，即包括测试逻辑函数myfunc的函数库注入目标游戏进程，即通过注入函数替换原来libxlua.so中的脚本编译函数，替换为测试逻辑函数myfunc。libxlua.so为支持lua脚本的函数库。

步骤904：目标游戏进程加载libxlua.so。

步骤905：目标游戏进程解析并加载luabytecode。

目标游戏进程加载libxlua.so时，则同样会把测试逻辑函数myfunc加载至进程空间中，并在目标游戏进程解析并加载luabytecode时，即在目标游戏进程执行脚本编译函数逻辑时，就可以触发测试逻辑函数myfunc的执行，从而在这里增加对自编写的lua脚本进行编译，lua脚本中实现了一个全局进行性能监控的性能监控函数profile，进行编译，这样，通过测试逻辑函数myfunc则可以调用脚本编译函数，对性能监控函数profile进行编译，并调用性能监控函数profile执行。

在性能监控函数profile编译完成并执行后，则表明可以开始采集性能数据，相应的，在移动终端设备上可以显示“开始采集”按钮，如图6或者图7所示。

步骤906：测试工具端向游戏端发送开始采集指令。

具体的，测试人员对“开始采集”按钮进行操作之后，测试工具端可以将相应指示是否采集的变量的值置为指示采集的值，以指示采集性能数据。

步骤907：性能监控函数profile基于脚本函数调用的触发，进行性能数据的采集。

在性能监控函数profile编译完成后，即完成测试点打桩，此时性能监控函数profile基于脚本函数调用的触发，进行性能数据的采集，即可以根据lua提供的lua_debug在所有脚本函数执行前后进行函数执行时间的统计。

步骤908：测试工具端向游戏端发送停止采集指令。

具体的，测试人员对“停止采集”按钮进行操作之后，测试工具端可以将相应指示是否采集的变量的值置为指示停止采集的值，以指示停止采集性能数据。

步骤909：汇总性能数据并发送至java层。

性能监控函数profile采集的所有统计的性能数据存储在队列中进行排序处理，运行在游戏进程空间的数据统计线程可以对性能数据进行处理，并在处理完毕后发送到java层。

步骤910：性能数据合并归类处理。

java层，或者测试工具端可以对性能数据进行进一步的合并归类处理。

步骤911：将性能数据上传至web服务器的数据库。

步骤912：web服务器可以对性能数据进行对比分析生成测试报告。

综上所述，本申请实施例中提供的脚本性能测试方法，通过使用hook技术获取到游戏的运行态，从而在脚本函数执行的过程中进行插桩，在新的进程进行函数执行数据的统计和上报。并在web服务器进行数据存储和分析，通过对场景的标记和记录，进行本次测试及前后版本的脚本性能分析和对比。该方法实现了在移动终端平台进行脚本性能测试，免去需要单独编译windows平台的版本过程，测试人员直接针对外发的版本进行性能测试，脚本测试过程中可以直接针对app进行测试并获取脚本执行时间的数据，性能数据反映了应用在真实运行过程中的性能消耗，结果更具备参考价值，更能帮助开发定位分析问题，找到瓶颈。

此外，该方法可以是适用于所有用到脚本实现执行逻辑的app都适用，无需针对不同app单独编写测试代码，并且无需开发人员单独编辑用于测试侧应用版本，降低了脚本性能测试的门槛。

请参见图10，基于同一发明构思，本申请实施例还提供了一种脚本性能测试装置100，该装置包括：

注入单元1001，用于监测到需进行脚本性能测试的目标应用的目标进程已启动时，将测试逻辑函数注入目标进程；

调用单元1002，用于调用测试逻辑函数，以对性能监控函数进行编译，并在编译完成时执行性能监控函数；

数据采集单元1003，用于监测到目标进程调用脚本包括的目标函数时，触发性能监控函数采集目标函数的性能数据；

数据分析单元1004，用于根据性能监控函数采集的性能数据，对目标应用的脚本进行性能分析。

可选的，装置还包括确定单元1005；

确定单元1005，用于响应于在测试工具页面中进行的选择操作指示，将至少一个应用中被选中的应用确定为目标应用；

调用单元1002，还用于响应于对目标应用进行脚本性能测试的测试操作指示，调用目标应用的初始化程序，以启动目标进程。

可选的，注入单元1001，具体用于：

调用注入函数修改目标进程的函数执行逻辑，以使得在目标进程调用脚本编译函数时，触发测试逻辑函数的调用。

可选的，测试逻辑函数的执行过程包括：

调用脚本编译函数对性能监控函数进行编译；

监测到性能监控函数编译完成时，调用性能监控函数，以使得性能监控函数开始执行。

可选的，装置还包括页面控制单元1006；

页面控制单元1006，用于从测试工具页面跳转至目标应用的显示页面；其中，显示页面上包括控制性能监控函数开始或者停止采集性能数据的可操作按钮；以及响应于对可操作按钮进行的操作，控制性能监控函数开始或者停止采集性能数据。

可选的，

调用单元1002，还用于调用java本地接口将采集的性能数据发送给java层；

数据分析单元1004，还用于根据java层接收的性能数据，在测试工具页面上展示性能数据；或者，将java层接收的性能数据发送给网页服务器，以在打开网页服务器对应网页时，在网页上展示性能数据；或者，将java层接收的性能数据通过数据传输接口发送给其他显示设备，以通过其他显示设备展示性能数据。

可选的，数据分析单元1004，具体用于：

根据各目标函数的开始执行和执行结束时的时间戳数据，获取各目标函数的执行时长；

根据各目标函数的执行时长，确定目标应用的脚本中的性能瓶颈对象。

该装置可以用于执行图4～图9所示的实施例中涉及的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图4～图9所示的实施例的描述，不多赘述。其中，确定单元1005和页面控制单元1006并非必选的功能单元，因此在图10中以虚线示出。

请参见图11，基于同一技术构思，本申请实施例还提供了一种计算机设备110，可以包括存储器1101和处理器1102。

所述存储器1101，用于存储处理器1102执行的计算机程序。存储器1101可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器1102，可以是一个中央处理单元(centralprocessingunit，cpu)，或者为数字处理单元等等。本申请实施例中不限定上述存储器1101和处理器1102之间的具体连接介质。本申请实施例在图11中以存储器1101和处理器1102之间通过总线1103连接，总线1103在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线1103可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1101可以是易失性存储器(volatilememory)，例如随机存取存储器(random-accessmemory，ram)；存储器1101也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flashmemory)，硬盘(harddiskdrive，hdd)或固态硬盘(solid-statedrive，ssd)、或者存储器1101是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1101可以是上述存储器的组合。

处理器1102，用于调用所述存储器1101中存储的计算机程序时执行如图4～图9中所示的实施例涉及的方法。

在一些可能的实施方式中，本申请提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图4～图9中所示的实施例涉及的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。