前言
最近比較多的時間是在做壓力測試，也就是常說的壓測，而且壓力測試也屬於性能測試中的其中一個，所以今天總結下性能測試的測試方案。
性能測試分類
常見的性能測試分類一般分爲：負載測試、壓力測試、穩定性測試
①負載測試（Load Testing）：在確定的各種工作負載下系統的性能，目標在負載逐步增加情況下，查看系統各項性能指標的變化情況
②壓力測試（Stree Testing）：在逐步加壓的情況下，觀察系統能承受的最大服務級別，即系統能承受的最大瓶頸
③穩定性測試（Stability Testing）：增加系統資源佔用系統長時間的大併發運行或正常流量的系統訪問情況下，能夠長期穩定工作的一種能力
測試流程
以壓力測試爲例進行舉例
性能測試計劃
測試目的（清晰明確、無歧義）
測試範圍（主要測哪些接口，是單接口測試還是多接口測試）
性能指標（TPS、平均響應時間等指標，可量化）
測試數據（測試的數據以及選擇數據的依據）
測試環境（其中包括軟件、硬件、網絡等）
測試工具和監控工具
風險控制（風險描述、嚴重級別、如何規避、負責人等）
組建測試團隊
也就是在測試整個測試過程中，需要哪些人去配合才能更好完成性能測試，以atype爲例，主要有：
產品經理、系統架構師、核心開發工程師、數據分析師、運維工程師、數據工程師
設定性能測試指標
列出性能測試過程中成功的數據指標
1.吞吐量（TPS）
2.平均響應時間
3.系統穩定運行時間要求，一般爲（7x24）
4.是否考慮系統支持水平擴容（如加服務器）
5.考慮系統最大容量
性能測試環境建模
基本按照測試環境，這個測試一般按照測試環境與生產環境1:1複製即可，如果不是一樣的情況下也可以進行測試，最後明確進行投入的軟硬件資源
性能測試工具選擇
一般情況下可以選擇：Loadrunner、Jmeter、Siege、Apache Bench、自寫工具，這裏選擇：Jmeter，基本掌握一款工具即可。
用例設計思路
測試執行階段主要包括以下工作：
基準測試
單接口測試
多接口測試
穩定性測試
用例設計
業務流程：流程比較簡單不需要做太多分析
使用參數化方式：使用CSV參數化方式
斷言內容：主要判斷返回的結果是否符合自己想要的結果
加壓策略：以50爲基準，按每次增加50線程的方式逐步加壓
監控方法：添加CPU、TPS插件等方式
日誌分析方法：查看日誌方式
測試通過標準
測試通過標準一般來自兩方面，一方面來自自己所測得出的結果，被測系統是否已經測試到了極限（如：某些資源是否被耗盡，cpu、內存、數據庫），另一方面來自以往測試結果，所以每次測試完成後必須出一份測試報告，並走郵件，方便下一次可以做比較，原則爲此次測試結果比以往測試結果更好即可，還有一方面來自團隊間相互討論得來的結果，大家有一個共識（這個需要做一定的評估）
常見瓶頸
在測試中，常見的瓶頸有CPU資源耗盡、系統內存耗盡、Swap內存被佔用、I-O存在排隊、響應時間過長、虛擬機內部佔用內存情況