接口性能測試方案

1、 性能測試術語解釋 
1. 響應時間 
響應時間即從應用系統發出請求開始，到客戶端接收到最後一個字節數據爲止所消耗的時間。響應時間按軟件的特色再能夠細分，如對於一個 C/S 軟件的響應時間能夠細分爲網絡傳輸時間、應用服務器處理時間、數據庫服務器處理時間。另外客戶端自身也存在着解析時間、界面繪製呈現時間等。 
 
響應時間主要站在客戶端角度來看的一個性能指標，它是用戶最關心、而且容易感知到的一個性能指標。 
2. 吞吐率 
吞吐率指單位時間內系統處理用戶的請求數，從業務角度看，吞吐率能夠用每秒請求數、每秒事務數、每秒頁面數、每秒查詢數等單位來衡量。從網絡角度看，吞吐率也能夠用每秒字節數來衡量。 
吞吐率主要站在服務端的角度來看的一個性能指標，它能夠衡量整個系統的處理能力。對於集羣或者雲平臺來講，吞吐率指標反映的是服務器集羣對外總體可以承受的壓力，該指標比用戶數更容易對比。 
備註：吞吐量 = 吞吐率 * 單位時間 
3. 用戶數 
對於服務器集羣或者雲平臺，幾乎都是多用戶系統，系統能提供給多少用戶正常使用，也是一個很是重要的度量指標。咱們把這些用戶按照使用系統的時機不一樣，作以下區分。 
系統用戶數（System Users）：指系統可以存儲的用戶量。 
在線用戶數（Online Users）：指用戶經過身份確認後，處於能正常使用狀態的用戶個數。 
併發用戶數（Concurrent users）：指在某個時間範圍內，同時正在使用系統的用戶個數。 
嚴格併發用戶數（Strictly the number of concurrent users）：指同一時刻都操做某個業務的用戶數。 
在性能測試過程當中，咱們要去模擬實際用戶來發請求。可是爲了吐服務器產生更大的壓力，咱們模擬的用戶操做和實際的用戶操做存在必定的差別（好比模擬的用戶請求比實際用戶的請求更頻繁），並且返種模擬的用戶數和實際的用戶數也難以相互換算。因此在度量服務器集羣能力時，吞吐率指標比用戶數指標更實用。 
2、 性能測試方法及目標 
1. 性能測試方法 
1.1 基準測試（Benchmark Testing） 
基準測試是基於必定規模的數據量上進行單業務或按實際用戶操做同比例組合業務的測試，目的在於量化響應時間、吞吐率的指標，便於後續比對。 
方法是作多組不一樣場景的測試，觀察結果，抽取出幾個關鍵數據作好記彔，用於之後進行性能對比和評價。 
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 發現缺陷 
和其餘測試同樣，性能測試也能夠發現缺陷。特別是嚴格併發訪問時是否存在資源爭奪致使的響應時間過慢，或大量用戶訪問時是否致使程序崩潰。 
方法是設置集合點，實現嚴格併發用戶訪問；或者設置超大規模用戶突發訪問等這樣的性能測試用例進行測試。 
通常採用的方法是：併發測試。 
3、 性能需求分析 
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次/天

4、 性能測試範圍 
1. 業務範圍 
關鍵業務功能點描述。 
2. 設計範圍 
網絡接入層、接口層、中間件、存儲層等被測組件及拓撲結構描述。 
5、 併發數計算方法 
作過一些性能測試的童鞋剛開始比較糾結某個或某一類接口的併發數如何計算，其實併發數能夠從用戶業務和服務器的2個角度來看。 
1. 80/X原則 
適用範圍：無限制 
以一項目爲案例，母親節當天接口服務器訪問量分佈以下所示，如何計算當天平均併發數和高峯併發數？ 
 
經過百度統計平臺 http://tongji.baidu.com/ 查看母親節當天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萬在線用戶數訪問，如何經過性能需求分析來計算併發用戶數？你們能夠經過以上內容學習，獨立思考下？

6、 性能測試用例與場景

1. 腳本模板 
   　 　 　 　 　
2. 場景模板 
   　

7、 性能測試工具選擇 
1. 數據建模工具 
DataFactory是一種強大的數據產生器，它容許開發人員和QA很容易產生百萬行有意義的正確的測試數據庫,該工具支持DB二、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等，以下所示： 

8、 性能測試結果分析 
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處理增長量

假設該網站後續部署升級天數已知，這樣咱們能夠知道提早升級的天數：

系統可支持正常運行天數 — 部署升級天數。 9、 性能測試經過標準 1. 全部計劃的測試已經完成。 2. 全部計劃收集的性能數據已經得到。 3. 全部性能瓶頸獲得改善並達到設計要求。