大話性能測試系列（1）- 性能測試概念與主要指標

若是你對性能測試感興趣，可是又不熟悉理論知識，能夠看下面的系列文章

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
• 服務報錯：沒法同時正常響應多個請求
• 服務器宕機：系統徹底用不了

 

什麼是壓力測試？

概念

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

 

場景類比

問：你們何時會以爲工做壓力大？

答：99六、007；由於你不會以爲955壓力山大吧

結論：因此在咱們平常工做中，長時間工做強度高，纔會以爲壓力大；若是你一週就加班一天也說壓力大...（那就別幹這一行了）

 

壓力測試用來幹嗎的

測試系統的穩定性

 

類比

工做壓力大，你還能堅持下去（那穩定性確定好吧），那若是你很快就離職了（那穩定性確定差，都宕機罷工了）

 

何時會作壓力測試

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

 

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

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

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

 

怎麼分析是服務異常仍是服務器異常 

• 若是全部請求都是一片紅，應用程序發送的全部請求都報紅，就是服務器出現了異常
• 若是有些請求偶爾成功響應，偶爾又失敗，則是服務異常，出現不穩定的狀況

 

如何取壓力值

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

 

靈魂拷問

負載測試通常時間比較短，壓力測試時間比較長，持續運行時間短就能正常使用，但持續運行時間長就可能崩掉了，這是什麼緣由呢？

 

場景類比

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

 

總結

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

 

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

• 標準性能測試裏面，通常是7*24小時，或者是它的倍數
• 可是實際工做中，並不會這麼久，不然成本過高
• 因此會以小時爲單位，好比：4個小時、8個小時...晚上下班以後作，次日早上上班看結果

 

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

• 先負載測試
• 負載測試能夠找到服務器性能瓶頸的範圍值，若生產環境中系統穩定性較差，再作壓力測試
• 因此壓力測試是可作可不作的

 

什麼是可靠性測試？

概念

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

 

業務場景栗子

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

 

如何理解可靠性測試

1. 編寫性能腳本：假設一秒內有一萬我的同時發起請求
2. 有壓力嗎？有，一萬我的同時發起請求
3. 可是持續時間短，不像壓力測試同樣須要持續一段時間
4. 目的是爲了驗證當這麼多人同時發起請求時，成功秒殺的用戶可否繼續完成後續下單付款等操做【必定業務壓力下，系統是否穩定運行】

 

什麼是容量測試？

概念

• 在必定的軟、硬件條件下，在數據庫不一樣數據量級數據量的狀況下，對系統中讀/寫比較多的業務進行測試，從而得到不一樣數據量級下的性能指標值
• 關鍵字：不一樣數據量級

 

數據庫數據量對性能測試結果有沒有影響？

確定有

• 好比數據庫已經有幾百條數據和幾百萬條數據，查詢的速度確定不同，因此確定會影響性能測試結果
• 數據量級的差別，會影響TPS、響應時間、網絡等

 

場景類比

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

 

性能測試的前提

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

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

 

可測性，可量化爲性能指標值

通常有需求文檔，根據老闆或者產品提出的需求，咱們須要將裏面的內容量化爲性能指標值，這是咱們的預期結果，若是沒法量化的話，咱們就沒有預期性能指標值，在性能測試完成得出性能指標值後，沒有可對比的值，那就不知道是否知足需求的須要

 

開展性能測試必備條件

網絡要求

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

 

獨立環境

功能測試不能和性能測試共用環境（測試環境）

• 在作負載測試的時候，會短期內佔用大量的系統資源，若是此時有功能測試正在進行中，極可能會致使功能的不穩定或異常
• 在作壓力測試的時候，會長期佔用系統的資源，致使一段時間內沒法穩定進行功能測試

 

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

• 生產環境有真實用戶的各類數據，數據量確定很是龐大【用戶數據】
• 性能測試模擬大數據量測試，最終可能也會產生很是多的數據【產生數據】
• 這樣一來，真實用戶的數據+性能測試產生的數據混在一塊兒，生產環境的數據量翻倍變多，會影響服務器對真實用戶請求的響應時間【數據量變大，影響響應時間】
• 性能測試產生的數據屬於髒數據，不該該出如今生產環境中，因此性能測試不能在生產環境中進行，但硬件環境要儘量一致【髒數據】

 

結論

• 因此，作性能測試須要有單獨的一套環境，且硬件環境最好和生產環境一致
• 這樣性能測試最終獲得系統所能承受的最大負載量會更接近在生產環境中，系統所能承受的最大負載量

 

性能測試步驟

性能測試準備

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

 

搭建性能測試環境

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

 

性能測試腳本開發

• 選取協議
• 製做腳本
• 調試腳本
• 驗證腳本

 

性能測試執行

真正開始對服務器進行性能測試

• 試運行
• 場景執行

 

性能測試結果分析與調優

• 分析依據：結果圖表
• 分析思路：服務器硬件瓶頸>網絡瓶頸>服務器os瓶頸（參數配置、數據庫、web服務器）>應用瓶頸（sql語句、數據庫設計、業務邏輯、算法）
• 調優
• 修改腳本或場景

 

服務器硬件瓶頸

若是性能測試環境和生產環境的硬件相差甚遠，那麼很明顯就是硬件的問題，也不用去分析後面可能會致使瓶頸的緣由了

 

性能測試報告與結果跟蹤

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