如果你對性能測試感興趣，但是又不熟悉理論知識，可以看下面的系列文章
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米，用時多少？運動員的心跳、步伐頻率是多少？
- 跑步100米：業務場景
- 用時多少：響應時間
- 運動員的心跳、步伐：性能指標值
性能指標值和響應時間是否滿足當前業務場景的最低要求（合格線）
什麼時候能找出性能指標值
假設當前有一個業務
電商系統，下單業務，目前還不知道系統支持多少人同時下單，那麼我們需要找到服務器能正常支持多少人同時下單
性能測試初始階段（第一次做）
- 先把基礎的性能指標值找出來（第一次性能測試也叫做基準測試）
- 比如：100個人同時下單系統正常，但120個人同時下單就會出現部分請求的響應時間超長，連接異常
- 那麼100-120範圍內的某個值就是當前服務器能達到的性能指標值（基準值）
版本迭代，進行第二次做性能測試，重新跑一遍之前的性能腳本
- 又會得到一些性能指標值，對比上個版本的性能指標值，看是否有優化（性能變化）
- 假設這個時候120個人同時下單是正常的，150個人才有異常，那麼接口已經有優化了
假設公司是從0開始做性能測試
- 第一階段：做好性能測試，得到性能指標值
- 第二階段：假設性能比之前差，哪些性能指標值不滿足預期值，就需要分析是哪裡有問題
廣義理解
- 只要與服務器性能指標相關的測試都屬於性能測試
- 比如：響應時間、併發用戶數、服務器處理能力、吞吐量等性能指標
- 負載測試、壓力測試、容量測試、可靠性測試都屬於性能測試
- 通常嘴巴上說的做性能測試就是廣義的性能測試，它包括了很多內容，並不只是針對某一個測試類型
“官方”解釋
以下含義來源高老的解釋，比較“官方”的術語
- 性能測試針對系統的性能指標，建立性能測試模型
- 制定性能測試方案
- 制定監控策略
- 在場景條件下執行性能場景
- 分析判斷性能瓶頸並調優
- 最終得出性能結果來評估系統的性能指標是否滿足既定值
其實也算是一個簡潔描述的性測試流程了
注意
- 性能測試不像自動化測試那樣很多東西大家都是公認的，性能測試沒有一套標準的知識體系，只能說是相似的
- 基本每個人都有自己的一套知識體系，就好像高老也會說他給性能測試的定義很大可能會被轟炸一樣
- 只要屬於自己的知識體系建立起來了，那麼就能助力你正確的完成性能測試
- 不用太過糾結於哪個人對性能測試概念的解釋是最準確的
目前博主是正在學習性能測試的小白一枚，希望通過通俗簡單的術語來學懂性能測試，打造屬於自己的知識體系，歡迎大家進群與我溝通（870155189）
什麼是負載測試？
概念
- 逐步增加系統負載，測試系統性能變化，並最終確定系統所能承受的最大負載量
- 通俗理解：看看你幾斤幾兩
如何增加負載
通過增加“用戶數”，就是常說的併發數
場景類比
天平秤，稱東西的時候，需要逐步加砝碼，最終達到砝碼和物品重量的平衡點，因為它不可能一下子就達到平衡點【好比不可能一下子找到系統能承受的最大負載量】
- 稱東西：業務場景
- 加砝碼：逐步加壓
- 達到平衡點：找到最大負載量
實際場景
- 有一個業務，增加到40個人的時候，服務器還能正常使用，沒有異常
- 當你增加到50個人的時候，服務器已經開始有異常了，那麼就能確定40-50之間某個值就是系統所能承受的最大負載量【出現性能拐點，找到了服務器性能瓶頸的範圍值】
- 最後減小加壓梯度（比如：從40個人開始每次增加1個人、2個人），確認最大負載量【確認性能拐點】
服務器又有哪些可能會出現的異常呢
- 響應時間超長：正常服務器處理請求時間是 1s，但現在變成3s – 5s
- 服務報錯：無法同時正常響應多個請求
- 服務器宕機：系統完全用不了
什麼是壓力測試？
概念
- 在較大的性能壓力下，持續運行一個比較長的時間，看看系統服務是否正常及系統資源的利用率情況
- 通俗理解：鴨梨山大！
- 關鍵字：較大壓力 + 較長時間
- 注意：不是滿負荷壓力哦
場景類比
問：大家什麼時候會覺得工作壓力大？
答：996、007；因為你不會覺得955壓力山大吧
結論：所以在我們日常工作中，長時間工作強度高，才會覺得壓力大；如果你一周就加班一天也說壓力大…（那就別干這一行了）
壓力測試用來幹嘛的
測試系統的穩定性
類比
工作壓力大，你還能堅持下去（那穩定性肯定好吧），那如果你很快就離職了（那穩定性肯定差，都宕機罷工了）
什麼時候會做壓力測試
- 生產環境下，系統隔三差五的出現不穩定的情況
- 這個時候，就需要通過壓力測試去測試系統的穩定性情況
啥情況算不穩定？穩定性差？
隔三差五的出現下面的情況
- 服務異常：響應錯誤、響應時間超時等
- 服務器出現異常：宕機
怎麼分析是服務異常還是服務器異常
- 如果所有請求都是一片紅，應用程序發送的所有請求都報紅，就是服務器出現了異常
- 如果有些請求偶爾成功響應，偶爾又失敗，則是服務異常，出現不穩定的情況
如何取壓力值
- 在負載測試中，我們確認了系統所能承受的最大負載量
- 壓力值 < 最大負載量，一般取80%左右
靈魂拷問
負載測試一般時間比較短，壓力測試時間比較長，持續運行時間短就能正常使用，但持續運行時間長就可能崩掉了，這是什麼原因呢？
場景類比
- 栗子一：電腦保持開機狀態很長時間，會逐漸變卡，因為內存的東西會越來越多，得不到有效的回收， 就會越來越卡
- 栗子二：當你經常工作壓力很大，且你的心理所能承受的壓力逐漸達到最大值時，你就可能會選擇離職
總結
壓力測試長時間運行，可能會逐漸增加系統的內存佔用空間，若得不到有效的內存回收，當達到內存最大值時，系統就會崩掉
壓力測試持續運行時間要多久？
- 標準性能測試裏面，一般是7*24小時，或者是它的倍數
- 但是實際工作中，並不會這麼久，否則成本太高
- 所以會以小時為單位，比如：4個小時、8個小時…晚上下班之後做，第二天早上上班看結果
先負載測試還是壓力測試？
- 先負載測試
- 負載測試可以找到服務器性能瓶頸的範圍值，若生產環境中系統穩定性較差，再做壓力測試
- 所以壓力測試是可做可不做的
什麼是可靠性測試？
概念
- 在給定的一定的業務壓力下，持續運行一段時間，查看系統是否穩定
- 關鍵字：是否穩定，一定業務壓力
- 注意：不是較大壓力哦
業務場景栗子
電商秒殺場景，幾十個商品幾十萬個人同時秒殺搶購
如何理解可靠性測試
- 編寫性能腳本：假設一秒內有一萬個人同時發起請求
- 有壓力嗎？有，一萬個人同時發起請求
- 但是持續時間短，不像壓力測試一樣需要持續一段時間
- 目的是為了驗證當這麼多人同時發起請求時，成功秒殺的用戶能否繼續完成後續下單付款等操作【一定業務壓力下，系統是否穩定運行】
什麼是容量測試？
概念
- 在一定的軟、硬件條件下，在數據庫不同數據量級數據量的情況下，對系統中讀/寫比較多的業務進行測試，從而獲得不同數據量級下的性能指標值
- 關鍵字：不同數據量級
數據庫數據量對性能測試結果有沒有影響？
肯定有
- 比如數據庫已經有幾百條數據和幾百萬條數據，查詢的速度肯定不一樣，所以肯定會影響性能測試結果
- 數據量級的差異，會影響TPS、響應時間、網絡等
場景類比
從一袋米中找一個綠豆，和一碗米中找一個綠豆，找的時間肯定是千差萬別的
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※超省錢租車方案
※教你寫出一流的銷售文案?
※網頁設計最專業,超強功能平台可客製化
※產品缺大量曝光嗎?你需要的是一流包裝設計!