如果你對效能測試感興趣，但是又不熟悉理論知識，可以看下面的系列文章

https://www.cnblogs.com/poloyy/category/1620792.html

學習前的認知

我們在學習效能測試之前，需要有個新的認識：效能測試，不再是像功能測試一樣單純的找 Bug，而是去找效能指標

轉變思維

• 在做功能測試、自動化測試的時候，我們基本都是依託介面進行測試，也稱 GUI 測試，我們的目的就是為了跑通功能、程式，併成功找到 Bug
• 但在做效能測試的時候，我們大部分是 headless 模式（所謂的：無頭，無介面模式），目的不再是單純的為了找到 Bug，而是要分析效能指標等等（後續講到）

效能測試的時間一般會比自動化、功能測試長，為啥？

• 因為效能測試的步驟跟自動化、功能測試的步驟不一樣，比如說前期的準備（瞭解系統，環境搭建），後期的壓力測試（7*24h）等等
• 在後面，我們通過講述效能測試步驟來仔細瞭解

效能測試一定要工具，手工不行嗎？

• 效能測試是模擬系統在被很多很多使用者同時使用時，系統能不能正常使用和提供服務
• 重點：很多很多使用者
• 功能測試：一個人點點點就知道功能通不通，有沒有 Bug 了
• 效能測試：用手工的話，可以模擬幾個、十幾個使用者，但是當需要模擬上千萬個使用者時，手工又怎麼模擬資料量多的場景呢？
• 類比，吃飯場景：一個人可以吃好幾碗，但是叫你吃幾百碗是不可能的
• 結論：工具就可以模擬大資料量的場景，可以做到人做不到的事情

大資料量測試是效能測試嗎？

大資料量測試

簡單理解：一個介面返回的資料比較多（假設：不使用分頁，把所有資料同時返回）

結論

• 返回大資料量的介面的響應時間會變長
• 這麼大的資料量，我們需要考慮：網路傳輸資料、伺服器查詢這些資料、伺服器處理這些資料等等分別需要多少時間
• 這已經跟響應時間掛鉤，所以已經屬於效能測試的範圍，但不歸納於效能分析範圍

大資料測試是效能測試嗎？

大資料測試的功能屬於功能測試哦

效能測試過程發現問題需要立即提交嗎？

在效能測試過程中發現一些問題，假設定位到某一段程式碼有問題，可以截圖提交 Bug 給開發，但這並不是我們效能測試的最終目的，最終目的是找出效能指標

有哪些效能指標？

• 比如說響應時間：10個人、100個人 、1000個人 、10000個人向伺服器發起請求，伺服器響應請求的平均響應時間是多少，這就是一個指標
• 又好比TPS：伺服器在當前的配置下，不同使用者數發起請求，伺服器的 TPS 處理能力是多少，這也是一個指標
• 後續詳細介紹

效能測試中發現的 Bug 

• 效能測試過程中發現的 Bug 屬於一個衍生品，並不是最終得到的結果
• 但像功能測試，最終目的就是為了找出 Bug

關於這個問題的總結

• 做效能測試，當資料量變大後，會出現連線超時、連線拒絕、500、502等異常問題；在效能測試中，這些異常問題基本都會出現的，但不會去立即提 Bug
• 對於效能測試工程師，我們要做的是分析為什麼在當前資料量下會出現連線超時、連線拒絕，響應時間超時、伺服器異常等異常問題
• 這就需要我們去分析效能瓶頸，並不會單獨去看某個異常問題出現在哪裡，而是分析為什麼會出現這個異常問題，分析的是伺服器或者是程式碼，而不是讓開發人員馬上來修復這些異常問題

我們常說的壓測是指壓力測試嗎？

• 並不是，而是指負載測試，一般都是為了找出系統的最大負載量
• 就好像你老闆說：你去壓測下，看看系統能支撐多少使用者同時訪問我們的系統

什麼是效能測試？

狹義理解

• 通過工具，找出或獲得系統在不同工況下的效能指標值
• 效能測試過程中，重點是找出效能指標，而不再是找出 Bug，
• 效能測試的產出絕對不只是 Bug

場景類比

跑步100米，用時多少？運動員的心跳、步伐頻率是多少？

1. 跑步100米：業務場景
2. 用時多少：響應時間
3. 運動員的心跳、步伐：效能指標值

效能指標值和響應時間是否滿足當前業務場景的最低要求（合格線）

什麼時候能找出效能指標值

假設當前有一個業務

電商系統，下單業務，目前還不知道系統支援多少人同時下單，那麼我們需要找到伺服器能正常支援多少人同時下單

效能測試初始階段（第一次做）

• 先把基礎的效能指標值找出來（第一次效能測試也叫做基準測試）
• 比如：100個人同時下單系統正常，但120個人同時下單就會出現部分請求的響應時間超長，連線異常
• 那麼100-120範圍內的某個值就是當前伺服器能達到的效能指標值（基準值）

版本迭代，進行第二次做效能測試，重新跑一遍之前的效能指令碼

• 又會得到一些效能指標值，對比上個版本的效能指標值，看是否有優化（效能變化）
• 假設這個時候120個人同時下單是正常的，150個人才有異常，那麼介面已經有優化了

假設公司是從0開始做效能測試

• 第一階段：做好效能測試，得到效能指標值
• 第二階段：假設效能比之前差，哪些效能指標值不滿足預期值，就需要分析是哪裡有問題

廣義理解

• 只要與伺服器效能指標相關的測試都屬於效能測試
• 比如：響應時間、併發使用者數、伺服器處理能力、吞吐量等效能指標
• 負載測試、壓力測試、容量測試、可靠性測試都屬於效能測試
• 通常嘴巴上說的做效能測試就是廣義的效能測試，它包括了很多內容，並不只是針對某一個測試型別

 什麼是負載測試？

概念

• 逐步增加系統負載，測試系統性能變化，並最終確定系統所能承受的最大負載量
• 通俗理解：看看你幾斤幾兩

如何增加負載

通過增加“使用者數”，就是常說的併發數

場景類比

天平秤，稱東西的時候，需要逐步加砝碼，最終達到砝碼和物品重量的平衡點，因為它不可能一下子就達到平衡點【好比不可能一下子找到系統能承受的最大負載量】

• 稱東西：業務場景
• 加砝碼：逐步加壓
• 達到平衡點：找到最大負載量

實際場景

• 有一個業務，增加到40個人的時候，伺服器還能正常使用，沒有異常
• 當你增加到50個人的時候，伺服器已經開始有異常了，那麼就能確定40-50之間某個值就是系統所能承受的最大負載量【出現效能拐點，找到了伺服器效能瓶頸的範圍值】
• 最後減小加壓梯度（比如：從40個人開始每次增加1個人、2個人），確認最大負載量【確認效能拐點】

伺服器又有哪些可能會出現的異常呢

• 響應時間超長：正常伺服器處理請求時間是 1s，但現在變成3s - 5s
• 服務報錯：無法同時正常響應多個請求
• 伺服器宕機：系統完全用不了

什麼是壓力測試？

概念

• 在較大的效能壓力下，持續執行一個比較長的時間，看看系統服務是否正常及系統資源的利用率情況
• 通俗理解：鴨梨山大！
• 關鍵字：較大壓力 + 較長時間
• 注意：不是滿負荷壓力哦

場景類比

問：大傢什麼時候會覺得工作壓力大？

答：996、007；因為你不會覺得955壓力山大吧

結論：所以在我們日常工作中，長時間工作強度高，才會覺得壓力大；如果你一週就加班一天也說壓力大...（那就別幹這一行了）

壓力測試用來幹嘛的

測試系統的穩定性

類比

工作壓力大，你還能堅持下去（那穩定性肯定好吧），那如果你很快就離職了（那穩定性肯定差，都宕機罷工了）

什麼時候會做壓力測試

• 生產環境下，系統隔三差五的出現不穩定的情況
• 這個時候，就需要通過壓力測試去測試系統的穩定性情況

啥情況算不穩定？穩定性差？

隔三差五的出現下面的情況

• 服務異常：響應錯誤、響應時間超時等
• 伺服器出現異常：宕機

怎麼分析是服務異常還是伺服器異常 

• 如果所有請求都是一片紅，應用程式傳送的所有請求都報紅，就是伺服器出現了異常
• 如果有些請求偶爾成功響應，偶爾又失敗，則是服務異常，出現不穩定的情況

如何取壓力值

• 在負載測試中，我們確認了系統所能承受的最大負載量
• 壓力值 < 最大負載量，一般取80%左右

靈魂拷問

負載測試一般時間比較短，壓力測試時間比較長，持續執行時間短就能正常使用，但持續執行時間長就可能崩掉了，這是什麼原因呢？

場景類比

• 栗子一：電腦保持開機狀態很長時間，會逐漸變卡，因為記憶體的東西會越來越多，得不到有效的回收， 就會越來越卡
• 栗子二：當你經常工作壓力很大，且你的心理所能承受的壓力逐漸達到最大值時，你就可能會選擇離職

總結

壓力測試長時間執行，可能會逐漸增加系統的記憶體佔用空間，若得不到有效的記憶體回收，當達到記憶體最大值時，系統就會崩掉

壓力測試持續執行時間要多久？

• 標準效能測試裡面，一般是7*24小時，或者是它的倍數
• 但是實際工作中，並不會這麼久，否則成本太高
• 所以會以小時為單位，比如：4個小時、8個小時...晚上下班之後做，第二天早上上班看結果

先負載測試還是壓力測試？

• 先負載測試
• 負載測試可以找到伺服器效能瓶頸的範圍值，若生產環境中系統穩定性較差，再做壓力測試
• 所以壓力測試是可做可不做的

什麼是可靠性測試？

概念

• 在給定的一定的業務壓力下，持續執行一段時間，檢視系統是否穩定
• 關鍵字：是否穩定，一定業務壓力
• 注意：不是較大壓力哦

業務場景栗子

電商秒殺場景，幾十個商品幾十萬個人同時秒殺搶購

如何理解可靠性測試

1. 編寫效能指令碼：假設一秒內有一萬個人同時發起請求
2. 有壓力嗎？有，一萬個人同時發起請求
3. 但是持續時間短，不像壓力測試一樣需要持續一段時間
4. 目的是為了驗證當這麼多人同時發起請求時，成功秒殺的使用者能否繼續完成後續下單付款等操作【一定業務壓力下，系統是否穩定執行】

什麼是容量測試？

概念

• 在一定的軟、硬體條件下，在資料庫不同資料量級資料量的情況下，對系統中讀/寫比較多的業務進行測試，從而獲得不同資料量級下的效能指標值
• 關鍵字：不同資料量級

資料庫資料量對效能測試結果有沒有影響？

肯定有

• 比如資料庫已經有幾百條資料和幾百萬條資料，查詢的速度肯定不一樣，所以肯定會影響效能測試結果
• 資料量級的差異，會影響TPS、響應時間、網路等

場景類比

從一袋米中找一個綠豆，和一碗米中找一個綠豆，找的時間肯定是千差萬別的

效能測試的前提

必要性，是否有做效能測試的必要（關鍵項評估）

• 主管部門、監管部門審查
• 涉及生命財產安全
• 大型新系統
• 核心系統
• 架構調整
• 業務劇增
• 重大缺陷修復

可測性，可量化為效能指標值

一般有需求文件，根據老闆或者產品提出的需求，我們需要將裡面的內容量化為效能指標值，這是我們的預期結果，如果無法量化的話，我們就沒有預期效能指標值，在效能測試完成得出效能指標值後，沒有可對比的值，那就不知道是否滿足需求的需要

開展效能測試必備條件

網路要求

內網（zoom域） 外網獨立分開，千萬不要用跨內網外網

獨立環境

功能測試不能和效能測試共用環境

不能使用測試環境、生產環境

生產環境有真實使用者的各種資料，資料量肯定非常龐大

而效能測試也會模擬大資料量，也會產生非常龐大的資料

這樣一來，真實使用者的資料+效能測試產生的資料混在一起，資料量翻倍變多，會影響真實使用者

效能測試步驟

效能測試準備

• 需求分析，熟悉業務：確定需要重點關注的點，如TPS、響應時間
• 明確性能測試目標（預期效能指標值）
• 瞭解軟體功能、架構
• 指定測試計劃，做好工作量評估
• 制定測試模型（編輯測試用例）：比如負載測試，場景如何設計

搭建效能測試環境

• 工具選型與準備
• 被測系統環境搭建（伺服器、服務版本更新、資料庫資料準備）
• 網路配置

效能測試指令碼開發

• 選取協議
• 製作指令碼
• 除錯指令碼
• 驗證指令碼

效能測試執行

真正開始對伺服器進行效能測試

• 試執行
• 場景執行

效能測試結果分析與調優

• 分析依據：結果圖表
• 分析思路：伺服器硬體瓶頸>網路瓶頸>伺服器os瓶頸（引數配置、資料庫、web伺服器）>應用瓶頸（sql語句、資料庫設計、業務邏輯、演算法）
• 調優
• 修改指令碼或場景

伺服器硬體瓶頸

如果效能測試環境和生產環境的硬體相差甚遠，那麼很明顯就是硬體的問題，也不用去分析後面可能會導致瓶頸的原因了

效能測試報告與結果跟蹤

• 效能測試報告
• 效能測試問題跟蹤

&n