性能測試工具選擇政策——仿真度對比測評分析報告

1、概述

在做性能測試時，網絡上關于性能測試工具推薦有很多，到底如何選擇一款性能測試工具比較好呢？網絡上關于性能測試工具對比他們優缺點有很多描述，但主要是從：并發能力、資源監控、是否開源、是否支援錄制、是否支援分布、實作語言、社群活躍度、腳本的維護、易用性、可擴充性、壓測平台編碼量等方面對比。但幾乎沒有人提到性能測試工具的仿真度能力。仿真度就是性能測試工具模拟用戶端向服務端下發請求與用戶端的相似能力。仿真度越高，測試獲得的結果越可信。

本文宗旨是選擇幾款常用的性能測試工具進行仿真度對比測試，以此來幫助軟體測試人員在工作中如何選擇一款适合自己工作需要的性能測試工具。

性能測試工具比較多，限于作者時間有限，不能對每一款性能測試工具一一測試，計劃挑三款性能測試工具互相對比測試。選擇政策是：挑選國産一款，國外二款（商用和開源免費各選擇一款）

國外的性能測試工具我們挑選國内最常用兩款：

LoadRunner、Jemeter作為測試對象；國産的性能測試工具我們選擇KylinTOP(B/S)作為測試對象。

性能測試工具一般支援的協定都非常多，不可能對每一種協定都做仿真度測評。國内常用的協定主要是HTTP協定，是以文本主要針對HTTP協定的仿真度進行測評。

文本所有通過wireShark抓封包件分析獲得的瀑布圖，在附錄中均附有抓封包件及過程分析資料。

2、浏覽器并發能力分析

在向浏覽器位址欄輸入一個URL位址回車時，浏覽器呈現在我們眼前的是一個完整的頁面。頁面中有很多的元素（如：文字連結、按鈕、輸入框、圖檔等），這些元素都是浏覽器從服務端擷取的資料。浏覽器獲得這些元素按并行方式擷取的（通過并行的HTTP請求獲得），每個浏覽器并行擷取的能力也是不同的，詳見下表：

浏覽器	并發數
HTTP / 1.1	HTTP / 1.0
IE 11	6
IE 10
IE 9	10
IE 8
IE 6,7	2	4
火狐
Safari 3,4
Chrome 4+

注：浏覽器的并發能力引用：

HTTPs://www.cnblogs.com/sunsky303/p/8862128.html

文章中提到的系統資料庫中的：MaxConnectionsPerServer（**HTTP

1.1）和MaxConnectionsPer1_0Server（HTTP

1.0）**配置項，作者使用的是wind10，自帶ie11浏覽器,其中MaxConnectionsPerServer=10，但是浏覽的并發量并沒有增加到10，仍為6。

3、仿真度的重要性

性能測試工具的工作流程：錄制腳本-建立測試計劃（建立測試場景）-執行測試計劃-分析測試結果。工作原理是：啟動一個線程循環執行錄制腳本，相當于仿真一個真實線上使用者不停的循環操作。那麼這個使用者的仿真度就與執行腳本的方式具有強相關性。執行方式與浏覽行為越接近，那麼它的仿真度越高。

性能測試工具的建立測試計劃（場景）步驟可以選擇的屬性有：

運作時間或疊代次數、并發使用者數以及使用者新增或下降方式等。其中“運作時間或疊代次數”和并發使用者數是性能測試過程中的兩個重要的屬性特征。用于測試伺服器在指定的時間段内可承受的最大并發使用者數。直接反應伺服器性能名額的參數是：HTTP請求數/秒、吞吐量（Mb/秒），但是這兩個屬性不能按業務層面反應伺服器的性能，如：最大并發使用者數是一個業務層面的性能名額。因為業務不同，浏覽器的并發請求數和請求時序不同，且對應的HTTP類型也不同。有些HTTP的請求是比較消耗資源的，尤其是對業務複雜處理的HTTP請求。

性能測試工具的仿真度的高低，直接展現了性能測試工具對真實業務的仿真，包括HTTP請求并發量、并發時序，業務類型等。仿真度越高測試結果獲得的資料越可信。

如下圖所示，每一個使用者就代表一個線程，每一個線程就是對錄制腳本的循環執行。下圖中的每一個方格就代表對錄制腳本的一次完整執行。紅框标志出某一刻伺服器承受的所有并發使用者數，它所承受的HTTP并發請求總數等于每一個方格此時此刻的HTTP并發數總和，用公式表達就是：

伺服器承受的HTTP并發總數＝（1-2使用者HTTP請求并發數）+（2-2使用者HTTP請求并發數）+……+(m-2使用者HTTP請求并發數)。

從這個表達式可以看出，伺服器承受的HTTP并發總數與每一個方式格的并發數相關，即錄制腳本在此時運作的并發數。如果性能測試工具按照腳本HTTP請求，順序執行HTTP請求（最不理想的情況），那麼它的并發總數就是：ｍ，如果按浏覽器的最大并發數運作,它的并發總數就是：6m（浏覽器一般可以最大并發６個），相差５倍。在伺服器承受的HTTP并發能力一定的情況下，腳本運作的并發數，決定了并發使用者數。那麼如何才能展現真實的并發使用者數呢，隻有在性能測試工具執行腳本的HTTP請求時，HTTP并發數、時序完全與浏覽器完全相同時，才能最能真實的反映出伺服器承受的最大并發使用者數。

4、測試設計分析

性能測試工具的工作原理是仿真浏覽器該問服務端。每一個浏覽器相當于一個使用者（使用者）。性能測試工具通過多線程實作模拟多使用者的通路（相對比較容易實作），每個使用者通過模拟浏覽器的行為仿真實使用者行為(實作難度較大)。浏覽器的行為包括：HTTP請求、以及HTTP請求之間的關系，這些關系通過浏覽器的瀑布圖可以觀查到也可以通過wireShark抓包工具來分析獲得。本文的重點旨在通過測試對比找出最佳的使用者仿真能力的性能測試工具。

使用者行為即浏覽器的HTTP請求行為，HTTP請求行為主要包括：

1. HTTP請求順序，包括：并行和串行兩種行為，如下所示：waterfall中的橫向圖代表一個HTTP請求的開始與結束時間。串行的HTTP請求，表示隻有前面的HTTP請求傳回響應值後，再請求下一個HTTP請求。并行HTTP請求，可以同時下發請求。
2. HTTP請求的數量，如下圖所示每一個頁面都由多個HTTP請求組成。
3. HTTP的請求類型，其中包括：靜态請求(如；css,js,html,jsp,png)和動态請求(背景接口)

如果性測試工具如果能對上述三種HTTP行為模拟的越接近，則性能測試工具的仿真度越高，測試結果與真實能力越接近。是以本文就圍繞這三種能力進行對比測試。

圖2-01

5、測試環境

5.1、試環境配置

作業系統	CPU	記憶體
kylinTOP	Window 10 專業工作站版 64bit	Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz	8GB
LoadRunner 12.55
LoadRunner 11	Windows 7 專業版，32位	Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz (2 CPUs), ~2.7GHz	2524MB RAM	虛拟機
Jemeter

5.2、測試工具

工具名稱	版本	工具作用	工具介紹
	1.8	性能測試工具	深圳市奇林軟體有限公司成立于2016年，是一家從事測試工具開發與測試服務的公司。kylinTOP是一款國産的性能測試工具。
Jmeter	5.1		Apache軟體基金會（ASF）是一家總部位于美國的非營利性慈善組織。ASF的所有産品都通過公共論壇的線上協作開發，并從美國境内的中央伺服器分發。Jmeter是ASF的一款開源免費軟體 ，在國内被很多中小公司當作性能測試工具廣泛使用。
LoadRunner	11.04.0.0，12.55		惠普（HP）是世界最大的 資訊科技 （IT）公司之一，成立于1939年，總部位于美國 加利福尼亞州 帕洛阿爾托市。LoadRunner是目前國内使用最廣泛的性能測試工具。
Wireshark	3.0.5	網絡抓包工具	美國自由軟體基金下的一款優秀的開源免費協定分析軟體,，Wireshark（前稱Ethereal），是目前全世界使用最廣泛的網絡封包分析軟體之一。
Internet Explorer 11	11.805.17763.0		Windows系統自帶的一款web浏覽器
Internet Explorer 9	9.0.8112.16421
Google Chrome	76.0.3809.87（正式版本）（32 位）		Google公司的一款世界著名的浏覽器

5.3、測試環境組網

圖5-3-01

5.4、被測試對象

HTTP://cloud.10oa.com/trial/view/catalogue.aspx?sid=132000&name=%u6211%u7684%u5DE5%u4F5C%u8BA1%u5212

或

HTTP://cloud.10oa.com/trial/view/catalogue.aspx

注：這兩個位址内容是一樣的，kylinTOP使用的是第1個位址，Jmeter使用的是第2個，因為Jmeter錄制時無法解析第1個位址，弄了很久才發現把後的參數去除才可以錄制。後續loadRunner均使用第2個位址，以免出現相同的問題。

圖5-4-01

打開該首頁共：16個請求,用時：815ms

6、HTTP請求仿真度對比

6.1、測試思路

步驟1：Loadrunner、kylinTOP、JMeter具錄制同一個網頁

步驟2：調試腳本回放，使之請求内容相同（錄制能力不同錄制結果也不同，這裡隻對比雙方都能錄制的請求）

步驟3:建立測試計劃，各自運作腳本一次，運作的過程通過（wireShark抓包）

步驟4：通過對wireShark網絡抓包結果分析HTTP請求的順序，然後進行互相對比。

注：kylinTOP工具能夠記錄錄制和執行過程中的HTTP請求順序，但loadrunner無此功能需要通過抓包分析。

6.2、對比基線

6.2.1、請求清單

序列	Info
1	GET /trial/view/catalogue.aspx?sid=100000&name=%u6211%u7684%u684C%u9762 HTTP/1.1
	GET /trial/awesome/css/font-awesome.min.css HTTP/1.1
3	GET /trial/skin/view.css HTTP/1.1
	GET /trial/common/viewCn.js HTTP/1.1
5	GET /trial/common/view.js HTTP/1.1
	GET /trial/common/10oa.png HTTP/1.1
7	GET /trial/images/dotBlue.gif HTTP/1.1
8	GET /trial/images/dotGreen.gif HTTP/1.1
9	GET /trial/images/dotYellow.gif HTTP/1.1
	GET /trial/images/dotRed.gif HTTP/1.1
11	GET /trial/images/dotGray.gif HTTP/1.1
12	GET /trial/images/person.png HTTP/1.1
13	GET /trial/images/lock.png HTTP/1.1
14	GET /trial/skin/bg.jpg HTTP/1.1
15	GET /trial/skin/bg40.png HTTP/1.1
16	GET /trial/skin/bg20.png HTTP/1.1

表1

6.2.2、 IE11浏覽器HTTP請求瀑布圖

圖6-2-2-01

圖6-2-2-02

圖6-2-2-03

TTFB 全稱 Time To First

Byte，是指網絡請求被發起到從伺服器接收到第一個位元組的這段時間,此時HTTP請求已發出。從IE11提供瀑布圖看并發請求最高達到7個。但對應wireShark抓包隻有6個。後續對比我們以wireShark抓包圖為準。

6.2.3、IE9浏覽器HTTP請求瀑布圖

ie9單獨通路URL，最大并發數是6個。

圖6-2-3-01

HTTP的實際請求開始時間從黃色背景開始

6.2.4、Chrome浏覽器HTTP瀑布圖

Chrome自帶的瀑布圖與wireShark工具抓包分析瀑布圖顯示一緻

圖6-2-4-01

圖6-2-4-02

圖6-2-4-03

圖6-2-4-04

6.3、KylinTOP仿真度分析

6.3.1、kylinTOP腳本錄制：chrome浏覽器代理錄制

圖6-3-5-01

注：kylinTOP錄制的HTTP請求要比loadrunner多，在調試過程中已删除多餘部分，友善兩者對比。

圖6-3-5-02

圖6-3-5-03

注：kylinTOP自帶的繪制HTTP請求瀑布圖與wireShark抓包資料分析繪制的HTTP請求瀑布圖完全一緻（注意兩圖的有三個HTTP請求位置不同導緻看起來不一樣，但開始與結束時間是相同的）

6.3.2、執行性能測試任務

6.3.2.1、模拟浏覽器行為，根據錄制并發請求

圖6-3-2-1-01

從上圖分析kylinTOP性能監控執行HTTP請求瀑布圖與錄制時的請求瀑布存在一些差異，差異部分是HTTP請求之間空白時間段被壓縮。

圖6-3-2-1-02

注：kylintTOP自帶的繪制HTTP請求瀑布圖（錄制快照圖和性能測試計劃中運作時間圖）與wireShark抓包資料分析繪制的HTTP請求瀑布圖完全一緻，後續将以kylinTOP畫圖結果為準，不再另行wireShark抓包。

6.3.2.2、模拟浏覽器行為，按照錄制時間間隔時間并發請求

圖6-3-2-2-01

注：wireshark的抓包瀑布圖隻包括綠色和藍色兩部分。

6.3.3、測試結果分析

模拟浏覽器行為，按按照錄制時間間隔并發請求模式：

kylinTOP的性能測試計劃執行獲得HTTP請求瀑布圖與kylinTOP錄制快照圖（圖6-3-5-02）及錄制時的wireShark抓包圖（圖6-3-5-03）（包括：HTTP請求之間的時間間隔）。錄制的HTTP請求瀑布圖與chrome單獨打開URL的瀑布圖（圖6-2-4-01至圖6-2-4-04）存在一點差異，但相似度非常高（并發數、請求時序），目測相似度在95%左右。chrome每一次單獨打開URL的瀑布圖也是不一樣的，也就是說HTTP請求時序存在一定的随時性，但并發總是不變的。是以kylinTOP的仿真的相似度在并發數和請求時序上幾乎與浏覽器完全一樣。

模拟浏覽器行為，根據錄制并發請求

該種模式下kylinTOP給使用者多了一種選擇，把HTTP請求之間的空閑期進行壓縮，并盡可能的并發請求。作者猜想可能為了解決以下場景：、

場景1：錄制的腳本的HTTP請求有空閑期，這種情況頁一般來說是需要優化的，但開發人員還沒有優化，kylinTOP提供一種提前解決腳本的辦法。

6.4、Jmeter仿真度分析

6.4.1、Jmeter腳本錄制

圖6-4-1-01

圖6-4-1-02

6.4.2、執行性能測試計劃

圖6-4-2-01

圖6-4-2-02

6.4.3、測試結果分析

從Jmeter的測試計劃執行結果的wireShark抓包分析的瀑布圖看，Jmeter對HTTP請求是按順序執行，并發數為1個HTTP,從開始執行到最後執行結束，用時超過3秒鐘，真實浏覽器單獨通路URL時長在1秒左右，參見附件7.1：《Chrome單獨通路URL抓包資料分析_wireShark_001.xlsx》。主要是因為Jmeter的使用者HTTP請求采用串行請求，不具有真實浏覽器的仿真能力。

6.5、LoadRunner 11仿真度分析

6.5.1、腳本錄制

圖6-5-1-01

圖6-5-1-02

從并發圖看，有5個并發，但6個并發不是很明顯示，與IE9單獨通路時的瀑布圖（詳見：6.2.3章節）相差很大。圖形有并發請求，但請求之間交錯比較明顯，不存在明顯的同時并發。

6.5.2、執行性能測試測試計劃

圖6-5-2-01

圖6-5-2-02

6.5.3、測試結果分析

通過LoadRunner11的測試計劃的執行結果的瀑布圖看，HTTP請求基本上是按2個HTTP請進行并發的。HTTP的請求時序與錄制時IE的請求瀑布圖不同，且與IE9單獨通路URL時的HTTP請求瀑布圖也不相同。請求瀑布圖是按照loadRunner自己的内部規則并發，與Jmeter相比，在單使用者内有2個并發，是有一點進步的，但與IE浏覽器的真實行為仍然差距很大。

6.6、LoadRuner12仿真度分析

6.6.1、腳本錄制：基于HTML的腳本

6.6.2、執行測試計劃

配置測試計劃：啟動1個虛拟使用者且隻運作一次
LoadRunner12在運作1虛拟使用者的場景，在左圖中看起來多啟了2個使用者。
測試計劃執行完畢後，通過的數是1個。通過wireShark抓包分析，腳本執行了3次。抓封包件詳見附件。

6.6.3、測試結果分析

1. 從并發數個看，已達到6個，與浏覽器能力一緻。
2. 與錄制時的HTTP請求瀑布圖對比。相者相差很大，也就是說LoadRunner12在錄制時沒有記錄HTTP的時序。是按照自己内部規則下發請求。
3. 與浏覽器單獨通路題的瀑布圖相比，存在一定差異，如：catalogue.aspx和font-awesome.min.css這兩個HTTP請求，LoadRunner是順序執行，存在并行的時間視窗。
4. 對于/trial/skin/bg.jpg這個HTTP請求，浏覽器始終是放在倒數第3個請求執行，LoadRunner12提前了很多。

總結：LoadRunner12對錄制的請腳本執行，可以仿真IE11浏覽器的6個線程并發，但不能仿真器的HTTP請求之間的順序，相比LoadRunner11已經有了很大的提升。

6.7、HTTP請求仿真度對比總結

通過kylinTOP、Jmeter、LoadRunner11、LoadRuner12的測試計劃執行結果的HTTP瀑布圖對比結果看。他們的仿真能力排序：kylinTOP>LoadRuner12>LoadRunner11>Jmeter。

根據他們的能力行為，給出如下測試建議：

Jmeter：

可用于開發人員在産品開發中的功能調試使用并做一些非定量的性能測試，不适用于測試人員做定量的性能測試，更不能以此測試結果輸出測試結論誤導他人。

LoadRunner11：用于開發人員在産品開發中的功能調試使用顯示得比較厚重，用起來不是很友善，因為LoadRunner11的HTTP請求被LoadRunner做了二次封閉，不便于開發人員調試。用于測試人員做定量的性能測試，準确度又不夠（誤差還是比較大），是以處于一個比較尴尬的地位。

LoadRuner12

：仿真的測能力與浏覽器相近，可以用于性能測度，但定量的準确度還不夠。

KylinTOP:可以用于開發人員在産品開發過程中的功能調試并一些非定量的性能測試（kylinTOP的HTTP未做二次封裝）。同時也适用于測試人員做定量的性能測試，仿真度比較高，測試結果相對其它性能測試工具準确可信。

上述性能測試工具仿真度的測評都是以靜态HTTP請求為基準的測試結果，後續我們将進一步以動态HTTP請求為作為測試對象，對性能測試工具做一次更高能力的測評，敬請關注。