1 / 4
文档名称:

性能测试步骤.docx

格式:docx   大小:18KB   页数:4页
下载后只包含 1 个 DOCX 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

性能测试步骤.docx

上传人:文库旗舰店 2022/4/30 文件大小:18 KB

下载得到文件列表

性能测试步骤.docx

相关文档

文档介绍

文档介绍:性能测试步骤
作者:网络转载 发表于:[ 2011-9-5 9:23:56 ]
性能测试步骤(一)——熟悉应用
这是整个性能过程最关键的步骤之一,毋庸质疑。
我们必须了解:应用的架构
以我熟悉的应用类型为例。了解了应用架构,我们才。包括:网络带宽要高于服务器吞吐量、网络带宽要稳定。
测试数据
如果被测功能涉及数据库和高速缓存,通常需要预设很大的数据量才能凸显性能瓶颈,这通常是挺困难的一个环节。
如果是已经上线的应用,数据可以从线上拷贝得到;如果还没有上线,那需要构造类似于线上的数据量。
比如,要测试群聊性能,我们首先需要注册大量用户;然后把测试用户都加入到聊天群中。
测试数据准备的脚本,有时候比测试脚本本身还要多。
对于实在没有办法构造大数据量的情况,如果要测试高速缓存,我们有时候会按数据量的比例减少高速缓存,以使测试结果尽量准确。
测试脚本
Grinder脚本用jython实现
测试脚本的实现往往会花费比较长的时间
因为涉及到应用实现的细节,需要和开发不断交流才能完成。这也是需要了解应用架构的原因之一。
关于sleep time
基于真实模拟的考虑,sleep time还是尽量按照真实时间,并给一定的偏差。
不过对于测试客户端来说,sleep time往往会引起很多客户端测试线程的调度,浪费客户端系统资源。
Sleep time越小,客户端能模拟的吞吐量就越大,所以,实际测试中,我们往往会把sleep time设置为0 。
性能测试步骤(四)——测试执行
测试的执行中,需要监控测试客户端和服务器性能,监控服务器端应用情况:
客户端的系统资源(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会出现内存泄漏的情况,不过我们在被测试的应用中还没有发现过这种情况。
但是,在某些系统架构下,内存会成为瓶颈问题。比如我们曾经测试过聊天系统,每个