文章目錄
- 前言
- 常見性能名額
- 性能測試步驟
- 準備階段
- 執行階段
- 分析階段
- 調優階段
- 驗證階段
- 結尾
前言
大家好，我是洋子，相信剛學習軟體測試的同學都聽說過性能測試、壓力測試、負載測試、穩定性測試等等，在日常性能測試工作中，我們不用太關心這四者之間有什麼差別，因為壓力、負載、以及穩定性測試都是屬于性能測試的範疇
談到性能測試，大家可能會想到Jmeter。網上有很多關于Jmeter的學習資料，但是請大家注意，學會Jmeter并不等于掌握了性能測試，Jmeter隻是一個測試工具，用來輔助我們執行性能測試，除了Jmeter我們也可以選擇其他的工具來執行性能測試。本篇文章不是一篇Jmeter的教程，而是帶你了解性能測試完整的工作流程
常見性能名額
在學習性能測試之前，我們需要了解常見的性能相關資料名額。性能測試的對象可以分為
服務端
和
用戶端
對服務端接口進行性能測試，我們通常會關注如下資料名額
- 可用性：系統在面對異常時可以提供正常服務的能力
- QPS（Queries-per-second，每秒查詢率）：QPS是對一個特定的查詢伺服器在規定時間内所處理流量多少的衡量标準
- 平響（平均響應時間）：所有請求平均耗費的時間
- 并發數：并發使用者數是指系統可以同時承載的正常使用系統功能的使用者的數量。并發數=QPS*平均響應時間
- PV（Page View）：即頁面浏覽量或點選量，使用者每次對網站的通路均被記錄，使用者對同一頁面的多次通路，通路量累計
- 錯誤碼：接口傳回結果的HTTP狀态碼
- 吞吐率：機關時間内伺服器處理的請求數來描述其并發處理能力
- 執行個體存活度：對多個機房執行個體同時進行性能測試後，執行個體正常運作的數量
- 業務關鍵名額：根據自己業務設定的性能資料名額
而對APP用戶端進行性能測試時，關注的名額如下：
- 記憶體
- CPU
- 網絡流量
- 電量
- 啟動速度
- 滑動速度、界面切換速度
- 與伺服器互動的網絡速度
性能測試步驟
在實際工作當中進行性能測試，一般有如下五個步驟：
- 準備
- 執行
- 分析
- 調優
- 驗證
下面我以服務端性能測試為例，講解各階段該怎麼做
準備階段
需要深入了解性能問題對象并對性能問題進行粗略評估，還需要了解服務的整體架構、對應的伺服器資訊，對系統應用的熟悉程度，在很大程度上決定了是否能更快的發現問題，比如需要梳理壓測接口及接口的依賴下遊，準備壓測環境，redis緩存的填充，準備接口入參（線上引流或資料構造），監控名額的配置，熔斷方案
跟産品經理以及開發溝通本次性能測試的方案，包括确定被測系統、要進行壓測的接口，确定本次壓測的接口的最高
QPS
，制定應急預案，確定執行測試出現異常時，有人及時跟進處理
性能測試方案制定完成後，還需要準備監控平台，用于監控目前測試的狀态以及各項性能名額
編寫壓測腳本用于批量發送壓測的接口請求，也可以使用Jmeter 這樣的測試工具，在成熟的公司裡面，一般會有通用的壓測平台，配置壓測任務即可進行性能測試
執行階段
在執行性能測試時，若某個接口需要壓1000 QPS。我們不會讓它立馬上漲到 1000，而是設定100 QPS為初始值，增長的步長也為100。因為我們一般是直接對線上環境的接口進行壓測，這樣做能保證線上服務不受影響，否則一下子提到很高的QPS，伺服器可能會壓崩潰
分析階段
達到預期的QPS以後，我們就可以停止壓測，進行資料分析。通過分析準備階段新增的監控進行收集問題資訊，包括系統/業務監控報警，關聯系統故障追溯；
此時還可以通過通過性能分析工具對問題進行初步定位
下面幾張截圖是監控平台上的名額趨勢，下圖為可用性，可以看到可用性基本是維持在98%-100%
下圖為平均響應時間，基本是在100 ms
下圖為PV，有時候還會采集PV lost資料名額，PV lost是對伺服器日志中的status為500狀态碼的日志做采集
錯誤碼，正常接口傳回錯誤碼是200，下圖當中有少量499、404、504的錯誤碼
調優階段
當我們在性能測試的名額發現異常後，就需要與開發配合，讓開發優化代碼修複性能問題
根據定位到的瓶頸點針對性解決，包括應用性能調優，系統部署優化
性能測試發現的常見問題有接口讀取資料逾時，優化方式一般是優化SQL查詢語句、修改索引，或者增加 Redis 緩存直接從緩存讀取資料等等