如果你對性能測試感興趣，但是又不熟悉理論知識，可以看下面的系列文章
https://www.cnblogs.com/poloyy/category/1620792.html
性能測試的前提
必要性，是否有做性能測試的必要（關鍵項評估）
- 主管部門、監管部門審查
- 涉及生命財產安全
- 大型新系統
- 核心系統
- 架構調整
- 業務劇增
- 重大缺陷修復
可測性，可量化為性能指標值
- 一般有需求文檔，根據老板或者產品提出的需求，我們需要將里面的需求內容量化為性能指標值，這是我們的性能指標預期結果
- 如果無法量化的話，我們就沒有預期性能指標值，在性能測試中測出的性能指標值，沒有可對比的值，那就不知道是否滿足需求的需要
開展性能測試必備條件
獨立網絡
內網（zoom域）、外網獨立分開，千萬不要用跨內網外網
為什么要獨立網絡
- 在做性能測試會向服務器發送大量的請求，會有大量的網絡傳輸，可能會出現網絡堵塞
- 如果和功能測試人員使用的網絡相同，將會導致功能測試時請求響應時間變長
建議使用直連的局域網
- 這不意味着要單獨開辟一個條新的網線
- 注意：壓力機和服務器之間不要通過wifi、vpn、堡壘機、跳板機來連接，他們很容易網絡不穩定（如丟包），容易造成性能指標值不准確
- 建議：而使用局域網，有線網，壓力機和服務器相連接的網絡相對穩定，可以忽略網絡延遲等網絡因素影響性能測試結果
- 結論：如果連網絡都得不到保障的話，那么測出來的性能指標值則不可信了，因為性能結果很可能會受網絡因素的影響，從而導致和實際結果差異很大
如果使用公有雲服務器
有內網、外網，測試時一般都是用公網，而上行會比較寬，可以基本忽略網絡延遲
獨立環境
功能測試不能和性能測試共用環境（測試環境）
- 在做負載測試的時候，會短時間內占用大量的系統資源，如果此時有功能測試正在進行中，很可能會導致功能的不穩定或異常
- 在做壓力測試的時候，會長期占用系統的資源，導致一段時間內無法穩定進行功能測試
不能使用測試環境、生產環境
- 生產環境有真實用戶的各種數據，數據量肯定非常龐大【用戶數據龐大】
- 性能測試模擬大數據量測試，最終可能也會產生非常多的數據【產生數據】
- 這樣一來，真實用戶的數據+性能測試產生的數據混在一起，生產環境的數據量翻倍變多，會影響服務器對真實用戶請求的響應時間【生產數據量變大，影響真實用戶的響應時間】
- 性能測試產生的數據屬於臟數據，不應該出現在生產環境中，所以性能測試不能在生產環境中進行，但硬件環境要盡可能一致【臟數據】
結論
- 所以，做性能測試需要有單獨的一套環境，且硬件環境最好和生產環境一致
- 這樣性能測試最終得到系統所能承受的最大負載量會更接近在生產環境中，系統所能承受的最大負載量
性能測試步驟
性能測試准備
- 需求分析，熟悉業務：確定需要重點關注的點，如TPS、響應時間（確定需要收集的性能測試指標值）
- 明確性能測試目標（預期性能指標值）和測試范圍
- 了解軟件功能、架構
- 制定測試方案、測試計划，做好工作量評估
- 制定測試模型（編輯測試用例）：比如負載測試，場景要如何設計
搭建性能測試環境
- 技術准備：選擇性能測試工具；測試方案中涉及到的技術問題；測試數據的收集方案實現；如何監控系統資源
- 被測系統環境搭建（服務器、服務版本更新、數據庫數據准備）
- 網絡配置
- 創建初始數據，如：測試賬號（預估並發量）
性能測試腳本開發
- 選取協議
- 制作腳本
- 調試腳本
- 驗證腳本
性能測試執行
真正開始對服務器進行性能測試
- 試運行
- 場景執行
- 收集並整理測試數據
性能測試結果分析與調優
- 分析依據：結果圖表
- 分析思路：服務器硬件瓶頸>網絡瓶頸>服務器os瓶頸（參數配置、數據庫、web服務器）>應用瓶頸（sql語句、數據庫設計、業務邏輯、算法）
- 調優
- 修改腳本或場景
- 性能回歸，和之前的測試數據進行對比，是否有優化
服務器硬件瓶頸
如果性能測試環境和生產環境的硬件相差甚遠，那么硬件很大程度造成了性能瓶頸，也不用去分析后面可能會導致性能瓶頸的其他原因了
性能測試報告與結果跟蹤
- 性能測試報告：整理調優前后的測試數據
- 性能測試問題跟蹤
- 構建持久化的性能監聽平台，監聽線上服務器的系統資源