软件内存泄露测试
作者:网络转载 发布时间:[ 2012/3/7 10:35:20 ] 推荐标签:
在解决内存泄漏问题之前,先来看看如何发觉哪些进程存在内存泄漏,也是内存泄漏的测试方法。主要有两种测试方法:
(1)模仿用户长时间使用设备,经过一段时间后(例如:几天),查看进程内存的使用情况,对于那些内存大量增长的进程,可以初步怀疑其有内存泄漏。
为了排除进程可能确实需要那么多内存的影响,一般在把大部分测试用例运行一遍之后,这时该分配的内存都已经分配,记录各个进程的内存使用情况,作为检测各个进程是否存在内存泄漏的基点。
进行长时间的操作后,再来记录各个进程的内存使用情况,与前面记录的结果比较,进行分析。
这种测试的好处在于,更加贴近用户的实际情况,结果比较真实可靠,测试成本比较低。其问题在于,虽然发现了有内存泄漏,但并不知道是在哪个测试用例出现的内存泄漏,程序员不得不查看其整个代码来查找原因,这对程序员来讲无疑是个噩梦。
而且这种方法很可能会造成:程序员奉命检查内存泄漏,经过千辛万苦终于找到一个内存泄漏,满心欢喜地修改完成后交工了事。而实际上呢,代码中往往不止一个地点存在内存泄漏。这样程序员改完之后再测,测完再改,极大地浪费了时间。
虽然这种方法有很多缺点,但鉴于测试成本比较低,不用刻意去操作,还是应该多多使用。毕竟如果你想把东西卖给别人,自己先要用着好用。
(2)针对某个具体的测试用例,检查是否有内存泄漏。这时测试人员需要对每一个测试用例反复操作,比较前后进程的内存使用,以检查是否存在内存泄漏,工作量很大,非常麻烦。
这种方法的好处在于:程序员能够很清楚哪几个操作存在内存泄漏,那么他可以采用后面讲到的一些方法,去查找内存泄漏,而且也防止了程序员在查到一个内存泄漏之后兴奋不已,草草地交工了事。这样可以提高程序员查找、修复内存泄漏的效率。
缺点在于:成本高,对于一个测试用例,检查其是否存在内存泄漏要比验证其是否工作正常,在时间和精力上要多几倍,因此不能像前面的方法频繁使用。
如果称第一种方法为系统测试的话,那么这种方法可以称为单元测试。
从修复内存泄漏的角度来讲,程序员更希望采用第二种方法进行测试,针对其测试成本高的问题,可以想一些方法来进行优化。
● 对于用户频繁使用的测试用例要作为重点,经常进行测试验证。如果这些测试用例哪怕出现一点内存泄漏,经过多次操作累积,内存泄漏的数量也是很大的;同理,对于那些不常使用的测试用例,测试的频率可以降低。
● 对于守护进程的测试用例要详细,内存泄漏主要出现在守护进程中。
● 对于非守护进程,基本可以不测,因为这些进程一退出,内存都还给系统了,但这里有一个隐患:如果这些进程与守护进程存在通信的话,可能导致守护进程出现内存泄漏。
检测设备的内存泄漏是一个长期的过程,需要不断进行测试、修改,千万不要想起来了,测试一下,改完之后,认为问题都解决了。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11