JMeter的简介

可以肯定的是，JMeter至少符合以下几条自动测试标准：

• 零购置成本－－直接从http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi下载得到。
• 学习曲线平滑－－只需要基本的html和正则表达式知识。
• 功能全面－－不仅只能测试web应用。
• 架构可伸缩－－其组件被设计为可通过合并完成大规模测试。测试可以在多台主机上同时运行。
• API可扩展－－API开放，并可由用户扩展编程。
• 技术支持良好－－在线用户指南、用户论坛、网络文章也包括这本书。

本章引导您开始第一次的JMeter试用。将向您介绍JMeterm同时使您对它的能力有一个整体的认识。除此之外，还会带您认识JMeter的操作界面，让你亲身感受到几个重要的JMeter组件。

 让我们开始...
JMeter是一个桌面应用，被设计为用于测试c/s结构的应用程序，如web应用或FTP应用。是到目前为止，一个使用得最广泛的开源测试工具。它是由 纯java编写的，通过其API可以对它进行扩展。JMeter位于c/s中的客户端工作，它可以测试服务器的响应时间，CPU负载，内存占用和资源的使 用。

 绝大多数的JMeter测试脚本或测试计划都涉及到创建一个循环，按照预先定义的时间间隔和线程组来模拟向服务器发出请求。这些测试脚本可以定制和扩展。一个基本的JMeter测试计划应该至少包括三个部分：线程组，监听器，采样器。
线程组用来模拟一组用户（用户数至少一个）。
采样器使请求发往目标服务器。
监听器捕获每个请求后收到的响应数据。

通过界面认识它
一个典型的测试计划由一个或多个线程组，逻辑控制器，监听器，定时器，断言和配置等元素组成。
线程组：一个线程模拟一个用户。所有的测试计划的元素都必须放在一个线程组元素下。
监听器：监视JMeter运行测试用例时接收到的数据。
控制器：其逻辑可以自定义，如让检验员告诉JMeter向服务器发出请求。
定时器：设定一个线程发出的两次请求间的间隔时长。
断言：测试返回的结果是否是期望的值。
配置：与检验员相关，可以增加和修改请求。

以下为界面截屏图。

 

JMeter界面上有两个面板，一旦JMeter投入运行，你可以看到它们。测试计划和工作区面板，如下图所示。一个测试计划描述了JMeter投入运行后的测试步骤。工作区提供临时的数据存放空间。工作区数据与测试计划分开存放。

左边的面板以树形显示了我们测试计划，其中节点的添加和删除可以通过右击节点进行。右边的面板显示了每个节点的详细配置。

下面是由一个线程组和其它一些元素组成的一个测试计划例子。

在我们使用JMeter进行性能测试时，线程组是必选元素。这个元素可以通过模拟多个用户对服务器进行压力测试。你甚至可以对测试进行的时间进行预设，下图是线程组的详细显示。

另一方面，同样一个测试计划可以扩展成为包括功能或回归测试。如下图所示添加Assertion（断言）元素。

 正式开始使用...

 安装JMeter
你需要首先从以下网址下载最新发布的版本http://jakarta.apache.org/site/downloads/index.html，下载完成后，解压缩到你想要的目录就完成了安装。
提醒：为了进行远程测试请避免在压缩时使用带空格的目录名。

设置环境变量
首先机器上建议安装jdk1.4或更高版本。并设置JAVA_HOME环境变量。

运行JMeter
在你的JMeter的安装目录下有bin目录。在windows系统中，运行jmeter.bat。如果你运行在unix系统中，你需要运行jmeter。
在这个过程中，JMeter会自动在它的lib目录或lib/ext目录中找所需要的jar包。因此，如果将来您自己开发了JMeter的组件，你也需要把它们拷贝到JMeter的lib/exit目录中。
如果你运行JMeter在代理或防火墙的后面，你需要提供服务器名和端口号，用命令行的参数指定。
例如
jmeter -H 129.198.1.1 -P 8000 -u someusername -a someuserpassword -N localhost

测试计划

 JMeter的测试计划封装了你需要手动编写的测试脚本。
什么是测试计划？
测试计划定义了如何进行测试的框架。最简单的测试计划包括以下元素：
线程组：用于指定运行线程的个数和坡道期，循环次数。每个线程模拟一个用户，坡道期指定创建所有线程的时间。例如指定5个线程和10秒的坡道期，表示每个线程的创建时间为2秒。循环次数定义了测试重复的次数。而且可以指定开始和结束的具体时间。

采样器：用于发出http/ftp/soap/xml/jdbc/ldap请求到服务器。

监听器：用于后处理请求数据。例如你可以保存数据到文件或者以图表显示。

开始运行JMeter,测试计划就会出现工作区左边的面板窗口中。

具体描述如下：
User Defined Variables:你可以定义静态变量，它们是允许你在测试中重复提取的值，如服务器名，端口号等。例如你要测试一个www.example-jmeter.net的应用，你可以定义一个"server"变量，那么测试脚本中的"${server}"就会该值替代。

Functional Test Mode:它会记录下从服务器返回的数据。如果你要进行压力测试，请不要选择它因为它会影响结果。
Run each Thread Group separately：单独运行每个线程组。如果您有二个或更多的线程组在你的测试计划中。选中该项，表示JMeter会顺序地运行它们，否则会并发运行它们。

Add directory or jar to classpath:如果你自己扩展了JMeter组件，可以使用该项添加jar包。记住需要重启后才能生效。另外，你也可以直接把jar包拷贝到 JMeter/lib目录下。或者通过编辑JMeter.properties文件来包含额外的jar，如"#user.classpath=.. /classes;../jars/jar1.jar,这样可以避免出现路径中包含空格引发的问题。

测试计划的组成
测试计划必须由至少一个线程组组成。每个线程组中都可以包含一个或多个以下组合：
采样器，逻辑控制器，配置，监听器和定时器。每个采样器能够关联一个或多个预处理元素，后处理元素和断言元素。让我们更进一步了解它们。

线程组
线程组是测试计划的入口，它包含所有其它的JMeter元素，一个线程组控制所有由JMeter创建的仿真线程，它们模拟多用户请求。
线程组代表着一组执行特定测试用例的用户，在线程组的控制面板里，显示在下图。如果有多个线程组那么它们会彼此独立地执行。

详细描述如下：
Action to be taken after a Sampler error:一旦采样器在测试过程中报错，你可以作出以下的选择：Continue继续进行下测试，stop Thread停止当前测试的线程，Stop Test完成停止测试，便于进行错误原因的查看。
Number of Threads:模拟用户的人数或者是web应用的连接数。
Ramp-Up Period:定义JMeter创建所有测试线程的时长。例如设定线程数为10，坡道期为60秒，那么每个线程会以6秒/个的速度连续创建。在60秒以 后，所有的线程将会投入运行。比较好的策略是将你的坡道期设置得足够长以避免在测试一开始就造成很大的工作负载，但不要过长，你可以一开始将坡道期设置为 等于要创建的线程数，稍后根据情况进行调整。
Loop Count:定义测试执行的次数，默认情况下，测试仅执行一次。点击Forever选项框那么测试会一直重复执行直到你手动停止它。
Scheduler Configuration:1.9之后的版本具有该项，允许你设定测试的开始和结束时间。只有时间到达开始时间，测试才会真正开始。在每个测试循环之 后，除非结束时间到了，测试将会继续下去一直到达loop count的上限。startup delay用于设定JMeter在第一个测试线程启动前的开始等待时间，duration用于设定整个测试的进行时间。前者用于覆盖start time的设定，后者覆盖end time的设定。

控制器
JMeter有两类控制器：
1.Samplers:允许发送特定类型的请求给服务器。稍后我们会发送http请求给服务器，所以我们会选用Http Rquest采集器。可以通过Configuration元素给采集器进行设定。

2.Logic Controllers:允许自定义何时发出请求的逻辑。例如你可以用Random Controllers来向服务器随机发出http请求。

采集器
JMeter采集器允许你定义发往服务器的请求，模拟一个用户通过网页向服务器发出的请求。每个采集器生成结果包含以下一些，如性能、延迟时间、呑吐量 等。默认情况下，JMeter会按照采样器出现在测试计划树中的顺序发送请求命令。当然，为了处理的采样的顺序可以使用逻辑控制器进一步定制。这将在后面 的“逻辑控制器”中进一步解释 。

您可以自定义每个采样器通过设置其属性，或者您也可以添加配置元素。在这本书中，因为我们将发出许多HTTP请求到相同的服务器，我们可以使用默认配置元素，它预先定义了发送的http请求。

一个http请求的采样器面板显示如下：

 
如果你希望JMeter进行验证，你可以添加Assertion元素，关于Assertion的更多内容，后面再详细介绍。
在一个Http请求采样器面板中的响应Assertion显示如下：

 以下是JMeter提供的所有采样器列表：

HTTP Request
FTP Request
JDBC Request
Java Request
SOAP/XML-RPC Request
WebService (SOAP) Request
LDAP Request
LDAP Extended Request
Access Log Sampler
BeanShell Sampler
BSF Sampler
TCP Sampler
JMS Publisher
JMS Subscriber
JMS Point-to-Point
JUnit Request
Mail Reader Sampler
Test Action

逻辑控制器：用于定义采样器的执行顺序。一个逻辑控制器的子元素有：采样器、配置，其它逻辑控制器。JMeter可能会随机选取（使用随机控制器） ，重复（使用回路控制器） ，交换（使用交错控制器）等。

 

 
以下是所有JMeter提供的定时器列表：
Constant Timer
Gaussian Random Timer
Uniform Random Timer
Constant Throughput Timer
Synchronizing Timer
BeanShell Timer

 

配置元素
配置元素允许你创建默认的变量在采样器中使用。用于修改采样器发出的请求内容。
它们只能被同一范围内的采样器访问，并且先于采样器被执行。
以下是HTTP Request Defaults 面板，如图：


 

• 添加用户
• 添加和配置默认的HTTP Request
• 添加HTTP Request
• 添加监听器显示、存放测试结果
• 保存和运行测试计划

添加用户
1.右击Test Plan图标在左边窗格，然后选择add|Thread Group。


 右边的将显示Thread Group的控制面板。

2.将Thread Group更名为My Users.
3.设定为一次连接和一个用户。
4.更变Ramp-Up Period(坡道期)为0,意味着用户将会马上开始测试。如果还有其他的用户，那就意味着所有的用户立即开始测试。

 

接下来做其它的步骤。
添加默认的HTTP Request
1.右击My Users元素，选择Add | Config Element | HTTP Request Defaults。
2.选择后显示它的控制台界面。
3.重命名为My URL。
4.在服务器名或IP地址栏中输入www.mocksite.net或其它你想用的网址。其余不动。设置HTTP Request Default Element会引起在My Users中的所有请求采样器访问同一个服务器。
显示如下：


 

 

添加监听器
最后，我们添加一个简单的监听器，Aggregate Report。这个元素将存放所有http请求的结果，并以表格形式输出。
1.选择My Users元素并Add | Listener | Aggregate Report。
2.在Write All Data to a File：在Filename栏中输出目录名或用browse按钮选择，并输入输出文件名。
以下为完成图：


 

保存和运行测试计划
JMeter要求我们在运行之前保存测试计划。
1.选择Save Test Plan从File菜单。JMeter允许你只保存一部分，通过选择分支。
2.在Save as中输入文件名，例如输入My Users。扩展名为.jmx。
3.从run 菜单选择运行。
以下为Aggregate Report Element和Control Panel运行结果。注意右上角有小的方框，旁边的数字显示激活的线程数和总线程数。


 
以下为运行测试计划之后的界面。右上角方框为灰色，只显示总线程数，你也可以手动停止测试，通过选择Stop从Run菜单。

 

　　1.Running Vusers（负载过程中的虚拟用户运行情况）

　　说明——系统形成负载的过程，随着时间的推移，虚拟用户数量是如何变化的，描述为（用户在几分钟左右到达了组在峰值多少个虚拟用户，负载的生成是大约每分钟增加几个用户，峰值负载持续为几分几秒）。

　　2.Rendezvous（负载过程中集合点下的虚拟用户数）

　　说明——脚本中一般要设置集合点才会产生并发，随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。描述（刚开始的几分钟内，负载的并发用户都是几个，而后面变化为几个用户并发）。

　　（二）在Transactions（事务）中

　　这里给出了所有和事务相关的数据统计，方便了解被测试系统业务处理的响应时间和吞吐量。

　　1.Average Transaction Response Time（平均事务响应时间）

　　说明——反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。描述（看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并且在不到多少时间的时候突然出现响应时间大幅下降的情况）另外事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。

　　2.Transactions per Second（每秒事务数）

　　说明——数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统每秒可以处理多少个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在几分钟以后开始出现少量的失败事务）

　　3.Transaction Summary（事务概要说明）

　　说明——通过的事务数越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。描述（对于注册操作一共有对少次操作成功，有几次失败。可以开率结合前面的每秒错误数进一步分析为什么会出现几个注册错误，以及错误发生的时间和该时间产生错误的原因）

　　4.Transaction Performance Summary（事务性能概要）

　　说明——给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。描述（看到这个事务最大时间为多少S，最小时间为多少S，平均时间为多少S。柱状图的落差越小说明响应时间的波动较小，那么说明系统不够稳定。）

　　5.Transaction Response Time Under Load（在用户负载下事务响应时间）

　　说明——在负载用户增长的过程中响应时间的变化情况，起始这张图也是将Vusers和Average Transaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，说明系统越稳定。描述（看到负载逐渐增加到几个用户时，事务的响应时间基本没有变化，而用户增加到几个开始，随着用户负载的增加响应时间也有较大的波动）

　　6.Transaction Response Time（Percentile）（事务响应时间的百分比）

　　说明——有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。描述（看到百分几%的事务是在几秒内）

　　7.Transaction Response Time （Distribution）（每个时间段上的事务数）

　　说明——在每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。描述（看到在所有的事务中，有多少个事务的响应时间最接近几秒，而有几个事务的响应时间最接近几秒）

　　（三）在Web Resources（网页资源信息）中

　　当Controller的Run Time Setting中Preferences下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。

　　1.Hits per Second（每秒点击数）

　　说明——每秒点击数提供了当前负载重对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。描述（随着时间的增加，每秒点击数在上升，最高达到了多少次/s）。

　　2.Throughput（带宽使用）

　　说明——当前系统负载下所使用的带宽，该数据越小说明系统的贷款依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈。描述（得到醉倒的带宽峰值是多少B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈）。

　　3.HTTP Responses per Second（每秒HTTP响应数）

　　说明——每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于发出的请求数，那么说明服务器无法应答超出负载的连接请求。描述（最高峰时服务器每秒能返回接近多少个HTTP _ 200 OK的状态）。

　　4.Connections Per Second（每秒连接数）

　　说明——两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。描述（随着时间的推移，系统的连接数逐步上升，最高达到每秒几个连接）同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决问题。

　　（四）在Web Page Diagnostics（网页分析）中

　　当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长时由服务器端（后端）处理能力不足还是短连接到服务器的网络（前端）消耗导致的。

　　1、 Web Page Diagnostics（网页分析）

　　说明——添加该图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。描述（在注册用户事务进行分析，整个负载由三个页面请求组成，其中有一个请求始终在多少秒以内，而另外几个请求时间较长并且有上升趋势，然后通过Select Page to Break Down命令选择具体的Page来获得每个请求的相关详细信息——分析如下：

　　1.Download Time下载时间分析——组成页面的每个请求下载时间——可以看到创建用户的操作由4个请求组成，其中导致注册用户较慢的主要原因是注册完成后需要等待两秒钟再刷新至论坛首页，而非注册用户本身需要消耗的时间，首页刷新慢也只是因为Client（客户端）需要消耗较多时间，同时Receive（接收）的时间也有一定的影响。

　　2.Component（Over time）各模块的时间变化——通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。随着时间的增加，首页的处理时间（最上面的一根线）从多少秒上升到了最大值多少秒，而注册英护响应时间几乎没有上升。

　　3.Download Time（Over time）模块下载时间——针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。发现首页请求的下载时间主要消耗在Client上，而多少分多少秒之前Recevie所消耗的时间在逐渐变长。

　　4.Time to Buffer（Over time）模块时间分类——列出该元素所使用的时间分配比例，是受Network Time影响的多还是Server Time影响的多。对于首页刷新的响应时间来说，主要是Network Time网络上消耗的时间，而Server Time服务器端的处理时非常优秀的。Server Time是服务器对该页面的处理时间；Network Time是指网络上的时间开销。）

　　2、 Page Download Time Breakdown（页面响应时间组成分析）

　　说明——显示每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time客户端浏览接收所需要使用的时间，可以不用考虑。

　　Connections Time连接服务器所需要的时间，越小越好。

　　DNS Resolution Time通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。

　　Error Time服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返回错误的时间，该时间越小越好。

　　First Buffer Time连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time SSL加密握手的时间，而Analysis在这里会分析得到页面请求的组成比例图，便于分析页面时间浪费在哪些过程中。

　　3、 Page Download Time Breakdown（Over time）（页面组成部分时间）

　　说明——随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析再不同的时间点上组成该页面的各个请求时间是如何变化的。描述（看到大多数页面的响应时间是比较稳定的，其中首页刷新变动较大——首先找到变化最明显或者响应时间最高的页面，随后在针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因。）

　　4、 Time to First Buffer Breakdown（页面请求组成时间）

　　说明——组成页面时间请求的比例说明（客户端时间/服务器时间），通过这个图，我们可以直接地了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前段还是在后端。描述（网络或客户端的时间开销占了绝大多数）

　　5、 Time to First Buffer Breakdown（Over time）（基于时间的页面请求组成分析）

　　说明——在整个负载过程中，每一个请求的Server Time和Client Time随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。描述（对于用户注册操作，望楼上的时间变化比服务器上的时间变化要剧烈）

　　（五）在Network Monitor（网络监控）中

　　在 Controller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。

　　1、Network Delay Time（网络延迟时间）

　　说明——从监控机至目标主机的平均网络延迟变化情况。描述（看到网络延迟从多少毫秒逐渐减少到多少毫秒，最后上升到多少毫秒）。

　　2、Network Sub-Path Time（网络Sub-Path时间）

　　说明——当客户端在连接一个远程服务器时，路径并不是唯一的，收到路由器的路由选择，可能会选择不同的路径最终访问到服务器。描述（从监控服务区至目标服务器所经历的路径，以及每个路径上的网络延迟）

　　3、Network Segment Delay Time(网段延迟时间)

　　说明——各个路径上的各个节点网络延迟情况。描述（路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的原因及节点）。

　　（六）在Resources（资源监控）中

　　资源包括很多种，在Analysis中监控的都市各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统的瓶颈。

　　1、 System Resources（系统资源）列出了再负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控后才出现：

　　1.Database Server Resources（数据库资源）

　　说明——数据库的相关资源在负载过程中的变化情况。

　　2.Web Server Resources（Web服务器资源）

　　说明——Web服务器资源在负载过程中的变化情况。

　　（七）在Error（错误统计）中

　　当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。

　　Error per Second（每秒错误数）

　　说明——每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。描述(看到场景在多少的时候出现了一次错误)。

　　Service Level Agreement Legend（SLA图标说明）

　　1、图标为灰色带减号的为No Data，说明在SLA中未对这个数据项进行监控，没有数据；

　　2、图标为红色带叉的为Fail，说明在SLA中定义了该项的数据监控，但该数据未能达到期望的阀值；

　　3、图标为绿色带钩的为Pass，说明在SLA中定义了该项的数据监控，该数据达到了期望阀值。

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Vusers (虚拟用状态)

　　Vusers　用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助了解负载生成的过程。

　　Running Vusers(负载过程中的虚拟用户运行情况)

　　此图反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。

　　Rendezvous(负载过程中集合点下的虚拟用户)

　　当场景中设置了集合点后会出现该图，反映了随着时间的推移各个时间点上并发用户的数目，方便了解并发用户数的变化情况。

　　Errors(错误统计)

　　当场景在运行中出现错误时，错误信息将会保存在该计数器组中，通过 Error 信息可以了解错误产生的时间和错误的类型，帮助定位产生错误的原因。

　　Errors per Second(每秒错误数)

　　可以了解在每个时间点上错误产生的数目，该数据越小越好，通过该图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。

　　Transactions(事务)

　　给出所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量。

　　事务默认状态：PASS、FAIL、STOP，如果是手工事务那么状态会有 PASS 和 FAIL 两种。

　　Average Transaction Response Time(平均事务响应时间)

　　反映了随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。

　　结合负载生成图合并一起看，可以发现用户负载增加对系统事务响应时间的影响规律。

　　Transactions per Second(每秒事务数)

　　另一个关键数据是 TPS 吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。

　　TPS 会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS 会有所下降。

　　Transaction Summary(事务概要说明)

　　说明事务的 Pass 个数和 Fail 个数，了解负载的事务完成情况。通过的事务越多，说明系统的处理能力越强，失败的事务越少，说明系统越可靠。

　　结合每秒错误数图进一步分析错误产生的原因。

　　Transaction Performance Summary(事务性能概要)

　　事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。

　　柱状图的落差越小说明系统响应时间的波动较小，如果落差很大，说明系统不够稳定。

　　Transaction Response Time Under Load(在用户负载下事务响应时间)

　　在负载用户增长的过程中响应时间的变化情况，改图的线条越平稳，说明系统越稳定。

　　Transaction Response Time(Percentile)(事务响应时间的百分比)

　　不同百分比下的事务响应时间范围，可以了解有多少比例的事务发送在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。

　　Transaction Response Time(Distribution)(每个时间段上的事务数)

　　每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。

　　Web Resources(网页资源信息)

　　给出的是对于 Web 操作的一些基本信息，这些信息在服务器端也能获得，当 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performance graphs 选相处于开启状态时，才会得到该图。

　　Hits per Second(每秒点击数)

　　每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。

　　Throughput(宽带使用)

　　在当前系统下所使用的带宽，该数据越小说明系统的带宽依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈(注意使用单位为字节)。

　　HTTP Responses per Second(每秒 HTTP 响应数)

　　每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而 HTTP 响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。

　　结合每秒点击数看，如吻合，则说明服务器能够对每一个客户端请求进行应答。

　　Connections Per Second(每秒连接数)

　　给出两种不同状态的连接数，即中断的连接和新建的连接，方便了解当前每秒对服务器产生连接的数量。

　　同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常服务器会返回504错误。

　　可以通过修改服务器的最大连接数来解决该问题。

　　Web Page Diagnostics(网页分析)

　　当在场景中打开 Diagnostics 菜单下的 Web Page Diagnostics 功能，就能得到网页分析组图。

　　通过该图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间的分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过该功能，可以实现对网站前端的性能分析，明确系统响应时间较长是由服务器端处理能力不足还是客户端连接到服务器的网络消耗导致的。

　　Web Page Diagnostics(网页分析)

　　添加改图先会得到真个个场景运行后虚拟用户访问 Page 列表，也就是所有页面下载时间列表。

　　通过 Select Page to Break Down 命令选择具体的 Page 来获得每个请求的相关详细信息。

　　Diagnostics options 选项提供四大块功能。

　　Download Time(下载时间分析)

　　可以得到组成页面的每个请求下载时间。

　　Component(Over time)(各模块的时间变化)

　　列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。

　　通过该功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。

　　Download Time(Over time)(模块下载时间)

　　提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。

　　Time to First Buffer(Over time)(模块时间分类)

　　这里会列出该元素所使用的时间分配比例，是受 Network Time 影响的多还是 Server Time 影响的多。

　　Network Time：指网络上的时间开销。

　　Server Time：服务器对该页面的处理时间。

　　Page Download Time Breakdown(页面响应时间组成分析)

　　这张图显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time

　　客户端浏览器接收所需要使用的时间，可以不考虑。

　　Connections Time

　　连接服务器所需要时间，越小越好。

　　DNS Resolution Time

　　通过 DNS 服务器解析域名所需要的时间，解析受到 DNS 服务器的影响，越小越好。

　　Error Time

　　服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是 Web 服务器直接返回的，包含了网络时间和 Web 服务器返回错误的时间，该时间越小越好。

　　First Buffer Time

　　连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含了网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time

　　FTP 认证时间，这是进行 FTP 登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time

　　接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time

　　SSL加密握手时间

　　得到页面请求的组成比例图，便于分析页面时间浪费在那些过程中。

　　Page Download Time Breakdown(Over Time)(页面组成部分时间)

　　提供了随着时间的变化所有请求的响应时间变化过程。将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。

　　首先找到变化最明显或者响应时间最高的页面，随后再针对这个页面进行进一步的分析了解时间偏长或者变化快的原因。

　　Time to First Buffer Breakdown(页面请求组成时间)

　　提供了组成页面时间请求的比列说明(客户端时间/服务器时间)，通过这个图，可以直观的了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长。从而分析得到系统的性能问题是在前端还是后端。

　　Time to First Buffer Breakdown(Over Time)(基于时间的页面请求组成分析)

　　给出了整个负载过程中，每一个请求的 Server Time 和 Client Time 随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。

这些年，我的软件性能测试

很早之前就说好好总结一下自己的职业，一直忙于一些乱七八糟的事，现在这个时间难得偷得空闲，趁着有感觉，赶紧进行敲下“这些年，我的软件性能测试”来祭奠我这IT行业的几年......

　　记得第一次做性能测试项目，心情是忐忑的，觉得，性能测试，做不好就背包滚蛋了都可能，不过当时带我做项目的老大给了我很大的信心和支撑，我在做的过程中，遇到的疑问，他都会耐心的给我以解答或者给我一个方向，让我去前行，解决，随着一个个问题的出现和解决，自己每一天也过的感觉很充实。也是在这个项目里面，这个老大告诉我，作为性能测试，如果仅仅只会用工具，这个只能算初级性能测试工程师，重要的还是设计能力，思想为王，于是，我从他口里听到了一个词：性能建模和容量规划......当时，我真心的不知道这个是什么，有的就是对老大的崇拜和对未来的路如何走的思考......

　　第一个性能项目，如期完成，对google的GA插入的js代码进行测试，验证该js注入website之后，对性能的影响（因本身js需要做下载和数据上报，中间的过程需要看下情况如何），测试过程中，发现会有大部分的用户响应时间比较长，当时就是按照2-5-10法则来做的响应时间是否合理（想想，这个就是传说中的拍脑袋吧呵呵），想到该如何分析是哪里原因呢？第一次做性能测试，看到结果之后，欣喜的同时更多的是一种忐忑，不知道对着面前的report该如何下手？好在，有老大给予指导，分析了带宽，排除带宽的影响，查看server本身的资源，也无问题，同时细分验证，发现大部分的时间是消耗在server层，于是基于此基础，直接看了下apache（当时我们用的server）的队列等待（当时用的方法很简单，直接ps -ef|grep httpd|wc -l），发现随着虚拟用户的逐步增多，会造成排队的数也越来越多，初步怀疑是配置问题，咨询了运维，apache 的配置没有动，用的默认的配置方式，于是我们提出，需要查看并尝试调整该配置文件。在查看的过程中，参考网上朋友的资源，发现maxclient的确是默认的，修改之后，进行重启，回归，发现问题还是存在，，，难道是别的地方慢？怎么弄呢？这个时候运维告诉我们，apache只修改这个还不够，还需要修改一个隐藏变量，serverlimit，只有修改了它，maxclient修改超过1000的时候才会生效。于是也是瞎子摸象，动手试一试，发现，果真是这里，修改了之后，排队的用户减少了，超过5S以上响应时间的用户百分比也降低，于是开始准备性能测试报告（报告写了我十多次才发出去，那个苦啊～～～），顺便给予运维建议，因当时这一服务对应的apache是单点，建议去除单点，再申请一台机器作为热备，高峰时还可作为balance功能使用。于是，我的第一次性能测试，随着这第一份性能测试报告的发出，结束了.......也从此，我开始踏上了性能测试的路，开始爱上了性能测试

　　在后面的工作中，大大小小的项目也接触了一些，零零散散的一些性能问题也跟研发，DBA一起定位，调优解决了，但是慢慢的我在思考，性能测试就是这样了吗？在随后而来的一次项目中，让我知道，其实性能测试并不如此，远非我之前看到的，之前看到的还不够深入......

　　记得那次项目，是对c++开发的一个搜索服务server的测试，在测试的过程中，发现，开始没多久，磁盘就速度变大，内存也消耗的很快，cpu飙的特别快......可并发用户才5啊，，，，这个问题会在哪里呢？cpu飙的特别快，那一般是运算复杂，调度频繁，切换频繁等原因造成的，于是，找到研发，咨询相关的算法，是否过于复杂，可否再优化？研发也好沟通，给耐心的讲解了算法，并回复，当前无法再优化，只能后面逐步来看。那难道就这样放出去？反正公司不差服务器，堆服务器就是了，硬件解决性能问题似乎成了行业的潜规则，而且产品也说了，平常根本也没多少人会用这个，这样的问题，他们也可以接受......就这样发到外网？不，作为一名性能测试工程师，如果就这样洗洗睡了，那我们的价值在哪里？于是，跟研发建议，如果确实是算法的问题，在当前我们无法进行修改，调优的基础上，是否可以进一步请求资深和专家研发给予check和给予建议，对该风险进行分析？于是，研发开始进一步确认到底是算法哪一块，哪一处消耗最多，戏剧的是，分析到最后，发现该问题并不是算法是主要凶手，之前冤枉了算法，而是程序本身的一个bug，研发之前对于c++里面用到的hashtable，错误的认为是有序的，但实际该hashtable在处理的时候是无序的，从而造成每次都会生成新的追加的文件，这样文件越来越大，造成磁盘疯狂的长，同时写磁盘这个过程对cpu的占用也就飙的很高，再一个，读数据的时候，之前都是直接很疼的从磁盘上拿，没有做map处理，map处理之后使得程序都从内存里面读，这样响应时间也得到了有效的提升，并且，研发还对不该加锁的地方进行了顺序读的锁处理进行修复，导致server的吞吐率得到提升......最终，版本打回研发，研发自测后，再进行提测和验证

　　在上个项目中，让我觉得，作为一名性能测试工程师，不要错误的将自己定义为架构师（很多行业的人都觉得性能测试工程师很牛逼，牛逼的过程中，不自然间就把这个职位等价成了架构师，其实我想说，架构师是高于性能测试工程师的），但是，一名优秀的性能测试工程师应该不断的靠近架构师，只有这样，才能真正的从根本上去发现，解决问题，才能在研发体系中更好的体现自己的价值.也在这个项目之后，我开始思考并有了后面我主导的一个虚拟项目，“BMW软件性能平台”（据说名字霸气点是好事：））......

　　另：这些年的项目经验，还让我认识到，对于有的性能问题，在调优的时候，并不是说就一定需要用技术解决的，有的问题，技术不能解决的，需要思考和尝试业务需求上的调整，有的性能问题的定位和分析，并不是说就一定要那么费劲周折，高并发，查这里，看那里来定位和解决，有的只用单个用户，发个请求，抓个包，看下timechart，看下代码构成，就可以解决了.性能测试，我一直坚持，它跟监控是离不开的，有了监控，有了数据准备和数据收集，我们才能更快更好的发现问题，分析和解决问题（这个也是我弄“BMW软件性能平台”的原因）

　　这些年，我的软件性能测试项目经验，让我获得了很多，也失去了很多，对于行业的认识也看的更加深入了些，开始接触并学习之前根本不知道的语言内核知识，TCP/IP原理等网络知识，深深的感觉到学海无涯，而吾身有涯......

　　这些年，我的软件性能测试，写在我即将逝去的28岁......

　1引言

　　互联网和电子商务技术的发展，人们可以足不出户完成在线购物、实时通讯、信息检索等操作，这些系统大部分是B/S架构。对于系统本身而言，其性能直接决定了可容纳的在线用户数和用户体验满意度，而用户数的攀升意味着广告等收入增长，所以性能测试在B/S系统中起到了一个非常关键的作用，尤其是面向公众的互联网系统。

　　2什么是性能测试

　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，包括负载测试，强度测试，批量测试等类型。在性能测试过程中，会发现很多系统潜在的问题，这些问题往往与一定规模的访问量有关，所以无法通过简单手工测试发现。借助于测试工具或者自己编写的脚本，模拟实际场景对目标系统进行全方位性能测试，能够将问题暴露在上线之前，减少后期维护成本。

　　3性能测试阶段划分

　　性能测试整个过程大体可以划分为测试规划、测试执行和结果分析。本文引入一个测试模型用于实例讲解，相关信息见下表1：

　　表1 测试模型

　　模型系统名称 网上购物系统

　　模型系统架构 基于MVC三层架构的B/S系统

　　模型系统功能 商品浏览：用户随意进入网站进行商品浏览。

　　订单提交：注册用户登录后，下订单购买商品，系统返回成功与否。

　　后台处理：数据库每天晚上11点自动执行数据库脚本，清算当日的交易数据。

　　4性能测试规划

　　测试规划是整个性能测试最复杂，也最有价值的一部分。测试规划包括：确认测试目标、整理业务流程、制定量化指标、制定测试用例与场景、准备测试资源、安排测试计划。

　　4.1确认测试目标

　　针对不同被测系统，需首先明确本次测试的目标。比如设定为“检验当前系统各业务功能的并发处理能力”，由于系统参与人员的职责不同，对性能测试的目标定位也不相同，需综合实际情况来确定。在本文测试模型中，假定有产品经理和技术经理两个角色，他们对于性能测试目标简要归纳为表2所述，综合两者就能确认本次测试目标。

　　表2 测试目标

　　职责 测试目标

　　产品经理 检验系统能够支撑的最大用户访问量、最佳用户访问量、每秒钟最大事务处理数、是否能够满足预期业务量7 * 24小时运行需要。

　　技术经理 检验系统性能瓶颈所在、有没有内存泄漏、中间件和数据库的资源利用率是否合理。

　　一般而言，性能测试是作为一个上线之前的验收环节。处于这个阶段的系统功能基本都已开发完成，测试目标主要是对系统整体的一个性能测验。此时发现核心组件需要修改，调整的代价是很昂贵的。我们可以在项目建设初期就可以引入性能检测，在开发过程中就对各业务模块进行测试，进一步细化各阶段的测试目标，如下图所示：

　　图 1. 性能测试切入点

　　从图1可以看出，系统本身有很多测试切入点。当用户界面层还不稳定的话，可以从业务逻辑层着手，对系统进行性能检测。如果把系统看作是一幢大楼，则至下而上的每一层就是一个组件，组件本身牢固了，房子整体才结实。

　　4.2整理业务流程

　　测试目标确认之后，就需要针对这个目标，对业务流程进行整理，对于功能复杂的系统，还需要业务和开发人员的参与，以下方面可以关注：

　　1：区分用户操作流程与系统的处理流程。两者都是业务流程，但是系统处理流程是后台发起，用户不可见。例如，本文测试模型中，商品浏览属于用户操作流程；数据库自动执行批处理是系统处理流程。

　　2：站在用户的角度模拟业务操作，要覆盖到所有的操作分支，包括容易产生的操作中断。

　　业务流程整理直接关系到后续的测试用例和场景设计，两者决定了性能测试数据是否能够真实反映系统状况，当遇到性能测试实施团队不熟悉业务的情况，性能测试项目经理需安排支援。

　　4.3制定量化指标

　　在性能测试报告中，系统性能状况会体现为一堆测试指标及对应的数值。被测目标不同，指标集合也不同，针对本文测试模型，可以制定以下简单的指标（更加细化的指标可参阅相关文档）。

　　功能层：事务平均响应时间、每秒完成的事务数、成功的事务数、失败的事务数。

　　中间件：JVM内存使用情况、中间件队列、线程池利用率。

　　数据库：队列长度、最占资源的SQL、等待时间、共享池内存使用率。

　　操作系统：CPU平均利用率、CPU队列、内存利用率、磁盘IO。

　　有了指标，我们还需要根据测试目标，设定其对应的数值范围。例如根据产品经理要求，在并发一千人访问的情况下，系统平均一次事务响应时间不超过5秒，则可以设定响应时间的数值范围是小于5秒成功，大于5秒失败。还可以指定CPU利用率、JVM内存利用率等性能指标的数值范围（表3），需要说明的是，不同测试工具支持的指标集是不同的，可利用多个测试工具进行协同收集。

　　表3 性能指标数值范围

　　指标项目 测试场景 合理指标值

　　平均CPU利用率 并发一千用户 < 85%

　　平均JVM利用率 并发一千用户 < 80%

　　量化的性能指标能够给系统带来优化的目标，当我们说性能符合预期，指的是所有指标的值都在理想范围以内，那么如何制定正确的数值范围呢，这个就必须靠经验和系统历史数据来进行分析。前者是类比同类型系统的性能指标，后者需要挖掘运维数据，包括用户访问峰值，每秒最高事务处理数等。
4.4制定测试用例与场景

　　性能测试用例是对整理过的业务流程进行再分解，描述其成为可测试的功能点，结合性能指标转换为测试执行代码。本文测试模型中，用户登录的用例简要描写如下（省略掉用例前置条件，例如系统配置和部署信息）：

　　表4 测试用例1

　　登录测试用例

　　1：用户打开网站首页，页面应该正常展现，超过60秒则算失败。

　　2：用户输入账号和密码，点击登录按钮，等待系统提示成功或失败，如果等待超过60秒，则算登录失败。

　　测试用例1中，用户与系统有两次交互（打开网址和点击登录按钮），需分别统计每一次交互的等待时间。考虑到用户实际操作的话，会有一定的停顿，我们可在脚本中添加思考时间来模拟（固定或随机等待时间）。不要小看这个设置，在用户量大的情况下，对系统施加的压力是完全不同的，然后在在统计的时候，去掉这部分思考时间。

　　性能测试用例执行需对应的场景，用于模拟系统实际运行状况。全面的系统测试在理论上是不可行的，所以设计测试场景的时候，主要定位是用户典型的应用场景。可粗略划分为两类：功能点测试场景和复杂业务测试场景。前者的目标主要是检验系统某个功能点的并发能力，后者更加贴近系统实际运行情况。对于测试模型的用户登录功能，设计功能点测试场景1如下：

　　表5 测试场景1

　　并发用户数：总共300，起始数量100，每1秒钟增加10个用户。

　　运行方式：每一个并发用户循环执行登录测试用例，持续15分钟。

　　考虑到业务流程可以交叉进行，例如测试模型中数据库批处理与用户操作混搭，我们设计一个复杂的测试场景如表6所示：

　　表6 测试场景2

　　并发用户数：总共300，起始数量100，每1秒钟增加10个用户。

　　运行方式：数据库启动批处理清算，同时并发200个用户进行循环登录，另外100个用户随机浏览商品。

　4.5准备测试资源

　　测试资源包括4个方面：

　　1：硬件资源。性能测试环境应该采用与生产环境一致的硬件条件，严格来说，如果硬件环境不一致，性能测试报告是不具备说服力的。

　　2：软件资源。性能测试目标系统需要部署与生产一致的软件，在系统上生产之后，往往会增加一个监控软件，但监控软件也是有资源损耗的，尤其是B/S系统，频繁的抓取JVM数据，会造成较大的压力。

　　3：数据资源。数据量对性能的影响非常大，分两种情况考虑测试数据，第一种是已经运行的系统做改造，则可以把生产环境的数据备份到测试环境。另外一种是首次上线的系统，这个时候业务数据是空的，需要造一些测试数据。至于数据量的级别，可以预测两年后，业务数据量会有多少，性能测试需要有一定的前瞻性。

　　4：人力资源。性能测试会发现很多问题，而问题的定位和解决，需要更加专业的人来完成，包括商业软件提供商。测试过程中，保持与开发团队的紧密沟通，是顺利开展项目的关键。

　　4.6安排测试计划

　　当测试资源、可执行代码准备好之后，就需制定一个测试计划并分阶段实施，简单示例如表7所示。

　　表7 测试计划

　　测试项 描述 测试类型/测试目标（简要）

　　基准测试 收集系统基准测试性能指标 强度测试，获取基准测试数据数据。

　　开发调试 开发修复性能测试发现的Bug

　　功能点测试 对各业务功能点进行性能测试 强度测试，获取系统最大并发值等数据。

　　复杂业务测试 复杂业务场景性能测试 容量测试，获取最佳用户访问值等数据。

　　开发调试 开发修复性能测试发现的Bug

　　长时间负载测试 系统在一定负载的情况下，长时间运行。 疲劳测试，发现内存泄漏等情况。

　　表7测试计划说明如下：

　　1：表7中省略掉了测试项目的起止时间，包括了开发调试的工作。这是因为在实施过程中，如果遇到性能问题，开发是需要时间去修复的，性能测试有可能需要暂停。

　　2：首先进行功能点测试，通过之后再进行复杂业务测试，这是因为单个功能点相对简单，业务逻辑复杂度不高，资源竞争与数据锁等问题不太容易暴露。

　　3：基准测试是系统日后升级的性能比较对象，例如在硬件升级后，同样的测试场景，是否会得到更优的结果，系统新技术的引进或版本升级，对性能的影响是正面还是负面，都可以通过与基准测试比较得出。

　　4：每一个测试阶段都有相应的测试目标，采用的测试类型也不同，具体需根据之前的测试规划来制定。

　　5性能测试执行

　　执行过程需要注意以下事项：

　　1：注意保存测试运行过程的数据，作为测试结果的佐证。

　　2：有问题尽快反馈，系统的修改可能导致测试返工。

　　3：基准功能点测试过程中，需清理测试现场后再进行后续的测试，因为系统可能存在缓存。

　　4：按优先级测试各业务场景。

　　6测试结果分析

　　每次执行完测试后，会得到一个测试结果。先别着急完成后续的测试任务，可以先简要的分析一下本次测试结果，看看数据是否符合逻辑。例如，对于同一个测试场景，增加并发用户数（强度测试中常见），却发现响应时间反而变短，这就不符合逻辑。当所有的测试任务完成后，分析数据并提交测试报告，注意以下方面：

　　1：针对不同角色的人员出具不同的测试报告，对于技术人员，可以有较多的性能数据和分析。

　　2：进行一些前瞻性的预测，综合本次测试的资源情况和指标数据，分析系统性能扩展的瓶颈。

　　7总结

　　性能测试不是一锤子买卖，随着系统不断升级，性能测试需要作为一个常态被关注。性能测试领导者也需保持对业务的关注，及时调整测试策略

　事情的起因是这样的：

　　上周三下午要出去打个电话，经过小会议室门口的时候测试负责人叫住我问有事吗？小A做的性能测试出现了点问，要我帮忙分析一下。打完电话后到小会议室与小A、测试负责人一起看小A的性能测试出现了什么问题。小A说她对X项目进行了性能测试，但是结果与现在线上的差距特别大，线上入库是10条/秒，而她测试的结果是3-4条/秒，对于她测试得出来的结果项目的负责人很不认同，认为是她做错了，而她又找不出来问题出在哪，她很郁闷。

　　接下来是我们的一段对话

　　我：小A，你说一下这次性能测试，是对哪几个点做的，场景都是啥样的？

　　小A：主要是两个点，一个是单一场景针对短信入库的，场景设计的是30、50、100条数据并发持续2个小时，是根据线上前段时间出现的问题发3万条短信，结果处理的时间特别长这个问题设计的；另外一个是将接收到的不同类型的短信入库，是个混合场景，场景是短信2条、彩信1条、WAPPUSH1条、EMN1条，这些数据并发，持续2个小时。

　　我：问一下，线上对于短信发送真实操作场景是什么样子的呢？

　　小A：这个我不知道啊，反正我只知道现在线上要求1个小时内必须把这些短信发完，线上现在预计的入库量是10条/秒。

　　我：好吧，换个问法，X系统小A你最熟了，线上的这个问题，有大量的数据过来，X系统 对这些数据是怎样处理然后入库的呢，是一批一批的处理，还是一条一条的处理呢，如果是一批一批的处理，对于这一批数据是怎样处理的呢，是同时处理掉，还是一条一条的数据。

　　小A：这个我不清楚，要不一会儿我去问一下开发的吧。

　　我：我再问一下，现在搭建的这套测试环境，各个机器的配置是怎么样的？和线网的机器配置差距有多大？线网的带宽是多少？现在测试环境的带宽是多少？线网是有负载均衡的，有VPN通道的，测试环境上有这些吗？

　　小A：tomcat的机器是一台服务器，4核的，另外两台数据库还有LR加压机都是实体机。线网的机器配置我不知道，测试环境也是100兆带宽，负载均衡啥的测试环境都做不了。

　　我：线网带宽是千兆的，测试环境的百兆带宽不全是给你来测试用的，公司上班时间所有同事办公还占用一部分带宽呢。线网的数据库做过一次优化的，有几个参数是调整过的。

　　我觉得这次问题的分析可以从几个方面来入手查，第一，场景设计，我从开发的那里了解到线上真实的情况是没有并发的，只是一条一条的来处理，处理的数据量是3万条，1个小时处理完，是我们自己的要求。所以场景可以重新设计，设计成没有并发，处理3万条数据；第二，测试脚本的性能，测试脚本里的代码可能本身响应时间就长；第三，机器配置、网络带宽，查看现在测试机的配置与线网比相差多少，这些能不能想办法进行一下换算，结果可能有误差，如果找到依据，看看误差能控制在多少范围内。

　　小A：我觉得脚本代码不是问题，我就是这样写的都能执行过去，能执行过去为啥就会有问题呢。线上真实的操作那在那台服务器上还可能有别的省发短信呢，对那台服务器还有影响呢，那台服务器的配置好可能还有别的省来占用呢，所以机器配置也不应该是问题。带宽我觉得也不是问题，公司百兆的带宽也够用了呀，我在测试的时候也没发现网络上哪里出现了问题，CPU占用率呀都非常少的。

　　我：......无语

　　对于性能测试，到底应该怎样做，会用了工具（最著名的是LR）就会了性能测试了吗？NO，NO，NO

　　我认为：

　　前期分析：

　　分析业务：分析用户群，业务真实使用和操作情况。比如在哪个时间段哪个操作会多，哪个操作会少，怎样来操作，是会有很多人一起对系统发起请求呢（所谓的并发），还是数据量很大，但是都是一个请求一个请求过来的，很持续很长时间吗（比如8个小时都在做这样的操作），还是主要是对一定的数据量操作的（比如处理完几十万条数据后任务就完成了），每次只有一个场景吗，还是是个混合场景都有，如果是混合场景，那么各个场景的比例大约是多少呢。线上已经有多少数据量了？预期要达到多少数据量？

　　分析环境：线上系统环境是什么样子的？有负载均衡吗？有多次转发吗？......机器配置是什么样子的，每台机器上都有哪些服务？线网的带宽是多少？是专用的吗？搭建的测试环境和线网真实的环境有多大的差距，带宽是多少，是专用的吗？测试环境不可能与线网环境是一模一样的，有办法换算吗？误差大约是多少？

　　分析团队成员：给你配备的配合的开发人员了吗？与你配合的开发人员靠谱吗？你的团队里有性能测试的高手吗？团队对这个项目的性能测试支持吗？

　　时间分析：测试的时间充足吗？哪些是必须测的，哪些是可以不测的。

　　测试执行：

　　有了前面的详细的分析之后，才能整理出测试需求、设计测试方案、编写测试用例、编写测试脚本、设计出合理的测试场景，才能执行测试。

　　结果分析：

　　测试出了结果，不能就算完事了，把结果丢给别人让别人分析查找原因，那不是高手，真正的高手是可以分析出问题在哪里，是什么原因产生的，怎样优化。简单的几个切入点可能从服务器系统CPU、内存等等，数据库中SQL执行速度，数据库CPU、内存等入手。查看事务平均响应时间是否在可控范围内，每秒处理的事务数怎样等等。借用一些工具查看操作数据库的SQL执行情况等等。

　　总结一下，性能测试个人认为最重要的不是使用工具，而是测试前的分析和结果的分析，前面的分析够透彻才能保证后面做的是对的，而不是一上来就是用工具，就大并发，只有大量的并发才是性能测试，一定得根据现实的真实使用情况来做才可以，违背了现实做再多也是无用。每次一听到有开发的对我讲你帮我们做一下性能测试吧，弄个几万的压一下，我就特无语。

性能测试知多少---了解前端性能  《转载》

我的上一篇博文中讲到了响应时间，我们在做性能测试时，能过工具可以屏蔽客户端呈现时间，通过局域网的高宽带可以忽略数据传输速度的障碍。这并不是说他们不会对系统造成性能影响。相反，从用户的感受来看，虽然传输速度受用户带宽的限制。但我们可以通过很多技术来使用户想要看到的页面更快的显示。这就web是前端性能。

　　如果考虑到web应用本身的特性，响应时间的构成应该会更加复杂。

　　Web应用的基础是超文本传输协议（HTTP）和超文本标记语言（HTML），HTTP协议本身是一种面向非连接的协议，HTML语言则是一种用于制作超文本文档资料的简单标记语言。

　　对于一个页面而言，“请求”和“返回数据”都可能是多次发生的。这个我在《在做性能测试之前需要知道什么》一文中举了一个简单的例子来讲解。由于HTTP对浏览器下载资源并发请求数量、Cache等方面都进行定义和限制，以及浏览器对于HTML的处理过程。完全可以说，用户所以感受的响应时间中的相当大的一部分并不完全取决于应用的后台处理所需要的时间，而取决于web应用的前端。在yahoo中，到少50个团队通过纯粹的前端性能相关的技巧，将最终用户的响应时间减少了25%以上。

　　HTTP是一个属于应用层的面向对象的协议，用于传送WWW方式的数据，采用请求\响应模型，客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本，以及包含请求修饰符、客户信息和内容的类似于HTML的消息结构。服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息，实体元信息以及可能的实体内容。

　　HTML是一种用于制作超文本文档资料的简单标记语言，用HTML编写的超文本文档能够独立于各种操作系统平台。从诞生开始，HTML语言就一直被用于描述web页面格式设计，使用HTML语言描述的文件需要通过WWW浏览器显示效果。

　　用于查看前端性能工具太多的。

　　嵌入浏览器的有 yslow 、page speed、httpwatch

　　独立界面的有 fiddler2、charles 、

　　页面性能测试之一 ：http://www.51testing.com/html/62/n-249062.html

　　下面用两种方式来对比较两种测试响应时间的差别

　　Apache  benchmark 简称ab ，是非常有名又小巧的压力测试工具。

　　下载安装apache web server 安装或解压之后，在bin\目录下有个ab执行文件。

　　打开运行--cmd 打开命令提示符，定位到bin\目录下。

　　基本用法：

　　ab  -c  [并发用户数]  -n  [发送请求数]   [被测试页面的URL]

　　设置一个用户一个请求，对百度首页加压：http://www.baidu.com/

　　从上表中我们可以看到请求的总字节数为8024字节；响应时间为0.173 秒，也就是下面显示的173.010毫秒。

Firebug非常有名的debug工具，firefox浏览器最得意的集成工具。

　　在firefox浏览菜单栏“工具”---添加组件---搜索firebug下载安装重启浏览器。

　　同样对百度首页的访问：http://www.baidu.com/

　　从上面图中看到请求的大小为10KB；响应时间1.4秒。清楚的发现这数据可以远远大于ab工具所得到的数据。仔细观察发现，firebug给出的数据，访问 http://www.baidu.com/ 网址时，客户端（浏览器）和应用之间的数据交互并非1次，而是5次。

　　我们再分析其中的一个请求，firefox给出的的图形中，有红色和蓝色两种颜色的线条。蓝色表示到此刻发生了DOMContentLoaded事件。红色线条表示onload事件被触发。DOMContentLoaded事件W3C推荐的标准事件，它发生在页面的DOM树建成时，而onload则发生在页面所有的资源（图片文件、CSS文件、js文件等）都被下载完成后。

　　从上图的右下角，我们会得到两个响应时间，1.41秒是onload事件被触发的时间，前面的1.4秒则是页面的所有请求都返回所需要的总时间。那么哪个时间才是用户感受到的响应时间呢？准确的说，两个都不是。用户的感受是个不确定的状态，取决于页面本身的类型以及呈现手段。如果某页面仅为用户提供阅读信息，一旦页面上开始出现可供阅读的内容，用户就开始阅读了。那么，用户认为响应时间就是发出请求到页面上出现可阅读信息。如果页面存在大量的交互内容，需要用户填写或在页面上进行拖拽等操作，在这种情况下，只有当页面的所有元素都被下正确的呈现出来，所有的js文件都已经执行完成后，用户才会感受到这个页面已经就绪。

　　Web前端性能的研究并不是为了准确地得到一个响应时间数据，实际上，根据friebug图表的结果，web性能一部分取决于web服务器和应用服务器（建立连接，下载连接），别一部分取决于浏览器的实现机制、web页面上的js的执行等。取决于web服务器和应用服务器的响应时间与服务器的负载、压力等相关；而取决于浏览器实现机制与js文件执行所需要的时间则几乎与服务器端的负载和压力无关。那么web端的响应时间也是总响应时间的一部分，那么有必要web端的性能进行了解。

　　那么前端性能这么见效，为什么还要去做后端性能测试呢？因为他们关注点不同，前端性能关注单个用户的感受。后端性能关注是更多用户访问系统时，服务器能更稳定、更快的处理用户发来的请求。一个强大的后台是前台的基础。

页面性能测试

　　一、页面性能测试概述

　　页面性能测试则是针对于页面性能优化而开展的一种性能测试，目的是对Web系统的页面进行测试以确认系统页面是否会影响系统的性能并为页面的优化提供依据与建议，最终提升系统的整体性能表现，提高用户体验满意度。可见，Web系统页面性能测试是相对Web系统后台测试的另外一种性能测试，是Web系统性能测试的一个重要部分。

　　二、页面性能测试必要性

　　相对于C/S架构的应用系统，Web应用系统所有数据都需要从服务器端下载，虽然浏览器有缓存机制，但客户每次访问仍然需要下载大量的数据。特别是用户对系统要求越来越高，除了要求功能完备，对界面的美观、易用性也提出了更高的要求，越炫的页面也就意味着页面中要包含更多的脚本、样式表、图片和Flash，页面的数据量也就越大，这对Web系统的性能提出了极大的挑战。

　　曾经有个在线打印服务的应用提供商说他们的系统不需要关注系统性能问题，没有必要进行性能测试，因为他们可以购买足够多的服务器来支撑系统；不少业界同行也认为只要有足够多的服务器资源，性能就不会存在问题。其实不然，他们都只关注到了应用系统的后台性能表现，而忽略了页面对系统整体性能的影响。举个例子，当一个页面中包含几百个请求，页面中没有经过优化的javaScript文件、CSS 文件与图片件大小达到10MB，即使当前只有一个用户在访问该系统，页面的访问速度也会慢得惊人，纵使增加再多的服务器也不见得会有明显的性能提升。

　　可见，对Web应用系统的页面进行性能测试和优化是非常有必要的。只有通过对页面的性能测试，发现页面存在的性能问题并根据性能测试结果进行页面优化以提升页面的加载性能，从而提升系统的整体性能。在应用系统高并发访问时，更能体现出Web页面优化后所带来的系统整体性能提升效果。

　　2种方式来提升你的web 应用程序的速度：

　　● 减少请求和响应的往返次数

　　● 减少请求和响应的往返字节大小。

　　减少请求和响应的往返次数：

　　HTTP缓存是最好的减少客户端服务器端往返次数的办法。缓存提供了提供一种机制来保证客户端或者代理能够存储一些东西，而这些东西将会在稍后的HTTP 响应中用到的。（即第一次请求了，到了客户端，缓存起来，下次如果页面还要这个JS文件或者CSS文件啥的，就不要到服务器端去取下来了，但是还是要去服务器上去访问一次，因为请求要对比ETAG值，关于这个值，我将会在下次翻译中介绍其作用）这样，就不用让文件再次跨越整个网络了。

　　缓存相关的请求头

　　为了提高性能，微软的IE和其他的web客户端总是想尽办法来维持从远程服务器上下载下来的本地的缓存。

　　当客户端需要一个资源（html，css.js…），他们有3种可能的动作：

　　1、发送一个一般的HTTP请求到远程服务器端，请求这个资源。

　　2、发送一个有条件的HTTP请求到服务器，条件就是如果它不同于本地的缓存版本。

　　3、如果缓存的拷贝可用，就使用本地的缓存资源。

　　当发送一个请求，客户也许会使用如下的几个HEADER

　　减少请求肯响应往返的字节大小：

　　1、使用更少的图画

　　2、将所有的CSS浓缩到一个CSS文件中

　　3、将所有的脚本浓缩到一个JS文件中

　　4、简化你的页时间

　　5、使用HTTP压缩

三、页面性能测试工具介绍

　　第一种是通过HTTP代理的方式来截取客户与服务器之间的通讯。

　　此类的工具非常的多，如：

　　charles是一个HTTP代理/ HTTP监视器/使开发人员可以查看所有的计算机和互联网之间的HTTP和SSL/ HTTPS流量的反向代理。这包括请求，响应和HTTP标头（其中包含的cookies和缓存信息）。

　　charles界面清爽，采用中国的瓷器为logo，给人的感觉简洁高雅。而且使用也非常简单。进入下载页面，选择你适合你的版本，安装也非常简单，一路“next”就OK了。

　　点击工具栏上的“红色”按钮，就自动的记录你浏览器访问的所有网站。

　　Fiddler是一个Web调试代理，记录所有的HTTP（S）之间的计算机和互联网的交通。提琴手允许您检查交通，设置断点，和“捣鼓”传入或传出数据。菲德勒包括一个强大的基于事件的脚本子系统，并可以使用任何。NET语言扩展。

　　Fiddler是免费软件，可以调试，从几乎任何应用程序，支持代理，包括IE浏览器，谷歌Chrome，苹果Safari，Mozilla Firefox中，歌剧，还有数千交通。您也可以像Windows电话，iPod/ iPad和其他流行的设备调试的交通。

　　Fiddler2相比Charles功能要更强大一些。当然了，如果单单把他们理解成页面性能测试工具有此片面，尤其Fiddlers2功能强大，当然了，我也没有深究，在此就不过多评论了

ab和LoadRunner的区别，及ab的运用方法   《转载》

ab的全称是ApacheBench，是 Apache 附带的一个小工具，专门用于 HTTP Server 的benchmark testing，可以同时模拟多个并发请求。这个小工具在apache的bin目录下面，但是每次使用都要先跳到该目录下，为了能够直接在cmd下使用，可以讲ab.exe这个文件移到C:\WINDOWS\system32路径下，这样每次使用就很方便了。

　　loadrunner用的好好的为什么要研究这个ab呢？我给我自己的理由是：

　　1.ab是开源的，很多大公司都喜欢开源的因为loadrunner太贵了，所以想成为一个性能测试高手必须要懂几个开源的性能测试工具，个人意见；

　　2.ab这个工具小巧使用并且很简单，上手快学习起来比较简单，而loadrunner相比起来就太复杂了，脚本开发抛开不说，就loadrunner这个工具就够学上个一个月的。

　　3.ab虽然很小，但是功能还是 很强大的，提供的数据足够我们使用了，其实loadrunner中虽然提供了很多功能，但是我们用能使用多少呢，性能监控这块，我 基本不用全部都是第三方监控或者linux命令，loadrunner中给出的很多指标对我们很有用的也就是1、事物的响应时间 2、事物的成功率 3、系统的吞吐量  3、在单位时间内完成的事物数这些ab基本上都可以实现。

　　4.如果遇到临时任务或者很简单的一个测试，可以这么说吧，开发写了一个接口让你帮他看一下性能如何，只需大概，正好你有没有loadrunner安装包，那怎么办呢，其他不说就下个loadrunner安装包估计就让开发等的不耐烦了，使用ab就不一样了很快就可以给他结果；

　　总而言之2者各有特点，如果做大项目，逻辑关系比较复杂的项目ab就无能为力了，所以做为一名性能测试人员就必须掌握2~3种性能测试工具，不同情况下可以使用不同的测试工具。

　　说了这么对废话，咱们下面就看一看这块小巧的性能测试工具吧：

　　我们在使用一个新工具之前当然首先看的帮助文档了，那下面我们就看看ab这个工具的帮助文档：

　下面是一个很简单的例子：

　　ab -n 100 -c 10 http://www.baidu.com/

　　向百度发送100个请求，以10个并发用户同时进行，这就模拟了loadrunner中的并发用户了

　　//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于937 毫秒，60％ 的用户响应时间小于1000 毫秒，最大的响应时间小于1390 毫秒

　　由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数

初探网络性能测试

　　最近对云主机进行性能测试，第一次涉及到了网络方面的性能测试，其实不能算是一次很全面的网络性能方面的性能测试，只是针对不同的测试目标进行了测试，在这期间，了解了网络性能测试需要掌握的性能指标、测试工具、功能选型和对比等。下面一一介绍下：

　　网络性能指标

　　常见的网络性能测试指标包含：网络吞吐量（Throughput）、网络延迟（latency）、抖动（jitter）、丢包率等

　　网络吞吐量：单位时间内通过某个网络（或信道、接口）的数据量，吞吐量受网络的带宽或者网络的额定速率限制的，例如家庭带宽为10M网络，表明网络吞吐量不可能超过10Mbits/s，吞吐量的单位通常表示为位元每秒（bit/s或bps）。

　　网络延迟：通俗的讲，就是数据从电脑这边传到那边所用的时间。这儿有个问题需要确认，数据是指一个数据包的传输还是任意大小，和你传输的数据量相关。可以明显的看到，从A到B传送1个字节的时间和传送100MB的时间肯定是不一样的。标准意义上的延迟，应该仅仅指1个字节的传输时间，类似网络课上讲到的传播时延。（不同意见欢迎讨论）。同样存在一个名词叫做传播延时，这个应该可以标识整个数据包的传输时间，不论包大小为多少。

　　抖动：用于描述包在网络中的传输延时的变化，抖动越小，说明网络质量越稳定越好。抖动是评价一个网络性能的最重要的因素。

　　丢包率：测试中所丢失的数据包数量占所发送的数据包的比率，因为我们知道TCP协议是可靠的，所以，一般在使用UDP传输时，才会统计丢包率。

　　网络性能测试工具

　　大家熟知的，常用的开源网络性能测试工具有两个：iperf 和 netperf，这两种工具都是可以测试TCP协议和UDP协议的，从可测试的网络性能指标，我们对两种工具进行下对比：

　　可测试的网络性能指标：

可见，iperf也可以完成基本的网络性能测试，但是工具比netperf要略差些，我们测试过程中，选用的工具为netperf，下面对netperf进行下详细介绍：

　　安装：netperf的安装可以找SA部署，但是SA安装的版本时2.4版本，很多功能没有实现，可以自己make安装netperf 2.6版本，是目前为止最新的版本。

　　基本命令：netperf -H hostname -l testtime: 例如 netperf -H 172.0.0.2 -l 60，表示发送到172.0.0.2（这台机器上需要启动netserver进程），发送时间为60s，默认的发送方式为TCP Stream方式。

　　发送方式：netperf 可以支持多种不同的发送方式，通过 -t 参数指定：

　　TCP_STREAM、UDP_STREAM模式：即不停往发送方发送数据，可以通过-m 参数指定发送数据的大小，默认大小为socket size。

　　TCP_RR模式：即Request、Response模式，类似模拟http请求、数据库请求等，默认大小Request size 和 Response size 均为1byte，可以通过 -r 64,32K 设置 Request、Response size。

　　统计数据：默认得到的数据只有传输时间和吞吐量等，可以通过-k 参数设置要显示的结果数据：

　　MIN_LATENCY,MAX_LATENCY,MEAN_LATENCY,P50_LATENCY,P90_LATENCY：可以得到延迟相关的统计数据，延迟最大最小值、平均延迟，延迟50、70、90、99值等。

　　STDDEV_LATENCY：延迟标准差，可以通过该值反应网络的抖动情况

　　THROUGHPUT：两台机器之间当前的吞吐量

　　LOCAL_CPU_UTIL,REMOTE_CPU_UTIL：发送方和接收方的CPU使用率

　　REQUEST_SIZE,RESPONSE_SIZE：RR模式时，Request、Response size

　　LOCAL_TRANSPORT_RETRANS：重传次数

　　通过上面对netperf命令的描述，可以看到该工具基本可以测试得到所有网络性能方面的指标，但是netperf、iperf这种工具可能更适合作为一种基准工具，进行压力测试，作为负载测试工具还不是很合适，测试过程中，可以通过-b -w的参数制定发送数据包个数和发送间隔，但是不能从根本上限制网络吞吐量仅占网络带宽的50%等情况。

性能瓶颈定位案例    《转载》

被测系统介绍

　　被测系统为B/S结构，J2EE架构，应用服务器为Tomcat，数据库为Oracle 10g。系统的使用对象为公司的内部人员，网络环境为100兆局域网。

　　性能瓶颈描述

　　客户反映访问页面时反应慢，并且出现部分请求失败的现象。

　　通过对单用户的网络带宽计算，排除网络瓶颈。

　　解决思路

　　在应用服务器Tomcat植入dynaTrace Agent，Agent能7X24实时收集应用服务器的所有的Log，包括最终客户端向Tomcat发送的Web Requests、Tomcat向DB请求的SQL语 句、DB执行完SQL语句的返回数据、Tomcat向最终客户端发送的返回数据。dynaTrace Server智能分析dynaTrace Collector收集到的所有Agent捕获的Log。通过dynaTrace Client实时查看监控信息，对被测系统进行性能瓶颈定位并分析。详细的测试环境部署图如下：

　　解决过程

　　1）通过Error快速定位瓶颈

　　对实时监控收集的Log进行分析。首先查看其事务流图Transaction Flow。如图2。Failed Transactions显示失败的事务及失败事务数占总事务数的百分比。图2显示存在失败的事务867个，占总事务数的3.17%。

　　对出现失败的事务进行分析，首先查看失败事务提示的Error Log，如图3。说明存在4XX 、5XX Error，也有重要程序内部Log，具体Error见图4、图5、图6。

　 　将收集的Error Log提交bug给开发人员。HTTP Response Code的Error详情可以协助开发人员快速定位并修复有问题的URL。Important Loggings可以帮助开发人员快速定位程序出现问题的原因。如图6显示创建Socket 连接失败，并提示确认相关Server已开启或相关组件已正常运行。

　　2）快速定位瓶颈原因

　　在性能索引图表快速锁定响应时间长的性能索引。如图7，事务响应时间最长的性能索引为/IOST/as.do，响应时间为40004.86ms。

　　分析性能索引的方法执行情况，可快速看到执行过程中出现了Exception。如图8。

　　定位到出现Exception的源码，如图9。

　　针对响应时间最长的性能索 /IOST/as.do进行分析。钻取性能索引/IOST/as.do 的Web Request，定位其相关的URL，如图10。URL为http://172.16.200.61:8080/IOST/as.do，在浏览器上访问 URL报404错误，如图11。

　　进一步分析404 Error的原因，钻取性能索引/IOST/as.do的Error，定位到一个JRedis API的Socket连接失败，如图12。

　　效果

　　JRedis为缓存服务器。Web前台将根据一定规则，从数据库直接获取需浏览或查询的信息进行显示，为了规避当前 系统请求负担引发事务处理失败的情形，引入Redis缓存服务器，使系统请求入口点统一从缓存进行处理，以达到快速访问和确保事务成功的双重目的。引入缓 存服务器大幅度地提高了系统处理客户请求的能力,解决了系统处理网络I/O操作的瓶颈问题。不但提高系统可扩展性，而且有利于提高系统吞吐率。

　　更多解决方案》》http://www.51testing.cn/

　　dynaTrace工具》》http://www.51testing.cn/product_service/dynatrace.html

版权声明：本文为51Testing软件测试网原创，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。

性能测试新手误区（五）：如何提出一个好的性能问题   《转载》

　　性能测试新手误区（一）：找不到测试点，不知为何而测

　　性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？

　　性能测试新手误区（三）：用户数与压力

　　性能测试新手误区（四）：一切来自录制

　　经常会见到新人提出这样的性能问题：

　　“100用户时，A操作响应时间达到了XX秒，请修改。”

　　面对这样的问题，开发人员一定会觉得很无助，他们甚至不知道问题是什么。

　　即使从测试人员的角度来看，这也算不上是一个合格的问题。

　　那么一个好的性能问题应该是什么样呢？

　　好问题要描述清晰

　　100个用户，是指绝对并发操作么？还是什么样的场景？

　　是只测这一个A操作？还是有多个操作在同时进行？

　　如果有多个操作，是只有这一个操作变慢？还是普遍变慢？

　　测试环境是什么样的？测试数据量是多少？

　　也许开发人员理解了详细的测试场景后，会告诉你，这个场景在业务中是不可能的，或者测试数据量是不合理的。

　　好问题要有尽量准确的定位

　　只是描述清晰还不够，要明白什么是表面现象，什么才是问题。

　　问题是需要定位才能发现的。

　　“100个用户操作时，A事务的响应时间过长”，这只是一个现象，问题是什么呢？

　　响应慢是慢在哪？是中间件还是数据库？这是最基本的分层定位。

　　是服务器达到了硬件瓶颈么？如果硬件或操作系统上没有瓶颈，那么瓶颈在哪？

　　是不是由于一些基本配置问题导致了排队呢？比如中间件的HTTP线程数和数据库的连接数。

　　如果基本配置没有问题，那么再深入一些，是内部的哪些资源产生了争用和等待么？

　　是哪些SQL引起了数据库内部资源的争用呢？应用程序上又是哪个方法在占用资源呢？

　　……

　　定位的越深入，需要的技术能力也就越高。

　　好问题应该用最简单的手段复现

　　比如上面的100个用户，导致了数据库的一张表的争用，因此产生了大量锁等待现象，最终导致了外部的A响应时间过长。但是通过之前的分析和定位，我们发现也许引发问题的那些SQL语句，只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现，其他90个用户都是干扰。这样问题被简化了，开发人员也就更容易理解问题，对于测试的复测也更加方便。

　　不过还是要记住，最终的用户场景模拟才是决定性的验证。

　　最后再总结一下，性能问题到底应该如何提呢？其实只有一个标准，那就是能让开发理解问题、找到根本原因并进行修正的就够了（假设开发人员无所不能）。再进一步深入的分析，可能是为了减轻开发的一些负担，也可能是为了锻炼自己的能力，这就不是每个测试人员都会去做的了。

性能测试之数据准备  《转载》

不知道大家在做性能测试的时候，测试数据是如何准备的，笔者在实际工作中发现测试数据的准备会遇到以下几个问题：

　　其一，由于性能测试需要具备一定的并发量，尤其在实际系统所能承受最大并发量未知的情况下，测试数据的量也必须满足预期业务并发量的一个量的需求，如何准备这些量的数据是第一个问题；

　　其二，除了量的需求，数据也必须是符合业务逻辑的，是可用或者可测试用的数据，不是脏数据或无效数据。比如表与表之间是具备一定的关联关系，记录之间也有关联关系，所有的测试数据要符合这些规则，如何完全了解掌握这些规则，并且根据规则来生成测试数据是第二个问题；

　　其三，性能测试往往是安排在功能测试完成之后，在项目进度非常紧张的情况下，时间资源甚至是人力资源非常有限的情况下，如何快速掌握业务，准备有效的并且符合量的需求的测试数据是一个比较大的挑战。

　　针对以上问题，笔者工作中用到以下几种数据准备的方法：

　　一是用SQL脚本方式，插入测试数据，但是有几个前提条件，首先需要对该业务下所有关联的表结构非常熟悉，其次对整个业务也需要非常熟悉，而这些条件只有开发或者功能测试人员会具备。在以这种方式准备数据的时候，需要密切与开发或者功能测试人员进行沟通了解学习，并且在信息来源不全的情况，需要不断尝试，不断调试才能够准备出符合要求的测试数据。但是仍然会存在风险，即便数据准备完毕，也不能完全确保这些数据是真正合法的，可能这些数据符合被测业务的需求，但是却不符合其他业务或者实际生产环境的需求，也就是说不能完全代表真实数据；并且也存在遗漏其他数据但是业务却跑通的情况。通常情况下，SQL脚本批量导入数据的方式仍然是非常直接有效的方法，比较灵活，量和业务需求都是可控的；缺点就是需要搞清表间关系，精通业务流程，脚本也需要经常维护。

　　二是通过业务的方式去产生测试数据，当然不是手工去一个一个添加，如果量很大，势必需要依靠自动化工具来实现。这种情况下，测试人员只需要了解业务的操作流程，然后采用自动化工具比如LoadRunner，QTP之类就能通过业务大量生成数据，这样的数据一般都是合法可用的，能够确保之后的性能测试的质量。然而缺点也很明显，需要开发额外的测试脚本，要花费额外的时间和人力。

　　三是直接采用生产数据，在有现成数据并且数据保密性要求不高的情况下，可以采用这种方法，毕竟生产数据是原原本本的用户行为所产生的数据。但是有这样几个缺点，量不可能控，可能某些业务的数据量少了，不符合性能测试的需求；生产数据也会有脏数据的产生，会因为系统架构的调整，表结构的变化等等诸多因素产生脏数据，而这些数据是不具备业务意义的；多数情况下，生产数据一般不会被用于测试。

　　在没有开发的支持下，第一种方法会略显困难，但第一种方法也是非常直接有效的。

　　最后讲一下，我所设想的最后一种方法，可以节省很多时间和精力，从而把重点放在性能的调优上。在性能测试的初期分析阶段，可以先确立被测的模块，尽量缩小模块的范围，针对这个小模块的业务来准备数据，让开发配合去掉不必要的业务限制，比如说验证码、资格码之类就用相同的码就能验证通过，尽量减少数据之间的关联和限制。这样在准备数据的时候就非常轻松，可能只是简单的插入操作而已。从而把主要的精力放在了性能调优或者用户模型以及场景的设计上。

　　如果各位看客有自己的想法或者经验，非常欢迎畅所欲言，感激不尽！

性能测试监控工具nmon安装及使用方法

　1、概述

　　监控，在检查系统问题或优化系统性能工作上是一个不可缺少的部分。通过操作系统监控工具监视操作系统资源的使用情况，间接地反映了各服务器程序的运行情况。根据运行结果分析可以帮助我们快速定位系统问题范围或者性能瓶颈点。

　　nmon是一种在AIX与各种Linux操作系统上广泛使用的监控与分析工具，相对于其它一些系统资源监控工具来说，nmon所记录的信息是比较全面的，它能在系统运行过程中实时地捕捉系统资源的使用情况，并且能输出结果到文件中，然后通过nmon_analyzer工具产生数据文件与图形化结果。

　　nmon所记录的数据包含以下一些方面（也是我们在寻找问题过程中所关注的资源点）：

　　● cpu占用率

　　● 内存使用情况

　　● 磁盘I/O速度、传输和读写比率

　　● 文件系统的使用率

　　● 网络I/O速度、传输和读写比率、错误统计率与传输包的大小

　　● 消耗资源最多的进程

　　● 计算机详细信息和资源

　　● 页面空间和页面I/O速度

　　● 用户自定义的磁盘组

　　● 网络文件系统

　　另外在AIX操作系统上，nmon还能监控到其他的一些信息，如异步I/O等。

　　2、下载安装nmon

　　如何获取nmon呢？我们可以在IBM的官方网站上免费下载获取，下载网址为：http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon。

　　nmon的安装步骤如下：

　　1）用root用户登录到系统中；

　　2）建目录：#mkdir /test；

　　3）把nmon用ftp上传到/test，或者通过其他介质拷贝到/test目录中；

　　4）执行授权命令：#chmod +x nmon。

　　3、nmon数据采集

　　3.1 数据采集

　　为了实时监控系统在一段时间内的使用情况并将结果记录下来，我们可以通过运行以下命令实现：

　　#./ nmon -f -t -s 30 -c 180

　　n -f：按标准格式输出文件：<hostname>_YYYYMMDD_HHMM.nmon；

　　n -t：输出中包括占用率较高的进程；

　　n -s 30：每30秒进行一次数据采集

　　n -c 180：一共采集180次

　　输入命令回车后，将自动在当前目录生成一个hostname_timeSeries.nmon的文件，如果hosname为test1，生产的文件为：test1_090308_1313.nmon。

　通过sort命令可以将nmon结果文件转换为csv文件：

　　# sort -A test1_090308_1313.nmon > test1_090308_1313.csv

　　执行完sort命令后即可在当前目录生产test1_090308_1313.csv文件。

　　3.2 生成图形化结果

　　为了分析nmon监控获得的结果，IBM还提供了相应的图形化分析工具nmon_analyser，通过nmon analyser.xls工具可以把监控的结果文件转换成excel文件，方便分析系统的各项资源占用情况。

　　nmon analyser.xls工具的使用方法如下：

　　（1）打开nmon analyser.xls工具；

　　（2）调整excel宏安全性：工具-宏-安全性

　　（修改安全级别与可靠发行商）

　　（选择）安全级别：低

　　（勾上）信任所有安装的加载项和模板

　　（勾上）信任对于“Visual Baisc项目”的访问

　　（3）修改完后，确定-关闭nmon analyser.xls，重新打开；

　　（4）点击Analyse nmon data按钮，加载之前下载的test1_090308_1313.csv文件。

　　以下是分析结果的截图：

　　以上就是nmon的简单描述与使用介绍，大家可以根据自己所采集到的结果分析系统的情况。

LoadRunner设置检查点的几种方法介绍  《转载》

前段时间在群里跟大家讨论一个关于性能测试的问题，谈到如何评估测试结果，有一个朋友谈到规范问题，让我颇有感触，他说他们公司每次执行压力测试的时候，都要求脚本中必须有检查点存在，不然测试结果将不被认可，这是他们公司的规范。其实，在做压力测试过程，我们很容易忽略很多东西，而且随着自身的技术演变，我们很容易去丢失掉一些很好的习惯，当我们再碰到这些问题的时候，我们才发现其实是我们太粗心大意了，所以说好的习惯要保持。这次我刚好也要接手一些性能工作，因此就如何规范设置检查点来谈谈一些基本的流程和方法。

　　使用LoadRunner做压力测试，大致如下几个流程：

　　1、明确测试目标

　　2、录制测试脚本

　　3、脚本优化、调试

　　4、场景运行

　　5、分析测试结果

　　当然这里都是概况性的标题，但从这里我们可以明确的是测试脚本是整个压力测试过程中的重点步骤，如果测试脚本都不能确保正确与否，后面的测试过程就无从说起了。很多时候我们把脚本调试就简单的认为是脚本回放没有错误就认为脚本是没有问题的，这当然不能这么肯定，脚本调试是一个非常严谨的过程，我大致归纳如下几步：

　　1、明确每一行脚本的作用，也就是说每一行脚本执行的功能是什么；

　　2、删减不需要的脚本语句，比如在录制过程由于LR默认设置导致录制之后出现很多冗余的脚本，这些个脚本对我们的测试过程没有用途的应该删除掉，至于哪些是冗余就要具体分析了，所以说脚本录制完之后要分析脚本运行的过程，方能理解脚本执行的用途，不然在后面施压时运行错误，就会开始到处找问题，而又找不出问题；

　　3、查找存在的关联并进行相关设置

　　4、设置检查点，设置检查点的目的就是为了验证页面每次运行之后是否正确，设置检查点的过程总要通过不能的回放来进行验证检查点设置是否正确。

　　5、通过测试目标明确脚本执行的目标事务，并添加事务；

　　6、对需要进行并打操作的功能设置集合点

　　7、根据实际情况设置ThinkTime

　　8、在以上所有脚本调试步骤完成之后，设置迭代次数，通过在Vuser中设置多次迭代来验证脚本在多次循环运行时是否存在错误

　　注意：在Vuser中运行和回放脚本的过程，要密切关注replay log，也就是回放日志，很多问题通常都暴露在回放日志中，只不过我们没有认真去检查，所以没发觉。因为大多数情况是我们在回放脚本之后只观察回放日志中有没有红色的错误提示信息，如果没有我们就认为我们的脚本是ok的，其实不然，很多时候一些隐藏的错误就在回放日志中可以被发现，比如回放日志中的Warning信息，也就是警告信息，这些信息一旦你不去理会它，它将在场景运行过程中开始频繁暴露出来，而在场景中报错之后我们就认为可能是系统有问题或者是测试过程存在其他问题等等，而很难去考虑到是脚本的问题，是脚本在Vuser中调试就存在的问题。还有的时候一些问题在一次脚本回放中就不能被发现，他需要通过Vuser中设置多次迭代才能在回放日志暴露出问题来，所以说我们通常的思维就是一旦测试脚本没有一次回放没有出现错误，就去场景中运行，结果在场景中哪怕是运行10个用户都还会报错，这就是问题的根源所在。

　　下面还是重点说说检查点吧，三种常用的文本检查web_reg_find的方法：

　　1、 将脚本切换到树结构，在page view页面上找到你要check的文本内容， 并执行鼠标右键，选择Add a text check.

　　2、 通过Vuesr界面去设置检查点，如图所示：

3、将脚本切换回代码界面， 在光标闪烁的上行，添加如下的代码：

　　添加的代码根据你检查的方式不同而不同， 你可以选择其中之一即可。

　　代码一：

　　web_reg_find("Text=Payment Details",LAST);

　　注：“Payment Details” 为你要检查的文本；

　　脚本执行到此处，若在页面上找到了这几个字符串，那脚本继续执行下去；若没有找到，脚本将在此报错并且结束。

　　代码二：

　　web_reg_find("Text=Payment Details", "SaveCount=para_count", LAST); //check 的函数

　　这里是要运行的页面脚本

　　if (atoi(lr_eval_string("{para_count}"))>0)        //验证是否找到了页面上的要检查的字符串

　　lr_output_message("Pass!");

　　else

　　lr_output_message("Failed!");

　　注意：

　　“Payment Details” 为你要检查的文本；

　　脚本执行到此处，不管页面上是否存在你要检查的字符串，脚本都不会报错，而是执行下去。

　　此段代码将找到的你要检查的字符串的个数，存为一个参数。 然后在页面代码的后面，通过检查这个参数的值是否大于0，来判断是否找到了你所要检查的字符串。

　　注意：这里的测试结果均以200状态码返回，其失败的结果将在分析报告中进行分类标识。

　　代码三：

　　web_reg_find("Text=Payment Detdils", "Fail=NotFound",LAST);或者

　　web_reg_find("Text=Payment Detdils", "Fail=Found",LAST);

　　以上两段脚本就比较简洁，通过查询文本内容来决定此次运行的测试结果是否失败。

　　注意：在使用检查点的时候我们还需要注意一些问题，通常我们都要设置一些中文检查点，但是LR默认不支持，如果你设置了中文检查点而报错，那你就应该注意了，在录制脚本的时候去掉默认设置的UTF-8选择，如下图所示：

　　并且还设置启用图片和文本检查点，如下图所示：

　　以上就是设置检查点的全过程，设置检查点的目的不只是为了验证我们的脚本没有错误，而更重要的是一个规范问题，如何使得测试结果更具有说服力，那就所有的测试脚本中都添加检查点设置。

LR手动关联参数化问题总结  《转载》

所谓的关联就是把脚本中某些写死的代码（hard-coded）数据，转变成截取自服务器所送的、动态的、每次都不一样的数据。

一般情况下，比较聪明的服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器，一般称这个辨识码为SessionID。对于每个新的请求，服务器都会产生新的SessionID给浏览器。这也就是执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器发现这个Session ID是失效的或者它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。

要对付这种服务器，必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代脚本中有用到Session ID的部分，这样就可以成功骗过服务器，正确地完成整个交易了。 

一、什么地方需要关联

凡是脚本每次执行时都必须获得唯一标识的地方都需要关联。假如脚本需要关联，如果不做关联是不会执行通过的，也就是说会有错误消息发生。不过很遗憾，并没有任何特定的错误消息是和关联有关系的。会出现什么错误消息，与系统实际的错误处理机制有关。错误消息有可能会提醒用户要重新登录，但是也有可能直接就显示HTTP 404的错误消息。 

二、如何做关联

关联会用到下列的函数： 

1、web_reg_save_param；

2、web_create_html_param；

3、web_create_html_param_ex；

其中，web_reg_save_param的语法为：

web_reg_save_param ( "Parameter Name" , < list of Attributes >, LAST ); 

web_create_html_param和web_create_html_param_ex这两个函数主要是保留以兼容以前旧版本。建议使用web_reg_save_param函数。

那么，如何找出要关联数据呢？简单地说，每一次执行时都会变动的值，就有可能需要做关联。VuGen提供两种方式帮助用户找出需要做关联的值：自动关联和手动关联。

自动关联一般情况下比较简单，在此就不进行说明了，下面主要是总结手动关联时的一些方法以及出现的一些问题的解决方式。

三、手动关联总结

1、正常情况下的手动关联：web_reg_save_param("SessionId","LB=value=\"","RB=\">",LAST);

LR:所需截取字符串的左边界

RB:所需截取字符串的右边界

如果左右边界中存在各种特殊字符，如双引号等，则需先用\进行转义

一般情况下，如果所截字符串的左右边界比较唯一的话，可以直接用上面的方式进行获取，无需设置别的属性了。

（“LAST”是固定的。。。）

2、如果进行关联后，有报错信息，提示参数化未成功，有可能是以下几方面的原因：

1）左右边界取值不正确，可以进入Generation log中，查看在关联的参数左右边界是否正确

2）关联函数的位置放置错误

可以将log设置成输出Extended log。

设置方法为：Vuser->Run-time Settings->Log属性中，选中Extended log 并选中下面三个日志。

在输出的日志中找到所要关联化的参数第一次的输出位置（注意是response返回的值，不是request中的），对照左侧的脚本行数，将关联函数放在此行数之前，即可。

3、关联没问题，运行时无报错，可就是得不到参数的值，可以从Extended log中找到原因。

将Replay Log中的日志改为输出Extended log->Parameter substitution日志，再重新运行一次，便可看到所关联参数的变化情况。

有一次我在录制了Flex协议的脚本后，将JSessionId做好手动关联，运行无任何错误，可是将JSessionId打印时却得不到任何值，一直找不到原因，后来通过这种日志输出，看到了JSessionId的一个数据变化的过程，得知由于flex编码中含有十六进制数，在我需要截取的参数前，有一串"\\x04\\x00\\x06"，在获取参数时由于这一串数的影响无法获取到我所需要的值，所以后来就将web_reg_save_param函数中一个属性SaveOffset设置为4才得到了所需的字符串。

SaveOffset的用法为：当找到符合的动态数据时，从第几个字符开始才开始存储到参数中。此属性值不可为负数，其默认值为0。

4、另外一种设置方法可以使左右边界简单化

针对jsp页面中，如果要获取form中的某个属性的值，如下面这段代码：

<form method="post" name="frmLogout">

<div align="left">

<br>

业务号:

<input type="text" name="serviceId" size="100" maxlength="20"

value="">

<br>

XML数据:

<textarea name="data" rows="10" cols="100"></textarea>

<br>

<input type="submit" name="submit" value="提交"

onclick="dosubmit(1)">

<input type="submit" name="submit" value="取消"

onclick="dosubmit(2)">

<br>

sessionId:

<input type="text" name="sessionId" size="100" maxlength="20"

value="af0616ae-cbe7-412d-8965-1d33ba55fc3b">

<br>

</div>

</form>

想要截取到sessionId的value值，如果直接用左右边界截取，由于程序中的太多的value，所以需要截取左边界为name="sessionId" size="100" maxlength="20" value="，

由于此边界的内容显示时有换行，所以如果以上面那一段内容作为左边界的话可能会有截取不成功的情况，所以在这种情况下，我们可以采取以下方式：

web_reg_save_param("SessionId","LB=value=\"","RB=\">","ORD=5",LAST);

ORD可以定位整个数据中取第几个值

利用ORD属性，在左边界出现的第5次时再进行截取。如果不确定自己所要截取的这段字符串是在第几次出现，那么可以先将ORD设置为ALL，然后通过Extended log->Parameter subsitution日志，可以看到所有左右边界一致的截取的字符串数组，再确认自己所需截取的字符串是在这个数组中的第几个位置，将ORD设置为几即可。

5、如果某个参数关联成功，可是运行时却发现还会报错，那么可以考虑一下是不是因为有别的值跟你所截取的这个参数相关联，随着那个值的变化，你所截取的这个参数也会进行某一方面的变化，那样的话就需要将那个变化的值同样进行参数化。

6、如何打印出参数值

解决方法：利用lr_eval_string与lr_output_message这两个函数来打印出参数值。

例：lr_output_message("SessionId=%s",lr_eval_string("{ParameterName}"));

打印参数值这段代码所放的位置一定是在已经获取到参数值后，才可打印出来。

四、参数说明：

ParamName：存放动态数据的参数名称。

list of Attributes：其他属性，包含 “Notfound”、“LB”、“RB”、“RelFrameID”、“Search”、“ORD”、“SaveOffset”、“Convert”以及“SaveLen”。

下面将详细说明每个属性值的意义：

1、Notfound：指定当找不到要找的动态数据时该怎么处理。

当指定Notfound=error时，表示着找不到动态数据时，就发出一个错误消息。此为该属性的默认值。

当指定Notfound=warning时，表示当找不到动态数据时，不发出错误消息，只发出警告，脚本也会继续执行下去不会中断。在对脚本出错时，可以如此设置。

2、LB：动态数据的左边界字符串。此属性是必须要有的，而且区分大小写。

3、RB：动态数据的右边界字符串。此属性是必须要有的，而且区分大小写。

4、RelFrameID：相对于URL而言，欲搜寻的网页的Frame。此属性可以是All或是数字，而且可有可无。

5、Search：搜寻的范围，其值可以是Headers（只搜寻headers）、Body（只搜寻body部分，不搜寻header）、Noresource（只搜寻body部分，不搜寻header与resource）或是All（搜寻全部范围，此为默认值），此属性可有可无。

6、ORD：指明从第几次出现的左边界开始才是要撷取的数据，默认值是1。假如该属性值为All，则所有找到符合的数据会存储在数组中。此属性可有可无。

7、SaveOffset：当找到符合的动态数据时，从第几个字符开始才开始存储到参数中。此属性值不可为负数，其默认值为0。

8、Convert：转换数据格式。当指定该属性值为HTML_TO_URL时，意味着将HTML-encoded数据转成URL-encoded数据格式。如果是HTML_TO_TEXT，表示将HTML-encoded数据转成纯文字数据格式。

9、SaveLen：当找到匹配项后，偏移量之后的几个字元存储到参数中。此参数可有可无，默认值是-1，表示一直到结尾的整个字符串都存入参数中。

五、转义字符总结

在做手动关联时，取边界值的时候，会经常用到转义字符，现将转义字符整理如下：

\b 退格

\f 换页

\n 换行

\r 回车

\t 水平制表

\v 垂直制表

\\ 反斜杠

\? 问号字符

\' 单引号字符

\" 双引号字符 

\0 空字符

性能测试的重要意义   《转载》

　　随着社会的发展，科技的进步，信息技术的飞速发展，计算机的普及，软件产品已经应用到社会的各个行业领域，加上网络的发展，信息的共享性等，人们对计算机及网络的依赖性越来越大。软件产品的使用者对高质量、高效率的工作方式的要求越来越高，因此对于工作和生活中息息相关的IT系统服务，他们也要求提供更快、更高效的服务品质。

　　网络的发展，让人们对网络的依赖越来越大，对外界新事物的好奇心等也越来越强烈，成千上万的用户在庞大的网络系统中游转。网络时代的到来，也给提供服务的系统带来严重的系统负荷，这就是系统网络发展中最明显的特征："高并发"、"数据集中"。

　　数据越来越集中于后台系统服务器中，众多系统同时为成千上万的网络用户提供服务，如银行、电信、社交网站等公司的软件系统随处可见，影响着我们生活的方方面面。随着各个企业的业务发展、用户访问量的增加，其服务系统承载的负荷也会随着增加，系统性能的好坏将严重影响企业的利益，因此对于IT服务系统的性能测试与优化也越来越受业界的重视。

　　目前典型的企业信息服务系统的架构大致如图1.1所示。

图1.1  典型的企业信息服务系统的架构

　　一般是由客户端、网络、防火墙、负载均衡服务器（硬件如F5、软件Apache等）、Web服务器、应用服务器（中间件WebLogic、Tomcat等）、数据库服务器等各个环节组成。

　　在交付给客户上线使用之前，业务系统的每个环节都要进行性能测试和优化，才能保证上线后的质量。每个环节都要有专业人士协助性能的诊断和优化，这些专业人士包括：性能测试工程师、系统管理员、网络工程师、DBA、程序设计人员等。

　　IT服务系统的性能测试与优化是一项复杂、富有挑战性的工作，对于一个专业的测试人员而言，性能优化技术的学习和研究有利于性能测试工作的顺利、深入开展。

　　功能测试和性能测试

　　功能测试主要根据产品业务需求、产品行业特征、模拟用户操作方式来测试一个产品的特性以确定它们是否满足用户需求。

　　性能测试则是通过某种特定的方式对被测试系统按照一定的测试策略进行施压，获取该系统的响应时间、运行效率、资源利用情况等各项性能指标，来评价系统是否满足用户性能需求的过程。

　　通俗地说，功能测试用于确保软件系统做了正确的事情，性能测试则用于确保软件系统快速地完成了任务。

　　项目组不同角色眼中的软件性能

　　1、系统管理员眼中的软件性能

　　系统管理员作为软件系统的运维人员，主要关注服务器的资源使用状况、系统的扩展性、系统支持的最大用户量、系统稳定性，以及系统可能出现的瓶颈、出现异常的情况下如何处理等。

　　2、研发人员眼中的软件性能

　　作为研发人员，他们会更关注软件系统架构设计的合理性、数据库的设计是否存在问题、代码是否存在性能方面问题、内存使用方式是否正确、线程同步方式是否合理、是否存在不合理的资源竞争等。

　　3、测试人员眼中的软件性能

　　测试人员是软件性能质量的把关者，在软件性能生命周期中占据至关重要的位置，软件性能测试工程师要对性能问题进行监控、分析及模拟实际使用过程中所出现的性能问题。还要跟各个角色做好沟通工作，对测试出的各种性能问题，要提供充分有力的数据，为后续的分析和定位性能问题、性能优化工作做好充分的准备。

　　1秒的性能对于顾客的意义

　　根据2008年Aberdeen Group的研究报告，对于Web网站，1秒的页面加载延迟相当于少了11%的PV（page view），相当于降低了16%的顾客满意度。如果从金钱的角度计算，就意味着：如果一个网站每天挣10万元，那么一年下来，由于页面加载速度比竞争对手慢1秒，可能导致总共损失25万元的销售额。

　　Compuware公司分析了超过150个网站和150万个浏览页面，发现页面响应时间从2秒增长到10秒，会导致38%的页面浏览放弃率。

　　由此可见，网站性能与业务目标有着直接的关系，对网站进行负载测试非常重要。

认识软件性能测试10大误区   《转载》

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 性能测试 软件测试 

　　曾经我们帮助客户进行软件性能测试的时候，客户不解的问，不是必须通过功能测试后才可以测试性能吗？可能有很多人会存在这样的疑问，在这里，我们的多位专家根据多年经验总结出性能测试的10大误区，希望能给大家带来帮助。

　　误区1：应用程序必须通过功能测试后才可以测试性能。

　　应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起后，才能检查一个系统的真正性能。

　　性能测试从早开始，完成一个小模块，对小模块的接口进行性能测试，一般耗费资源很少，但可以防止问题在项目最后出现，花费很大的精力去修改。

　　而有些资料中提到的：在系统代码开发和功能测试完成之后，进行性能测试的说法，是为了检查系统整体性能的做法。一般经常出现在验收性能测试中。

　　误区2：软件性能测试要向功能测试一样，覆盖到所有功能。

　　性能测试的主要目的是为了系统调优。不可能对所有的系统功能都进行性能测试。在测试设计时需要结合当时的实际系统，先分析软件可能存在的瓶颈，此时可依据80/20原则分析：对系统资源的利用、数据大量传输、数据转换、用户使用频率、逻辑复杂度等进行分析，选择要执行的功能和场景，再依次制定性能测试的方案。

　　误区3：系统吞吐率随着并发量增加而增加。

　　随着并发量的增加吞吐率并不是线性增长的。并发量从小逐渐增大，开始阶段吞吐率随着并发量的增加线性变化；当并发量达到某一值时，系统处理能力趋于饱和（也可能某一硬件条件达到临界值），此时再逐渐增大并发，会有一些请求处于等待状态，所以响应时间变慢，吞吐率趋于稳定；当并发量达到系统的最大处理能力后，再增加并发，系统处理能力会下降，吞吐率也会下降，最终可能发生宕机。

　　误区4：客户给出性能指标，我们一定要想法设法达到。

　　根据用户提供的指标进行可行性分析，分析这些指标在理想状态下是否可以达到。比如有这么一个要求：有一台服务器，希望能承载10000个用户每秒200kb的传输。从CPU、Disk、网卡等方面分析都是很难达到的，也是很难测试的。需要和客户商讨增加硬件配置或者通过其他途径来解决。

　　误区5：压力测试、负载测试、容量测试等这些不同类型的测试一个一个分开来执行。

　　现实场景是复杂的，测试也需要尽可能的模拟负载的场景。在一个整体的系统性能测试场景中，应该包括各个类型的测试。而需要检查某一个方面的指标或分析某个性能问题时，尽量保证场景简单、单一、容易模拟。

　　误区6：做性能测试主要就是性能测试工具的使用；我做不好性能测试，是因为对测试工具不熟悉；测试工具可以自动生成我所需要的报表；依靠性能测试工具就能准确定位系统瓶颈；

　　测试工具在测试中只能起到辅助性作用。而测试方案、测试场景的分析、问题的定位这才是性能测试的关键。不要期望测试工具能够生成你想要的东西（报表、瓶颈分析），工具只是尽可能多的提供我们分析的依据。

　　误区7：在线用户数就是并发用户数。并发用户数高意味着PV（页面浏览量）大。

　　并发用户数*用户访问页面数=PV

　　误区8：提高一下硬件配置就可以提高性能了，因此性能测试不重要。

　　随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如：内存泄露问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃；数据库连接等配置信息、数据库死锁是和硬件很难挂钩的；算法逻辑问题导致程序缓慢。即使要提高配置，也要首先用性能测试的方式得出哪些硬件可能存在瓶颈。

　　误区9：性能测试独立于功能测试

　　一方面，整体性能测试的场景设计要求的系统功能非常熟悉；另一方面，功能测试可以发现性能问题，性能测试也能发现功能问题。很多性能问题时由于软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试可能会发现这些问题。

　　误区10：随便找个环境下进行一下性能测试就可以了。

　　做性能问题分析可以在类生产环境上进行，配置可以有些差别，但是，整体性性能测试、验收性性能测试要尽量在用户生产环境下进行。

loadrunner测试同时监控服务器资源   《转载》

　楔子：测友们总是再问lr测试同时怎么监控服务器的资源！---发生在胡胡测试群中的故事

　　本人秉着说错了无所谓--咱改！ 大不鸟挨砖的态度写下这篇文章!

　　hp loadrunner的监控已经做的很好了，可以监控多种资源，譬如：

　　1.unix(linux)服务器资源(需要在unix服务器安装rstatd守护程序==)

　　2.监控windows服务器资源（需要对所监控的服务器有相应的访问权限）

　　3.apache资源（需要动态加载一个apache的库对监控作为支持）

　　4.welogic资源（需要在服务器端安装jdk 修改xml权限配置==）

　　还有好多，用lr监控服务器资源

　　优点：可以实时查看并能记录到analysis中而且能和其他资源合并比较。

　　缺点：存在一点的延时，优点中的“实时”也就找洞别见人了！耗费资源：rstatd守护程序比较

　　好资源，且稳定性不好，容易死掉，自己实测遇到N次，找运维、开发讨论多次无果果断放弃使用。---这些缺点主要针对unix资源监控，因为我用的比较多！

　　推荐监控方式。

　　1.windows资源监控 可以使用自带的性能计数器。

　　优点：可以导出监控log，在analysis中导入数据生成图表。

　　缺点：感觉麻烦。

　　2.spotlight for windows（这个比较喜欢 还有for oracle、for linux不同的版本）

　　3.unix(linux)监控工具--nmon

　　优点：可实时监控。且记录到文本用nmon_analysis转换成图表。

　　4.unix(linux)监控工具--nagios

　　优点：太多了 监控项也比较全，不够的还能自己写脚本加入！

　　缺点：俗称“难搞死”。第一次弄的时候弄了1天才弄好。

　　5.linux监控工具--zabbix

　　优缺点未知，运维的哥们给介绍的！

　　6.linux监控工具--spotlight for linux

　　7.jvm监控工具--jconsole

　　8.在linux下还可以使用自带的命令，如：vmstat sar iostat netstat top 很多，可以用python或者shell写脚本 实用啊！

　　一句话就是：比较推荐nmon、nagios和自带命令--linux  性能计数器--windows！