整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
b是apachebench命令的縮寫，它是apache自帶的Web性能測試工具。ab工具非常實用，它可以去創建多個并發訪問線程，模擬多個訪問客戶端同時對某一網站URL地址進行訪問，這樣我們就可以用來測試apache的負載壓力，也可以對其它類型的服務器進行壓力測試，比如nginx、tomcat、IIS等其它Web服務器的壓力。網站性能壓力測試可以說是服務器網站性能調優過程中必不可缺少的一環，只有讓服務器處在高壓情況下，才能真正體現出軟件、硬件等各種設置不當所暴露出的問題。本文詳細介紹一下ab工具的使用。
ab安裝我們可以通過yum方式直接安裝apache的工具包httpd-tools。
yum -y install httpd-tools
安裝完成后可使用“ab –V”命令查看當前的版本。
有關ab命令的使用，我們可以通過“ab -help”幫助命令進行查看。如下：
ab的命令參數比較多，但是我們常用的主要參數就是-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攻擊。我們測試使用時需要注意，否則一次上太多的負載，可能造成目標服務器資源耗完，嚴重時甚至導致死機。
JMeter
Apache JMeter是Apache組織開發的基于Java的壓力測試工具。用于對軟件做壓力測試，它最初被設計用于Web應用測試，但后來擴展到其他測試領域。
（1）因為JMeter是使用JAVA寫的，所以使用JMeter之前，先安裝JAVA環境，
oracle官網下載JDk https://www.oracle.com/technetwork/java/javase/downloads/index.html
配置變量
系統變量→新建 JAVA_HOME 變量 。 變量值填寫jdk的安裝目錄（本人是 E:\Java\jdk1.7.0)
系統變量→尋找 Path 變量→編輯
在變量值最后輸入 %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;
（注意原來Path的變量值末尾有沒有;號，如果沒有，先輸入；號再輸入上面的代碼）
系統變量→新建 CLASSPATH 變量
變量值填寫 .;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar（注意最前面有一點）
系統變量配置完畢
測試jdk是否安裝成功，可在【開始】中搜索cmd，輸入【java -version】
1.JMeter下載地址：在官網 http://jmeter.apache.org/
2.解壓下載的二進制包，使用cmd命令進入bin目錄，使用jmeter.bat啟動程序。（注意直接雙擊jmeter.bat無法啟動時需要使用Window+R，輸入cmd，然后進入bin目錄如下）
3.啟動之后會有兩個窗口，一個cmd窗口，一個JMeter的 GUI
上面的意思就是：不要使用GUI運行壓力測試，GUI僅用于壓力測試的創建和調試；執行壓力測試請不要使用GUI。使用下面的命令來執行測試：
jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
1.創建線程組
在“測試計劃”上右鍵 【添加】-->【Threads(Users)】-->【線程組】
2.設置線程數和循環次數。我這里設置線程數為500，循環一次。
3.創建Http請求
在“線程組”右鍵 【添加-】->【samlper】-->【HTTP 請求】
4.添加察看結果樹和聚合報告
在我們剛剛創建的線程組上右鍵 【添加】-->【監聽器】-->【察看結果樹】。添加聚合報告，右鍵 【添加】-->【監聽器】-->【聚合報告】。
直接添加，然后點擊運行按鈕就可以看到結果了。
結果樹分析：
通過察看結果樹，我們可以看到每個請求的結果，其中紅色的是出錯的請求，綠色的為通過。
Thread Name（線程組名稱）: 線程組 1-24
Sample Start（ 啟動開始時間）: 2019-02-15 15:00:14 CST
Load time（加載時長）: 290
Connect Time:（連接時長） 86
Latency（等待時長）: 174
Size in bytes（發送的數據總大小）: 2212
Sent bytes:821
Headers size in bytes（發送數據的其余部分大?。? 1162
Body size in bytes: 1050
Sample Count（發送統計）: 1
Error Count（錯誤統計）: 0
Data type ("text"|"bin"|""): text
Response code（返回狀態碼）: 200
Response message（返回信息）: OK
這里綠色的就說明請求是通過的，返回值是200，如果出現紅色的×就說明請求失敗，這時候可以通過右邊的取樣器結果和響應數據來查看結果。
聚合報告分析：
Sample:本次測試場景共運行多少線程；
Average:平均響應時間；
Median:統計意義上的響應時間中值；
90% line:所有線程中90%的線程響應時間都小于xx的值;
Min:響應最小時間；
Max:響應最大時間；
Error:出錯率；
Throughput - 吞吐量以“requests/second、requests /minute、 requests /hour”來衡量。 時間單位已經被選取為second，所以，顯示速率至少是1.0，即每秒1個請求。 當吞吐量被保存到CVS文件時，采用的是requests/second，所以30.0 requests/second 在CVS中被保存為0.5
Kb/sec - 以Kilobytes/seond來衡量的吞吐量
（1）50個用戶在10秒中同時訪問企業用戶會議室預定頁面，平均響應時間是0.146秒，最大的響應時間0.387秒，最小的響應時間是0.096秒，錯誤率為0。
（2）100個用戶在10秒中同時訪問企業用戶會議室預定頁面，平均響應時間是2.295秒，最大的響應時間8.132秒，最小的響應時間是0.425秒，錯誤率為0。
要：最近筆主帶著兩位新入職的同事進行了公司新平臺的壓力測試，工具選擇的當然是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）關注+私信回復："入群" 就可以邀請你進入軟件測試群學習交流~~
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
