執行緒數：需要設定的併發使用者數
併發使用者數： 受cpu的主頻、分配的記憶體大小、作業系統(允許開啟檔案數量、開放的埠數量)的影響，一台電腦，大概能支援 1500併發使用者數以內(http協議)
ramp-up時間： 在多長時間內啟動所有的執行緒。
注意：只是說明，在第n秒結束時，會產生m個併發使用者數，並不代表每秒會產生多少個併發使用者數
已經產生的併發使用者數，就會呼叫 取樣器，進行請求。請求迴圈次數用完，這個併發使用者數的資源就會釋放，這個併發使用者數就會消失。
1.5s的來由： 效能測試行業標準 apdex
負載測試： 逐步增加併發使用者數，找到我們的最優併發使用者數的區間
最優併發使用者數：介面未大量報錯且平均響應時間在目標時間內的最大併發使用者數
使用執行緒組：jp@gc stepping thread group
***活躍執行緒數active threads over time
響應時間圖response times over tim
tps圖transactions per second
獲取最大（最優）併發使用者數的方法
1、先設定乙個比較大的範圍值 普通執行緒組+ 聚合報告執行較短時間，通過聚合報告中的，異常率 + 平均響應時間來判斷。
2、設定合適的步長，執行一輪 階梯場景 觀察tps圖中是否有報錯、在某一併發使用者數範圍的時響應時間，與目標響應時間對比， 從而找到乙個最大併發使用者數的區間。
3、縮小範圍，設定 起始值、最大值為上一步的區間值，步長根據實際情況來設定 首先看 tps 有沒有錯誤(連續性報錯），如果連續報錯，說明此時的併發使用者數已經超過了最大併發使用者數 沒有錯誤，就看響應時間圖 ，看平均響應時間符合目標值的時間點，然後對照活躍執行緒數active threads over time，同樣的時間點的活躍執行緒數，就為最大（最優）併發使用者數
用一定量的併發使用者數，持續執行一段比較長的時間，來看伺服器的穩定性。
關鍵點：一定量的併發使用者數，執行時間要比較長
壓力測試場景流程
1、負載測試-階梯場景，找到最大併發使用者數
2、最大併發使用者數進行普通效能場景測試
3、如果出現服務不穩定的情況，再進行壓測試場景
請求會在一段時間集中爆發，然後趨零，然後再爆發的週期性請求場景，有時間規律的請求
定義：不同數量的併發，對不同介面向伺服器發起請求，模擬真實的請求場景
要點期望某個介面系統的處理能力不低於 200 次/秒，問你，這樣的場景，你如何設計？
類似場景：秒殺，模擬伺服器要能在1秒鐘處理1000個事務，實際上是要求tps大於等於1000就可以了
使用說明
對照***，檢視達到設定tps，穩定執行狀態的介面響應時間，以判斷是否滿足要求
使用說明：
實際使用階梯執行緒組並無太大區別
效能測試場景設計之容量測試場景設計
目前僅限於容量測試場景設計。場景模型的設計過程其實就是根據預期目標tps和測試模型計算出每乙隻交易的併發使用者數和迭代間隔時間。選擇固定間隔時間方式，詳細方法請看7.3節中的pacing選項的說明，不同的預期目標tps將會得到不同的併發使用者數和間隔時間。首先，假定乙個總的目標tps，然後通過測試模...
效能測試的標準測試場景
1 單交易基準測試時指通過單個虛擬使用者逐筆發起交易，該測試用於獲取交易的效能基線。2 單交易負載測試是指通過一定的併發使用者，對某個被測試交易施加較大的壓力，通過單交易負載測試能夠暴露被測試交易自身的效能問題，並進行調優。3 混合負載測試是按照特定的比例，併發發起多個被測交易，混合負載測試是最接近...
效能測試場景分析設計
效能測試工作多年，經歷大小專案上千個，說起效能測試可能一千個人眼中就有一千個哈姆雷特。有人會說效能測試就是搞個壓測工具壓下就行，有人會說效能測試是瓶頸定位，有人說效能測試是保障大促的測試，有人說效能測試是容量規劃等等。其實這都是片面的不完整的，效能測試是乙個複雜的系統工程，真正做一次完整的效能測試要...