一、性能基礎
什么是性能測試--->本質?
基於協議來模擬用戶發送的請求（業務模擬），對服務器形成一定負載。
關注點：時間性能、空間性能
與界面無關
性能測試分類
-
性能測試（狹義）
性能測試方法是通過模擬生產環境運行的業務壓力量和使用場景組合，測試系統性能是否滿足生產性能要求。通俗地講，這種方法就是要在特定的運行條件下來驗證系統能力狀態。
-
負載測試
通過在被測系統上進行不斷加壓，直到性能指標達到極限，例如“響應時間”超過了預定指標或都某種資源已經達到了飽和狀態。
-
壓力測試（強度測試）
壓力測試方法，測試系統在一定飽和狀態下，例如cpu、內存在飽和使用情況下，系統能夠處理的會話能力，及系統是否會出現錯誤。
-
並發測試
並發測試方法通過模擬用戶並發的訪問，測試多用戶並發訪問同一應用、同一模塊或數據記錄時，是否死鎖或其他性能問題。
-
配置測試
配置測試方法通過對被測系統軟\硬件環境調整，了解各種不同對系統性能影響程度，找到系統各項資源最優分配原則。
-
可靠性測試
在給系統加載一定業務壓力情況下，使系統運行一定時間，來檢測系統是否穩定。
常見的性能測試指標
-
用戶數
並發用戶數在同一時間向服務器發送請求的用戶數量
與每秒的並發請求數不同，一定要確認需求的目的是並發用戶數還是並發請求數 -
吞吐量（Throughput）
說明：單位時間內處理客戶端請求數量，直接體現軟件系統性能承載能力。
通常情況下，吞吐量用"請求數/秒"或"頁面數/秒"來衡量。
提示：
1.從業務角度看，吞吐量可以用"業務數/小時"、"訪問人數/天"、"業務數/天"，"業務訪問量/天"去衡量。
2.從網絡角度看，還可以用"字節數/天"、"字節數/小時"等來衡量網絡流量。
3.每秒事務數（TPS）、每秒查詢數（QPS）都歸屬吞吐量，區別是TPS\QPS描述服務器具體性能處理的能力。
-
並發數
說明：並發測試的用戶數
擴展：
並發用戶數：某一物理時刻同時向系統發送請求的用戶數。
在線用戶數：某段時間內訪問系統的用戶數，這些用戶不一定都是同時向系統來提交請求。
系統用戶數：系統注冊的總用戶數據。
-
響應時間
說明：用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回結果整個過程中所消耗的時間。
-
點擊數
說明：衡量web服務器處理能力的重要指標。
提示：
1.點擊數並不是大家認為的訪問一個頁面就是1個點擊數，點擊數是頁面中包含的元素（如：圖片、鏈接等）向web服務器發出請求數數量。
2.通常會用每秒點擊次數（Hits per Second）指標來衡量web服務器的處理能力。
注意：
只有web項目才有指標。
-
資源利用率
說明：指系統各種資源的使用情況，使用率=已使用的資源/全部的資源x100%
常見的資源使用率指標：
CPU，不超過80%
內存，不超過80%
磁盤，不高於90%
網絡，不超過80%
如果資源利用率太小，也是造成資源浪費
-
錯誤率
說明：指系統各個資源的使用情況，一般使用"資源的使用量/總的資源可用量x100%"生成資源利用率的數據。
提示：通常，沒有什么特殊需求的話
1.不同系統對錯誤率要求不同，但一般不超過千分之五---（根據實際項目而定萬分之五等等）。
2.穩定性較好的系統，其錯誤率應該是由超時引起的---超時率。
-
TPS（Transactions Per Second）
說明：每秒的事務數（單位時間內系統處理客戶端請求事務次數）
計算：tps=並發數/平均響應時間
事務：業務站在代碼角度的統稱，可以理解為一段或多段代碼。
提示：TPS歸屬吞吐量
-
QPS（Query Per Second）
說明：每秒查詢數（衡量web服務器處理能力的一個重要指標）
應用：控制服務器每秒處理指定請求數（如：控制服務器達到每秒60qps，服務器的性能各項性能指標是否正常）。
二、性能測試流程
流程圖
需求分析
-
測試對象
-
常用的
-
核心的，重要的
-
數據量、並發量
-
例子：
注冊、登錄、搜索、添加購物車、下訂單、支付
-
-
確定性能指標
-
吞吐量、TPS
服務器每秒處理的請求數量 -
響應時間
從瀏覽器發出請求，服務器處理，到收到響應所需要的處理時間
-
用戶數
-
資源利用率
-
例子：
例子一：要求每天完成交易額2億,求每秒鍾最大交易數？ 客單價:200-500,以300計算 采用28定律換算得出，以24小時計算 2/8原則：80%的用戶請求，集中在20%的熱點數據上，或時間段 計算公式：(200000000/300*0.8)/(24/0.2)/3600s=30.86個/s例子二:每天8小時系統支付500萬用戶訪問 1.500萬在8小時內完成，500萬/8*3600，一般不采用，除非系統負載比較平穩/平均 2.先分析流量分布，再根據2/8定律估算每秒請求 80%的用戶數：500*0.8=400w 20%的時間內：8*0.2=1.6h 計算得出服務器需要支持694次/s--->500*0.8/(8*0.2)/3600s 每小時的平均負載*4（估算，不建議此計算） -
-
測試場景
-
單一場景
登錄
注冊
搜索
添加購物車
下單、支付
-
混合場景
用戶使用場景
系統使用場景
-
測試計划
-
測試目標
-
測試人員組織
-
壓測進度安排
-
壓力機
- 配置
- 要求
- 數量
-
風險
測試方案
-
測試工具
loadrunner
jmeter
-
測試環境
數據庫
服務器
架構設計
有條件的情況下盡量和生產環境一致
-
測試策略
單一場景
混合場景 -
監控工具
- Linux
nmon
rpc
jvisualVm
Spotlight - windows
Spotlight
perfmon.exe
- Linux
用例設計
-
測試腳本
基於腳本的用例 -
場景設計
基於場景的用例
測試執行
-
腳本編寫
-
場景監控設計
業務設計-
場景搭建
說明：測試場景設計重要的原則就是依據測試用例，把用例設計場景進行展現出來。
提示： 1.虛擬用戶數量及啟動虛擬用戶方式 2.場景相關的設置（如：集合點） 3.腳本是否有依賴關系（如：登錄與注冊）
-
-
運行場景
說明：運行腳本就是運行場景
1.負載的測試機不能夠運行設定的虛擬用戶數 2.沒有"預熱"過程 3.沒有模擬用戶的真實環境 4.性能用例運行次數過少 -
監控場景
-
測試報告
定位分析問題
- 后端
- 代碼
- 軟件（服務）
數據庫
應用服務器 - 硬件
- 前端
- 網絡
測試定位問題順序：硬件問題--->網絡問題--->應用服務器、數據庫服務器配置問題--->源代碼、數據庫腳本--->系統架構問題
性能調優
性能測試人員經過對測試結果的對比，發現系統性能的瓶頸。
提示：
1.調優人員：以開發為主導，數據庫管理員、系統管理員、網絡管理員、性能測試分析人員配合進行性能問題的調優
2.驗證：性能測試驗證通常需要很多輪；每輪回歸時需要對所有的測試指標進行全方位的對比
系統調優由易到難的順序：
- 硬件問題
- 網絡問題
- 應用服務器、數據庫服務器配置問題
- 源代碼、數據庫腳本
- 系統架構問題
測試報告
-
對整體性能測試階段的回顧（覆蓋需求、測試不同階段的進度和產物、性能測試結果的分析）--->技術角度
-
對整體性能測試階段風險的管理--->管理的角度
-
對項目性能測試結果的總結（是否通過，經驗、教訓）
三、工具介紹及選型
LoadRunner
- 工業化的性能測試工具，能支持大量用戶，提供詳細的報表來提供測試分析的數量
- 支持的協議多
- 使用C語言來編寫的
優點
1.支持用戶量大（以萬為單位）
2.提供精確的報表
3.支持ip欺騙
缺點
1.收費
2.體積大
3.無法定制
Jmeter
jmeter是Apache組織基於java開發的一款性能測試軟件。多協議（HTTP/HTTPS、JDBC、JAVA...等等)
優點
1.開源免費
2.體積小
3.有豐富的第三方插件
缺點
1.不支持ip欺騙
2.報表的精度比LR要差
LoadRunner與Jmeter之間該如何選擇？
- 優選選擇Jmeter
- Jmeter能解決用Jmeter，Jmeter解決不了的用LoadRunner
四、Jmeter工具使用
先來學習下工具使用：
【測試基礎】jmeter工具介紹及使用：https://www.cnblogs.com/upstudy/p/15962793.html
五、性能測試常用術語解釋
性能測試，有些專業術語，為了方便大家的理解，這里用通俗易懂的語言來解釋下，若有不准地方，謝謝糾正。
並發：tps
線程數：跑道中參加賽跑的人數
迭代：每人跑多少圈
循環：一次迭代里面，循環跑其中的一條腳本，就是重復來回跑其中一條跑道
參數值：發請求時用的數據
參數化：這是一種策略，上面有介紹到它的具體用法
思考時間：模擬用戶等待時間
關聯：下一個請求入參依賴上一個請求中的某個返回值
檢查點：判斷請求的是否成功，一般只有查詢請求才會加檢查點，也就是斷言
集合點：等待所有用戶，同一時刻去發起請求，主要應用場景是購物中的秒殺
事務：一般把被測試中某個或者某幾個請求一起定義成一個事務，是人為的測試定義，可以是整個下單流程，也可以是下單中的一個請求
負載：服務器的繁忙程度，如果一個服務器，每次可以同時處理8個請求，如果請求數量大，后面請求就排隊，排隊請求越多，服務器負載就越高
平均響應時間（art）：每個事務處理時間，從發送請求到接收到的響應
tps：每秒處理事務數
每秒點擊率（數）：每秒處理請求數，而不是用戶每秒發送請求數
六、性能學習路線:
jmeter→java基礎→beanshell→架構知識→linux分析調優→各種中間件等定位調優