b是apachebench命令的缩写，它是apache自带的Web性能测试工具。ab工具非常实用，它可以去创建多个并发访问线程，模拟多个访问客户端同时对某一网站URL地址进行访问，这样我们就可以用来测试apache的负载压力，也可以对其它类型的服务器进行压力测试，比如nginx、tomcat、IIS等其它Web服务器的压力。网站性能压力测试可以说是服务器网站性能调优过程中必不可缺少的一环，只有让服务器处在高压情况下，才能真正体现出软件、硬件等各种设置不当所暴露出的问题。本文详细介绍一下ab工具的使用。

ab安装

ab安装我们可以通过yum方式直接安装apache的工具包httpd-tools。

yum -y install httpd-tools

安装完成后可使用“ab –V”命令查看当前的版本。

有关ab命令的使用，我们可以通过“ab -help”帮助命令进行查看。如下：

ab使用

ab的命令参数比较多，但是我们常用的主要参数就是-n和-c参数。

• -n：表示一共模拟访问的次数。
• -c：表示模拟并发的客户端数量。

模拟访问次数除以客户端就是每个客户端所发送的访问请求。

命令：ab -n Number1 -c Number2 url

实例：ab -n 100 -c10 https://www.baidu.com/

输出结果如下：

# ab -n 100 -c 10 https://www.baidu.com/  
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.baidu.com (be patient).....done
Server Software:        BWS/1.1    #Web服务器软件版本
Server Hostname:        www.baidu.com    #请求的URL主机名
Server Port:            443    #Web服务器软件的监听端口
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128    #SSL协议类型
Document Path:          /    #请求的URL中的根绝对路径
Document Length:        227 bytes    #HTTP响应数据的正文长度
Concurrency Level:      10    #请求的并发数，设置的-c参数
Time taken for tests:   1.276 seconds    #所有这些请求被处理完成所花费的总时间
Complete requests:      100    #总请求数量，设置的-n参数
Failed requests:        0    #失败的请求数量
Write errors:           0    
Total transferred:      111098 bytes    #所有请求的响应数据长度总和，包括每个HTTP响应数据的头信息和正文数据的长度。注意这里不包括HTTP请求数据的长度，仅仅为web服务器流向用户PC的应用层数据总长度。
HTML transferred:       22700 bytes    #所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度。
Requests per second:    78.38 [#/sec] (mean)    #吞吐率，也叫QPS，计算公式：Complete requests/Time taken for tests
Time per request:       127.583 [ms] (mean)    #用户平均请求等待时间，从用户角度看，完成一个请求所需要的时间。计算公式：Time token for tests/（Complete requests/Concurrency Level）
Time per request:       12.758 [ms] (mean, across all concurrent requests)    #服务器完成一个请求的时间，计算公式：Time taken for tests/Complete requests，正好是吞吐率的倒数
Transfer rate:          85.04 [Kbytes/sec] received    #网络传输速度，计算公式：Total trnasferred/ Time taken for tests，这个统计很好的说明服务器的处理能力达到极限时，其出口宽带的需求量
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       42   85  17.3     88     129
Processing:    15   27  10.8     23      66
Waiting:       15   27  10.5     23      66
Total:         67  112  19.7    111     167
 #这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接（Connect），系统处理（Processing）和等待（Waiting）三个部分。
表中min表示最小值； mean表示平均值；[+/-sd]表示标准差（Standard Deviation） 表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max表示最大值。
需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了167ms
Percentage of the requests served within a certain time (ms)
  50%    111    
  66%    121    
  75%    124    
  80%    128    
  90%    136   
  95%    152    
  98%    161    
  99%    167   
 100%    167 (longest request)
#这部分数据用于描述每个请求处理时间的分布情况，比如以上测试，50%的请求处理时间都不超过111ms，60%的请求处理时间都不超过121ms...这个处理时间是指前面的Time per request，即对于单个用户而言，平均每个请求的处理时间

总结

ab工具使用方便，上手较快，可以提供查看服务器性能的基本指标，但是不能够以图形化的形式展现，也不能监控，所以可以做临时的、简单的服务器性能测试。同类型的压力测试工具还有：webbench、siege等。需要注意的是ab命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存，但却会给目标服务器造成巨大的负载，其原理类似CC攻击。我们测试使用时需要注意，否则一次上太多的负载，可能造成目标服务器资源耗完，严重时甚至导致死机。

要：最近笔主带着两位新入职的同事进行了公司新平台的压力测试，工具选择的当然是Loadrunner，小笔发现有很多刚入门Loadrunner的小白都会遇到很多相似的问题，但是这些问题并不能在各大搜索网站上得到完善的解决。因此，小笔选中了51testing这个流量给力认可度高的专业测试平台给各位loadrunner新手提拱一份参考，希望能够帮助到有需要的朋友。

在如今的大数据时代，软件、测试、自动化测试都在扮演者不可或缺的重要角色，我们开发一个平台要求的已经不仅仅是功能要正确，更要考虑的是随着访问量的增加给客户带来的压力体验。

OK，引文部分已经完成，下面我们一起走进Loadrunner的压力测试吧。

跟着小笔一起动手来完成此次的压力测试吧！一个完整的压力测试三部曲：

1.脚本录制->2. 场景设计->3. 结果分析

场景介绍：此处我们选择最具有代表意义的多用户并发登录系统，我们测试150个用户并发登录平台A的时候给系统增加的压力情况。

测试背景： Windows Server 2008+Loadrunner11+IE8

1．录制脚本（Virtual User Generator）

安装好Loadrunner后（安装比较容易，在此暂且省略），打开Virtual User Generator进行脚本录制，录制时相关设置：

Step 1、Catalog选择'Web(HTTP/HTML)'，点击[Create] 按钮。

Step 2、[URL Address]的值输入需要测试系统的地址，点击[OK]按钮。

Step3、开始进行登录系统的脚本录制，一般情况下，我们在录制的过程中需要切分action，不同的操作放在相对应的action里，此处因为操作简单，我们暂且不去细分。

Step4、生成脚本

Step5、优化脚本：添加集合点，事务，思考时间。

事务：定义一个action的范围，以便对此action进行某种操作。比如对该action进行计时操作。

语句：lr_start_transaction("login");

集合点：正如字面意思，等待所有的事务集合到一起进行的操作，用来执行负载测试。要实现此操作，可以同步 Vuser 以便恰好在同一时刻执行任务。通过创建集合点，可以配置多个 Vuser 同时执行某个操作。当某个 Vuser 到达该集合点时，将进行等待，直到参与该集合的全部 Vuser 都到达。指定数量的 Vuser 均到达后，释放所有这些 Vuser。

语句：lr_rendezvous("login");

思考时间：思考时间即等待时间，是一种延迟操作，很好理解。

语句：lr_think_time(5);

2．场景设计（Controller）

Step1、打开 controller，添加上面优化好的脚本，设置场景模式。（此处命名为testLogin）设置场景如下：

Step2、点击【Start Scenario】运行脚本，结果如下：

Step 3、点击紫色框中按钮，生成测试结果报告。

2．结果分析（Analysis）

Analysis 可以说是Loadrunner压力测试的重点和难点，所以对于新手而言 analysis不是测试的结束，而是开始。因此，对于各项测试结果我们要做出准确的理解和判断。在本次的实践中，我们做的是一个比较简单的场景，那么针对此场景的各项结果如下：

【测试报告分析摘要】，这里显示了实际测试过程中，总体的测试结果。我们可以选择更过的图来分析系统的负载情况。

【Running Vuser】结果分析：Vuser是并发测试选取的虚拟用户，从下图中可以看出，Vuser是每5秒增加5个，在02:20秒的时候达到了顶峰值150，持续运行了一分钟后，逐渐退出系统。

【Hits per Second】结果分析：每秒提交的HTTP请求数量，在本场景中执行的时间比较短，因此结果不是很明显，建议大家此处可以放宽执行时间，这样得到的结果比较准确。

【Throughput】结果分析：吞吐量是指返回的应用层数据的值，吞吐量单位是以字节数为准，表示Vuser在任何给定的某一秒上从服务器获得的数据量。借助此图我们可以依据服务器吞吐量来评估Vuser产生的负载量。该数据越小说明系统的带宽依赖就越小，通过这个数据可以确定是不是网络出现了瓶颈。

【Tansaction summary】结果分析：事务概要说明，统计执行的事务数量，比如在本次场景中，login和exist这两个事务的值都是855次。同事也监控了事务的Pass数和Fail数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务数越小说明系统越可靠。这个比较容易理解，不多阐述。

【Average Transaction Response Time】- 事务响应时间结果分析：这里需要注意的一个问题是因为在Transaction Response Times里面是场景运行时记录的响应时间的最大值最小值与平均值，而Average Transaction Response Time 是按照采样率每隔几秒钟取一个值画出来的图，然后根据图来记录最大值最小值和平均值，在报告中也可以看到，Average Transaction Response Time中写的是图最大值、图小值和图平均值。如果将采样率设置小一些，这两个值就会比较接。所以，抽象率是关键。那么下图现实的结果可以看出，login这个action最大值是14.978，最小值是2.134，平均值是7.869；exist最小值是0.02，最大值0.214，平均值是0.078 。这些时间是可以接受的压力响应的时间。

本次测试过程中常见问题汇总：

之所以加上问题汇总是因为笔主觉得大家在做压力测试的时候，这类问题的出现率很高，所以，在此稍微总结一下。

问题1：averager esponse time响应时间过长？（与实际偏差甚大完全不合理）

解决方法：导致此问题的原因很多，但是我们可以从以下几类去分析：1、是否在脚本中添加了多长时间的思考时间。2、事务和集合点的先后顺序是否正确，正确的顺序是把集合点放在事务前面，反之则也会增加事务响应时间的值。3、网速问题，网速一般不会造成太大的偏大，但是不排除并发量很大的情况下造成的延误。

问题2：LoadRunner超时错误

解决方法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

问题3：LoadRunner脚本中出现乱码

解决方法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

问题4：在录制过程中IE页面上，某些控件显示有问题，导致录制不了。

解决方法：一般情况下，将被测系统的URL加入到可信任站点即可解决此类问题。

问题5：Error -27796：Failed to connect to server‘XXXX’

这个问题可以说是经常遇到但是不易被解决的难题，我们大致可以这样去排查

（1）检查run time setting中的请求超时时间Preferences中点击Options‘HTTPrequest connect timeout’，‘HTTP-request receieve timeout’，‘Step download timeout’，查看其值是否为1000、1000、10000；run time setting设置完了后记住还需要在control组件的option的run time setting 中设置相应的参数；

（2）Browser Emulation中的Download non-HTML resources选项去掉，点击OK即可如果还不能解决的话，继续尝试第3种方法

（3）设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项，选项后再回放就成功了。如果实在不行的话就试试重启大法吧，因为有些问题的确可能是因为工具问题，网络问题，机子问题等等。

总结：用Loadrunner进行压力测试难免会遇到各种问题，细心排查总能一一解决，所以笔者想对刚刚踏入这一行业的朋友说，不急不燥认真去思考，问题总能被解决。希望此篇文章对大家有所帮助，任何问题都可以留言喔。

最后：

1）关注+私信回复：“测试”，可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试等。

2）关注+私信回复："入群" 就可以邀请你进入软件测试群学习交流~~