1.併發使用者數
就是模擬每秒多少人同時作業系統，當前，未來三年，極大值【卡死，但只要停掉系統就可恢復】
2.高峰週期
在哪個時間段訪問系統使用者數量最多（與專案團隊評估）
3.場景
正確使用場景，模擬使用者真實操作，每個測試場景就是乙個用例
4.協議和請求
效能測試都是走協議的，建立http請求，用fidder抓包，將指令碼匯入jmeter
5.為了場景正確，要關聯和引數化
6.事務控制器
把請求結合到一起，看響應時間
7.事物成功率
看錯誤率和新增斷言
8.彙總報告和聚合報告
（看平均事物響應時間，90%響應時間（90%的使用者同時操作的響應時間），錯誤率（低於0.01%）），彙總報告看平均時間，與聚合報告內容有點不同，沒有90%、95%、99%等響應時間
9.nmon資源監控
a.在linux系統下操作，主要看cpu，不能長時間超過90%，短時間都行（低於85%），就算可以
b.看記憶體空閒，跑程式時還剩多少記憶體，一般剩個10%勉強接受，跑完程式會釋放，如果沒釋放叫記憶體洩露，有新的請求過來，檢視記憶體，記憶體越來越少，直到崩掉，證明記憶體洩露了
c.看磁碟io，有讀有寫就行，過程中有空閒就行
d.網路低於50%，占用的網路低於50%就還可以
1.併發使用者數
每秒多少人同時作業系統
就是當前時間訪問系統的使用者數
3.系統使用者數
系統註冊使用者數，說大一點就是訪問過系統的使用者數
4.效能測試
以效能預期目標為前提，對系統不斷增加壓力，驗證系統是否能正確處理
5.負載測試
不斷增加壓力，在不同負載使用者數量下，驗證系統是否正確，一般為當前負載數量，後一年的負載數量（老闆告知預計增長使用者數量百分比）及未來負載
6.壓力測試
在系統超過預期負載時，能頂住的最大壓力
7.併發測試
模擬使用者同時進行操作，jmeter中要做到絕對併發，新增乙個同步定時器（例如秒殺）
8.穩定性測試
模擬多個使用者同時作業系統，檢視異常率，異常率越低，穩定性越強
9.可靠性測試
使用者同時作業系統，加長jmeter中線程組的持續時間，檢視不引起系統失效的概率
10.響應時間
使用者傳送請求到伺服器返回結果的整個過程的時間
11.事務成功率
如果事物失敗，返回的響應時間是假的，沒意義，所以需要在請求下新增斷言，保證事務正確，一般異常率不超過0.01%
12.tps每秒事務數
伺服器每秒鐘處理的事務個數
13.hps每秒點選數
每秒請求的數量
14.效能測試模型
可以理解為不同的用例，也就是不同的使用場景
15.加壓方式
可以理解為執行緒數，ramp-up及持續時間的不同組合方式
16.拐點、瓶頸
拐點就是效能報告圖表中的資料突然上公升、下降或趨於平穩的點，可以利用拐點來做測試分析和定位
瓶頸就是限制系統效能的關鍵因素，通過監控器檢視導致使用場景響應時間增加的有問題的區域
17.吞吐量
伺服器每秒處理請求的個數，一般可看出是否有網路瓶頸問題
1.併發使用者數如何獲取（也就是效能需求分析如何做）
2.效能測試場景如何模擬（抓包和使用jmeter錄製指令碼）
3.結果檢查和效能問題分析
就是根據效能需求文件，在jmeter中錄製指令碼，設定測試場景，為了保證場景正確，需要做關聯和引數化，不同的併發數測試場景就是乙個用例，比如負載測試，一般採用階梯式的併發數，當前所支援的併發使用者數，三年後可支援的併發數，那這兩個就都是效能測試用例，或者組合場景，使用者做不同操作，設定測試場景併發數，執行指令碼，這也是乙個用例
1.做什麼？（測試內容說明，測試的環境說明）
2.需求是什麼？（併發使用者數的計算過程）
3.場景說明：（jmeter中多種不同的設定會產生多種不同的測試方法，相當於效能測試的測試用例）
5.用例（就是把jmeter中的操作全部結合起來，就是用例）
active threads over time：隨時間變化的活動執行緒
bytes throughput over time：隨時間變化的位元組吞吐量
connect times over time：連線時間隨時間變化
hits per second：達到每秒、每秒點選次數
response codes per second：每秒響應碼
response latencies over time：響應延遲時間
response times over time：響應時間
transactions per second：每秒事務數、事務處理速率 、每秒處理事項數
假設某電商平台，使用者數量為20萬，高峰時段為15分鐘，一般採用2-8原則，80%的使用者在20%的時間內完成操作，20萬x80%=16萬人，15分x20%=3分鐘，3分鐘就是180秒，16萬/180秒=889人/秒，併發使用者就是每秒889人
一般檢視測試報告中，cpu使用情況：系統占用cpu低於85%就還可以，長時間占用超過90%就不行
記憶體使用情況：記憶體一般剩餘10%勉強接受，超過則說明不行，還要注意看記憶體有沒有被釋放，就是看記憶體最後是不是呈下降趨勢
磁碟情況：一般有讀有寫，有忙有空閒就沒問題
看每秒事務數、每秒點選數、吞吐量、每秒連線數：這幾個都是相關的，乙個有問題，其他幾個一定有問題，走向有高有低，中間如果有大量空閒則說明伺服器在那個空閒時間段沒有處理請求，系統可能是卡死狀態
首先50個使用者併發，平均事務響應時間中伺服器有3分鐘沒有響應，每秒事務數有兩段1分鐘伺服器沒有處理事務，接下來的每秒點選次數、吞吐量情況、連線數情況、每秒連線數量多個報表都指向同乙個問題，出現兩段沒有請求或處理，說明系統遭遇長時間卡死
其實從50個併發使用者數就可以看出系統效能已經有問題了，到80個併發使用者數可想而知必出問題，平均事務響應時間報表可以看出伺服器長時間沒有響應，相應的每秒事務數、每秒點選次數、吞吐量情況、連線數情況伺服器都出現相同三段長時間沒有請求或處理，說明到80個併發使用者，效能不能通過
1.拿到效能需求文件後，根據效能需求和業務主流程進行效能場景分析（算併發數或者組合場景）
2.編寫效能需求方案
3.開發效能測試指令碼，通過fidder抓包，匯入jmeter指令碼
4.主要指令碼功能實現後，對指令碼進性關聯，引數化
5.指令碼準備完成後，使用jmeter執行，進行效能測試，收集效能資料及監控效能資源
6.測試完成後，對結果進行分析，如果不符合預期，交給開發進行除錯，並回歸測試，直到達到預期效能
7.測試結果通過後，編寫效能測試報告
效能測試基本概念
1 應用系統從請求發出開始到客戶端收到相應所消耗的時間 2 應用系統從請求發出開始到客戶端接收到最後乙個位元組資料所消耗的時間 ps 由於瀏覽器的行為是既定的，所以仍然採用第二種方式來描述響應時間 併發使用者數 1 業務併發使用者數 同乙個時間段內訪問系統的使用者數量，該概念一般在效能測試 perf...
效能測試基本概念釋疑
似乎許多人都對效能測試有或多或少的不清楚，這裡就我的理解提供一些解釋 1 負載測試 load test 壓力測試 stress test 容量測試 capability test 與效能測試 performance test 是什麼關係？效能測試是乙個較大的範疇，包括負載測試 壓力測試和容量測試。其...
LoadRunner之效能測試基本概念
在一些軟體專案中，專案經理或測試經理經常會安排測試工程師進行下面的工作 一 什麼是效能測試 狹義的效能測試主要用於描述常規的效能測試，是指通過模擬生產執行的業務壓力或使用者使用場景來測試系統的效能是否滿足生產效能的要求。廣義的效能測試則是壓力測試 負載測試 強度測試 併發 使用者 測試 大資料量測 ...