接口性能測試方案

一、 性能測試術語解釋

　　1. 響應時間

　　響應時間即從應用系統發出請求開始，到客戶端接收到最後一個字節數據爲止所消耗的時間。響應時間按軟件的特點再可以細分，如對於一個 C/S 軟件的響應時間可以細分爲網絡傳輸時間、應用服務器處理時間、數據庫服務器處理時間。另外客戶端自身也存在着解析時間、界面繪製呈現時間等。

　

　　響應時間主要站在客戶端角度來看的一個性能指標，它是用戶最關心、並且容易感知到的一個性能指標。

　　2. 吞吐率

　　吞吐率指單位時間內系統處理用戶的請求數，從業務角度看，吞吐率可以用每秒請求數、每秒事務數、每秒頁面數、每秒查詢數等單位來衡量。從網絡角度看，吞吐率也可以用每秒字節數來衡量。

　　吞吐率主要站在服務端的角度來看的一個性能指標，它可以衡量整個系統的處理能力。對於集羣或者雲平臺來說，吞吐率指標反映的是服務器集羣對外整體能夠承受的壓力，該指標比用戶數更容易對比。

　　備註：吞吐量 = 吞吐率 * 單位時間

　　3. 用戶數

　　對於服務器集羣或者雲平臺，幾乎都是多用戶系統，系統能提供給多少用戶正常使用，也是一個非常重要的度量指標。我們把這些用戶按照使用系統的時機不同，做如下區分。

　　系統用戶數（System Users）：指系統能夠存儲的用戶量。

　　在線用戶數（Online Users）：指用戶通過身份確認後，處於能正常使用狀態的用戶個數。

　　併發用戶數（Concurrent users）：指在某個時間範圍內，同時正在使用系統的用戶個數。

　　嚴格併發用戶數（Strictly the number of concurrent users）：指同一時刻都操作某個業務的用戶數。

　　在性能測試過程中，我們要去模擬實際用戶來發請求。但是爲了吐服務器產生更大的壓力，我們模擬的用戶操作和實際的用戶操作存在一定的差異（比如模擬的用戶請求比實際用戶的請求更頻繁），而且返種模擬的用戶數和實際的用戶數也難以相互換算。所以在度量服務器集羣能力時，吞吐率指標比用戶數指標更實用。

　　二、 性能測試方法及目標

　　1. 性能測試方法

　　1.1 基準測試（Benchmark Testing）

六、 性能測試用例與場景

　　腳本模板

　　

　　場景模板

　　

　　七、 性能測試工具選擇

　　1. 數據建模工具

　　DataFactory是一種強大的數據產生器，它允許開發人員和QA很容易產生百萬行有意義的正確的測試數據庫,該工具支持DB2、Oracle、 Sybase、SQL Server數據庫，支持ODBC連接方式，無法直接使用MySQL數據庫，可間接支持。

　　2. 腳本開發工具

　　（1） 若考慮腳本運行效率，則可考慮底層開發語言C或支持異步通信的語言JS,我們可以分別選擇：Loadrunner 或 Node.js 的IDE環境進行開發。

　　（2） 若考慮腳本開發效率，則可考慮代碼複用性，可以選擇面嚮對象語言C#或Java，爲此我們可以分別選擇：VS2008及以上版本 + 對應LR.NET控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。

　　HTTP、Socket等協議接口性能測試腳本開發過程，請詳見附件：

　　HTTP接口性能測試之腳本開發與性能問題分析.pdf

　　利用LR.Net控件完成性能測試腳本編寫方法.pdf

　　Node.js學習入門手冊.pdf

　　3. 壓力模擬工具

　　（1） 若爲Java類接口且單機併發數控制在500內，則可選擇Jmeter或者 Loadrunner。

　　（2） 若爲WebService類接口且單機併發數控制在500內，則可選擇SoapUI或者Loadrunner。

　　（3） 若單機併發數超過500且控制在5000內，則可選擇Loadrunner。

　　（4） 若單機併發數超過5000，則建議採用負載集羣，即採用“中控（Control Center）+ 多機部署（Load Generator）”方案。

　　4. 性能監控工具

　　4.1 監控工具

　　無論Windows或Linux平臺，一般存在的是一個或一組進程實例，我們可以選擇Loadrunner 或 Nmon 來監控。有時爲了獲取被測應用的一些特性指標，可以選擇被測組件自帶的性能工具集或監控系統。常見應用服務器監控工具推薦如下：

　　

　　4.2 監控平臺

　　監控機器主要對被測集羣服務器的服務或資源使用情況進行監控，比如各種開源的監控工具，MRTG：流量監控；CACTI：流量預警，性能報告Smokeping:IDC 質量監控；綜合監控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：

　

　　4.3 第三方監控雲服務（APM）

　　APM提供端到端應用性能管理軟件及應用性能監控軟件解決方案,包含移動,瀏覽器,應用,基礎設施,網絡,數據庫性能管理等，支持Java、.NET、PHP、Ruby、Python、Node.js、iOS、Android、HTML5等應用性能監控管理，主流雲服務包括聽雲、OneAPM等，如下所示：

　　

　　八、 性能測試結果分析

　　1. 指標分析

　　性能測試的指標可分爲產品指標和資源指標兩類。對測試人員而言，性能測試的需求來自於用戶、開發、運維的三方面。用戶和開發關注的是與業務需求相關的產品指標，運維人員關注的是與硬件消耗相關的資源指標。

　　

　　（1） 從用戶角度關注的指標

　　用戶關注的是單次業務相關的體驗效果，譬如一次操作的響應快慢、一次請求是否成功、一次連接是否失敗等，反映單次業務相關的指標包括：

　　a.成功率b.失敗率c.響應時間

　　（2） 從開發角度關注的指標

　　開發人員更關注的是系統層面的指標。

　　a.容量：系統能夠承載的最大用戶訪問量是多少?系統最大的業務處理量是多少?

　　b.穩定性:系統是否支持7*24小時(一週)的業務訪問。

　　（3） 從運維角度關注的指標

　　運維人員更關注的是硬件資源的消耗情況。

　　

　　以上說明了測試人員在選擇指標時需站在用戶角度去思考，另外爲了後續能夠更好地分析問題，更需掌握與被測組件特性或運行原理相關的性能指標。

　　舉例來說，通常接口系統均會直接或間接地訪問數據庫層介質（如Mysql、Oracle、SQLServer等），此時我們需考慮由接口系統產生壓力下存儲介質的性能情況，通常我們會選擇分析指標如下：

　　（1） 連接數（Connections）

　　（2） 每秒查詢數/每秒事務數（QPS/TPS）

　　（3） 每秒磁盤IO數（IOPS）

　　（4） 緩存命中率（Buffer Hits）

　　（5） 每秒發生的死鎖數（Dead Locks/sec）

　　（6） 每秒讀/寫字節數（Read/Write Bytes/sec）

　　對於Windows或Linux平臺具體指標監控及分析方法，請詳見附件：

　　《Windows操作系統性能監控工具和指標分析V1.0》.pdf

　　《Linux操作系統性能監控分析手冊V1.0》.docx

　　2. 建模分析

　　2.1 理髮店模型

　　

　　圖中展示的是1個標準的軟件性能模型。在圖中有三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這裏是指每秒事務數）以及響應時間（Response Time）。圖中座標軸的橫軸從左到右表現了併發用戶數（Number of Concurrent Users）的不斷增長。

　　在這張圖中我們可以看到，最開始，隨着併發用戶數的增長，資源佔用率和吞吐量會相應的增長，但是響應時間的變化不大；不過當併發用戶數增長到一定程度後，資源佔用達到飽和，吞吐量增長明顯放緩甚至停止增長，而響應時間卻進一步延長。如果併發用戶數繼續增長，你會發現軟硬件資源佔用繼續維持在飽和狀態，但是吞吐量開始下降，響應時間明顯的超出了用戶可接受的範圍，並且最終導致用戶放棄了這次請求甚至離開。

　　根據這種性能表現，圖中劃分了三個區域，分別是Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受並放棄請求）。在Light Load和Heavy Load 兩個區域交界處的併發用戶數，我們稱爲“最佳併發用戶數（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個區域交界處的併發用戶數則稱爲“最大併發用戶數（The Maximum Number of Concurrent Users）”。

　　當系統的負載等於最佳併發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待；當系統負載處於最佳併發用戶數和最大併發用戶數之間時，系統可以繼續工作，但是用戶的等待時間延長，滿意度開始降低，並且如果負載一直持續，將最終會導致有些用戶無法忍受而放棄；而當系統負載大於最大併發用戶數時，將註定會導致某些用戶無法忍受超長的響應時間而放棄。所以我們應該保證最佳併發用戶數要大於系統的平均負載。

　　2.2 壓力變化模型

　　

　　隨着單位時間流量的不斷增長，被測系統的壓力不斷增大，服務器資源會不斷被消耗，TPS 值會因爲這些因素而發生變化，而且符合一定的規律。

　　圖中：

　　a 點：性能期望值

　　b 點：高於期望，系統資源處於臨界點

　　c 點：高於期望，拐點

　　d 點：超過負載，系統崩潰

　　2.3 容量計算模型

　

　　以一網站性能測試爲案例：

　　1. 通過分析運營數據，可以知道當前系統每小時處理的PV數

　　2. 通過負載測試，可以知道系統每小時最大處理的PV數

　　即整理得

　　系統每小時PV處理剩餘量 = 系統每小時最大處理的PV數 — 系統每小時處理的PV數

　　假設該網站用戶負載基本呈線性增長，現有系統用戶數爲70萬，根據運營推廣計劃，1年內該網站發展用戶將達到1000萬，即增長了14倍。即整理得：

　　系統每小時PV處理增加量 = 當前系統每小時處理的PV數 * 14 — 當前系統每小時處理的PV數

　　每天系統負載增加率 = 100% / 365 = 2.74 % （備註：此處將未來系統用戶數達到1000萬的負載定義爲 100% ）

　　系統每天PV處理增加量 = 系統每小時PV處理增加量 * 每天系統負載增加率 * 24

　　所以，我們可以知道在正常負載條件下：

　　系統可支持正常運行天數 = 系統每小時PV處理剩餘量 * 24 / 系統每天PV處理增加量

　　假設該網站後續部署升級天數已知，這樣我們可以知道提前升級的天數：

　　系統可支持正常運行天數 — 部署升級天數。

　　九、 性能測試通過標準

　　1. 所有計劃的測試已經完成。

　　2. 所有計劃收集的性能數據已經獲得。

　　3. 所有性能瓶頸得到改善並達到設計要求。

　　基準測試是基於一定規模的數據量上進行單業務或按實際用戶操作同比例組合業務的測試，目的在於量化響應時間、吞吐率的指標，便於後續比對。

　　方法是做多組不同場景的測試，觀察結果，抽取出幾個關鍵數據做好記彔，用於以後進行性能對比和評價。

　　1.2 性能測試（Performance Testing）

　　通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生產性能要求。

　　特點：

　　（1） 主要目的是驗證系統是否具有系統宣稱的能力。

　　（2） 需要事先了解被測系統的典型場景，並具有確定的性能目標。

　　（3） 要求在已確定的環境下運行。

　　1.3 負載測試（Load Testing）

　　通過在被測系統上不斷增加壓力，直到性能指標，例如“響應時間”超過預定指標或者某種資源使用已經達到飽和狀態。

　　特點：

　　（1） 主要目的是找到系統處理能力的極限。

　　（2） 需要在給定的測試環境下進行，通常也需要考慮被測系統的業務壓力量和典型場景，使得測試結果具有業務上的意義。

　　（3） 一般用來了解系統的性能容量，或是配合性能調優使用。

　　1.4 壓力測試（Stress Testing）

　　測試系統在一定飽和狀態下，例如CPU、內存等在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。

　　特點：

　　（1） 主要目的是檢查系統處於壓力情況下是應用的表現。

　　（2） 一般通過模擬負載等方法，使得系統的資源使用達到較高水平。

　　（3） 一般用於測試系統的穩定性。

　　1.5 配置測試（Configuration Testing）

　　通過對被測系統的軟/硬件環境的調整，瞭解各種不同環境對系統性能影響的程度，從而找到系統各項資源的最優分配原則。

　　特點：

　　（1） 主要目的是瞭解各種不同因素對系統性能影響的程度，從而判斷出最值得進行得調優操作。

　　（2） 一般在對系統性能狀況有初步瞭解後進行。

　　（3） 一般用於性能調優和規劃能力。

　　1.6 併發測試（Concurrency Testing）

　　通過模擬用戶的併發訪問，測試多用戶併發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題。

　　特點：

　　（1） 主要目的是發現系統中可能隱藏的併發訪問時的問題。

　　（2） 主要關注系統可能存在的併發問題，例如系統中的內存泄露、線程鎖和資源爭用方面的問題。

　　（3） 可在在開發的各個階段使用，需要相關的測試工具的配合和支持。

　　1.7 可靠性測試（Reliability Testing）

　　通過給系統加載一定的業務壓力（例如資源在70%~90%的使用率）的情況下，讓應用持續運行一段時間，測試系統在這種條件下是否能穩定運行。

　　特點：

　　（1） 主要目的是驗證系統是否支持長期穩定的運行。

　　（2） 需要在壓力下持續一段時間的運行。

　　（3） 需要關注系統的運行狀況。

　　1.8 失效恢復測試（Failover Testing）

　　針對有冗餘備份和負載均衡的系統設計的，可以用來檢驗如果系統局部發生故障，用戶是否能夠繼續使用系統；以及如果這種情況發生，用戶將受到多大程度的影響。

　　特點：

　　（1） 主要目的是驗證在局部故障情況下，系統能否繼續使用。

　　（2） 還需要指出，當問題發生時“能支持多少用戶訪問”的結論和“採取何種應急措施”的方案。

　　（3） 一般來說，只有對系統持續運行指標有明確要求的系統才需要進行這種類型的測試。

　　2. 性能測試目標

　　概況來說，可分爲4個方面：

　　2.1 能力驗證

　　在系統測試或驗收測試時，我們需要評估系統的能力，衡量系統的性能指標。系統的能力可以是容納的併發用戶數，也可能是系統的吞吐率；系統的性能指標可以是響應時間，也可以選擇 CPU、內存、磁盤、網絡的使用情況。

　　特點：

　　（1） 要求在已確定的環境下進行。

　　（2） 需要根據典型場景設計測試方案和用例。

　　一般採用的方法是：性能測試、壓力測試、可靠性測試、失效恢復測試。

　　2.2 能力規劃

　　評估某系統能否支持未來一段時間內的用戶增長或是應該如何調整系統配置，使得系統能夠滿足增長的用戶數的需要。

　　特點：

　　（1） 屬於一種探索性的測試

　　（2） 可被用來了解系統的性能以及獲得擴展性能的方法，例如系統擴容規劃。系統容量可以是用戶容量，也可能是數據容量，或者是系統的吞吐量（系統的處理能力）。對於集羣服務我們更多的是用吞吐率作爲容量。

　　方法是①先對各子系統、組件進行性能測試，找出它們之間的最優配比；②然後再通過各環節的水平擴展，計算出整體的擴容機器配比。

　　一般採用的方法是：負載測試、壓力測試、配置測試。

　　2.3 性能調優

　　爲了更好的發揮系統的潛能，定位系統的瓶頸，有針對性的進行系統優化。

　　方法是在進行系統調優時，我們需要做好基準測試，用以對比性能數據的變化，並反覆調整系統軟硬件的設置，以使系統發揮最優性能。當然在進行系統優化時，我們會選取關鍵的指標進行優化，返時可能要犧牲其他的性能指標。如目標是優化響應時間，我們可能選取的策略是以空間換時間，以犧牲內存或擴大緩存爲代價，還需要我們在各個性能指標中找到平衡點。

　　一般對系統的調整包括以下3個方面：

　　（1） 硬件環境的調整

　　（2） 系統設置的調整

　　（3） 應用級別的調整

　　一般採用的方法是：基準測試、負載測試、壓力測試、配置測試和失效恢復測試。

　　2.4 發現缺陷

　　和其他測試一樣，性能測試也可以發現缺陷。特別是嚴格併發訪問時是否存在資源爭奪導致的響應時間過慢，或大量用戶訪問時是否導致程序崩潰。

　　方法是設置集合點，實現嚴格併發用戶訪問；或者設置超大規模用戶突發訪問等這樣的性能測試用例進行測試。

　　一般採用的方法是：併發測試。

　　三、 性能需求分析

　　1. 性能需求獲取

　　1.1 功能規格說明書

　　1.2 系統設計文檔

　　1.3 運營計劃

　　1.4 用戶行爲分析記錄

　　2. 性能關鍵點選取

　　主要從以下4個維度進行選取：

　　2.1 業務分析

　　確定被測接口是否屬於關鍵業務接口或先分析出關鍵業務以間接獲取該業務所訪問的接口。

　　2.2 統計分析

　　若接口系統訪問行爲存在日誌分析記錄，則直接獲取日訪問量高的接口；否則根據接口發佈類型，選擇第3方日誌分析工具間接獲取。

　　（1） IIS日誌分析工具：Log Parser 2.2 + Log Parser Lizard GUI

　　下載地址：http://www.lizard-labs.com/log_parser_lizard.aspx

　　（2） Tomcat日誌分析工具：AWStats v7.3

　　下載地址：http://www.awstats.org

　　（3） Nginx日誌分析工具：GoAccess v0.9

　　若IIS或Tomcat等接口應用服務器使用Nginx進行負載，則日誌訪問量要以負載爲準，因避免接口在Nginx設置緩存（即未進行透傳）而導致統計不正確。

　　下載地址：http://www.goaccess.io

　　2.3 技術分析

　　（1） 邏輯實現複雜度高的接口（如判斷分支過多或涉及CPU/IO密集型運算等）

　　（2） 對系統（內存、CPU、磁盤IO）及網絡IO等硬件資源耗用高的接口

　　備註：若接口因邏輯修改而重構，則需重新分析。

　　2.4 運營分析

　　由於運營推廣活動導致日訪問突增高的接口。

　　備註：若運營計劃調整，則需重新分析。

　　3. 性能指標描述

　　3.1 響應時間

　　在一般情況下，弱交互類接口平均響應時間不超過1秒，強交互類接口平均響應時間不超過200毫秒。

　　3.2 成功率

　　在一般情況下，接口響應成功率需達到99.99%以上。

　　3.3 系統資源

　　若爲最佳負載，則系統CPU及內存使用率建議區間[50%，80%]，否則建議不超過50%。

　　3.4 處理能力

　　立項申請書明確要求：在XX壓力下（併發數）TPS需達到XX或 接口系統可支撐XX萬實時在線訪問。

　　3.5 穩定性

　　在實際系統運行壓力情況下，可穩定運行N*24(一般 N >= 7 )小時。 在高於實際系統運行壓力1倍的情況下，可穩定運行12小時。

　　3.6 特性指標

　　例：Java類應用 FullGC 次數 <= 1次/天

　　四、 性能測試範圍

　　1. 業務範圍

　　關鍵業務功能點描述。

　　2. 設計範圍

　　網絡接入層、接口層、中間件、存儲層等被測組件及拓撲結構描述。

　　五、 併發數計算方法

　　做過一些性能測試的童鞋剛開始比較糾結某個或某一類接口的併發數如何計算，其實併發數可以從用戶業務和服務器的2個角度來看。

　　1. 80/X原則

　　適用範圍：無限制

　　以一項目爲案例，母親節當天接口服務器訪問量分佈如下所示，如何計算當天平均併發數和高峯併發數？

　　

　　查看母親節當天UV曲線分佈 與 請求量呈線性關係，如下所示：

　　

　　採用微積分的思想，將每個時間點視爲一個矩形，可以通過求和的方式求出整個分佈圖的面積，如下所示：

　　

　　其實每個矩形的長度均爲1（1小時），故求面積時只需考慮寬度，即考慮每小時請求量即可。

　　根據80/X原則，找出佔據總體面積80%的時間，選擇儘可能大的點計算出佔據總體面積80%的時間，發現點的個數是7，意味着此時間長度佔總時間長度30%，則80/X原則轉換成80/30原則，如下所示：

　

　　故，平均併發數（每秒平均請求數）= 80% * 日請求量 / 1天 * 30%

　　進而計算出最高峯值與平均併發數的倍數 = 2.25

　　故，高峯併發數（每秒高峯請求數）= 2.25 * 平均併發數 =

　　2.25 * 80% * 日請求量 / 1天 * 30% = 6 * 日請求量 / 1天

　　因UV與請求量曲線分佈呈線性關係，日請求量 = 9.25 * 日UV

　　故，高峯併發數 = 6 * 9.25 * 日UV / 1天 = 55.5 * 日UV / 1天

　　2. 公式法

　　適用範圍：Web類訪問

　　公式（1）計算平均併發用戶數：C = n * L / T

　　C是平均的併發用戶數；n是login session的數量；L是login session的平均長度；T指考察的時間段長度。

　　公式（2）計算併發用戶數峯值： C’≈ C+3根號C

　　C’指併發用戶數的峯值，C就是公式（1）中得到的平均的併發用戶數。該公式的得出是假設用戶的login session產生符合泊松分佈而估算得到的。

　　

　　例1：

　　假設有一個OA系統，該系統有3000個用戶，平均每天大約有400個用戶要訪問該系統，對一個典型用戶來說，一天之內用戶從登錄到退出該系統的平均時間爲4小時，在一天的時間內，用戶只在8小時內使用該系統。

　　C = 400 * 4 / 8 = 200

　　C’≈ 200 + 3 * 根號200 = 242

　　爲了更好地理解上述公式，將其轉換爲如下公式：

　　公式（3）併發用戶數 = 吞吐率 * 場景業務時間 / 單位時間段

　　例2：

　　一個OA系統，1小時內有8000用戶登錄系統。用戶每次登錄系統，需啓動登錄頁面，然後輸入用戶名和密碼，進入首頁。一般情況下，用戶在上述操作過程中需耗時5秒，且要求從點擊登錄按鈕到首頁完全展現，需控制在5秒內。

　　分析：

　　吞吐率 = 8000 * 2（整個業務操作需加載2次頁面才能完成）

　　場景業務時間 = 5 + 5 = 10 秒

　　單位時間段 = 1小時 = 3600 秒

　　併發用戶數（登錄場景） = （8000 * 2）* 10 / 3600 = 45

　　通過以上方法得到業務併發數後，我們可以進一步分析業務訪問了哪些接口，我們只要模擬這些接口調用方式和調用時序就行了。

　　有時我們需要計算某一個或某一類接口的併發數，我們可以按如下步驟進行分析計算：

　　（1） 梳理出被測接口被訪問的業務場景和每個業務場景訪問的次數

　　（2） 通過上述方法計算出業務場景的併發用戶數

　　接口併發數 = 場景1 併發用戶數 * 業務場景接口調用次數1 + 場景2併發用戶數 * 接口調用次數2 + …

　　假如一個系統需支撐10萬在線用戶數訪問，如何通過性能需求分析來計算併發用戶數？大家可以通過以上內容學習，獨立思考下？