软件评测师性能测试,软件评测师之性能测试步骤[2]

性能测试步骤(四)--测试执行

测试的执行中，需要监控测试客户端和服务器性能，监控服务器端应用情况：

客户端的系统资源(cpu、io、memory)情况

服务端的系统资源(cpu、io、memory)情况

服务器的jvm运行情况

服务端的应用情况，看是否有异常

响应时间、吞吐量等指标

系统资源监控，linux下可以采用的工具有：vmstat、top、meminfo等。

JVM的监控，可以用jprofiler工具，linux下面的jmap、jhat等。

响应时间、吞吐量等，由grinder提供。

上述这些信息，一般在测试结束后，均需要归档整理，已备后续详细分析

我们自己开发一套脚本，用于以固定的频率获取测试客户端和服务器的vmstat和top输出、grinder的log,并从中截取有用信息保存，用于事后分析。

每次测试运行完以后，肯定会增加很多数据，需要考虑本次执行对数据量的影响，如果数据量的变化对后续测试会有影响，则需要清理数据。

性能测试步骤(五)--测试分析

测试分析一般跟测试监控息息相关，在测试执行的过程中，用各种监控工具能看到系统运行的状态，并及时发现问题。

常见的问题有：内存问题、有限资源竞争问题。

内存问题

从top中看tomcat的内存占用，这个是不准的，需要用专门的内存分析工具来查看。

工具：jmap,jhat,jstat,可以得到内存快照，得到堆内存的详细信息。

垃圾收集配置会影响系统性能，如果内存块生成和销毁量很大，则能看到系统吞吐量随垃圾收集呈现周期性的变化。

从理论上来说，JAVA会出现内存泄漏的情况，不过我们在被测试的应用中还没有发现过这种情况。

但是，在某些系统架构下，内存会成为瓶颈问题。比如我们曾经测试过聊天系统，每个长连接需要占用5M内存，那么，一台10G内存的服务器只能保持2000个长连接。

共享资源竞争问题

有限资源的竞争有很多，比如Service层的一个共享对象，比如数据库连接，比如数据库中的某一个使用频率很高的数据表。

一个共享资源在一个时间点上，只能被一个线程获得，其他线程必须等待，这就容易造成很多线程的timed wait状态。通过jprofiler工具，能够得到线程快照，并分析改进方法。

性能测试经验交流--偶然性问题

跟一般的功能测试一样，性能测试也会出现偶然性问题。

碰到这种问题，我们需要发挥测试人员的革命精神，追查到底。我们常发现的因素如下：

外部因素变化，比如，某几次测试，有时候好，有时候不好，并没有规律可循。最后发现原来是因为网络不稳定造成。请求返回变化。有时候第二次请求的内容取决于第一次的返回信息(也就是所谓的“关联”)，这种关联一般通过string的parse实现，而这一般都不是很可靠，返回一旦变化，可能就会出错。

应用服务器如果是集群，一个用户请求某一台服务器能得到正确返回，但是如果换做另一个用户，可能该服务器并没有该用户的信息，所以返回错误。

性能测试经验交流--客户端并发

测试客户端要模拟高并发，必然要启动多线程，所以肯定也会存在线程并发问题。比如：

在做参数化的时候，存储参数的数组就是一个共享对象。如果要使每个线程的每次循环都读取不一样的参数，那数组下标的更新需要注意并发问题。

比如，如果在脚本中要调用System.out,那么也需要注意这也是一个共享对象，如果调用System.out过多，会导致线程的等待，使客户端性能降低。

性能测试经验交流--测试人员

性能测试由于涉及面广，对测试人员的要求就很高。我想，性能测试人员应该培养如下几方面的能力：

如前所述，对应用架构的透彻理解。

沟通能力，测试进行过程中，一定要培养勤于跟开发沟通的意识，以提高工作效率。

解决问题的能力，在编脚本或者测试执行过程中，会碰到很多问题。首先是不要害怕，先考虑问题的可能原因，然后一步步定位、验证。当然，这个过程，需要调试等经验的不断积累。

[1]  [2]