目錄
一、壓測是個啥？為啥要壓測？
二、壓測方案設計
1、壓力場景
2、壓測方案設計關注點
3、涉及到的知識點：
三、壓測執行
四、壓測報告關注點
一、壓測是個啥？為啥要壓測？
壓測屬于性能測試的一種：
性能測試的選擇和需求有關，選擇的場景不同，使用的性能測試方案均是不同的，性能是随着業務的發展，不斷新的要求，不同的階段，性能測試的頻率不一樣。
看到過網上有個饅頭的例子：
一口氣吃十個饅頭，并發，壓力（并發）測試，一口吃15個，20個，吃不下，一口吃18，能吃；
饅頭一個一個吃，負載測試； （壓死駱駝的最後一根稻草）
已知吃15個饅頭，繞操場跑，如果沒問題，就是穩定性很好。
壓測目的：
壓測的目的是為了觀察目前系統的負載能力，考察系統高負載的穩定性。
- 給出系統目前的性能狀況
- 定位系統性能瓶頸或潛在性能瓶頸
題外話：壓測經常和負載測試讓人分不清楚，從一篇部落格看到一句說的很明白的話：
負載測試就是不斷增加壓力，進行測試。壓力測試就是最大負載下的測試。
負載測試是通過改變系統負載方式、增加負載等來發現系統中所存在的性能問題。負載測試是一種測試方法，可以為性能測試、壓力測試所采用，負載測試的加載方式也有很多種，可以根據測試需要來選擇。
- 性能測試是為擷取或驗證系統性能名額而進行測試，多數情況下，性能測試會在不同負載情況下進行。
- 壓力測試通常是在高負載情況下來對系統的穩定性進行測試，更有效地發現系統穩定性的隐患和系統在負載峰值的條件下功能隐患等。
二、壓測方案設計
1、壓力場景
壓測包括兩種場景：
一種是單場景隻壓一個接口的；第二種是混合場景，多個有關聯的接口。
2、壓測方案設計關注點
1、調研下遊接口和基礎元件的負載能力，檢視調用次數，确定人員和接口是否可以承受；
2、梳理下遊接口的時候，整理出具體調的服務和次數；
3、确認是否有緩存，預估每個服務的QPS;
4、設計方案時候，預估風險；
5、壓測前測試時需要通過鍊路驗證，确定是否漏掉部分服務；
6、資料量大的時候，考慮壓測是否對線上真實資料有影響，比如寫資料庫，用影子緩存，如果隻是讀，可以考慮直接用線上資料；
7、在壓測中考慮是否回放，具體和緩存的失效時間也都有關；
8、報警需要把無關的mock掉，否則幹擾定位問題；
3、涉及到的知識點：
1.TP名額&QPS（TPS）
TP名額: TP50：指在一個時間段内（如5分鐘），統計該方法每次調用所消耗的時間，并将這些時間按從小到大的順序進行排序，取第50%的那個值作為TP50 值；配置此監控名額對應的報警閥值後，需要保證在這個時間段内該方法所有調用的消耗時間至少有50%的值要小于此閥值，否則系統将會報警。
需要指出的是，響應時間的絕對值并不能直接反映軟體的性能的高低，軟體性能的高低實際上取決于使用者對該響應時間的接受程度。對于一個遊戲軟體來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對于編譯系統來說，完整編譯一個較大規模軟體的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于使用者來說都是可以接受的。
TP90，TP99，TP999與TP50值計算方式一緻，它們分别代表着對方法的不同性能要求，TP50相對較低，TP90則比較高，TP99，TP999則對方法性能要求很高
這裡面包含了兩個概念一個是TP名額，一個是QPS。
QPS（TPS）：每秒鐘request/事務的數量。比如一秒内隻有一個請求，那麼qps=1;如果每秒50，那麼qps=50;
2. 吞吐量(Throughput)
吞吐量是指系統在機關時間内處理請求的數量。對于無并發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。前面已經說過，對于單使用者的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對于并發系統，通常需要用吞吐量作為性能名額。
對于一個多使用者的系統，如果隻有一個使用者使用時系統的平均響應時間是t，當有你n個使用者使用時，每個使用者看到的響應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由于每個請求的處理過程中有許多不走難以并發執行，這導緻在具體的一個時間點，所占資源往往并不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個使用者看到的平均響應時間并不随使用者數的增加而線性增加。實際上，不同系統的平均響應時間随使用者數增加而增長的速度也不大相同，這也是采用吞吐量來度量并發系統的性能的主要原因。
3. 并發使用者數
并發使用者數是指系統可以同時承載的正常使用系統功能的使用者的數量。與吞吐量相比，并發使用者數是一個更直覺但也更籠統的性能名額。實際上，并發使用者數是一個非常不準确的名額，因為使用者不同的使用模式會導緻不同使用者在機關時間發出不同數量的請求。對于網站系統我們會有三個關于使用者數的統計數字：注冊使用者數、線上使用者數和同時發請求使用者數。由于注冊使用者可能長時間不登陸網站，使用注冊使用者數作為性能名額會造成很大的誤差。而線上使用者數和同僚發請求使用者數都可以作為性能名額。相比而言，以線上使用者作為性能名額更直覺些，而以同時發請求使用者數作為性能名額更準确些。
三、壓測執行
生成報告：
- 本次壓測的要求名額，性能要求
- 本次壓測的機器性能
- 本次壓測的各項各項名額
- 本次壓測的報告結果分析
- 壓測報告建議
- 壓測報告等級
四、壓測報告關注點
1、壓測報告怎麼看?
行業經驗：對于遊戲行業而言，對于性能的要求是非常高的，響應和延遲是其中最為重要的名額。其性能底線往往是要求90%使用者的響應時間是在1秒内，對于2-3秒的使用者響應隻有一些非常小點選率的請求時才會适當允許! 對于一般的商業系統，性能不錯的在1~2秒作用，3~5秒則稍微難以接受。
這個性能名額是指90%的使用者響應秒數。
Min：最小響應時間
Max：最大響應時間
TP90，TP99，TP999等：例如，TP90代表的是90%請求的響應時間
Average ：每個請求的平均響應時間
Median ：中值，即50%請求的平均響應時間
Samples ：各個測試的樣本總數 ，也即是說線程數*循環次數，
Error%：本次測試中出現錯誤的請求的數量/請求的總數
KB/Sec：每秒從伺服器端接收到的資料量，相當于LoadRunner中的Throughput/Sec
當并發在多少（線程數）的時候，每秒的TPS是多少，每秒的查詢率QPS是多少QPS；目前系統90%Line使用者的響應時間是多少，最長的響應時間是多少Max，最快的響應時間是多少MIN。壓測中出現多少錯誤率Error，與目标允許的容錯率xxxx 不符合/符合。
壓測的結果一般情況可以通過吞吐量與并發數的比例來觀察，吞吐量與并發數呈正相關關系，在一定并發數的情況下，吞吐量越高，說明系統性能越好！