一、併發測試
概念：多執行緒在單位時間內同時發起單次請求，觀察響應時間
基礎執行緒組（強調單位時間的併發，不存在絕對併發）==》加定時器集合點Synchronizing Timer
二、負載測試
概念：持續不斷的增加壓力（併發使用者/每秒請求），觀察tps和響應時間的變化趨勢，找到瓶頸點（效能衰減點）
併發使用者模式的負載：不斷增加併發使用者數，發現瓶頸
吞吐量模式的負載：
1）吞吐量模式有兩種。一種是TPS，一種是RPS。前者用來設計業務量模型，後者用來控制壓力引擎。我們在用吞吐量模式設計負載場景的時候就有2種方法，持續的增加TPS和持續的增加RPS
但是tps用來衡量服務端的效能，是有上限的。也就是說我們持續增加的負載不可能超過服務端的吞吐量上限閾值
2）rps模式負載：加入jp@gc - Throughput Shaping Timer定時器，不斷增加每秒請求數（rps）對服務端施壓，發現tps瓶頸
3）TPS模式負載：新增bzm - Free-Form Arrivals Thread Group執行緒組，60s內將tps均勻的提升到800，通過tps的提升觀察平均併發數和響應時間的變化
併發使用者模式階梯加壓負載：持續不斷地增加負載，發現效能瓶頸（階梯加壓執行緒組，Concurrency Thread Group）
混合業務負載測試：通過設定每個介面的權重來控制每個介面的請求數，bzm - Weighted Switch Controller 
三、基準測試
1）基準併發 ==》設定1個現場組，迭代100次，看對應的tps和介面響應時間，錯誤率
2）基準負載
用併發基準點做一次簡單的指令碼測試，得到一個基線，為下一次的迴歸做理論依據
四、壓力測試
概念：tps瓶頸點上持續負載
穩定性壓力測試：指令碼以最大壓力的80%做持續執行（1h，1d，1w）
破壞性壓力測試：不考慮伺服器的穩定性，直接以極限壓力測試，目的是破壞伺服器，直接找到異常（記憶體溢位，超時）
階梯式壓力測試：逐漸增加測試負載，如每5s鍾增加100個併發數，高負載情況下持續執行一段時間，然後再逐漸降低負載，構成一個梯級的測試場景 ==》jp@gc - Stepping Thread Group用這個執行緒組，預設每隔30s啟動10個執行緒，一共啟動100個，到底100併發持續1分鐘，並且需要新增beanshell指令碼，檢視執行緒區間1-20，20-40，...100不同階梯壓力下的效能資料變化趨勢
失效恢復測試：系統在出現異常之後，能否及時恢復
容量規劃測試：根據未來的業務增長量來進行擴容，比如業務20擴到30萬，高峰時間段執行2小時
五、spike測試
在效能測試中屬於壓力測試的一個子集。指的是在某一瞬間或者多個頻次下使用者數和壓力陡然增加的場景。常見的場景：12306開始售票時使用者急劇增加，網站公佈高考成績、錄取分數時，使用者急劇增加
測試spike場景可以用：Ultimate Thread Group（終極執行緒組）