壓測分爲全鏈路壓測和單系統服務接口壓測兩種，對於全鏈路壓測要準備的事情和要改造的東西是特別多的，是一個相對龐大的系統工程，大致業務架構如下，可以單獨列出一個系列來講，這裏只講單系統的服務接口壓測。
壓測可以選擇的框架有多種，可以根據系統所採用的代碼、熟悉程度等選擇一個，更好的方式是在開源的壓測框架之上開發一個壓測平臺，降低學習成本，方便統一管控。下面的流程是假設公司內部有統一的壓測平臺展開的。
1.壓測工單申請|壓測通知
壓測時會對應用服務器、db、消息中間件、緩存、下游系統等關聯繫統造成影響，因而需要和關聯方進行告知或者申請，同步信息，得到確認後再開始
2.壓測數據準備
在前面的壓測改造和準備小節也提到過壓測數據的準備，根據業務的需求如果可以mock的數據一定要保證mock的數據足夠的隨機同時要保證壓測數據和線上正式數據是隔離的；對於緩存數據需要可能還需要進行預熱；對於不能mock的數據要保證脫敏並且後續的操作不會感染用戶的真實數據；
3.壓測腳本聯調
在準備好數據後，需要對壓測腳本進行聯調，確保壓測腳本符合預期：
1）業務邏輯是否符合預期
2）總調用量是否符合預期
3）db調用量是否符合預期
4.壓測預案准備
壓測預案和高峯期的預案可能相同，也可能不同，比如壓測時的緩存命中率就是壓測專用的，爲了方便各種開關的推送，最好把壓測相關的預案配置到一個預案中，方案統一執行和管控
5.壓測限流準備
在進行壓測時，線上仍然是有正常的流量進來的，因而對於接口的限流配置要仔細規劃。可以針對壓測流量進行單獨的限流，也可以對所有的流量進行限流。如果是前者，可以保證限流只作用於壓測流量，不會影響到線上業務；如果是後者當壓測流量比較大時就會影響到正常流量，但是可以利用這個機會驗證下限流是否生效。兩種方式各有利弊，可以根據自己的業務情況進行取捨。
6.壓測服務器申請
壓力測試也是由服務器發出請求的，因而要根據自己的目標請求量申請足夠的壓測服務器，否則也無法達標。
7.確定合適的上量速度
大促活動的上量速度通常是非常迅速的，可能在幾秒中上升到日常的十幾倍或者幾十倍，但是在壓測的時候特別是第一輪壓測時候上量需要慢些，留出比較長的觀察時間，以進行驗證，當出現異常情況時可以快速定位問題和快速回滾。
當壓測達標後再次進行壓測時可以比較快的上量，儘量模仿真實的情況。
8.數據記錄&覆盤
將壓測達標時系統的主要數據進行記錄：cpu、load、峯值、rt、error、內存、gc等。這些數據將會對後續的壓測及日常其他系統接入進行容量評估十分有幫助。
覆盤主要是針對壓測中預料之外的事情進行回顧，分析產生的原因以及之後如何避免，對產生的問題可能還要去修改腳本、預案、限流、代碼等內容。