性能測試下的AB測試實戰

如今你們都在學習自動化和性能，在進行性能測試的時候壓力測試確定是其中不可或缺的一環了。下面咱們就來看看怎麼用AB進行性能測試。

AB 的全稱是 ApacheBench ， 是 Apache 附帶的一個小工具 ， 專門用於 HTTP Server 的 benchmark testing ， 能夠同時模擬多個併發請求。前段時間看到公司的開發人員也在用它做一些測試，看起來也不錯，很簡單，也很容易使用，因此今天花一點時間看了一下。

經過下面的步驟，相信你們能夠更容易理解這個工具的使用。

AB壓力測試功能的安裝

Unix和Mac安裝

若是用的是*nix操做系統，則會有不少安裝Apache的選項。能夠經過ports、yum、apt-get安裝或只是下載源文件並安裝。顯示了安裝命令的完整列表。

使用存儲庫來安裝Apache Web服務器存儲庫命令

yumyum install apache2

portssudo port install apache2

apt-getapt-get install apache2

Mac用戶能夠在終端上使用MacPorts並執行所示的基於ports的命令。

Windows安裝

Windows用戶可在瀏覽器中打開http://httpd.apache.org/。加載此頁以後，單擊頁面左側的"Download from a mirror"（從鏡像下載）連接，找到適合你的系統的相應下載程序包，即Windows 32 Binary版本，而後下載。編寫本書時，最新的Apache版本爲2.2.X。

當程序包下載完以後，就能夠經過運行安裝嚮導在系統的任意位置上安裝該軟件。我將Apache安裝在默認位置C:\Program Files\Apache Software Foundation，但也能夠安裝在系統的任意位置。此處所選擇的位置就是APACHE_HOME引用所指向的位置。

如今，打開目錄\Apache2.2\bin。

AB壓力測試的經常使用參數

-n在測試會話中所執行的請求個數。默認時，僅執行一個請求。

-c一次產生的請求個數。默認是一次一個。

-t 測試所進行的最大秒數。其內部隱含值是-n 50000，它可使對服務器的測試限制在一個固定的總時間之內。默認時，沒有時間限制。

-p包含了須要POST的數據的文件。

-P對一箇中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。不管服務器是否須要(即, 是否發送了401認證需求代碼)，此字符串都會被髮送。

-T POST數據所使用的Content-type頭信息。

-v設置顯示信息的詳細程度-4或更大值會顯示頭信息，3或更大值能夠顯示響應代碼(404,200等),2或更大值能夠顯示警告和其餘信息。

-V顯示版本號並退出。

-i執行HEAD請求，而不是GET。

-X對請求使用代理服務器。

-C對請求附加一個Cookie:行。其典型形式是name=value的一個參數對，此參數能夠重複。

-H對請求附加額外的頭信息。此參數的典型形式是一個有效的頭信息行，其中包含了以冒號分隔的字段和值的對(如,"Accept-Encoding:zip/zop;8bit")。

-A對服務器提供BASIC認證信任。用戶名和密碼由一個:隔開，並以base64編碼形式發送。不管服務器是否須要(即,是否發送了401認證需求代碼)，此字符串都會被髮送。

-h顯示使用方法。

-e產生一個以逗號分隔的(CSV)文件，其中包含了處理每一個相應百分比的請求所須要(從1%到100%)的相應百分比的(以微妙爲單位)時間。因爲這種格式已經「二進制化」，因此比'gnuplot'格式更有用。

-g把全部測試結果寫入一個'gnuplot'或者TSV(以Tab分隔的)文件。此文件能夠方便地導入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行爲標題。

-i執行HEAD請求，而不是GET。

-k啓用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求。默認時，不啓用KeepAlive功能。

-q若是處理的請求數大於150，ab每處理大約10%或者100個請求時，會在stderr輸出一個進度計數。此-q標記能夠抑制這些信息。

AB壓力測試實例

一般AB測試只用到-c、-n兩個參數，假如咱們本地有個a.php的文件，則可執行以下命令： ab -n 1000 -c 100 http://127.0.0.1/a.php

此命令表示模擬每次執行100個請求，總共執行1000次，也能夠表示爲100人同時在線，每人同一時間發起一個請求，一共發送10次請求。效果以下圖：

能夠看到每次請求的數量爲100個，請求了10次，總請求爲1000個。 Document Path:請求的文件 Requests per second:每秒鐘能夠接收多少個請求。 Time per request：用戶平均請求等待時間 Time per request（across all concurrent requests）：服務器平均請求等待時間 Transfer rate:平均每秒網絡上的流量，吞吐量，越大抗壓越強

Connection Times:網絡上消耗的時間的分解

分別有鏈接、處理、等待的值

Percentage Of The Requests Served Within A Certain Time：整個場景中全部請求的響應狀況

在場景中每一個請求都有一個響應時間，其中50％的用戶響應時間小於25 毫秒，66％的用戶響應時間小於27 毫秒，最大的響應時間小於37 毫秒。

因爲對於併發請求，cpu實際上並非同時處理的，而是按照每一個請求得到的時間片逐個輪轉處理的，因此基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數。

有了上述的各項指標，咱們能夠進行屢次請求，不斷修改-c、-n的值來取得apache的最佳請求數量，從而進行優化配置。須要注意的是每一個請求鏈接得出的結果均不同。測試的時候能夠對多個鏈接進行測試。

AB不像 LR 那麼強大，可是它足夠輕便，若是隻是在開發過程當中想檢查一下某個模塊的響應狀況，或者作一些場景比較簡單的測試， ab 仍是一個不錯的選擇——至少不用花費不少時間去學習 LR 那些複雜的功能，就更別說那 License 的價格了。

近年來，軟件測試行業愈來愈不知足只會點點點的測試了，愈來愈多的公司開始要求自動化、性能等能力。

若是你還在猶豫我到底要不要提高的時候，那些比你學得更早的，更快的已經把你遠遠地甩在了後面。

若是你感受到了緊迫和壓力，歡迎加羣你們一塊兒交流自動化的技術，爲了更高的薪資，更爲了避免被行業淘汰！