检测内存泄漏的方法、装置及电子设备与流程

文档序号:11230361阅读:436来源:国知局
检测内存泄漏的方法、装置及电子设备与流程

本申请涉及软件测试技术领域,具体而言,涉及检测内存泄漏的方法、装置及电子设备。



背景技术:

内存泄漏是指程序里由于疏忽或错误造成程序未能释放已经不再使用的内存。内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终,在最糟糕的情况下,过多的可用内存被分配掉导致全部或部分设备停止正常工作,或者应用程序崩溃。

在一些软件中可能会有非常多的用户界面,由于用户界面通常会加载一些图形和特效,当程序的代码写得不规范时,导致容易出现内存泄漏。例如大型的手机游戏中,一般都会有非常多的用户界面,玩家在玩游戏的过程中也会频繁的打开和关闭这些用户界面。当玩家玩游戏的时间比较长,界面打开关闭频繁时,泄露的内存总量也会增加,导致游戏有因内存不足而闪退的风险。

当前比较常见的检测内存泄漏的方式,主要是通过观察游戏运行时内存的变化曲线,来获得内存的利用信息,当内存利用曲线持续升高时,就可以认为在游戏中存在内存泄漏的问题。比如图1中的内存占用曲线就是有明显的内存泄漏问题。

但是这种方式极为低效和不方便,例如在游戏里通常会有上百个用户界面,当用户界面比较多时,手动检测的方式比较费时费力,且很多用户界面藏得比较深,容易出现测试遗漏。



技术实现要素:

本申请公开检测内存泄漏的方法,以快捷地检测软件中用户界面是否存在内存泄露问题。

本发明的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本发明的实践而习得。

根据本发明的第一方面,提供一种检测内存泄漏的方法,包括:

获取待测的用户界面的标识;

根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作;

获取所述客户端每次打开和关闭所述用户界面时的内存快照;

根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

根据一些实施例,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求包括:通过脚本代码根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求。

根据一些实施例,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求包括:根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求包括:使用websocket或socket根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,所述用户界面的标识包括所述用户界面的名称和所述用户界面的引用路径。

根据一些实施例,根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露包括:

对所述内存快照上内存数量的差异进行统计,根据统计结果评估所述用户界面是否内存泄露。

根据一些实施例,获取待测的用户界面的标识之前还包括:遍历所述被测软件的用户界面,依次将遍历得到的用户界面作为所述待测的用户界面。

根据本发明的第二方面,提供一种检测内存泄漏的装置,其包括:

标识获取单元,用于获取待测的用户界面的标识;

模拟请求单元,用于根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作;

内存快照获取单元,获取所述客户端每次打开和关闭所述用户界面时的内存快照;

泄露评估单元,用于根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

根据一些实施例,所述模拟请求单元用于:通过脚本代码根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求。

根据一些实施例,所述模拟请求单元用于:根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,所述模拟请求单元用于:使用websocket或socket根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,所述用户界面的标识包括所述用户界面的名称和所述用户界面的引用路径。

根据一些实施例,所述泄露评估单元用于:

对所述内存快照上内存数量的差异进行统计,根据统计结果评估所述用户界面是否内存泄露。

根据一些实施例,所述装置还包括遍历单元,用于在获取待测的用户界面的标识之前,遍历所述被测软件的用户界面,依次将遍历得到的用户界面作为所述待测的用户界面。

根据本发明的第三方面,提供一种电子设备,包括:处理器;存储器,存储用于处理器控制如第一方面所述操作的指令。

本申请的实施例提供的技术方案可以包括以下有益效果:

首先,当内存曲线持续升高时,只能知道存在内存泄漏问题,但并不能定位到究竟是哪里产生了内存泄漏;其次,通常每个ui平均占用的内存都比较少,大概在几百k左右,单独查看某个用户界面是否存在内存泄漏通常并不明显,通常需要打开关闭很多次后才能看到较明显的内存变化;另外,游戏里通常有上百个用户界面,如果不能使用自动化的方法会比较费时费力,且容易出现测试遗漏。

本实施例提供的技术方案通过根据待测的用户界面的标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以在所述客户端执行打开和关闭所述用户界面的操作后获取内存快照,根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露,能准确定位到存在内存泄露的用户界面,能提高内存泄露的测试效率,能避免漏测。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性的,并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例,本发明的上述和其它特征及优点将变得更加明显。

图1示出了存在内存泄露问题时的内存占用曲线的示意图;

图2示出了根据本发明一实施例的检测内存泄漏的方法;

图3示出了根据本发明另一实施例的检测内存泄漏的方法;

图4示出了根据本发明另一实施例的检测内存泄漏的架构示意图;

图5示出了根据本发明另一实施例的检测内存泄漏的装置的框图;

图6示出了根据本发明一实施例的电子设备。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而,示例实施例能够以多种形式实施,且不应被理解为限于在此阐述的实施例;相反,提供这些实施例使得本发明将全面和完整,并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。

此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本发明的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本发明的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。

图2示出了根据本发明一实施例的检测内存泄漏的方法,本实施例可适用于检测包括用户界面的软件中的用户界面是否存在内存泄露的情况,如图2所示,本实施例所述的检测内存泄漏的方法包括:

在步骤s210中,获取待测的用户界面的标识。

其中,所述用户界面的标识用于区分被测软件中待测的用户界面,例如可以是用户界面的名称,也可以是用户界面的引用路径。

在步骤s220中,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作。

其中,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,可通过具体脚本代码实现。

所述请求可为远程过程调用请求,例如可使用websocket或socket实现所述远程过程调用的通信。

需要说明的是,步骤s210中所述待测的用户界面是指来自本步骤中所述被测软件中的用户界面。本实施例的技术方案用于检测一个待测的用户界面是否存在内存泄漏的情况,依据本实施例的方法,可对该被测软件中的部分或全部用户界面分别作为待测的用户界面逐一进行检测。

在步骤s230中,获取所述客户端每次打开和关闭所述用户界面时的内存快照。

在步骤s240中,根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

例如可对所述内存快照上内存数量的差异进行统计,根据统计结果评估所述用户界面是否内存泄露。

需要说明的是,获取待测的用户界面的标识可通过遍历所述被测软件的用户界面,依次将遍历得到的用户界面作为所述待测的用户界面。

本实施例提供的技术方案通过根据待测的用户界面的标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以在所述客户端执行打开和关闭所述用户界面的操作后获取内存快照,根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露,能准确定位到存在内存泄露的用户界面,能提高内存泄露的测试效率,能避免漏测。

图3示出了根据本发明另一实施例的检测内存泄漏的方法,如图3所示,本实施例所述的检测内存泄漏的方法包括:

在步骤s310中,遍历所述被测软件的用户界面,依次将遍历得到的用户界面作为所述待测的用户界面。

例如,遍历游戏内所有用户界面,得到所有用户界面的名称和引用路径。例如,从游戏项目中获取到游戏中所有的用户界面的名称或引用路径,以便于接下来循环遍历所有用户界面来模拟玩家打开和关闭用户界面的操作。由于不同的项目对用户界面的组织方式各不相同,因此这一步骤没有通用的技术解决方式,比如可以将所有的用户界面导出为以下键值对的方式以方便外部脚本来访问,其中“键”为用户界面的名称,“值”为该用户界面在游戏中的引用路径:

login="login.login.login"

login_windows="login.login_windows.loginwindows"

login_gonggao="login.gonggao.gonggaologin"

gonggao="login.gonggao.gonggao"

joystick="dungeon.player_joystick.playerjoystick"

pc_skill_panel="skills.skill_panel_pc.skillpanelpc"

skill_panel="skills.skill_panel_new.skillpanel"

jump_panel="jump_panel.jump_panel.jumppanel"

在步骤s320中,获取待测的用户界面的标识。

在步骤s330中,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作。

编写测试脚本,遍历所有获得的用户界面名称,向游戏客户端循环发送远程过程调用rpc请求,模拟玩家打开和关闭游戏用户界面操作。游戏客户端接收到请求后,通过该名称获取到对应的用户界面的引用路径,进行打开和关闭用户界面的操作。

例如,编写外部脚本,循环遍历导出的所有用户界面,向游戏客户端中发送打开和关闭用户界面的操作指令,来模拟玩家打开和关闭用户界面的操作。

由于直接向游戏客户端发送指令实现难度比较大,比如需要知道游戏客户端的通信格式和加密方式等。因此本申请通过在游戏客户端中内嵌一个rpc客户端的方式来实现rpc请求的接收,免去了对游戏本身通信协议和加密的依赖,并通过rpc服务端向rpc客户端发送请求。其中rpc服务端和rpc客户端的实现方式没有特别限定,可以直接使用socket来实现通信,也可以使用websocket来实现通信,本申请在实现时使用websocket来实现rpc通信,相关实现的核心python代码如下所示:

在游戏客户端中,内嵌一个rpc的客户端来接收发送过来的指令,并在游戏中启动实际的打开和关闭用户界面操作,核心python代码如下所示:

通过上述步骤,可以实现自动化打开和关闭用户界面的操作,下面就需要使用objgraph来判断在多次开关用户界面后,该用户界面是否存在内存泄漏。在实现方式上,需要在每次关闭用户界面时,使用objgraph.typestats()函数来获取到当前内存对象的状态,即内存快照,因此需要修改游戏中关闭用户界面的逻辑,加上内存统计的代码,核心代码如下所示:

在步骤s340中,获取所述客户端每次打开和关闭所述用户界面时的内存快照。

在游戏客户端的用户界面管理器中,使用objgraph来搜集内存使用数据,具体为:

a)每次打开关闭用户界面时,会调用一次gc.collect()函数,该函数会将不使用的内存对象清理掉。然后调用objgraph.typestats()函数,该函数是将未被gc清理掉的对象数据搜集出来,得到的结果可以看作是当前操作(打开关闭用户界面操作)后的一份内存快照。

b)通过多次打开关闭用户界面,就能得到每次操作下的内存快照数据。通过对比计算每次内存快照之间的python对象的差别,当差值大于0时,就表示存在内存泄露。

在步骤s350中,根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露,返回步骤s320。

例如每个用户界面的打开和关闭会重复5次,取平均值作为内存泄露严重程度的评估。

可以实现打开关闭用户界面后,通过统计内存快照上内存数量的差异,来统计每个用户界面是否出现内存泄漏,并将结果写入到一个临时文件中。通过将步骤1,2,3组合,就实现了游戏内用户界面内存泄漏的自动化检测,并生成测试报告。比如以下的样例测试结果,其中左边的字符串表示打开关闭用户界面所在的路径,后面的数字表示泄露的内存数量。由于内存回收会有一定的时间延迟,因此还是会有出现部分泄露的内存数量其数值大于0的情况,因此需要测试(打开关闭)多次,查看平均情况。例如,将泄露的内存数量的平均值一旦超过两位数时,也就是平均值介于10~20会启动程序进行检查,但这种情况并不能完全确定是内存泄漏问题,只有多次测试的内存泄露数量其平均值都大20的情况下,才会确定为内存泄漏。所以平均值的阈值可设定为10,其可根据需求进行具体设置,本公开不限于此,小于10即可以忽略不计,大于10就需要进一步检测。

例如,以下的样例测试结果表示该界面不存在内存泄露情况:

set(['action.action_panel.actionfloat'])0

set(['action.action_panel.actionfloat'])0

set(['action.action_panel.actionfloat'])4

set(['action.action_panel.actionfloat'])0

set(['task.all_tasks_panel.alltaskpanel'])1

set(['task.all_tasks_panel.alltaskpanel'])4

set(['task.all_tasks_panel.alltaskpanel'])0

set(['task.all_tasks_panel.alltaskpanel'])0

又如,以下的样例测试结果表示该界面存在内存泄露情况,需要查看代码并修复。

set(['equip.equip_dazao.equipdazao'])529

set(['equip.equip_dazao.equipdazao'])536

set(['equip.equip_dazao.equipdazao'])537

set(['equip.equip_dazao.equipdazao'])530

set(['bag.auto_food_setting.autofoodsetting'])692

set(['bag.auto_food_setting.autofoodsetting'])692

set(['bag.auto_food_setting.autofoodsetting'])689

set(['bag.auto_food_setting.autofoodsetting'])692

本实施例的技术方案能准确定位到存在内存泄露的用户界面,能提高内存泄露的测试效率,能避免漏测。

图5示出了根据本发明一实施例的检测内存泄漏的装置的框图,如图5所示,本实施例所述的检测内存泄漏的装置包括标识获取单元510、模拟请求单元520、内存快照获取单元530、以及泄露评估单元540。

该标识获取单元510被配置为,用于获取待测的用户界面的标识;

该模拟请求单元520被配置为,用于根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作;

该内存快照获取单元530被配置为,获取所述客户端每次打开和关闭所述用户界面时的内存快照;

该泄露评估单元540被配置为,用于根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

根据一些实施例,所述模拟请求单元520用于:通过脚本代码根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求。

根据一些实施例,所述模拟请求单元520用于:根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,所述模拟请求单元520用于:使用websocket或socket根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,所述用户界面的标识包括所述用户界面的名称和所述用户界面的引用路径。

根据一些实施例,所述泄露评估单元540用于:

对所述内存快照上内存数量的差异进行统计,根据统计结果评估所述用户界面是否内存泄露。

根据一些实施例,所述装置还包括遍历单元(图5中未示出),用于在获取待测的用户界面的标识之前,遍历所述被测软件的用户界面,依次将遍历得到的用户界面作为所述待测的用户界面。

关于上述实施例中的装置,其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。

本实施例提供的检测内存泄漏的装置可执行本发明方法实施例所提供的检测内存泄漏的方法,具备执行方法相应的功能模块和有益效果。

图6示出了根据本发明一实施例的电子设备,如图6所示,电子设备600可包括处理器610、存储器620、发射器630及接收器640。

存储器620可存储用于处理器610控制操作处理的指令。存储器620可包括易失性或非易失性存储器,如静态随机存取存储器(sram)、电可擦除可编程只读存储器(eeprom)、可擦除可编程只读存储器(eprom)、可编程只读存储器(prom)、只读存储器(rom)等,本发明对此没有限制。

处理器610可调用存储器620中存储的指令控制相关操作。根据一实施例,存储器620存储用于处理器610控制以下操作的指令:

获取待测的用户界面的标识;

根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作;

获取所述客户端每次打开和关闭所述用户界面时的内存快照;

根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

易于理解,存储器620还可存储用于处理器610控制根据本发明实施例的其他操作的指令,这里不再赘述。

处理器610还可控制发射器630和接收器640进行信号收发等。

通过以上的详细描述,本领域的技术人员易于理解,根据本发明实施例的系统和方法具有以下优点中的一个或多个。

根据本发明的实施例,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求包括:通过脚本代码根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求。

根据本发明的一些实施例,根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求包括:根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的远程过程调用请求。

根据一些实施例,本发明还提供一种非临时性计算机可读存储介质,例如包括指令的存储器,上述指令可由装置的处理器执行以完成上述方法。例如,非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。当存储介质中的指令由终端的处理器执行时,使得终端能够执行下述方法:获取待测的用户界面的标识;根据所述标识向被测软件的客户端循环发送用于模拟玩家打开和关闭所述用户界面的请求,以使所述客户端执行打开和关闭所述用户界面的操作;获取所述客户端每次打开和关闭所述用户界面时的内存快照;根据所述内存快照上内存数量的差异评估所述用户界面是否内存泄露。

本领域技术人员可以理解,附图只是示例实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的,因此不能用于限制本发明的保护范围。

本领域技术人员可以理解上述各模块可以按照实施例的描述分布于装置中,也可以进行相应变化唯一不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。

以上具体地示出和描述了本发明的示例性实施例。应该理解,本发明不限于所公开的实施例,相反,本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效布置。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1