CN105302714B - 一种测试过程中内存泄漏的监控方法和装置 - Google Patents
一种测试过程中内存泄漏的监控方法和装置 Download PDFInfo
- Publication number
- CN105302714B CN105302714B CN201410356321.5A CN201410356321A CN105302714B CN 105302714 B CN105302714 B CN 105302714B CN 201410356321 A CN201410356321 A CN 201410356321A CN 105302714 B CN105302714 B CN 105302714B
- Authority
- CN
- China
- Prior art keywords
- memory overflow
- judge
- file
- test process
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种测试过程中内存泄漏的监控方法和装置。该方法包括：在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。
Description
技术领域
本发明涉及软件测试领域，尤其涉及一种测试过程中内存泄漏的监控方法和装置。
背景技术
Java跟C++语言不一样，C++语言有明确的内存泄漏——指向一块内存的指针被重新赋值后，而该内存又没被回收，即由于再也无法访问而导致内存泄漏。但Java不会出现这种情况。虽然不会出现，但由于Java的引用计数机制，也容易出现一些我们不希望出现的内存泄露，例如一个小对象由于人为失误忘记删除对其引用，导致该小对象所引用的所有对象都无法被回收。
由于Java语言的特性，开发人员是不需要关注对象的回收的。但由于有可能是开发人员在开发过程中，由于某些人为原因导致一些对象没有被回收，而使得软件所占用的越来越大，这是不希望发生的。
发明内容
本发明提出了一种测试过程中内存泄漏的监控方法和装置，其通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。
为实现上述设计，本发明采用以下技术方案：
一方面采用一种测试过程中内存泄漏的监控方法，该方法包括：
在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；
对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
另一方面采用一种测试过程中内存泄漏的监控装置，该装置包括：
监控对象添加单元，用于在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；
次数统计单元，用于对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
内存泄漏判断单元，用于根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
本发明的有益效果在于：通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对本发明实施例描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据本发明实施例的内容和这些附图获得其他的附图。
图1是本发明实施例提供的一种测试过程中内存泄漏的监控方法的第一个实施例方法流程图。
图2是本发明实施例提供的一种测试过程中内存泄漏的监控方法的第二个实施例方法流程图。
图3是本发明实施例提供的一种测试过程中内存泄漏的监控方法的第三个实施例的方法流程图。
图4是本发明实施例提供的一种测试过程中内存泄漏的监控装置的第一个实施例的结构方框图。
图5是本发明实施例提供的一种测试过程中内存泄漏的监控装置的第二个实施例的结构方框图。
图6是本发明实施例提供的一种测试过程中内存泄漏的监控装置的第三个实施例的结构方框图。
图7是本发明实施例所涉及的设备结构方框图。
具体实施方式
为使本发明解决的技术问题、采用的技术方案和达到的技术效果更加清楚，下面将结合附图对本发明实施例的技术方案作进一步的详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
请参考图1，其是本发明实施例提供的测试过程中内存泄漏的监控方法的第一个实施例的方法流程图。本实施例的测试过程中内存泄漏的监控方法主要应用于各种基于Java语言开发的软件的测试，例如为安卓(Android)、Linux开发的软件。
如图1所示，该测试过程中内存泄漏的监控方法，包括：
步骤S101：在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象。
Java语言本身提供有工具用来监控对象在内存中是否被回收，这个工具就是幽灵引用(Phantom Reference)及引用队列(ReferenceQueue)，在软件开发的过程中，将软件中需要判断内存泄漏的对象在幽灵引用和引用队列中添加监控，在程序运行的过程中，幽灵引用和引用队列会监控对象在内存中的状态变化，具体幽灵引用和引用队列在Java语言中是惯用的语言工具，本专业人员对其都有一定程度了解，在此不再赘述。
步骤S102：对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数。
在软件测试的过程中，从引用队列中读取监控对象是否已经被回收，并分别统计每个对象的未被回收的次数。
步骤S103：根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
不同用途或类别的对象，其内存泄漏的判断标准各不相同，但是不管是哪种类型的对象，内存泄漏的判断都是基于未回收的次数得到结果的。hprof文件是Java内存中对象的引用树结构文件，用以记录对象在内存中的引用状态。
综上所述，本实施例通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。
请参考图2，其是本发明实施例提供的测试过程中内存泄漏的监控方法的第二个实施例的方法流程图。本实施例与方法第一个实施例的主要区别在于，进一步说明了添加需要判断内存泄漏的对象的具体过程以及一种判断对象是否内存泄漏的具体过程。
如图2所示，该测试过程中内存泄漏的监控方法，包括：
步骤S201：在面向切面的语言中定义集合和操作；所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中。
面向切面的编程主要实现的目的是对程序运行过程进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各对象的动作监控。常用的面向切面的语言如aspectj，当然，aspectj只是应用范围比较广的一种工具，还可以使用其他的面向切面的语言。在本步骤中，aspectj可以定义一个集合，这个集合中的所有对象new出来的时候，做一些自定义的操作，主要是添加内存泄漏监控，另外还可以打log。结合起来，就可以在自定义的集合中，new出对象时把对象监控起来。
步骤S202：在幽灵引用和引用队列中添加集合中的对象。
通过面向切面的编程可以实现大批量地添加对象，无需将每个对象都单独添加到幽灵引用和引用队列中，提高了测试的效率，减小了测试过程中的工作量。
步骤S203：对软件进行测试，周期统计需要判断内存泄漏的对象的未被回收的次数，记录每个历史周期统计到的所述次数。
步骤S204：周期对每个历史周期统计到的需要判断内存泄漏的对象的次数基于最小二乘拟合进行数据统计，当确定数据统计的结果超出该次数对应的对象要求的阈值时，判断出该对象内存泄漏，生成hprof文件。
内存泄漏的判断标准各不相同，在本实施例中，对象的内存泄漏的判断并不是基于单次的统计结果，而是基于对整个运行过程中的对象的未回收的次数的变化过程的统计，判断的标准不在于单次的计数，而在于计数的变化趋势。所以需要周期对对象的未回收的次数进行统计，再对获取到的次数进行最小二乘拟合，当最小二乘拟合后的到数据统计的结果超出该对象要求的阈值时，该对象视为内存泄漏，生成hprof文件。
更具体而言，所述基于最小二乘拟合进行数据统计，具体为：
以直角坐标系的纵轴表示每个历史周期统计到的需要判断内存泄漏的对象的次数，以直角坐标系的横轴表示所述次数对应的时间；在所述直角坐标系中用最小二乘拟合得出直线，所述直线的斜率为数据统计的结果。
在本实施例中，对象要求的阈值为10度，也就是如果直线的斜率超过10度，即视为该对象内存泄漏。
在本方案中，统计次数的周期和数据统计周期可以视为同一周期，也就是每次得到一个周期的次数之后，马上对最新记录的每个历史周期统计得到的次数进行数据统计。
步骤S205：发送hprof文件到预设的电子邮箱。
为了翻遍测试人员和软件开发人员对内存泄漏进行处理，每次生成hprof文件之后将其发送到预设的电子邮箱，方便对内存泄漏进行处理。
综上所述，本方案进一步说明了添加需要判断内存泄漏的对象的具体过程以及一种判断对象是否内存泄漏的具体过程。总体而言，通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。另外，通过一种批量添加需要监控的对象，实现了快速添加对象，提高了对象添加的效率，加快了软件开发和测试的进程，降低了时间成本；一种判断对象是否内存泄漏的方案也进一步说明了具体的统计判断过程。
请参考图3，其是本发明实施例提供的测试过程中内存泄漏的监控方法的第三个实施例的方法流程图。本实施例与方法第二个实施例的主要区别在于，进一步说明了另一种判断对象是否内存泄漏的具体过程、测试的具体过程和生成hprof文件的具体过程。
如图3所示，该测试过程中内存泄漏的监控方法包括：
步骤S301：录制测试文件。
在本方案中，测试可以通过手动执行，测试人员每次通过手动对软件进行操作，监控测试的结果。更为方便的，录制测试文件，测试文件相当于设置了一个虚拟的手并为这个虚拟的手设置了顺序动作，在测试过程中，通过虚拟的手对软件进行操作即可。
步骤S302：在面向切面的语言中定义集合和操作；所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中。
步骤S303：在幽灵引用和引用队列中添加集合中的对象。
进一步地，集合中的除了设定对象和添加对象的步骤，还设置了获取引用队列中的记录是否回收的动作，以实现尽可能地自动测试。实质上，完成测试前的准备工作之后，会将开发好的程序编译生成apk文件，运行apk文件，对apk文件进行测试，也就是对软件进行测试，但是因为编译生成apk是软件开发过程中的常规动作，在此不作单独的步骤详细说明。
步骤S304：运行测试文件，自动对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数。
步骤S305：比较所述次数与该次数对应的对象的极限次数的大小，当确定所述次数大于所述极限次数时，判断出该对象内存泄漏，确定所述对象是第一次内存泄漏时，生成hprof文件。
基于一些先验知识，知道某些被监控的对象的未回收的次数不可能超过某个数值，当监控到这类对象超过其对应的极限次数时，判断出该对象内存泄漏。
而对于一个软件而言，只要知道有内存泄漏即可，因为只要有内存泄漏，就说明软件开发过程中在该对象存在某方面的问题，需要改进，故而只在第一次判断内存泄漏时生成hprof文件。
另一种判断方式，某些对象在经过一些特定的操作后，是应该被系统回收了的，例如一些UI对象，在操作结束返回系统桌面后，是应该要被系统回收释放了的，如果返回系统桌面的操作已完成，但是UI对象没有被系统回收，此时判断为内存泄漏。
实际上，在测试过程，对于不同的对象有不同的判断方式，因此一个软件的测试一般都是由多种判断方式配合进行工作的，例如这里的一种判断方式以及实施例2中的一种判断方式总共三种判断方式综合进行内存泄漏的判断，当然，一个对象只用到一种判断方式，所以如果是综合使用多种判断方式，还会增加一个选择对象的判断方式的步骤。
步骤S306：发送hprof文件到预设的电子邮箱。
更精确的，可以读取该对象发生内存泄漏对应的开发人员的电子邮件，直接就爱那个hprof文件发送到开发人员的电子邮件中。
步骤S307：引用树查看工具打开hprof文件。
对于测试人员而言，系统可以直接用引用树查看工具，例如MAT、jprofile打开hprof文件，而且对于本领域人员，只要知道了hprof格式，可以自行制作一个读取hprof文件的工具。
综上所述，本实施例中进一步说明了另一种判断对象是否内存泄漏的具体过程、测试的具体过程和生成hprof文件的具体过程。总体而言，本实施例中通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。同时，自动化测试的方式减小了测试人员的工作压力；更多种的内存泄漏的判断方法能够更全面地对对象进行监控，每个对象只有在第一次发生内存泄漏是才生成hprof文件也减少了工作内容。
以下为本发明实施例提供的测试过程中内存泄漏的监控装置的实施例。测试过程中内存泄漏的监控装置的实施例与上述的测试过程中内存泄漏的监控方法实施例属于同一构思，测试过程中内存泄漏的监控装置的实施例中未详尽描述的细节内容，可以参考上述测试过程中内存泄漏的监控方法实施例。
请参考图4，其是本发明实施例提供的测试过程中内存泄漏的监控装置的第一个实施例的结构方框图。该测试过程中内存泄漏的监控装置，包括如下内容：
监控对象添加单元410，用于在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；
次数统计单元420，用于对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
内存泄漏判断单元430，用于根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
综上所述，上述各单元的协同工作，通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。
请参考图5，其是本发明实施例提供的测试过程中内存泄漏的监控装置的第二个实施例的结构方框图。本实施例与装置第一个实施例的主要区别在于，进一步说明了监控对象添加单元410的具体工作模块和内存泄漏判断单元430的具体工作过程。该测试过程中内存泄漏的监控装置，包括如下内容：
监控对象添加单元410，用于在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；
次数统计单元420，用于对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
内存泄漏判断单元430，用于根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
其中，所述监控对象添加单元410，包括：
批量定义模块411，用于在面向切面的语言中定义集合和操作；所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中；
批量添加模块412，用于在幽灵引用和引用队列中添加集合中的对象。
其中，所述内存泄漏判断单元430，具体用于：
周期对每个历史周期统计到的需要判断内存泄漏的对象的次数基于最小二乘拟合进行数据统计，当确定数据统计的结果超出该次数对应的对象要求的阈值时，判断出该对象内存泄漏，生成hprof文件；其中，所述次数统计单元420，具体用于：
运行预录的测试文件，周期统计需要判断内存泄漏的对象的未被回收的次数，记录每个历史周期统计到的所述次数；
其中，所述基于最小二乘拟合进行数据统计，具体为：
以直角坐标系的纵轴表示每个历史周期统计到的需要判断内存泄漏的对象的次数，以直角坐标系的横轴表示所述次数对应的时间；在所述直角坐标系中用最小二乘拟合得出直线，所述直线的斜率为数据统计的结果。
其中，所述监控装置，还包括：
邮件发送单元440，用于发送hprof文件到预设的电子邮箱。
其中，所述面向切面的语言包括：aspectj。
综上所述，本方案进一步说明了监控对象添加单元410的具体工作模块和内存泄漏判断单元430的具体工作过程。总体而言，通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。另外，通过一种批量添加需要监控的对象，实现了快速添加对象，提高了对象添加的效率，加快了软件开发和测试的进程，降低了时间成本；一种判断对象是否内存泄漏的方案也进一步说明了具体的统计判断过程。
请参考图6，其是本发明实施例提供的测试过程中内存泄漏的监控装置的第三个实施例的结构方框图。本实施例与装置第二个实施例的主要区别在于，进一步说明了另一种判断对象是否内存泄漏的具体过程、测试的具体过程和生成hprof文件的具体过程。该测试过程中内存泄漏的监控装置，包括如下内容：
监控对象添加单元410，用于在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象；
次数统计单元420，用于对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
内存泄漏判断单元430，用于根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
其中，所述监控对象添加单元410，包括：
批量定义模块411，用于在面向切面的语言中定义集合和操作；所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中；
批量添加模块412，用于在幽灵引用和引用队列中添加集合中的对象。
其中，所述内存泄漏判断单元430，具体用于：
对每个周期统计到的需要判断内存泄漏的对象的次数基于最小二乘拟合进行数据统计，当确定数据统计的结果超出该次数对应的对象要求的阈值时，判断出该对象内存泄漏，生成hprof文件；其中，所述次数统计单元420，具体用于：
运行预录的测试文件，周期统计需要判断内存泄漏的对象的未被回收的次数。
所述内存泄漏判断单元430，还用于：
比较所述次数与该次数对应的对象的极限次数的大小，当确定所述次数大于所述极限次数时，判断出该对象内存泄漏，生成hprof文件。
所述内存泄漏判断单元430，还用于：
当所述次数的对应的对象的预设的前续动作已完成且所述次数不为0时，判断出所述次数对应的对象内存泄漏，生成hprof文件。
其中，所述监控装置，还包括：
邮件发送单元440，用于发送hprof文件到预设的电子邮箱。
其中，所述面向切面的语言包括：aspectj。
所述监控装置，还包括：
文件查看单元450，用于引用树查看工具打开hprof文件。
其中，所述监控装置，还包括：
测试文件录制单元460，用于录制测试文件；
所述对软件进行测试，具体为：
运行测试文件，自动对软件进行测试。
其中，所述生成hprof文件，具体为：确定所述对象是第一次内存泄漏时，生成hprof文件。
综上所述，本方案进一步说明了另一种判断对象是否内存泄漏的具体过程、测试的具体过程和生成hprof文件的具体过程。总体而言，本实施例中通过幽灵引用和引用队列监控对象是否已经被回收，再根据监控的结果判断监控的对象是否已经内存泄漏，在内存泄漏时生成hprof文件，实现了自动监控内存泄漏，记录内存泄漏的自动定位，提高了监控正确率和效率。同时，自动化测试的方式减小了测试人员的工作压力；更多种的内存泄漏的判断方法能够更全面地对对象进行监控，每个对象只有在第一次发生内存泄漏是才生成hprof文件也减少了工作内容。
请参考图7，其是本发明实施例所涉及的设备结构方框图，该设备可以用于实施上述实施例中提出的测试过程中内存泄漏的监控方法，承载测试过程中内存泄漏的监控装置。具体来讲：
该设备可以包括内存110、存储设备120、外设130和处理器140。本领域技术人员可以理解，图7中的设备并不构成绝对的限定，例如电源作为常识性的必要部件未予说明。可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
内存110，用于测试过程中缓存需要处理的数据或对象。
存储设备120，用于存储测试对象和测试文件。
外设130，包括显示屏、鼠标、键盘、触摸外设等，用于显示测试过程，对软件进行操作。
处理器140，用于运行测试对象。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括存储器、磁盘或光盘等。
以上内容仅为本发明的较佳实施例，对于本领域的普通技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，本说明书内容不应理解为对本发明的限制。
Claims (18)
1.一种测试过程中内存泄漏的监控方法，其特征在于，包括：
在面向切面的语言中定义集合和操作，所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中；
在幽灵引用和引用队列中添加所述集合中的对象；
对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
2.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件，包括：
周期对每个历史周期统计到的需要判断内存泄漏的对象的次数基于最小二乘拟合进行数据统计，当确定数据统计的结果超出该次数对应的对象要求的阈值时，判断出该对象内存泄漏，生成hprof文件；
其中，所述对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数，具体为：对软件进行测试，周期统计需要判断内存泄漏的对象的未被回收的次数，记录每个历史周期统计到的所述次数；
其中，所述基于最小二乘拟合进行数据统计，具体为：
以直角坐标系的纵轴表示每个历史周期统计到的需要判断内存泄漏的对象的次数，以直角坐标系的横轴表示所述次数对应的时间；在所述直角坐标系中用最小二乘拟合得出直线，所述直线的斜率为数据统计的结果。
3.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件，包括：
比较所述次数与该次数对应的对象的极限次数的大小，当确定所述次数大于所述极限次数时，判断出该对象内存泄漏，生成hprof文件。
4.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件，包括：
当所述次数的对应的对象的预设的前续动作已完成且所述次数不为0时，判断出所述次数对应的对象内存泄漏，生成hprof文件。
5.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述生成hprof文件之后，还包括：
发送hprof文件到预设的电子邮箱。
6.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述生成hprof文件之后，还包括：
引用树查看工具打开hprof文件。
7.根据权利权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述在幽灵引用和引用队列中添加软件中需要判断内存泄漏的对象之前，还包括：
录制测试文件；
所述对软件进行测试，具体为：
运行测试文件，自动对软件进行测试。
8.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述面向切面的语言包括：aspectj。
9.根据权利要求1所述的一种测试过程中内存泄漏的监控方法，其特征在于，所述生成hprof文件，具体为：确定所述对象是第一次内存泄漏时，生成hprof文件。
10.一种测试过程中内存泄漏的监控装置，其特征在于，包括：
监控对象添加单元，用于在面向切面的语言中定义集合和操作；所述集合中的元素为软件中需要判断内存泄漏的对象，所述操作为所述元素添加到幽灵引用和引用队列中；在幽灵引用和引用队列中添加所述集合中的对象；
次数统计单元，用于对软件进行测试，统计需要判断内存泄漏的对象的未被回收的次数；
内存泄漏判断单元，用于根据所述次数判断所述次数对应的对象是否内存泄漏，若是，生成hprof文件。
11.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述内存泄漏判断单元，具体用于：
周期对每个历史周期统计到的需要判断内存泄漏的对象的次数基于最小二乘拟合进行数据统计，当确定数据统计的结果超出该次数对应的对象要求的阈值时，判断出该对象内存泄漏，生成hprof文件；其中，所述次数统计单元，具体用于：
运行预录的测试文件，周期统计需要判断内存泄漏的对象的未被回收的次数，记录每个历史周期统计到的所述次数；
其中，所述基于最小二乘拟合进行数据统计，具体为：
以直角坐标系的纵轴表示每个历史周期统计到的需要判断内存泄漏的对象的次数，以直角坐标系的横轴表示所述次数对应的时间；在所述直角坐标系中用最小二乘拟合得出直线，所述直线的斜率为数据统计的结果。
12.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述内存泄漏判断单元，还用于：
比较所述次数与该次数对应的对象的极限次数的大小，当确定所述次数大于所述极限次数时，判断出该对象内存泄漏，生成hprof文件。
13.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述内存泄漏判断单元，还用于：
当所述次数的对应的对象的预设的前续动作已完成且所述次数不为0时，判断出所述次数对应的对象内存泄漏，生成hprof文件。
14.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述监控装置，还包括：
邮件发送单元，用于发送hprof文件到预设的电子邮箱。
15.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述监控装置，还包括：
文件查看单元，用于引用树查看工具打开hprof文件。
16.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述监控装置，还包括：
测试文件录制单元，用于录制测试文件；
所述对软件进行测试，具体为：
运行测试文件，自动对软件进行测试。
17.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述面向切面的语言包括：aspectj。
18.根据权利要求10所述的一种测试过程中内存泄漏的监控装置，其特征在于，所述生成hprof文件，具体为：确定所述对象是第一次内存泄漏时，生成hprof文件。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410356321.5A CN105302714B (zh) | 2014-07-24 | 2014-07-24 | 一种测试过程中内存泄漏的监控方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410356321.5A CN105302714B (zh) | 2014-07-24 | 2014-07-24 | 一种测试过程中内存泄漏的监控方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105302714A CN105302714A (zh) | 2016-02-03 |
| CN105302714B true CN105302714B (zh) | 2019-02-05 |
Family
ID=55200003
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410356321.5A Active CN105302714B (zh) | 2014-07-24 | 2014-07-24 | 一种测试过程中内存泄漏的监控方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105302714B (zh) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107239394A (zh) * | 2016-03-29 | 2017-10-10 | 卓望数码技术（深圳）有限公司 | 一种安卓应用的内存泄露检测方法及装置 |
| CN106095689B (zh) * | 2016-06-24 | 2019-02-12 | 北京奇虎科技有限公司 | 一种应用内存泄露的检测方法和装置 |
| CN106649105B (zh) * | 2016-12-08 | 2019-06-04 | 武汉斗鱼网络科技有限公司 | 一种内存泄漏的检测方法和装置 |
| CN106844159A (zh) * | 2017-02-03 | 2017-06-13 | 广东欧珀移动通信有限公司 | 一种信息获取方法、装置及智能终端 |
| CN110543358A (zh) * | 2018-05-29 | 2019-12-06 | 北京京东尚科信息技术有限公司 | 图片还原方法和装置 |
| CN109558308A (zh) * | 2018-09-29 | 2019-04-02 | 中国平安人寿保险股份有限公司 | 应用程序内存泄露检测方法、装置、电子设备及存储介质 |
| CN109408383B (zh) * | 2018-10-12 | 2023-04-14 | 北京宝兰德软件股份有限公司 | 一种Java内存泄漏分析方法及装置 |
| CN111240956A (zh) * | 2018-11-28 | 2020-06-05 | 阿里巴巴集团控股有限公司 | 内存泄漏监测方法、装置、电子设备及计算机存储介质 |
| CN110032464B (zh) * | 2019-03-15 | 2023-06-16 | 北京星网锐捷网络技术有限公司 | 内存泄露的处理方法及装置 |
| CN111552616A (zh) * | 2020-04-30 | 2020-08-18 | 汉海信息技术(上海)有限公司 | 一种内存监听方法及装置 |
| CN113407419B (zh) * | 2021-07-15 | 2022-09-16 | 腾讯数码（深圳）有限公司 | 内存泄漏检测方法、装置、计算机设备和存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1466057A (zh) * | 2002-06-20 | 2004-01-07 | 华为技术有限公司 | 一种软件内存泄露的检查方法 |
| CN101539870A (zh) * | 2008-03-21 | 2009-09-23 | 中兴通讯股份有限公司 | 内存泄漏检测装置及方法 |
| CN102681938A (zh) * | 2012-05-15 | 2012-09-19 | 青岛海信移动通信技术股份有限公司 | 一种内存泄漏检测方法及装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2503477A (en) * | 2012-06-28 | 2014-01-01 | Ibm | Managing persistent messages between a message producer and a remote message consumer using references pointing to messages |
-
2014
- 2014-07-24 CN CN201410356321.5A patent/CN105302714B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1466057A (zh) * | 2002-06-20 | 2004-01-07 | 华为技术有限公司 | 一种软件内存泄露的检查方法 |
| CN101539870A (zh) * | 2008-03-21 | 2009-09-23 | 中兴通讯股份有限公司 | 内存泄漏检测装置及方法 |
| CN102681938A (zh) * | 2012-05-15 | 2012-09-19 | 青岛海信移动通信技术股份有限公司 | 一种内存泄漏检测方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105302714A (zh) | 2016-02-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105302714B (zh) | 一种测试过程中内存泄漏的监控方法和装置 | |
| Lewis et al. | Does bug prediction support human developers? findings from a google case study | |
| US8745572B2 (en) | Software development automated analytics | |
| US20150095892A1 (en) | Systems and methods for evaluating a change pertaining to a service or machine | |
| US9317400B2 (en) | Code coverage rate determination method and system | |
| US20150254593A1 (en) | Streamlined creation and utilization of reference human intelligence tasks | |
| CN107967209B (zh) | 一种检测前端网页代码中错误的方法、检测设备及服务器 | |
| US11868468B2 (en) | Discrete processor feature behavior collection | |
| US20100138811A1 (en) | Dynamic Performance Profiling | |
| US8434069B2 (en) | System and method for effort estimation | |
| CN110362483A (zh) | 性能数据采集方法、装置、设备及存储介质 | |
| US20100223600A1 (en) | Thread execution analyzer | |
| CN112153375B (zh) | 基于视频信息的前端性能测试方法、装置、设备及介质 | |
| Trubiani et al. | Performance issues? Hey DevOps, mind the uncertainty | |
| US20180336122A1 (en) | Generating application flow entities | |
| CN109542341B (zh) | 一种读写io监测方法、装置、终端及计算机可读存储介质 | |
| US20100268502A1 (en) | Downward propagation of results for test cases in application testing | |
| Lin et al. | Empirical Evidence on Developer's Commit Activity for Open-Source Software Projects. | |
| US10579761B1 (en) | Method and system for reconstructing a graph presentation of a previously executed verification test | |
| US10496524B2 (en) | Separating test coverage in software processes using shared memory | |
| Eloussi | Determining flaky tests from test failures | |
| CN108959006A (zh) | 一种硬件检测方法及其工具 | |
| US20160041900A1 (en) | Testing integrated business systems | |
| US20130091384A1 (en) | System and method for measuring the effect of interruptions on software application usability | |
| US11210714B1 (en) | Systems and methods for experience-based development |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |