文章轉自微信公眾號：全棧測試筆記，作者：全棧測試筆記，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≠性能測試。
第二：估算並發過程中需要多少參數化數據的數據量
（具體估算方式后續介紹）。
場景設計好后，就可以執行壓測了，然后監控查看測試各項指標是否滿足需求；
如果不滿足，可以結合表象及根據自己的經驗直接去看預估的瓶頸點；
否則，從請求開始，一步一步排查請求流經的節點，包括服務器資源（cpu、內存、磁盤io、網絡）是否存在性能瓶頸、是否存在隊列、線程池、連接池、線程死鎖、數據庫死鎖、慢sql、長事務等性能問題；
經常有測試朋友問我用什么工具監控，我大部分都是用的命令，為了方便，也會寫shell腳本來監控；
linux服務器，常用的命令是top、vmstat、free、df、sar、iostat、netstat等，一般是多個命令配合着用；
java應用：jvisualvm、jconsole、jmap、jstat、jstack等，以及自己寫的一些shell腳本；
redis、mysql、jvm等等，后續文章會專項介紹。
基於上一步的監控數據，對瓶頸進行分析、定位，模塊隔離分析、日志分析、內存分析、線程棧分析、代碼跟蹤等等；
這個真需要實戰積累，沒有捷徑，遇到好幾個去參加過性能培訓的朋友，他們反饋說還是不會性能，操作起來同樣一臉懵逼、無從下手。
定位到問題了，大部分情況下，優化方案也就有了，測試可以把自己建議的優化方案告訴開發，開發會結合自己的方案，一起做優化方案評估；如果測試沒有優化方案，那就把問題反饋給開發吧，但是也好好學學開發的優化思路，這就是成長的過程。
測試是否通過？
優化方案務必寫詳細，以便上線同事知道，把優化同步到其它各個環境。
聲明：封面或正文部分圖片來源於網絡，如有侵權，請聯系刪除。
