本文目录
jmeter 压力测试脚本怎么写
1. 运行jmeter 2. 左边树将出现测试计划、工作台两根节点。 3. 选择测试计划，按右键－》添加－》threads（users）线程组 线程组能设置以多少个线程并发做压力测试。 在”循环次数”设置不选择永远，循环次数设置1。***隐藏网址***
服务器性能测试典型工具介绍
众所周知，服务器是整个网络系统和计算平台的核心，许多重要的数据都保存在服务器上，很多网络服务都在服务器上运行，因此服务器性能的好坏决定了整个应用系统的性能。 现在市面上不同品牌、不同种类的服务器有很多种，用户在选购时，怎样从纷繁的型号中选择出所需要的，适合于自己应用的服务器产品，仅仅从配置上判别是不够的，能够通过实际测试来筛选。而各种的评测软件有很多种，你应该选择哪个软件测试？下面就介绍一些较典型的测试工具： （一）服务器整机系统性能测试工具 一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分，而针对不同的应用，可能会对某些部分的性能要求高一些。 Iometer（www.iometer.org）：存储子系统读写性能测试 Iometer是Windows系统下对存储子系统的读写性能进行测试的软件。可以显示磁盘系统的IO能力、磁盘系统的吞吐量、CPU使用率、错误信息等。用户可以通过设置不同的测试的参数，有存取类型(如sequential ,random)、读写块大小(如64K、256K)，队列深度等，来模拟实际应用的读写环境进行测试。 Iometer*作简单，可以录制测试脚本，可以准确有效的反映存储系统的读写性能，为各大服务器和存储厂商所广泛采用。 Sisoft Sandra（www.sisoftware.co.uk）：WINDOWS下基准评测 SiSoft发行的Sandra系列测试软件是Windows系统下的基准评测软件。此软件有超过三十种以上的测试项目，能够查看系统所有配件的信息，而且能够对部分配件（如CPU、内存、硬盘等）进行打分(benchmark)，并且可以与其它型号硬件的得分进行对比。另外，该软件还有系统稳定性综合测试、性能调整向导等附加功能。 Sisoft Sandra软件在最近发布的Intel bensley平台上测试的内存带宽性能并不理想，不知道采用该软件测试的FBD内存性能是否还有参考价值,或许软件应该针对FBD内存带宽的测试项目做一个升级。 Iozone（www.iozone.org）：linux下I/O性能测试 现在有很多的服务器系统都是采用linux*作系统，在linux平台下测试I/O性能可以采用iozone。 iozone是一个文件系统的benchmark工具，可以测试不同的*作系统中文件系统的读写性能。可以测试Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read, pread ,mmap, aio_read, aio_write 等等不同的模式下的硬盘的性能。测试所有这些方面,生成excel文件，另外, iozone还附带了用gnuplot画图的脚本。 该软件用在大规模机群系统上测试NFS的性能，更加具有说服力。 Netperf（www.netperf.org）：网络性能测试 Netperf可以测试服务器网络性能，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统发送数据，以及另外一个系统能够以多块的速度接收数据。 Netperf工具以client/server方式工作。server端是netserver，用来侦听来自client端的连接，client端是 netperf，用来向server发起网络测试。在client与server之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结果；在控制连接建立并传递了测试配置信息以后，client与server之间会再建立一个测试连接，用来来回传递着特殊的流量模式，以测试网络的性能。 对于服务器系统来说，网络性能显得尤其重要，有些服务器上为了节省成本，采用了桌面级的网络芯片，性能怎样，用这个软件一测便知了。 以上介绍的这几款测试工具都是可以免费从网上下载的非商业软件，但是其测试结果和认可程度均是为大多数使用者所认同的。你可以根据自己的应用需求选择不同的软件进行测试。 （二）针对应用的测试工具 随着web应用的增多，服务器应用解决方案中以Web为核心的应用也越来越多，很多公司各种应用的架构都以web应用为主。一般的web测试和以往的应用程序的测试的侧重点不完全相同，在基本功能已经通过测试后，就要进行重要的系统性能测试了。系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言包括执行效率、资源占用率、稳定性、安全性、兼容性、可靠性等等，以下重点从负载压力方面来介绍服务器系统性能的测试。系统的负载和压力需要采用负载测试工具进行，虚拟一定数量的用户来测试系统的表现，看是否满足预期的设计指标要求。负载测试的目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等如何决定系统的性能，例如稳定性和响应等。 负载测试一般使用工具完成，有LoadRunner，Webload，QALoad等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。 使用压力测试工具对web服务器进行压力测试。测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。 Loadrunner：预测系统行为和性能的负载测试工具 目前，业界中有不少能够做性能和压力测试的工具，Mercury（美科利）Interactive公司的LoadRunner是其中的佼佼者，也已经成为了行业的规范,目前最新的版本8.1。 LoadRunner 是一种预测系统行为和性能的负载测试工具，通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试，LoadRunner 适用于各种体系架构，能支持广范的协议和技术（如Web、Ftp、Database等），能预测系统行为并优化系统性能。它通过模拟实际用户的*作行为和实行实时性能监测，来帮助您更快的查找和发现问题。Loadrunner是一个强大有力的压力测试工具，它的脚本可以录制生成，自动关联。测试场景面向指标，实现了多方监控。而且测试结果采用图表显示，可以自由拆分组合。 通过Loadrunner的测试结果图表对比，你可以寻找出系统瓶颈的原因，一般来说可以按照服务器硬件、网络、应用程序、*作系统、中间件的顺序进行分析。 Loadrunner是一款收费软件，根据测试项目和虚拟用户数目的不同而花费不同的费用。不过你可以下载到免费使用10天的测试版本。 Webload：WEB性能压力测试 webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试; webload通过模拟真实用户的*作,生成压力负载来测试web的性能。 用户创建的是基于javascript的测试脚本,称为议程agenda,用它来模拟客户的行为,通过执行该脚本来衡量web应用程序在真实环境下的性能。当前版本是6.0。webload提供巡航控制器cruise control的功能,利用巡航控制器,可以预定义web应用程序应该满足的性能指标,然后测试系统是否满足这些需求指标; cruise control能够自动把负载加到web应用程序,并将在此负荷下能够访问程序的客户数量生成报告。 webload能够在测试会话执行期间对监测的系统性能生成实时的报告,这些测试结果通过一个易读的图形界面显示出来,并可以导出到excel和其他文件里。 这两个软件的功能虽然强大，并且可以自动生成测试报告，但其终究是一个工具，如果你想真正的定位服务器性能的好坏和性能的瓶颈所在，需要使用工具的人对于测试软件的方方面面都要有了解，比如软件体系构架，网络拓扑，服务器硬件等知识。
测试开发技术(二)——压力测试
上一篇文章里说过，目前互联网公司的测试开发岗位分两类。多数的一类是既要负责业务测试、自动化测试，同时也要去开发测试框架、效率工具来辅助业务测试。这类测试开发的岗位（主要指后端的岗位）一般多少都要接触压力测试。 压力测试、性能测试、负载测试、稳定性测试在网络上有很多文章介绍概念和区别，通常在项目过程中不会区分那么多，实际项目中都是以目标为导向，通常实际项目中都会说，压测一下看下性能，所以这里就不管详细的概念和区别了。为了好理解，我们这里统一叫压测，并以得到性能数据为性能测试，以观察稳定性为稳定性测试。 性能测试和稳定性测试的相同之处在于都是使用压测工具来进行。但目标不同，性能测试是通过压力测试得到系统的极限性能或者和上一版本的性能对比数据。而稳定性测试则是通过压力测试提供稳定或者变化的持续流量，来观察系统持续运行的情况下是否存在异常。 正常情况下，一般系统先做性能测试，拿到极限性能或者性能对比数据（对于非1.0项目，性能数据一般需要和上一个版本对比）之后，再通过安全的流量持续压测更长时间，来完成稳定性的验证。 下面我们就具体介绍一下怎么做性能测试和稳定性测试。 性能测试的第一步要确定目标，就是为什么要做性能测试，要达到什么样的目标或者效果。比如某个首次上线的系统，性能测试主要是为了得到系统的极限性能数据；再比如，系统优化，更换了RPC协议或者消息队列，性能测试就是为了量化此次系统优化在性能上优化的效果。另外，也不是所有的项目都需要性能测试，比如一个内部系统，用户数和流量本身就很少，而且在未来一段时间也不会有增量，这就基本不需要性能测试。 如果是从无到有的1.0项目，因为项目还没有上线，所以只能评经验来预估线上的流量数据；但如果是非1.0项目，就可以收集当前的线上数据。具体收集的数据如下（仅供参考，要按照实际情况来调整）：1）被测系统或模块各类请求流量比例；2）系统或模块目前平均、峰值、最小 qps；3）线上部署方式和规模；4）被测系统或模块依赖能承受的QPS或者容量。 确定目标和收集完线上现有数据之后，需要根据目标和现有数据确定压测方案，比如，每个阶段通过多大并发或者流量来压测、分几个阶段、每个阶段多长时间、以及压测过程中需要观察和记录哪些数据等。 同时，也要准备压测环境，压测的环境要尽可能的和线上一致，如果达不到，就做等比缩放。比如，一个系统有A、B两个模块组成，线上A部署了20台机器，B部署了5台机器，那么压测就可以A部署4台，B部署1台。机器和实例的数量只是一个方面，同时也要考虑机器的性能（CPU盒数、内存、磁盘、网卡等），还要考虑依赖方（如DB、缓存、消息队列等）的部署。部署压测环境的核心思路就是要用这套环境反应出线上环境的真实情况。 ***隐藏网址*** 选择好压测工具就要构造压测数据了。构造压测数据主要分两点： 第一点是要构造压测环境系统中的数据。因为线上系统内部一定是有一定数据的，我们要尽量模拟线上就要在系统中添加相应的数据。 另一点就是要准备压测的请求数据。这点跟选择的压测工具有关，一般来说分2种： 1）数据词典， 压测的请求提前准备好，存入文件、DB或缓存里，数据量较大的时候一般需要写程序生成。 2）实时生成，这种是压测工具在压测的时候根据配置规则来实时随机生成请求。 准备工作一切就绪，下一步就开始做压测的执行。这时候主要就是根据压测方案的从低到高去调整压测工具的并发数或请求数，来对目标系统或模块进行压测。 压测时，要观察CPU、内存、网络IO、磁盘空间、被压目标日志、依赖系统或者模块的状态等数，也要记录不同并发下目标系统或者模块处理请求的QPS和响应时间。同时也要注意有没有内存泄漏、句柄泄漏、系统崩溃等问题。 实际上部分数据在记录的过程中就可以初步整理出来。这里要针对上一步记录的数据，进行汇总，主要要产出在不同并发下，上面提到的数据都是什么情况。需要根据数据判断出极限性能，找到这种部署情况下瓶颈在哪，以及是什么原因造成的，为后续扩容提供依据。有些情况还需要跟以前的数据做对比，看性能提升或者下降的程度是不是符合预期。最后，把这些信息综合汇总、分析之后，产出性能测试的报告。 通常性能测试之后拿到了性能数据之后，都会在安全的并发或者流量下持续压测更长的时间来确保服务的稳定性。比如，笔者通常测试性能的时候，每轮可能压测半小时到一小时（在刚开始并发或者流量较小的时候可能会更短），在得到期限性能之后，会控制极限性能时80%-%90的流量或者并发去压测更长的时间，这个时间一般会比较长，而且多数情况下会在晚上下班前启动，然后第二天到公司来看结果。 除了长时间通过安全流量来验证外，有些时候在特殊场景下，也需要验证在安全流量范围内，流量急曾或者急降的情况下，稳定性是否有影响。或者，验证在一定流量下，模拟某个依赖或者系统内部的模块出现问题，执行相应预案时，对系统整体的影响是否符合预期。 当然，稳定性很多情况是异常，但更多的异常会在异常测试里去做，这里的稳定性测试是指在一定流量压力下的稳定性测试，其他的就不做讨论了。 上面介绍了压力测试里，性能测试和稳定性测试要做什么，那具体怎么做呢？下面我们就通过一个实例来简单介绍一下。 一个消息推送的系统，推送的消息就是我们日常手机APP的通知消息。这个消息通知的系统有三个接口，分别是单播（指定推送给某个人）、组播（推送给一个组，组里可能有多个人）、广播（推送给APP所有用户）。现在这个系统做了一个重构，更新了内部交互的RPC协议，所以要压一下，跟之前的性能数据做个对比。另外，系统重构前，线上集群极限性能为30000 QPS。 下面，我们就按照前面的步骤，来简单介绍一下具体怎么做。 目标就是要得到重构后的系统性能数据，并和原有的做对比，原有的极限性能已知，大概在30000 QPS左右。 收集线上数据，比如说我们收集到单播、组播、广播的请求比例为5：78：1；组内人数大概在300-1000；发送的消息字符数在30-100这个区间。 压测方案要先确定部署方案，比如这个系统向上是20台机器（或者实例），压测采用2台机器（等比缩放）。压测机器是线上的1/10，所以我们的目标性能就是3000qps。那么我们压测的方案就可以如下设置： 第一轮，2个并发，5-10分钟，主要目的是为了先验证环境和压测工具没有问题； 第二轮，根据上一轮并发数和机器资源（CPU、内存、IO）的情况，调整并发到极限的一半多一些（比如，之前是2个并发，CPU占用10%左右，内存、IO占用都很小，那么就以CPU的占用作为参考来计算，1个并发大概占用5%，那我们就可以吧并发调到10-12，目标CPU占用是50-60%）。这其实才真正开始压测，如果没问题，就开始逐步加压； 第三轮，开始逐步增加，按照实际情况一次增加2-5个并发，直到性能达到瓶颈。 这里是假设压测工具通过调整并发数来操作压力，主要需要看下并发对系统CPU、内存、IO的影响，根据压测时机器的资源占用信息来判断增加多少并发。 确定好方案，就需要部署压测环境了，这里要注意，尽量使用跟线上一致配置的机器。 压测工具要根据实际业务做选择，必要的时候需要自己开发，工具开发后面如果有机会在其他的文章里介绍，这里就不多介绍了。我们这个例子因为是系统更换内部协议，对外接口不变，所以可以使用原有压测工具。 下面就是要构造数据： 首先，要构造系统内部的数据，比如用户信息、设备信息、组信息，这里既要根据线上的收集到的信息来构造，比如用户数、组的数量、组内用户数等。这类如果方便的话可以直接在DB里插入，或者掉相应的系统API来准备。 然后就是压测的请求数据，比如说压测工具是用数据词典来压测，那么这里我们就通过脚本，来生成压测请求数据。这里要注意线上收集到的各个接口的占比，即5：78：1。压测的时候按照这个比例来提供流量。 准备工作完成，开始做压测。 这时候要先吧各类数据观察准备好，一般现在的互联网大厂都有图形化的工具来看，如果没有也可以通过linux的一些命令来看。常用的命令有top\ps\vmstat， 这里推荐使用top来查看实时的资源情况，使用vmstat的来定时输出当资源情况（vmstat -t 1 就是每秒输出一次）。 准备好了观测，那就启动压测工具，按照方案压测。压测方案上面已经介绍，这里就不重复了。 假如我们并发加到20个的时候，CPU占用达到85%左右，处理请求达到3600qps，其他资源占用都不足机器的一半；并发加到22个的时候，CPU占用达到95-100，处理请求是3700qps；并发加到24，CPU打满，处理请求3800QPS，并且出现错误日志。这时候就可以停止压测了。 数据整理，我们首先要整理一个表格或者图标，我们这里用表格： 这个表格就是压测产出的最核心的数据，由于CPU是明显的性能瓶颈，表格里就不体现其他资源了，如果其他资源使用率也比较高，也要放到这个表格里，又或者瓶颈在外部依赖，也要体现出来。通过这个数据可以看出，3700QPS就是系统处理的极限，安全的流量在3600QPS。这时候就可以用17-20的并发数，长时间压测压测一下，看看系统整体的稳定性。 那么性能报告怎么写呢？下面就给出一个比较简单的性能报告样例。 标题：消息推送RPC协议升级性能测试报告 一、项目背景 这里写项目背景和目标 二、压测环境 线上20台物理机，压测环境使用2台物理机，配置与线上一致，具体如下： XX核，XXG内存，万兆网卡，硬盘 400G * 6 SSD DB：XX主XX从XX备 三、压测方案和数据 1. 请求比例 单播：组播：广播 = 5：78：1 2. 压测过程数据 3. 资源占用图 可以把QPS和CPU占用使用工具（比如excel）生成一个折线图，另外，可以把其他资源数占用的数据图片贴一下。 四、结论 压测过程中，压力达到3700qp时，内存与IO正常，CPU占用达到98%，无错误日志。压力达到3800qps时CPU打满，且5分钟后开始出现错误日志。因此系统在2台物理机部署极限性能为3700qps，性能瓶颈在CPU，预计线上20台机器极限性能为37000qps. 系统RPC协议升级前20台机器30000qps，升级后预计能达到37000qps，性能整体提升23%，符合预期。 上面就是一个比较简单的报告，真实项目中瓶颈不一定是CPU，可能是其他资源，也可能是依赖的系统或者模块，这些都需要观察和分析压测中的数据来得出。 压力测试是后端测试和测试开发人员的必备技能，这篇文章只是根据笔者的经验针对压力测试进行的总结，不能覆盖所有压测场景，仅给大家做个参考。更多的是需要我们根据系统的实际情况去探索和实践。
loadrunner如何做接口的压力测试
是C接口还是java接口。
C接口：建一个纯C的loadrunner脚本，然后写调用接口的程序（我也不会，是让开发写的）。或者在linux上安装一个loadrunner agent，在上面新建一个脚本然后也是写C的脚本。
java接口：建一个java的loadrunner脚本，导入需要的jar包，然后写java代码（也是让开发写）。
最好的办法是写个页面，但是有风险，就是web服务器不要成为瓶颈。
如何用LoadRunner对Linux服务器进行压力测试
使用LR对数据库进行性能测试，实际上有多种办法，包括通过现有的数据库协议进行CS模式的先录制后执行的模式，以及通过socket方式向服务器发包方式的测试方式。这些是常规书籍上介绍的比较简单上手的测试方法，但是不具备通用性，受已有协议或socket编程方式的限制，所以需要更为通用的测试方法。 用Java user的协议进行所有数据库性能的测试工作：Java user 不需要录制，把所有的操作通过java语言进行实现，通过lr调用java的class进行加压批量操作，这样可以不关心被测系统是哪个数据库，只要能够通过jdbc进行访问，就能实现性能测试。一、测试环境准备1. 被测服务器准备，根据测试目的，搭建需要的数据库服务器，确保数据库能够正常访问，正常操作；2. Java代码的准备，无论使用哪种IDE，只要能够编写访问数据库的class就可以，形式可以是j2se，也可以是j2ee，因为在操作时只使用class的部分方法，所以j2ee就可以了；3. LR的脚本调试，把java的class导入到脚本调试模式，根据需要添加事务以及其他操作。二、编写数据库访问1. 使用myeclipse，创建web project，创建如下图的包目录：Java文件中包含各种访问数据库的方法。需要注意的是，class中的方法必须是public static，否则LR中无法调用。由于创建的是j2ee程序，所以不用main函数，在web中就可以进行功能验证。确认class中的方法编写完成，创建一个web.jsp文件，如下：导入class 声明类，并实例化，直接调用刚才编写的3个方法，因为这3个方法是直接对数据库进行操作，不需要实参，也没有返回值，所以直接实现即可。此时启动web服务，在浏览器中输入jsp的地址，直接刷新页面，就可以调用这3个方法，如果正确，就会对相应的表进行操作，如果不正确，则需要修改相应的代码。2. LR脚本准备：LR脚本实际上就是对访问代码的调用，关键在于需要根据测试场景划分不同的脚本布局。例如：在myEclipse里，我们只编写了一个class，其中包含三个方法，如果在执行性能测试时，这三个方法相互独立，互不干涉，则最简单的划分方法是，创建三个java user，每个java user中包含一个方法，做三份脚本，场景执行时分别进行调用。如果三个方法之间有相互关系，则需要根据实际情况，把有关联的方法放在一起，具体情况可按实际灵活分配。因为已经将class文件进行编译发布了，所以可以在“java2postgres\WebRoot\WEB-INF\classes\com\lr\test”目录中找到对应的class文件，复制这个文件，找到LR的目录：HP\LoadRunner\classes\com\lr\test\ 如果没有文件夹，按相同的内容创建。在LR脚本中进行引包操作：将需要执行的java类以及方法，放在action中，可根据实际测试情况和所需要验证的内容，具体调试代码。在这里可以像编写普通LR脚本一样，添加事务或集合点等内容。由于是通过JDBC对数据库进行访问，因此要在java user中加载jdbc驱动。运行时设置中，增加jdbc驱动，需要注意的是java user使用的本地jdk，需要至多1.6版本，若使用1.7版本，回放会有错误，这是jdk版本的问题。操作完成之后，按F5或点击运行，进行脚本回放，实际此时也对数据库进行了操作，可以直接查询对应的表，检查功能是否正确。 三、执行性能测试已经有了java user的脚本，和普通web性能测试一样，设计场景、执行测试、收集报告、分析性能瓶颈即可。
