性能測試一般流程

普通web接口性能測試通用流程

• • 一、測試準備
  • 二、測試分析
  • 三、編寫腳本
  • 四、測試執行
  • 五、問題複現及定位
  • 六、資料分析

根據本人的web接口性能測試的項目經驗，對測試流程進行了大緻劃分，以供諸位同志參考，如有錯誤，可與我讨論，轉載請注明出處。

一、測試準備

1.前置準備

(1)業務邏輯（需求文檔）；
	
	(2)資料流轉，若通過接口測試，還需了解接口規則（設計文檔）；
	
	(3)服務架構，服務運作時所用到的應用伺服器、資料庫伺服器及其他服務（本地與第三方），包括測試環境架構與生産環境架構。
           

2.環境準備

環境準備主要立足在以下兩點已确定的情況下：

(1)測試工具已确定（jmeter或loadrunner）
	
	(2)測試模式已确定，分為場景腳本錄制或編寫（jmeter或loadrunner）或者直接編寫接口腳本（jmeter）。
           

場景形式的壓測保證了測試過程中業務的連貫性以及場景覆寫的全面性，劣勢展現在：

1.編寫或錄制腳本需要更多的工作量，主要展現在請求篩選
	
	2.錄制完成之後仍需對腳本的變量參數進行優化
	
	3.不便于單業務場景拆分測試
           

接口形式的壓測優勢展現在編寫腳本時較為節約時間，能夠較為準确的定位出具體接口存在的問題，但也具有一些缺點：

1.場景覆寫時隻覆寫到主接口，可能會遺漏一些非必要但實際使用時會用到的接口。
	
	2.涉及到複雜業務場景，需要測試人員去進行接口組合。
	
	3.需要前期花費時間去熟悉接口規則。
           

關于環境的準備如下：

(1)安裝測試工具（jmeter與loadrunner），安裝測試過程中會使用到的插件。
	
	(2)擷取服務提供方，應用背景權限。（注意非服務調用方）
	
	(3)擷取資料庫部署裝置的linux背景權限。（不區分調用方與提供方，隻關注資料庫是否被使用）
	
	(4)在擷取的應用服務裝置與資料庫裝置中安裝資源監控工具。（一般為NMON）
	
	(5)生産環境業務量（根據實際情況擷取時間區間）
           

二、測試分析

1.測試環境架構分析

簡單來說，就是根據測試環境與生産環境兩者裝置的比例，來确定測試環境的承載力。
           

2.業務量分析

根據擷取的生産環境業務量與需求所需達到的标準，對需求展現出的負載量進行計算，
	
	根據前置準備時擷取的架構比例，計算出測試環境所要達到的需求負載量（TPS）。
           

3.場景分析

根據需求文檔與已設計完成的系統，來分析測試過程中所需覆寫到的測試點（業務場景）
	
	根據實際情況計算出，如需進行混合場景測試時，各場景的業務占比。
           

4.場景設計

根據已知資訊進行場景設計，設計主體根據壓力情況分為：基準測試、配置測試、壓力測試、穩定性測試。
	
	根據測試方式分為：單接口測試與混合場景測試。
           

三、編寫腳本

這部分可能比較亂，大家友善什麼時候寫就什麼時候寫就好

錄制或者手動編寫測試腳本

以下隻針對于jmeter腳本，loadrunner手工編寫需要C或Java基礎，建議直接錄制。

錄制編寫（場景形式）：

1.通過jmeter自帶http代理或badbody進行錄制，推薦此兩種錄制方法，前者較為便利，後者較為直覺。
	
	2.錄制完成後進行請求篩選，推薦先使用fidder工具，對業務請求進行抓包，根據請求資訊判斷篩選接口。
	
	3.對篩序完成後的腳本進行參數化。
	
	4.為每個請求添加斷言，便于定位問題。
           

手動編寫：

手動編寫分為兩種，一種是已知接口編寫，另一種是場景接口編寫。
	
	已知接口腳本編寫較為簡單，直接根據接口文檔，編寫腳本。（接口形式）
           

場景接口腳本編寫，需要先進行業務場景模拟，使用fidder進行抓包，篩選請求後，進行手動編寫。（場景形式）

四、測試執行

1.基準測試

腳本編寫完成後，先單使用者運作一次，确認腳本無誤。再2-3使用者執行一次，确認參數化資訊無誤。
           

2.并發測試

根據分析所得資訊，進行單接口并發或混合場景并發
           

執行時需要注意以下事項：

(1)需打開應用背景日志，實時檢視是否存在報錯資訊，因為存在一些報錯，斷言無法展現出。
必要時對日志檔案進行cut，找出具體報錯。
	
	(2)保證應用服務與資料庫服務的資源監控已運作（nmon）。
	
	(3)測試過程中如察覺到異常，可以使用top指令檢視服務資源，友善定位問題（必要時打開兩個背景）。
	
	(4)每次并發執行時，盡量保證能對服務做一次重新開機操作，使得測試資料更加真實。--
	
	(5)每次并發執行時，清除nohup.out日志，避免測試過程中日志占滿硬碟。
	
	(6) 每次并發執行時,若存在redis緩存服務，應清除緩存，避免曆史緩存存在對測試結果的影響。
           

3.梯度加壓測試

屬于并發測試的一種，不過能更加貼切的看出來系統性能變化的曲線
           

五、問題複現及定位

測試過程中遇到問題後，如背景報錯、響應時間過長等，我們可以對問題進行複現及定位，可參考以下步驟：

(1)明确出現問題的接口，可利用jmeter斷言，背景日志報錯來定位。
	
	(2)使用測試時遇到問題的配置（線程數、持續時間、疊代此時等）重新執行一次或多次，記錄問題，
若無法複現問題，可先對問題進行記錄。
	
	(3)問題複現後，記錄背景日志，入參資訊，及資料庫資料，若無法自己定位，可交給開發解決。
	
	(4)開發定位完成後，記錄問題原因（需要在報告中展現）。
	
	(5)問題解決後，參照曆史并發量、入參資訊、資料庫資料，重新執行一次。
	
	(6)若問題未解決，則重新與開發溝通。
	
	(7)若問題已解決，可參考曆史資料，驗證與問題接口類似的接口是否也存在此問題。
           

六、資料分析

計劃場景測試完成後，需要對所得資料進行分析，分析資料時，要注意以下幾點：

(1)資料對應，在測試過程中除了jmeter報告，可能還需要對服務資源監控，資料庫資源監控、redis服務監控、
drools-web服務等進行監控，是以，整理資料時，一定要保證各種類資料都要一一對應，這是分析的前提。
	
	(2)資訊歸納，分析資訊前，可以對所有資訊進行分類彙總，選取标志性資訊，歸納進excel表格中，
這樣可以更清楚明了的看出一個接口各并發量的差異。
           

常見問題分析思路:

1.曲線分析

利用加壓過程中響應曲線（響應時間、tps等）與資源消耗曲線（資料庫與應用服務cpu、記憶體等）進行對照，
尋找性能變化拐點，利用曲線可以清晰的看出是因為某方面的資源消耗使得響應曲線出現拐點，之後再去關注拐點附近的性能表現。
           

2.縱向資料分析

根據測試方案設計的并發量，首先統計各并發量階段的綜合資料，其次根據統計的資料情況，計算業務每個區間名額的跨度，
以混合場景測試的響應時間為例，若跨度按并發量表現為100ms、300ms、700ms、1500ms、2530ms，此時應關注500ms-700ms區間，
場景内各接口的表現情況，此時并發量均衡增加但響應時間未按照合理比例上升，可以去檢視此區間各系統的資源消耗情況，
可以較為容易的定位問題。
           

3.硬體分析

1.應用出現缺陷與瓶頸時，首先應考慮負載及的硬體資源是否達到上限，并發時檢查記憶體與cpu是否達到負載上限，
排除因為負載機的原因而産生僞性能問題的狀況。
	2.其次，檢視網絡情況，測試帶寬是否處于正常水準。、
	3.之後才需考慮應用伺服器，資料庫以及sql等原因。
           

4.sql分析與定位

在某一接口響應過慢或頻繁報錯的情況下，我們測試人員可以幫助開發人員定位問題，如sql問題
	定位時需要一定的操作linux系統的經驗，一般情況下，接口的入參與出參都會在背景日志中展現，先對接口進行定位，
定位完成後在日志中查找可參考linux操作文檔進行定位。
           

5.配置類問題

當問題顯現後，除了因為應用代碼缺陷而産生性能問題之外，配置問題也是我們需要關注的問題:
	如資料庫連接配接數是否足夠，swap記憶體配置設定是否合理，應用記憶體配置設定是否合理等。
           

有些地方可能寫的有些欠缺考慮，有些地方缺少了一些長篇大論，但是加上的話有些繁瑣，後面再一一解釋，這個隻能作為一個web接口性能測試一般流程的參考。如有大佬指點，感激不盡。