一、效能基礎
什麼是效能測試--->本質?
基於協議來模擬使用者傳送的請求（業務模擬），對伺服器形成一定負載。
關注點：時間效能、空間效能
與介面無關
效能測試分類
-
效能測試（狹義）
效能測試方法是通過模擬生產環境執行的業務壓力量和使用場景組合，測試系統效能是否滿足生產效能要求。通俗地講，這種方法就是要在特定的執行條件下來驗證系統能力狀態。
-
負載測試
通過在被測系統上進行不斷加壓，直到效能指標達到極限，例如“響應時間”超過了預定指標或都某種資源已經達到了飽和狀態。
-
壓力測試（強度測試）
壓力測試方法，測試系統在一定飽和狀態下，例如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工具使用
檔案目錄介紹
1.1 bin目錄
存放可執行檔案和配置檔案
jmeter.bat:windows的啟動檔案
jmeter.log：日誌檔案
jmeter.sh：linux的啟動檔案
jmeter-properties：系統配置檔案
jmeter-server.bat：windows分散式測試要用到的伺服器配置
jmeter-server：linux分散式測試要用到的伺服器配置
1.2 docs目錄
docs：是Jmeter的api文件，可開啟api/index.html頁面來檢視
1.3 printable_docs目錄
printable_docs的usermanual子目錄下的內容是Jmeter的使用者手冊文件。
usermanual下component_reference.html是最常用到的核心元件幫助文件。
提示：printable_docs的demos子目錄下有些常用Jmeter指令碼案例，可以參考。
1.4 lib目錄
該目錄用來存放Jmeter依賴的jar包和使用者擴充套件所依賴的jar包。
基礎配置
漢化設定
-
臨時修改：
options--->language--->choose language--->Chinese
-
永久修改：
-
開啟jmeter.properties
-
修改language=zh_CN
-
重啟jmeter
-
主題修改
選項--->主題--->選擇對應的主題，重啟jmeter
基本操作
- 啟動jmeter
- 新增執行緒組
- 新增http請求的取樣器，並配置
- 新增查詢結果樹的監聽器
- 點選"啟動"執行jmeter，並檢視結果
基本元件
執行緒組：模擬使用者的。
配置元件：進行測試環境和測試資料初始化--->比如自動化指令碼中setup
前置處理器：對要傳送請求進行預處理--->比如自動化指令碼中引數化
取樣器：往伺服器傳送請求--->比如自動化指令碼中發請求的程式碼
後置處理器：對收到伺服器的響應進行資料提取--->比如自動化指令碼中獲取響應中特定欄位語句
斷言：將收到響應結果又預期結果做對比--->比如自動化指令碼中斷言
監聽器：檢視測試指令碼執行後結果和日誌--->比如自動化指令碼中測試報告
定時器：等待一段時間--->比如自動化指令碼中sleep
測試片段：封裝基本功能，不單獨執行，需要通過指令碼的呼叫才能執行--->比如自動化指令碼中封裝函式
作用域
核心：根據測試計劃中的樹形結構的父子節點來確定的
原則：
- 取樣器是沒有作用域的。
- 邏輯控制器：只對其子節點下的所有元件有效。
- 其他的元件。
- 如果其父節點是取樣器，則只對父節點取樣器有效。
- 如果其父節點不是取樣器，對父節點下所有子節點及節點中子節點有效。
元件的執行順序
順序：配置元件--->前置處理器--->定時器--->取樣器--->後置處理器--->斷言--->監聽器
注意:
- 配置元件、前置處理器、後置處理器都需要依賴取樣器才能執行
- 在同一個作用域下，相同型別元件執行順序是從上到下來按順序執行
Jemter重要的三個元件
執行緒組
作用：通過配置執行緒組中的執行緒數來模擬使用者。執行緒數就是使用者數，執行緒組是使用者組
特點：
- 模擬多使用者
- 取樣器和邏輯控制器必須線上程組下使用
- 一個測試計劃下可以新增多個執行緒組，可以並行或序列執行
- 並行：預設情況下執行緒組為並行執行
- 序列：在測試計劃下勾上"獨立執行每個執行緒組"
執行緒組的分類：
- setup執行緒組：擁有測試前預處理操作，在所有執行緒組中最先執行
- 普通執行緒組：來執行業務測試指令碼
- teardown執行緒組：用來測試後的後置處理（資料、恢復環境）的操作，在所有的執行緒組中最後執行
執行緒組的屬性
執行緒數：模擬虛擬使用者數
Ramp-up時間：虛擬使用者啟動所需要的時間
迴圈次數：
- 配置指定次數：控制指令碼執行執行的次數
- 配置迴圈永遠
- 需要排程器配置使用
- 執行時間：指令碼執行的時間
- 延遲啟動時間：指令碼等待特定的時間才能開始執行
http請求
http協議：可以填寫為HTTP或者HTTPS，預設不填寫為HTTP協議
http主機名/ip：如：http://baidu.com 80
埠：可以填寫為任意值。預設不填寫時為80埠
請求發方法：HTTP協議所有支援的所有方法
路徑：目錄+引數
編碼格式：預設IOS國際標準，推薦使用utf-8
檢視結果樹
取樣器結果：統計請求相關的資訊
請求：HTTP請求的請求頭和請求體的詳情資訊
響應：HTTP響應的響應頭和響應體的詳情資訊
jmeter響應中出現亂碼時：
- 修改jmeter.properties檔案中，sampleresult.default.encoding=utf-8
- 重啟jmeter
Jmeter引數化常用方式
使用者定義的變數
- 方式1：
新增：執行緒組--->配置元件--->使用者自定義變數
配置：引數名+引數值
使用：在HTTP請求的取樣器中引用定義變數。$(引數名)
- 方式2：
配置：在測試計劃中去配置使用者定義變數
使用：在HTTP請求的取樣器中引用定義變數。$(引數名)
應用場景：當大量指令碼中的引數值需要修改時候，直接修改使用者定義變數中值會更方便
使用者引數
新增：執行緒組--->前置處理器--->使用者引數
配置：
- 引數：新增變數
- 引數值：新增使用者--->針對每個使用者配置不同的引數值
使用：在HTTP請求的取樣器中引用定義的變數。$(引數名)
應用場景：可以針對不同的使用者獲取到不同的引數值
CSV Data Set Config
新增：執行緒組--->配置元件--->CSV資料檔案設定
編寫CSV資料檔案（.csv作為字尾）：
- 多個引數寫為多列，其中用逗號分隔
- 多組引數值，則使用多行來設定
配置：
- 路徑
- 檔案編碼：UTF-8
- 變數名稱：從CSV資料檔案中讀取的資料需要儲存變數名。有多個變數時用逗號分隔
- 是否忽略首行：是否從CSV檔案第一行中開始讀取
- 分隔符：要求與CSV資料檔案中多列的分隔符一致
- 遇到檔案結束符是否再次迴圈：預設TRUE
- 遇到檔案結束符是否停止執行緒：當前一個引數為FALSE，該引數有效，一般設定為TRUE
函式
counter：
- TRUE：每個使用者使用獨立計數器
- FALSE：所有的使用者使用全域性計數器
引用：在取樣器中使用$(__counter(FALSE,))來引用對應值
建議大家使用函式方式
Jmeter斷言
作用：讓指令碼自動化執行過程中，能夠自動判定執行結果是否符合要求時候，需要新增斷言
響應斷言
新增：執行緒組--->HTTP請求--->斷言--->響應斷言
配置：
- 測試欄位：需要檢查的欄位
- 模式匹配規則：需要使用什麼規則來進行檢查
- 測試模式：需要校驗的值
Json斷言
適用於返回的HTTP響應為JSON格式
新增：執行緒組--->HTTP請求--->斷言--->JSON斷言
配置：
- JSON PATH：$.weatherinfo.city
- 勾選"Addltonal assert value"
- 在expected value裡填寫期望值
斷言持續時間：
適用於效能測試時，檢查HTTP請求的響應時間是否超過預期值
新增：執行緒組--->HTTP請求--->斷言--->斷言持續時間
配置：預期時間
Jmeter關聯（提取器、資料庫、邏輯控制器等）
當多個請求之間有依賴關係，後一個請求的引數需要使用前一個請求的響應資料時，需要用到關聯。
分類：
- 正規表示式提取器
- xpath提取器
- Json提取器
提取器
正則提取器
新增：執行緒組--->HTTP請求--->後置處理器--->正規表示式提取器
配置：
- 要檢查的響應欄位：預設主體
- 引用名稱：匹配後的資料要儲存的變數名
- 正規表示式：
<p>(.*?)</p>，"()"裡是要儲存的資料 - 模板：$1$
- 資料1代表上面正規表示式中第幾個()
- 匹配數字：0代表隨機值、1代表第一個結果，-1代表所有結果
- 預設值：當沒有匹配上時將該值儲存到變數裡
xpath提取器
新增：執行緒組--->HTTP請求--->後置處理器--->xpath提取器
配置：
- 引用名稱：匹配後的資料要儲存的變數名
- xpath path：xpath匹配規則
- 匹配數字：0代表隨機值、1代表第一個結果，-1代表所有結果
- 預設值：當沒有匹配上時將該值儲存到變數裡
json提取器
新增：執行緒組--->HTTP請求--->後置處理器--->json提取器
配置：
- 引用名稱：匹配後的資料要儲存的變數名
- json path：json路徑。$.weatherinfo.city
引用：直接引用變數名即可
資料庫
連線準備：
- 開啟資料庫，確定資料庫的表及對應的欄位
- 載入mysql的jdbc驅動
- 方法一：將jdbc驅動通過測試計劃，瀏覽的方式新增
- 方式二：將jdbc驅動jar包放入到lib\ext目錄下，並重啟jmeter
- 配置jdbc connection configuration
- created pool name：給連線池命名，用於後續引用
- 資料庫URL：jdbc:mysql://127.0.0.1:3306/test
- 使用者名稱
- 密碼
直連資料庫使用：
- 新增JDBC Request：取樣器下新增
- 配置：
- 配置連線池名稱
- 配置SQL語句
- 配置儲存的變數名
- 如果SQL語句返回了多個引數，輸入相同個數的變數名來儲存
- HTTP斷言中，就可以引用變數來進行判斷
邏輯控制器
控制元件的執行順序
if控制器
新增：執行緒組--->邏輯控制器--->if控制器
配置：
- 使用JS預發："${name}"=="baidu"
- 使用jmeter函式的方式：${__jexl3("${name}"=="baidu",)}
- 推薦使用函式的方式
迴圈控制器
指定HTTP請求執行特定的次數
新增：執行緒組--->邏輯控制器--->迴圈控制器
配置：次數
迴圈控制器中的迴圈次數配置m與執行緒組中的迴圈次數n配置對比：
- 關係：如果同時配置，迴圈控制器下HTTP請求實際執行的次數應該是n*m
- 區別：這兩個迴圈次數作用域不同
ForEach控制器
與使用者定義的變數或正規表示式提取器配合使用，迴圈讀取返回的變數值，執行一次或多次。
-
與使用者定義的變數配合
新增：執行緒組--->邏輯控制器--->ForEach控制器
配置：
-
使用者定義的變數
- 變數名：固定字首+連續數字
-
ForEach控制器
- 變數字首：使用者定義的變數中配置的固定字首
- 起始數字：連續數字的最小值-1
- 結束數字：連續數字的最大值
- 輸出變數名稱：依次讀取變數值後儲存到引數中，共HTTP請求來引用
-
HTTP請求：
- 引用輸出的變數名稱
-
-
與正規表示式配合使用
- 先通過正規表示式提取器，提取出請求中所有滿足條件資料
- 新增ForEach控制器，並配置提取所有滿足條件的資料，並儲存為變數
- 在其子節點下，新增HTTP請求並引用變數，可迴圈讀取正規表示式裡匹配的所有資料
定時器
同步定時器
需要進行大量使用者的併發測試時，為了讓使用者能真正同時執行，新增"同步定時器"使其阻塞執行緒，直到執行緒達到了預先設定數值，才開始進行取樣器操作。
配置：
-
併發數：同時達到多少使用者才開始發請求
-
超時時間：
- 必須配置：否則當虛擬使用者數無法被併發數整除時，會導致有部分使用者掛起無法執行
- 配置不能太短：必須比並發數載入時間要長。否則無法達到併發數的要求，資料就會被釋放掉
常數吞吐量定時器
用於效能測試中模擬使用者產生業務壓力，通過給定QPS來對伺服器傳送固定頻率要求。
新增：執行緒組--->HTTP取樣器--->常數吞吐量定時器
配置：吞吐量的值QPS*60
分散式
原理：
- 分散式測試時分為一臺控制機和多臺代理機
- 控制機負責釋出測試任務給代理機
- 代理機接收任務並向伺服器傳送請求，並接收伺服器返回的響應，然後將測試結果返回給控制機
- 由控制機對測試結果資料進行彙總統計
分散式相關注意事項：
- 所有的測試機防火牆都已經關閉
- 所有的測試機及伺服器在同一個網路內
- 所有的測試機的jmeter版本和JDK版本完全相同
- 關閉jmeter裡的RMI SSL開關
分散式配置
配置
- 代理機
- server_port：不重複。如果使用多個機器做代理機，可不用配置
- 關閉RMI SSL
- 控制機
- remote_server：所有代理機的IP+port，有多個代理機時要使用逗號分隔
- 關閉RMI SSL
執行
- 代理機
- jmeter-server.bat執行
- 控制機：
- jmeter.bat執行
- 控制代理機執行指令碼，執行--->遠端啟動所有
效能測試常用術語解釋
效能測試，有些專業術語，為了方便大家的理解，這裡用通俗易懂的語言來解釋下，若有不準地方，謝謝糾正。
併發：tps
執行緒數：跑道中參加賽跑的人數
迭代：每人跑多少圈
迴圈：一次迭代裡面，迴圈跑其中的一條指令碼，就是重複來回跑其中一條跑道
引數值：發請求時用的資料
引數化：這是一種策略，上面有介紹到它的具體用法
思考時間：模擬使用者等待時間
關聯：下一個請求入參依賴上一個請求中的某個返回值
檢查點：判斷請求的是否成功，一般只有查詢請求才會加檢查點，也就是斷言
集合點：等待所有使用者，同一時刻去發起請求，主要應用場景是購物中的秒殺
事務：一般把被測試中某個或者某幾個請求一起定義成一個事務，是人為的測試定義，可以是整個下單流程，也可以是下單中的一個請求
負載：伺服器的繁忙程度，如果一個伺服器，每次可以同時處理8個請求，如果請求數量大，後面請求就排隊，排隊請求越多，伺服器負載就越高
平均響應時間（art）：每個事務處理時間，從傳送請求到接收到的響應
tps：每秒處理事務數
每秒點選率（數）：每秒處理請求數，而不是使用者每秒傳送請求數
效能學習路線:
jmeter→java基礎→beanshell→架構知識→linux分析調優→各種中介軟體等定位調優