AppAgent 内存泄漏问题总结与反思

1.      原因分析

 

使用鱼骨图梳理该问题，可以发现主要是以下几个原因造成的：

一． 测试策略方面的失误

         AppAgent 企业通讯录功能，对不同的终端有不同类型的接口，我们经常提及的是移动客户端，话机，话务台。TR5前测试制定测试策略时， 由于不具备测试话机企业通讯录接口性能工具， 且测试话机接口需要比移动终端更多的物料（需要多配置网关和SIP号码），故决策AppAgent选择测试移动终端企业通讯录性能。

        此外，由于性能测试时间比较紧，主要重点是关注Linux大容量组网，windows组网只验证了最基本的性能。

 

二． 基础知识反面的错误

由于JAVA程序内存由GC管理， 且在性能测试过程中多发现的是OOM问题，内存泄漏问题比较少见，C++背景知识潜意识觉得JAVA不会有内存泄漏，对JAVA内存管理过于相信。

 

2.       总结与改进

一． 从AppAgent的使用场景来看，主要用于UC组网（移动客户端）和IPT组网（话机），故AppAgent性能测试策略应该要测试移动客户端和话机两种最常见类型（话务台相对使用较少，且目前缺乏相应的工具，在测试工具具备后也可以根据实际情况覆盖）

二． 策略继续维持重点关注Linux大容量组网场景，windows组网的策略更加明确，需要明确为如下几点：

1.      Windows 组网需要验证eServer 基本性能（目前有这样的动作）

2.      Windows 组网需要验证MAA 基本性能，顺带验证App 移动客户端企业通讯录性能( 目前没做)

3.      Windows 组网需要验证App 话机企业通讯录性能（目前没有做）

4.      Windows 组网需要验证UMServer 基本性能（目前没有做）

(Windows  版本App 与BMU 为同一个进程， App 验证过BMU可以不单独验证。MS比较稳定，可以不验证)

三． 学习了解JAVA可能出现内存泄漏的场景，增强自己对JAVA内存泄漏的警惕心

http://www.jianshu.com/p/93b91ea18c28

 http://blog.chinaunix.net/uid-7374279-id-4494760.html