壓力測試、性能測試、負載測試、穩定性測試在網絡上有很多文章介紹概念和區別，通常在項目過程中不會區分那麽多，實際項目中都是以目標為導向，通常實際項目中都會說，壓測壹下看下性能，所以這裏就不管詳細的概念和區別了。為了好理解，我們這裏統壹叫壓測，並以得到性能數據為性能測試，以觀察穩定性為穩定性測試。
性能測試和穩定性測試的相同之處在於都是使用壓測工具來進行。但目標不同，性能測試是通過壓力測試得到系統的極限性能或者和上壹版本的性能對比數據。而穩定性測試則是通過壓力測試提供穩定或者變化的持續流量，來觀察系統持續運行的情況下是否存在異常。
正常情況下，壹般系統先做性能測試，拿到極限性能或者性能對比數據（對於非1.0項目，性能數據壹般需要和上壹個版本對比）之後，再通過安全的流量持續壓測更長時間，來完成穩定性的驗證。
下面我們就具體介紹壹下怎麽做性能測試和穩定性測試。
性能測試的第壹步要確定目標，就是為什麽要做性能測試，要達到什麽樣的目標或者效果。比如某個首次上線的系統，性能測試主要是為了得到系統的極限性能數據；再比如，系統優化，更換了RPC協議或者消息隊列，性能測試就是為了量化此次系統優化在性能上優化的效果。另外，也不是所有的項目都需要性能測試，比如壹個內部系統，用戶數和流量本身就很少，而且在未來壹段時間也不會有增量，這就基本不需要性能測試。
如果是從無到有的1.0項目，因為項目還沒有上線，所以只能評經驗來預估線上的流量數據；但如果是非1.0項目，就可以收集當前的線上數據。具體收集的數據如下（僅供參考，要按照實際情況來調整）：1）被測系統或模塊各類請求流量比例；2）系統或模塊目前平均、峰值、最小 qps；3）線上部署方式和規模；4）被測系統或模塊依賴能承受的QPS或者容量。
確定目標和收集完線上現有數據之後，需要根據目標和現有數據確定壓測方案，比如，每個階段通過多大並發或者流量來壓測、分幾個階段、每個階段多長時間、以及壓測過程中需要觀察和記錄哪些數據等。
同時，也要準備壓測環境，壓測的環境要盡可能的和線上壹致，如果達不到，就做等比縮放。比如，壹個系統有A、B兩個模塊組成，線上A部署了20臺機器，B部署了5臺機器，那麽壓測就可以A部署4臺，B部署1臺。機器和實例的數量只是壹個方面，同時也要考慮機器的性能（CPU盒數、內存、磁盤、網卡等），還要考慮依賴方（如DB、緩存、消息隊列等）的部署。部署壓測環境的核心思路就是要用這套環境反應出線上環境的真實情況。
要進行壓力測試就壹定要有壓測工具，壹般來說壓測http或者其他開源協議可以在網上找到現成的工具，比如jmater之類的。但如果場景比較特殊，或者使用的是公司或項目的私有協議，就只能使用公司內部的工具或者自己動手開發了。
選擇好壓測工具就要構造壓測數據了。構造壓測數據主要分兩點：
第壹點是要構造壓測環境系統中的數據。因為線上系統內部壹定是有壹定數據的，我們要盡量模擬線上就要在系統中添加相應的數據。
另壹點就是要準備壓測的請求數據。這點跟選擇的壓測工具有關，壹般來說分2種：
1）數據詞典， 壓測的請求提前準備好，存入文件、DB或緩存裏，數據量較大的時候壹般需要寫程序生成。
2）實時生成，這種是壓測工具在壓測的時候根據配置規則來實時隨機生成請求。
準備工作壹切就緒，下壹步就開始做壓測的執行。這時候主要就是根據壓測方案的從低到高去調整壓測工具的並發數或請求數，來對目標系統或模塊進行壓測。
壓測時，要觀察CPU、內存、網絡IO、磁盤空間、被壓目標日誌、依賴系統或者模塊的狀態等數，也要記錄不同並發下目標系統或者模塊處理請求的QPS和響應時間。同時也要註意有沒有內存泄漏、句柄泄漏、系統崩潰等問題。
實際上部分數據在記錄的過程中就可以初步整理出來。這裏要針對上壹步記錄的數據，進行匯總，主要要產出在不同並發下，上面提到的數據都是什麽情況。需要根據數據判斷出極限性能，找到這種部署情況下瓶頸在哪，以及是什麽原因造成的，為後續擴容提供依據。有些情況還需要跟以前的數據做對比，看性能提升或者下降的程度是不是符合預期。最後，把這些信息綜合匯總、分析之後，產出性能測試的報告。
通常性能測試之後拿到了性能數據之後，都會在安全的並發或者流量下持續壓測更長的時間來確保服務的穩定性。比如，筆者通常測試性能的時候，每輪可能壓測半小時到壹小時（在剛開始並發或者流量較小的時候可能會更短），在得到期限性能之後，會控制極限性能時80%-%90的流量或者並發去壓測更長的時間，這個時間壹般會比較長，而且多數情況下會在晚上下班前啟動，然後第二天到公司來看結果。
除了長時間通過安全流量來驗證外，有些時候在特殊場景下，也需要驗證在安全流量範圍內，流量急曾或者急降的情況下，穩定性是否有影響。或者，驗證在壹定流量下，模擬某個依賴或者系統內部的模塊出現問題，執行相應預案時，對系統整體的影響是否符合預期。
當然，穩定性很多情況是異常，但更多的異常會在異常測試裏去做，這裏的穩定性測試是指在壹定流量壓力下的穩定性測試，其他的就不做討論了。
上面介紹了壓力測試裏，性能測試和穩定性測試要做什麽，那具體怎麽做呢？下面我們就通過壹個實例來簡單介紹壹下。
? 壹個消息推送的系統，推送的消息就是我們日常手機APP的通知消息。這個消息通知的系統有三個接口，分別是單播（指定推送給某個人）、組播（推送給壹個組，組裏可能有多個人）、廣播（推送給APP所有用戶）。現在這個系統做了壹個重構，更新了內部交互的RPC協議，所以要壓壹下，跟之前的性能數據做個對比。另外，系統重構前，線上集群極限性能為30000 QPS。
下面，我們就按照前面的步驟，來簡單介紹壹下具體怎麽做。
? 目標就是要得到重構後的系統性能數據，並和原有的做對比，原有的極限性能已知，大概在30000 QPS左右。
收集線上數據，比如說我們收集到單播、組播、廣播的請求比例為5：78：1；組內人數大概在300-1000；發送的消息字符數在30-100這個區間。
壓測方案要先確定部署方案，比如這個系統向上是20臺機器（或者實例），壓測采用2臺機器（等比縮放）。壓測機器是線上的1/10，所以我們的目標性能就是3000qps。那麽我們壓測的方案就可以如下設置：
第壹輪，2個並發，5-10分鐘，主要目的是為了先驗證環境和壓測工具沒有問題；
第二輪，根據上壹輪並發數和機器資源（CPU、內存、IO）的情況，調整並發到極限的壹半多壹些（比如，之前是2個並發，CPU占用10%左右，內存、IO占用都很小，那麽就以CPU的占用作為參考來計算，1個並發大概占用5%，那我們就可以吧並發調到10-12，目標CPU占用是50-60%）。這其實才真正開始壓測，如果沒問題，就開始逐步加壓；
第三輪，開始逐步增加，按照實際情況壹次增加2-5個並發，直到性能達到瓶頸。
這裏是假設壓測工具通過調整並發數來操作壓力，主要需要看下並發對系統CPU、內存、IO的影響，根據壓測時機器的資源占用信息來判斷增加多少並發。
確定好方案，就需要部署壓測環境了，這裏要註意，盡量使用跟線上壹致配置的機器。
壓測工具要根據實際業務做選擇，必要的時候需要自己開發，工具開發後面如果有機會在其他的文章裏介紹，這裏就不多介紹了。我們這個例子因為是系統更換內部協議，對外接口不變，所以可以使用原有壓測工具。
下面就是要構造數據：
首先，要構造系統內部的數據，比如用戶信息、設備信息、組信息，這裏既要根據線上的收集到的信息來構造，比如用戶數、組的數量、組內用戶數等。這類如果方便的話可以直接在DB裏插入，或者掉相應的系統API來準備。
然後就是壓測的請求數據，比如說壓測工具是用數據詞典來壓測，那麽這裏我們就通過腳本，來生成壓測請求數據。這裏要註意線上收集到的各個接口的占比，即5：78：1。壓測的時候按照這個比例來提供流量。
準備工作完成，開始做壓測。
這時候要先吧各類數據觀察準備好，壹般現在的互聯網大廠都有圖形化的工具來看，如果沒有也可以通過linux的壹些命令來看。常用的命令有top\ps\vmstat， 這裏推薦使用top來查看實時的資源情況，使用vmstat的來定時輸出當資源情況（vmstat -t 1 就是每秒輸出壹次）。
準備好了觀測，那就啟動壓測工具，按照方案壓測。壓測方案上面已經介紹，這裏就不重復了。
假如我們並發加到20個的時候，CPU占用達到85%左右，處理請求達到3600qps，其他資源占用都不足機器的壹半；並發加到22個的時候，CPU占用達到95-100，處理請求是3700qps；並發加到24，CPU打滿，處理請求3800QPS，並且出現錯誤日誌。這時候就可以停止壓測了。
? 數據整理，我們首先要整理壹個表格或者圖標，我們這裏用表格：
這個表格就是壓測產出的最核心的數據，由於CPU是明顯的性能瓶頸，表格裏就不體現其他資源了，如果其他資源使用率也比較高，也要放到這個表格裏，又或者瓶頸在外部依賴，也要體現出來。通過這個數據可以看出，3700QPS就是系統處理的極限，安全的流量在3600QPS。這時候就可以用17-20的並發數，長時間壓測壓測壹下，看看系統整體的穩定性。
? 那麽性能報告怎麽寫呢？下面就給出壹個比較簡單的性能報告樣例。
標題：消息推送RPC協議升級性能測試報告
壹、項目背景
這裏寫項目背景和目標
二、壓測環境
線上20臺物理機，壓測環境使用2臺物理機，配置與線上壹致，具體如下：
XX核，XXG內存，萬兆網卡，硬盤 400G * 6 SSD
DB：XX主XX從XX備
三、壓測方案和數據
1. 請求比例
? 單播：組播：廣播 =? 5：78：1
2. 壓測過程數據
? 3.? 資源占用圖
可以把QPS和CPU占用使用工具（比如excel）生成壹個折線圖，另外，可以把其他資源數占用的數據圖片貼壹下。
四、結論
壓測過程中，壓力達到3700qp時，內存與IO正常，CPU占用達到98%，無錯誤日誌。壓力達到3800qps時CPU打滿，且5分鐘後開始出現錯誤日誌。因此系統在2臺物理機部署極限性能為3700qps，性能瓶頸在CPU，預計線上20臺機器極限性能為37000qps.
系統RPC協議升級前20臺機器30000qps，升級後預計能達到37000qps，性能整體提升23%，符合預期。
上面就是壹個比較簡單的報告，真實項目中瓶頸不壹定是CPU，可能是其他資源，也可能是依賴的系統或者模塊，這些都需要觀察和分析壓測中的數據來得出。
壓力測試是後端測試和測試開發人員的必備技能，這篇文章只是根據筆者的經驗針對壓力測試進行的總結，不能覆蓋所有壓測場景，僅給大家做個參考。更多的是需要我們根據系統的實際情況去探索和實踐。