一、Controller的基本工作原理：通過1、2、3設置來模擬用戶的操作，收集出4的各種信息
二、場景設置一般步驟
-
1、新建場景（Controller）
-
2、添加腳本
-
3、設置Schedule（設置場景運行的策略，主要設置Globle Schedule 這一項）
-
4、添加壓力機（可以指定多台windows或者linux壓力機產生壓力）
1）添加壓力機方法：Scenario - Load Generators
2）添加的壓力機於Controller所在機器在同一網段，把防火牆關了 -
5、設置run time setting
1）以Controller中的選項為主 -
6、運行觀察
三、分析思路：
- 1、分析原則：由外到內，由表到里，層層深入。拆分問題，隔離問題（好比學習一樣，把時
間段分成一片一片的，把零散時間靈活應用起來）。 - 2、 對於一個應用系統，性能開始出現了下降，最直觀最直接的表象就是系統的響應時間，
如果響應時間變長，則系統響應時間就是分析性能的起點。 - 3、 任何一個復雜的系統都可以分為網絡和服務器兩部分。
- 4、 性能測試不是一蹴而就的，而是貫穿整個性能測試的流程。
- 5、 性能分析調優是一個不斷推理不斷驗證的過程，不斷試錯，不斷改正，打開自己的思維。
四、重點指標：
- 1、TPS（每秒通過事物數，直接反應服務器的處理能力，可理解為地鐵進站口刷卡機）
- 2、平均事物響應時間（最直觀的指標，可作為突破口）
- 3、每秒連接數（可初步判斷是否需要調優連接數配置）
- 4、點擊數（直接反應請求數、客戶端、網絡，點擊數出現問題一般為腳本或者網絡出現了問題）
五、分析思路模型：
1 、重點關注Transaction Summary （事物概要）模塊
*（1）平均響應時間：當標准差比較小的時候，選擇事物的平均響應時間。
*（2）90%響應時間：當標准差比較大的時候，去掉最高最低，取90%響應時間更有
分析價值。
*（3）Std：標准差比較小，則相對比較平穩，標准差比較大時，則表明浮動比較大
分析Web Tour中的Transaction Summary （事物概要），回想前面的內容，最直觀的指標就是“平均響應時間”，可把它作為突破口
由圖可以看出，check的平均響應時間是最大的，要相對的比較，可以把check作為分析的突破口。
其他事物可以不用分析，根據木桶原理，補最大的缺口。
2、HTTP Responses Summary（HTTP返回狀態概要）
*（1）HTTP Responses Summary主要統計服務器的返回狀態
*（2）由圖可看出返回都是200的狀態碼，而且總數8789與Statistics Summary（標准概要）
中的值基本一致，說明大部分請求都是成功的。
** 注意：**
說非200的狀態碼不一定是錯的，需要根據具體業務來分析，比如302、304狀
態碼也是很正常的，不會影響性能測試結果。但是返回500的狀態碼的話就是錯誤的，
說明服務器內部錯誤。
六、分析過程 重點、重點、、、
接觸LR的分析過程：
1、首先來分析running Vusers這項，雙擊打開
分析：
首先要看坐標圖，X軸代表時間，Y軸一般代表指標，這里就是代表模擬用戶數。由圖可以看出，模擬用戶數慢慢增長，然后平穩一段時間，最后再慢慢下降，這是一個合理的過程。假如出現紅線那樣的坐標圖，用戶數急速下降，那么很可能就是服務器down掉了。
2、 Error statistics（錯誤描述統計）
分析：
能進行到這一步說明腳本運行是沒問題的了（比如檢查點不對這些因素就可以排除掉了）。
最后兩行有Faied to connect server 明顯可以看出是連接服務器失敗了；有兩行是timeout提示，這個出現的次數不多，可以不管。
如果要去掉的話可以在Controller中Run-time-Setting設置，把perferences中的HTTP-request connect timeout(sec)、HTTP-request receive timeout(sec)和Step download timeout(sec)的值調大一點。
前面兩行初步判斷可能是關聯出了問題，關聯抓不到，可能是服務器返回失敗。
得出初步結論：
- （1）連接服務器失敗，遭到服務器拒絕，可能是系統出現瓶頸無法及時處理請求
- （2）關聯抓不到，可能是服務器返回失敗
- （3）timeout提示一般可以不管，如果要去掉的話可以在Controller中Run-time-Setting設置
3 、Error per Second（每秒錯誤數）
- 每秒錯誤數圖是對每秒出現的錯誤進行統計，數值越小越好。
- 2-7min過程中錯誤數明顯增加，可以判斷系統在這個時間段開始不穩定。
4、Average Transaction Response Time（平均事物響應時間）
每秒內事物執行所用的時間
由圖可以看出，到3s后，事物的平均響應時間突然下降。在這里可以大膽地推測，是不是因為服務器非常好，處理事物的能力非常強，所以事物執行的時間很少。
但是聯想到上面的每秒錯誤數的圖，在一段時間內每秒錯誤數都是差不多平穩的，所以說服務器處理事物能力非常好這個結論經不起推敲。
也有可能是處理能力差或者出現大量的連接錯誤、服務器出現down機等，前面說到，任何一個復雜的系統都可以分為服務器和網絡，所以說也有可能是網絡的原因。
結論：
*（1）服務器出現拒絕連接、出現大量錯誤或者是服務器down機了
*（2）也有可能是網絡連接的問題
5、 TPS（每秒通過事物數）
TPS是考查系統性能的一個重要指標，值越高，說明系統處理能力越強
可以看出來，整體的TPS不是很高，說明服務器處理能力有待提高，后續要把TPS提升
6 、Hits per Second（每秒點擊數）
虛擬用戶每秒向Web服務器提交的Http請求數
總體來看沒有啥問題，還是可以。2-5min過程中出現了一些波動，每秒點擊數是服務端側的，
那就應該是腳本或者網絡的問題，從前面的分析得知，腳本是沒問題的，那就基本可以判斷出現波動是因為網絡問題導致的。
7、Connections per Second（每秒連接數）
每秒連接數就是每秒中打開的TCP/IP連接數，當連接數到達穩定的時候而事物響應時間增大時，
添加連接數可以使系統性能得到提高。好比一個池塘放水，多開幾條溝水會放得越快。
每秒連接數統計新建的連接數和關閉的連接數，可以了解每秒對服務器產生連接的數量，
圖中可以看出每秒連接數都是比較低的，可以適當增加連接數來提高系統性能。
七、性能測試流程
過程分析：
（1）性能需求點獲取
- 根據客戶的需求由客戶方提出
- 根據歷史數據分析
- 參考歷史項目或者其他同行業的項目
- 業內通用規則
- 確實沒有數據，那就根據自己來，然后一邊分析
（2）測試點的提取，常放在客戶常用的、重點的模塊和功能上
- 用戶常用功能，比如登錄
- 數據流轉向復雜或頻繁的地方
- 發生頻率高的地方，比如搜索，提交訂單，下單結賬。
- 關鍵程度高的（比如產品經理認為絕對不能出現問題的地方，登錄、下單等）
- 資源占用非常嚴重的
- 關鍵的接口
（3）測試環境
- 最好能和線上保持一致
- 如果不能那就等比的放大或縮小
- 軟件版本應該一致
（4）測試數據
- 鋪底數據的准備：是空庫還是有數據量。數據量的選擇參考線上的數據量進行
等比的放大或縮小。 - 最好的數據來源於線上的真實數據，因為分布合理
- 如果涉及到保密的數據，注意數據的脫密處理
（5）測試過程
- 性能測試時一個需要不斷改進的過程，每一次盡量做得更好，多做一點點以前
沒想到的東西，然后不斷積累總結，然后你會發現自己對性能測試有了更深的
理解
（6）響應時間預估
- 線上監控系統得知
- 業界統一參考標准：2 - 5 - 8
（7）TPS預估
-
系統的性能由TPS決定，跟並發用戶數沒有多大關系。系統最大的TPS是一定
的，就好比池塘里裝的水是有限的。但是並發用戶數不一定，可以通過減小思
考時間來增大並發用戶數。 -
新系統：沒有歷史數據參考，只能通過業務部門來評估
-
舊系統：最好通過日志分析來得出
-
對於上線的系統，可以選取高峰時刻，在五分鍾或者十分鍾內，某個交易的最
大值，按照單位時間內完成的筆數計算書TPS，即業務筆數/單位時間