文章轉自微信公眾號：全棧測試筆記，作者：全棧測試筆記，https://mp.weixin.qq.com/s/4b2ZcMpXOwSg7DhUlgeuew

每天做著點點點測試有沒有危機感？

突然有一天，領導說：“小王，今天把996福報系統壓一下，下班前把壓測報告發我郵箱。”

啥？壓測？今天？報告？怎么壓？怎么寫？從來沒做過啊，心里一萬匹草泥馬奔跑而過，別說996了，估計明天都下不了班了；

好歹也像功能測試，給個壓測需求吧！沒法，你遇到了一個不懂性能測試的領導；

下面大概介紹下一個完整的項目是怎么做性能測試的，看完，你也知道怎么和領導溝通性能測試、以及該怎么做性能測試了，至于欠缺的性能知識，自己努力擠時間補吧。

一、前期準備

性能測試雖然是核心功能穩定后才開始壓測，但是在需求階段就應該參與，這樣可以深入了解系統業務、重要功能的業務邏輯，為后續做準備。

二、性能需求分析（評審）

評審時，要明確性能測試范圍、目標；

由于非專業性能測試人員不知道怎么定目標，如果你讓他們定，可能定的目標會很離譜，比如，要求單機tps10萬、支持1萬的并發等等，顯然是不合理的，你壓測也達不到這個目標；

所以，這個時候，就要體現性能測試人員的專業性了，最好是引導產品、需求或者開發出壓測目標（分別是單場景、混合場景、穩定性場景的），自己給建議，大家一起定一個當前合理的目標，達成一致后，讓產品或者需求把最終評審的結果以郵件方式發送給領導及項目組成員；

這樣，如果最后上線后出問題，還可以避免只有測試背鍋，總之目標也不是你一個人定的，是大家一起定的，要背鍋一起背鍋；

定性能指標，又分為迭代項目和新項目，迭代項目就根據生產監控、日志分析來評估指標，這里需要做容量規劃，新項目單獨評估（后續詳細介紹）；

這里說下性能指標，一般是tps（每秒處理事務數，這里都是通過的事務）、art（平均響應時間）及并發數，加上服務器資料利用率的要求（cpu、內存、IO、網絡等）、各個服務的資源情況。

三、熟悉系統架構，申請性能測試環境

做性能測試，必須要熟悉項目的架構，這樣你才知道監控哪些服務器，以及準備監控方案（監控方式及監控的性能指標點）；

包含具體用到的web服務器、應用服務器、緩存數據庫服務器、數據庫服務器、文件服務器等；

主流的技術棧：nginx、dubbo、mysql、redis、jvm等等（后續專項介紹）。

四、制定性能測試方案

項目背景及架構分析，

需要的資源，

技術策略（比如壓測、監控、分析工具選擇等），

場景設計，

計劃什么時候做什么事等等。

（模板請聯系作者獲取）

五、搭建測試環境，準備測試數據

搭建測試環境是測試必備的技能，當然，如有困難，你也可以找運維、開發一起配合；

測試數據分為基礎環境數據和業務數據；

基礎環境數據可以從功能測試的庫導過來，改一些配置即可；

業務數據包含：存量數據+容量規劃數據，比如一個查詢接口，都是并發100用戶，對應的表數據量是1萬和100萬，壓測結果是不一樣的；

數據量要參考生產環境，如果是新項目，除了空庫壓，最好也做一下存量數據壓。

六、壓測腳本開發

主流程穩定后，調試被測接口、開發壓測腳本（也可以在功能測試環境進行）；

客戶端并發工具，推薦用jmeter，主流、開源、輕量、免費、功能強大；

根據實際情況，對腳本調整，比如：參數化、關聯、事務、檢查點、思考時間、信息頭管理器等；

這些是基礎，可以訪問博客：

www.cnblogs.com/uncleyong/p/10530261.html

這里再強調一下，jmeter只是客戶端并發工具，jmeter≠性能測試。

七、預壓測（基準測試）

少量并發（比如1個用戶），壓測10分鐘，

第一：可以看壓測環境功能是否通；

第二：估算并發過程中需要多少參數化數據的數據量（具體估算方式后續介紹）。

八、執行壓測并監控

場景設計好后，就可以執行壓測了，然后監控查看測試各項指標是否滿足需求；

如果不滿足，可以結合表象及根據自己的經驗直接去看預估的瓶頸點；

否則，從請求開始，一步一步排查請求流經的節點，包括服務器資源（cpu、內存、磁盤io、網絡）是否存在性能瓶頸、是否存在隊列、線程池、連接池、線程死鎖、數據庫死鎖、慢sql、長事務等性能問題；

經常有測試朋友問我用什么工具監控，我大部分都是用的命令，為了方便，也會寫shell腳本來監控；

linux服務器，常用的命令是top、vmstat、free、df、sar、iostat、netstat等，一般是多個命令配合著用；

java應用：jvisualvm、jconsole、jmap、jstat、jstack等，以及自己寫的一些shell腳本；

redis、mysql、jvm等等，后續文章會專項介紹。

九、分析定位

基于上一步的監控數據，對瓶頸進行分析、定位，模塊隔離分析、日志分析、內存分析、線程棧分析、代碼跟蹤等等；

這個真需要實戰積累，沒有捷徑，遇到好幾個去參加過性能培訓的朋友，他們反饋說還是不會性能，操作起來同樣一臉懵逼、無從下手。

十、性能優化

定位到問題了，大部分情況下，優化方案也就有了，測試可以把自己建議的優化方案告訴開發，開發會結合自己的方案，一起做優化方案評估；如果測試沒有優化方案，那就把問題反饋給開發吧，但是也好好學學開發的優化思路，這就是成長的過程。

十一、性能回歸

優化后，復測。

十二、編寫性能報告

測試結果是多少？

測試是否通過？

發現了什么性能問題？

原因是什么？

如何優化解決的？

系統性能提升了多少倍？

優化方案務必寫詳細，以便上線同事知道，把優化同步到其它各個環境。

聲明：封面或正文部分圖片來源于網絡，如有侵權，請聯系刪除。

總結

以上是生活随笔為你收集整理的性能测试流程 | 怎么做性能测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。