效能測試 - 基本概念
阿新 • • 發佈:2020-12-04
一、學習前的認知
我們在學習效能測試之前,需要有個新的認識
:效能測試,不再是像功能測試一樣單純的找 Bug,而是去找效能指標
1.1 轉變思維
- 在做
功能測試、自動化測試
的時候,我們基本都是依託介面
進行測試,也稱GUI 測試
,我們的目的就是為了跑通功能、程式,併成功找到 Bug - 但在做
效能測試
的時候,我們大部分是headless 模式
(所謂的:無頭,無介面模式
),目的不再是單純的為了找到 Bug,而是要分析效能指標
等等(後續講到)
1.2 效能測試的時間一般會比自動化、功能測試長,為啥?
- 因為效能測試的步驟跟自動化、功能測試的步驟不一樣,比如說
前期的準備
(瞭解系統,環境搭建),後期的` 壓力測試
(7*24h)等等- 在後面,我們通過講述效能測試步驟來仔細瞭解
1.3 效能測試一定要工具,手工不行嗎?
- 效能測試是模擬系統在被很多很多使用者同時使用時,系統能不能正常使用和提供服務
重點:
很多很多使用者功能測試:
一個人點點點就知道功能通不通
,有沒有 Bug 了效能測試:
用手工的話,可以模擬幾個、十幾個使用者,但是當需要模擬上千萬個使用者時
,手工又怎麼模擬資料量多的場景呢?類比,吃飯場景:
一個人可以吃好幾碗,但是叫你吃幾百碗是不可能的結論:
工具就可以模擬大資料量的場景,可以做到人做不到的事情
1.4 大資料量測試是效能測試嗎?
大資料量測試簡單理解:一個介面返回的資料比較多(假設:不使用分頁,把所有資料同時返回)
結論
- 返回大資料量的介面的
響應時間會變長
- 這麼大的資料量,我們需要考慮:
網路傳輸資料、伺服器查詢這些資料、伺服器處理這些資料
等等分別需要多少時間 - 這已經跟響應時間掛鉤,所以已經屬於效能測試的範圍,但不歸納於效能分析範圍
1.5 大資料測試是效能測試嗎?
大資料測試的功能屬於功能測試哦
1.6 效能測試過程發現問題需要立即提交嗎?
在效能測試過程中發現一些問題,假設定位到某一段程式碼有問題,可以截圖提交 Bug 給開發,但這並不是我們效能測試的最終目的,最終目的
是找出效能指標
1.6.1 有哪些效能指標?
- 比如說
響應時間
:10個人、100個人 、1000個人 、10000個人向伺服器發起請求,伺服器響應請求的平均響應時間是多少,這就是一個指標 - 又好比
TPS
:伺服器在當前的配置下,不同使用者數發起請求,伺服器的 TPS 處理能力是多少,這也是一個指標 - 後續詳細介紹
1.6.2 效能測試中發現的 Bug
- 效能測試過程中發現的 Bug 屬於一個衍生品,並不是最終得到的結果
- 但像功能測試,最終目的就是為了找出 Bug
1.6.3 關於這個問題的總結
- 做效能測試,當
資料量變大
後,會出現
連線超時、連線拒絕、500、502等異常問題
;在效能測試中,這些異常問題基本都會出現的
,但不會去立即提 Bug - 對於效能測試工程師,我們要做的是
分析為什麼
在當前資料量下會出現
連線超時、連線拒絕,響應時間超時、伺服器異常等異常問題
- 這就需要我們去分析效能瓶頸,並
不會
單獨去看某個異常問題出現在哪裡
,而是分析為什麼會出現
這個異常問題,分析的是伺服器或者是程式碼
,而不是讓開發人員馬上來修復這些異常問題
1.7、我們常說的壓測是指壓力測試嗎?
- 並不是,而是指
負載測試
,一般都是為了找出系統的最大負載量 - 就好像你老闆說:你去壓測下,看看系統能支撐多少使用者同時訪問我們的系統
二、什麼是效能測試?
2.1 狹義理解
- 通過工具,找出或獲得系統在不同工況下的效能指標值
- 效能測試過程中,重點是
找出效能指標
,而不再是找出 Bug, - 效能測試的產出絕對不只是 Bug
2.2 場景類比
跑步100米,用時多少?運動員的心跳、步伐頻率是多少?
- 跑步100米:業務場景
- 用時多少:響應時間
- 運動員的心跳、步伐:效能指標值
效能指標值和響應時間是否滿足當前業務場景的最低要求(合格線)
2.3 什麼時候能找出效能指標值
假設當前有一個業務,電商系統,下單業務,目前還不知道系統支援多少人同時下單,那麼我們需要找到伺服器能正常支援多少人同時下單
2.3.1 效能測試初始階段(第一次做)
- 先把基礎的效能指標值找出來
(第一次效能測試也叫做基準測試)
- 比如:100個人同時下單系統正常,但120個人同時下單就會出現部分請求的響應時間超長,連線異常
- 那麼100-120範圍內的某個值就是當前伺服器能達到的效能指標值
(基準值)
2.3.2 版本迭代,進行第二次做效能測試,重新跑一遍之前的效能指令碼
- 又會得到一些效能指標值,對比上個版本的
效能指標值
,看是否有優化(效能變化) - 假設這個時候120個人同時下單是正常的,150個人才有異常,那麼介面已經有優化了
2.3.3 假設公司是從0開始做效能測試
- 第一階段:做好效能測試,得到效能指標值
- 第二階段:假設效能比之前差,哪些效能指標值不滿足預期值,就需要分析是哪裡有問題
2.4 廣義理解
- 只要與伺服器效能指標相關的測試都屬於效能測試
- 比如:響應時間、併發使用者數、伺服器處理能力、吞吐量等效能指標
- 負載測試、壓力測試、容量測試、可靠性測試
都屬於
效能測試 - 通常嘴巴上說的做效能測試就是廣義的效能測試,它包括了很多內容,並不只是針對某一個測試型別
2.5 "官方"解釋
以下含義來源高老的解釋,比較“官方”的術語
- 效能測試針對系統的效能指標,建立效能測試模型
- 制定效能測試方案
- 制定監控策略
- 在場景條件下執行效能場景
- 分析判斷效能瓶頸並調優
- 最終得出效能結果來評估系統的效能指標是否滿足既定值
其實也算是一個簡潔描述的性測試流程了
2.6 注意
- 效能測試不像自動化測試那樣很多東西大家都是公認的,效能測試沒有一套標準的知識體系,只能說是相似的
- 基本每個人都有自己的一套知識體系,就好像高老也會說他給效能測試的定義很大可能會被轟炸一樣
- 只要屬於自己的知識體系建立起來了,那麼就能助力你正確的完成效能測試
- 不用太過糾結於哪個人對效能測試概念的解釋是最準確的
三、什麼是負載測試?
3.1 概念
逐步增加
系統負載,測試系統性能變化,並最終確定系統所能承受的最大負載量通俗理解:
看看你幾斤幾兩
3.2 如何增加負載
通過增加“使用者數”,就是常說的併發數
3.3 場景類比
天平秤,稱東西的時候,需要逐步加砝碼,最終達到砝碼和物品重量的平衡點,因為它不可能一下子就達到平衡點【好比不可能一下子找到系統能承受的最大負載量】
- 稱東西:業務場景
- 加砝碼:逐步加壓
- 達到平衡點:找到最大負載量
3.4 實際場景
- 有一個業務,增加到40個人的時候,伺服器還能正常使用,沒有異常
- 當你增加到50個人的時候,伺服器已經開始有異常了,那麼就能確定40-50之間某個值就是系統所能承受的最大負載量
【出現效能拐點,找到了伺服器效能瓶頸的範圍值】
- 最後減小加壓梯度(比如:從40個人開始每次增加1個人、2個人),確認最大負載量
【確認效能拐點】
3.5 伺服器又有哪些可能會出現的異常呢
- 響應時間超長:正常伺服器處理請求時間是 1s,但現在變成3s - 5s
- 服務報錯:無法同時正常響應多個請求
- 伺服器宕機:系統完全用不了
四、什麼是壓力測試?
4.1 概念
- 在較大的效能壓力下,持續執行一個比較長的時間,看看系統服務是否正常及系統資源的利用率情況
俗理解:
鴨梨山大!關鍵字:
較大壓力 + 較長時間注意:
不是滿負荷壓力哦
4.2 場景類比
問:
大傢什麼時候會覺得工作壓力大?
答:
996、007;因為你不會覺得955壓力山大吧
結論:
所以在我們日常工作中,長時間工作強度高,才會覺得壓力大;如果你一週就加班一天也說壓力大...(那就別幹這一行了)
4.3 壓力測試用來幹嘛的
測試系統的穩定性
4.4類比
工作壓力大,你還能堅持下去(那穩定性肯定好吧),那如果你很快就離職了(那穩定性肯定差,都宕機罷工了)
4.5 什麼時候會做壓力測試
- 生產環境下,系統隔三差五的出現不穩定的情況
- 這個時候,就需要通過壓力測試去測試系統的穩定性情況
4.5.1 啥情況算不穩定?穩定性差?
隔三差五的出現下面的情況
- 服務異常:響應錯誤、響應時間超時等
- 伺服器出現異常:宕機
4.5.2 怎麼分析是服務異常還是伺服器異常
- 如果所有請求都是一片紅,應用程式傳送的所有請求都報紅,就是伺服器出現了異常
- 如果有些請求偶爾成功響應,偶爾又失敗,則是服務異常,出現不穩定的情況
4.6 如何取壓力值
- 在負載測試中,我們確認了系統所能承受的最大負載量
- 壓力值 < 最大負載量,一般取
80%
左右
4.7 靈魂拷問
負載測試一般時間比較短,壓力測試時間比較長,持續執行時間短就能正常使用,但持續執行時間長就可能崩掉了,這是什麼原因呢?
4.7.1 場景類比
例子一:
電腦保持開機狀態很長時間,會逐漸變卡,因為記憶體的東西會越來越多,得不到有效的回收, 就會越來越卡例子二:
當你經常工作壓力很大,且你的心理所能承受的壓力逐漸達到最大值時,你就可能會選擇離職
4.7.2 總結
壓力測試長時間執行,可能會逐漸增加系統的記憶體佔用空間,若得不到有效的記憶體回收,當達到記憶體最大值時,系統就會崩掉
4.8 壓力測試持續執行時間要多久?
- 標準效能測試裡面,一般是
7*24
小時,或者是它的倍數 - 但是實際工作中,並不會這麼久,否則成本太高
- 所以會以
小時為單位
,比如:4個小時、8個小時...晚上下班之後做,第二天早上上班看結果
4.9 先負載測試還是壓力測試
- 先負載測試
- 負載測試可以找到伺服器效能瓶頸的範圍值,若生產環境中系統穩定性較差,再做壓力測試
- 所以
壓力測試是可做可不做的
五、什麼是可靠性測試
5.1 概念
- 在給定的一定的業務壓力下,持續執行一段時間,檢視系統是否穩定
關鍵字:
是否穩定,一定業務壓力注意:
不是較大壓力哦
5.2 業務場景栗子
電商秒殺場景,幾十個商品幾十萬個人同時秒殺搶購
5.3 如何理解可靠性測試
- 編寫效能指令碼:假設一秒內有一萬個人同時發起請求
- 有壓力嗎?
有
,一萬個人同時發起請求 - 但是持續時間
短
,不像壓力測試一樣需要持續一段時間 - 目的是為了驗證當這麼多人同時發起請求時,成功秒殺的使用者能否繼續完成後續下單付款等操作
【一定業務壓力下,系統是否穩定執行】
六 什麼是容量測試
6.1 概念
- 在一定的軟、硬體條件下,在資料庫不同資料量級資料量的情況下,對系統中
讀/寫比較多的業務
進行測試,從而獲得不同資料量級下的效能指標值 關鍵字:
不同資料量級
6.1 資料庫資料量對效能測試結果有沒有影響?
肯定有
- 比如資料庫已經有
幾百條
資料和幾百萬條
資料,查詢的速度肯定不一樣,所以肯定會影響效能測試結果 - 資料量級的差異,會影響TPS、響應時間、網路等