1.壓測任務需求的確認
確定好工作范圍：
首先分析壓測最容易出現瓶頸的地方，有目的的進行測試。
用戶更關心整個系統中哪個環節的性能情況也會影響工作范圍。
2. 壓力測試 通過不斷加壓被測系統，直到性能指標達到飽和，這種測試能夠找到系統的極限，為系統調優提供數據
性能測試 通過模擬生產運行的業務壓力量和使用場景組合測試系統的性能是否滿足生產性能要求
配置測試 通過測試找到系統各資源的最優分配原則
并發測試 測試多個用戶同時訪問一個應用，同一個模塊或者數據是否存在死鎖或者其他性能問題
極限測試 測試系統在一定飽和情況下，系統處理會話能力，以及系統是否會出錯
容量測試 測試系統能夠承受住的最大的會話能力
可靠性測試 通過對系統加載一定量業務的壓力，運行一段時間
失敗測試 對于有冗余備份和負載均衡的系統，通過這樣的測試來檢驗如果系統局部發生故障用戶是否能夠繼續使用系統，用戶將受到多大的影響。
固定接口參數進行壓測還是進行接口參數隨機化壓測？
要求支持多少并發數？
TPS（每秒鐘處理事務數）目標多少？響應時間要達到多少？
壓服務器名稱還是壓服務器IP，一般都是壓測指定的服務器
jmeter 壓測設置
線程數：并發數量，能跑多少量。具體說是一次存在多少用戶同時訪問
Rame-Up Period(in seconds):表示JMeter每隔多少秒發動并發。理解成準備時長：設置虛擬用戶數需要多長時間全部啟動。如果線程數是20，準備時長為10，那么需要10秒鐘啟動20個數量，也就是每秒鐘啟動2個線程。
循環次數：這個設置不會改變并發數，可以延長并發時間。總請求數=線程數*循環次數
調度器：設置壓測的啟動時間、結束時間、持續時間和啟動延遲時間。
壓測結果查看
??運行完后，聚合報告會顯示壓測的結果。主要觀察Samples、Average、error、Throughput。
Samples:表示一共發出的請求數
Average：平均響應時間，默認情況下是單個Request的平均響應時間（ms）
Error%:測試出現的錯誤請求數量百分比。若出現錯誤就要看服務端的日志，配合開發查找定位原因
Throughput:簡稱tps,吞吐量，默認情況下表示每秒處理的請求數，也就是指服務器處理能力，tps越高說明服務器處理能力越好。
壓測結果的分析
有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的范圍內；
Throughput吞吐量每秒請求的數大于并發數，則可以慢慢的往上面增加；若在壓測的機器性能很好的情況下，出現吞吐量小于并發數，說明并發數不能再增加了，可以慢慢的往下減，找到最佳的并發數；
壓測結束，·登陸相應的web服務器查看CPU等性能指標，進行數據的分析;
最大的tps:不斷的增加并發數，加到tps達到一定值開始出現下降，那么那個值就是最大的tps。
最大的并發數：最大的并發數和最大的tps是不同的概率，一般不斷增加并發數，達到一個值后，服務器出現請求超時，則可認為該值為最大的并發數。
壓測過程出現性能瓶頸，若壓力機任務管理器查看到的cpu、網絡和cpu都正常，未達到90%以上，則可以說明服務器有問題，壓力機沒有問題。
影響性能考慮點包括：數據庫、應用程序、中間件（tomact、Nginx）、網絡和操作系統等方面。
?
)
