聊一聊性能測試

提到性能測試，不少從業相關人員可能會感受比較混淆。

性能測試，它是屬於測試領域一個專業細分領域，和軟件測試同樣，性能測試涉及到的範圍和所須要的技能是很是廣而精的，若是從大的類型來劃分的話性能測試能夠被分爲：

服務端性能測試 | 客戶端性能測試 | 全鏈路性能測試

這三種性能測試它的關注點及關注指標都是不同的，本系列以服務端性能測試展開，客戶端性能測試及全鏈路性能測試不在此係列說明

什麼是服務端性能測試？

那麼，什麼是服務端性能測試呢？

從你們熟悉的功能測試舉例吧！好比測試一個簡單登陸功能，在只考慮正常流程的狀況下無非就是輸入正確的帳戶和密碼點擊登陸，而後跳轉到系統首頁。

注意，這裏的登陸是隻考慮正常流程的狀況下，而在這裏功能測試也不是重點。

那麼，如何對該登陸功能進行性能測試呢？

就是在確保功能測試已經經過的狀況下，模擬多個用戶同時進行登陸，在這過程當中監控系統的各項性能指標及服務器硬件資源的使用狀況。

看到這裏，相信許多人都以爲比較簡單。雖然簡單，可是這例子已經包含的性能測試的三個基本特色。

• 功能測試已經過

• 必定的併發用戶

• 監控各項性能指標與硬件資源使用狀況

最後，在明確下什麼是性能測試：性能測試是在有性能測試指標的前提下模擬多個用戶對系統進行操做（請求），監控系統的各項性能測試指標與服務器資源是否達到咱們的一個預期值。

功能測試的測重點是測試功能是否與需求說明書一致，性能測試的測重點是測試系統是否符合咱們預期的一個性能指標。各位千萬別搞錯了哦！

性能測試類型？

根據不一樣的測試目的，性能測試能夠大體分爲五種類型，類型以下：

• 基準測試

• 負載測試

• 壓力測試

• 疲勞強度測試

• 穩定性測試

• 容量測試

性能測試類型概念？

基準測試：

基準測試是指模擬單個用戶執行業務場景，監控系統的性能指標與服務器資源。嚴格來講，基準測試不屬於性能測試的範疇，它與功能測試其實沒有太大的區別。具體的差別在於，基準測試的目的更多的是關注業務功能及驗證腳本的一個準確性，而後，將基準測試時採集到的結果（各項性能指標及服務器硬件資源）做爲後續併發測試性能分析的一個參考依據。

負載測試：

**負載測試是模擬系統在正常負載壓力場景下，考察系統的各項性能指標**。這裏說的正常負載，主要是指用戶對系統能承受的最大負載量的指望值。即預計系統最大可用支持的業務併發用戶數。**經過負載測試，能夠驗證系統是否能知足咱們預期的一個業務壓力場景**。

一般負載測試類型是最典型的性能測試類型。經過負載測試，獲得系統的性能拐點（最佳性能點），當達到這個點時，系統的極限與表現能力又是多少！負載測試也常常用於線上流量評估。

壓力測試：

壓力測試是測試系統在多大併發壓力下系統的性能會變得不可接受，或者出現性能拐點（崩潰）。在加壓策略上，壓力測試會對被測系統逐步加壓，在加壓的過程當中考察系統性能指標的走勢狀況，最終找出系統在出現性能拐點時的併發用戶數，也就是系統支持的最大併發用戶數。

壓力測試主要用於測試系統或系統某些部分的極限能力。經過一直增長負載，直到應用的部分功能不能正常工做，壓力測試的**目的是找到被測系統的容量天花板**。

看到這裏，是否是以爲負載測試和壓力測試好像沒啥差異。其實仍是有很大區別的！

• 目的不同。負載測試是驗證系統是否知足預期的業務壓力場景；而壓力測試是找到測試系統的容量天花板。

• 負載測試是模擬多個用戶不一樣時間段內持續向系統發送請求的，而壓力測試是模擬同一時間段內持續不斷的向系統發送請求的。

  若是各位還有不一樣看法的話能夠評論區下留言哦！

疲勞強度測試：

疲勞強度測試與負載測試testing以爲挺接近的，都是對系統模擬出系統能承受的最大業務負載量。差別在於，疲勞強度測試的側重點是系統在長時間運行狀況下系統各項性能指標的變化狀況。例如：系統在運行24 * 3後，是否會出現事務處理失敗、響應時間增加、業務吞吐量下降、CPU/內存資源增加等性能問題。

穩定性測試：

穩定性測試是測試被測系統持續正確運行的週期長度。

看到這裏，是否是以爲疲勞強度測試和穩定性測試很像，感受是一個東西，其實不是的。

穩定性測試是指被測系統被用戶正常的使用，能持續多長時間運行而不出現錯誤。而疲勞強度測試是指被測系統能夠支持的最大併發數長時間模擬運行業務，經過資源和性能指標側面分析系統的穩定性。

說到這，知道了穩定性測試須要花費的大量時間（如上月、上年）。因此大部分狀況下，用疲勞強度測試來替代穩定性測試。

容量測試:

當系統業務愈來愈複雜的時候，好比雙11、春節等大促。咱們應該怎麼評估線上的性能？如何去作合理的擴容？這個時候就須要開展相應的容量測試了。

其實說到這裏，經過對比能夠發現，不一樣的性能測試類型，其本質的差別仍是體如今了加壓策略上，而採用哪一種加壓策略，就取決於咱們性能測試的目的，即但願經過性能測試發現什麼問題。本節能夠總結出性能測試不一樣類型的重點在於加壓的方式及策略。

性能測試指標:

通常來講，性能測試指標從維度上劃分的話，主要能夠分爲兩大類，分別是**業務性能指標和系統資源性能指標。**這裏貼下百度的答案，具體的小編也有點忘了。

業務性能指標能夠直觀地反映被測系統的實際性能情況，常見的指標項有：

• **併發用戶數**
• **事務吞吐率（TPS/RPS）**
• **事務平均響應時間**
• **事務成功率**

系統資源性能指標主要是反映整個系統環境的硬件資源的一個使用狀況，常見的指標項有：

• 服務器：

CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁盤IO狀態、網卡帶寬使用狀況等。

• 數據庫：

數據庫鏈接數、數據庫讀寫響應時長、數據庫讀寫吞吐量等；

• 網絡：

網絡吞吐量、網絡帶寬、網絡緩衝池大小；

• 緩存（Redis）：

靜態資源緩存命中率、動態數據緩存命中率、緩存吞吐量等；

• 測試設備（壓力發生器）：

CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁盤IO狀態、網卡帶寬使用狀況等。

看到最後一項（測試設備）有些人可能會問了，監控被測系統環境的相關硬件資源使用狀況時，爲何還要關注測試設備自己呢？由於測試設備在模擬高併發請求的過程當中，測試設備自己也會存在較高的資源消耗，例如CPU、內存、網卡帶寬吃滿，磁盤IO讀寫頻繁，處理器排隊嚴重等；當出現這類狀況後，測試設備自己就出現了瓶頸，沒法產生預期的併發壓力，從而在測試中獲得的數據也就不具備可參考性了。

說到這裏，性能測試指標之間一般都是有密切關聯的。若是單純地看某個指標每每很難定位出性能瓶頸，因此須要咱們對各項性能指標的含義瞭然於胸，而後才能在實際測試的過程當中對系統性能情況綜合進行分析，找出系統真正的瓶頸。

舉個例子，在壓力測試時發現服務器端CPU利用率很是高，那這個能說明什麼問題呢？是服務端系統算法問題呢，仍是服務器硬件資源配置跟不上呢？光看這個指標並不能定位出產生問題的根本緣由，若是僅由於這一點，就決定直接去優化系統算法或者升級服務器配置，最後也很難真正地去解決問題。

是否是說到這裏就明白了，**性能瓶頸定位的重點在於性能測試指標的監控和分析**。

性能測試開展:

前面說了那麼多理論，那麼實際工做又是怎麼開展的呢？結合具體的一個實際狀況，小編以爲下面這流程是比較標準的。

• 瞭解&獲取性能測試需求，肯定性能目標

• 設計及肯定測試方案|測試計劃

• 提取測試的業務場景，設計測試用例

• 構建性能測試環境

• 編寫性能測試腳本和基準測試

• 執行性能測試和分析

• 測試結果分析和報告

性能測試工具推薦:

性能測試的主要手段是經過模擬真實業務的壓力對被測系統進行加壓，同時監控被測系統的各項性能指標，分析被測系統在不一樣壓力狀況下的表現，找出其潛在的性能瓶頸。

那麼，如何對系統進行加壓，又如何對系統的指標進行監控呢？這裏，就須要引入性能測試工具了。

固然，咱們也能夠看下在不借助性能測試工具的狀況下，如何手工地對系統進行性能測試。

假設如今咱們要對前面提到的登陸功能進行負載測試，驗證在10個併發用戶下登陸功能的事務平均響應時間是否在3秒之內。

很天然地，咱們想到測試的前提條件有以下幾點：

• 10個測試人員，產生業務壓力

• 1個指揮人員，對10我的員的協調控制，實現併發操做

• 1個結果記錄人員，對每個人員的操做耗時進行監控和記錄

• 若干資源監控人員，實時查看被測系統的各項性能指標，對指標進行彙總、分析

• 1個結果統計人員，對10個用戶各操做消耗的時長進行彙總，計算其平均值

能夠看出，要經過人工來進行性能測試，操做極爲繁瑣，須要投入的資源很是多。想像一下，若是要測試1000、10000、1000000併發呢？

顯然，這種狀況下是徹底不可能經過投入人力就能解決的。這也就是性能測試工具存在的必要性和誕生的背景。

性能測試工具推薦:

在性能測試工具方面，市面上已經有不少的測試工具能夠拿來使用，這裏重點給你們推薦 Locust、LoadRunner、Jmeter三款工具，排名不分前後。

從功能特性角度來講，LoadRunner做爲一個老牌的性能測試工具，其功能是最全面的，用戶羣體也是最多的，相應的學習資料也是最豐富的。我的建議若是是剛剛接觸性能測試，能夠先熟悉LoadRunner，藉此來熟悉一些理論上的東西。可是，缺點也是有的，LoadRunner不能跨平臺，目前貌似只支持在windows下使用。

由於這工具也沒怎麼用過，只是瞭解過，因此在這裏不做過多評價。

Jmeter是由Java開發的可在跨平臺運行的性能測試工具，除了作性能測試，它也經常使用於作接口測試。目前市面上大多數的人都在用它來開展性能測試。該款工具的併發機制是基於線程來實現的。有GUI界面操做，也支持命令行調用。功能插件也比較完善，我通常把它用來作接口測試或者接口自動化測試

Jmeter給個人惟一缺點就是靈活度，有點高不成低不就的味道。也可能我沒有對Jmeter進行一個系統的學習吧。

**Locust**是由Python開發的一款性能測試庫，性能測試過程皆是採用Python腳本描述，而且HTTP請求徹底基於Requests庫。除了HTTP(S)協議，Locust也能夠測試其它任意協議的系統，好比：websocket、Thrift、RPC協議等等，只須要採用Python調用對應的庫進行請求描述便可。須要強調的是Locust的併發機制摒棄了進程和線程，採用協程（gevent）機制。

這款工具testing仍是比較推薦的，由於去年在實際的性能測試項目實踐testing使用的就是這個框架，在靈活度上比LoadRunner及Jmeter高不少。可是缺點也仍是有的，好比報表功能太簡單，有些數據沒有進行收集，使用的人羣少，出現問題也只能本身鼓搗等。

資源監控工具推薦:

既然有性能測試工具，也確定有資源監控工具啦！下面推薦二款用過的。一款是nmon，一款是grafana軟件。

nmon是一款幫助收集服務器的各項硬件資源信息的工具。以爲，這款工具在操做上仍是有些繁瑣的。安裝後須要命令行運行，而後在收集信息的同時不能實時監控服務器資源；收集信息完後還須要導出收集結果在去nmon官方的一個可視化工具裏處理造成可視化報表。

是否是以爲很麻煩，因此後面一直在找一個可替代的工具。後面就發現了Grafana。

Grafana是一款強大的監控工具，使用Grafana能夠自定義本身的監控指標，可是Grafana官方提供了很是多的實用模板，使用官方的模板是一個快速開啓監控的好辦法哦。好比我監控Linux服務器資源，我可使用Grafana+Prometheus+Node Exporter進行監控，並且是實時的，也支持報表導出等。若是我想監控Mysql，我可使用Grafana+mysqld_exporter+Prometheus進行監控。這樣監控都在Grafana。

最後：

歡迎關注公衆號：程序員一凡。獲取軟件測試技術進階、大廠面試資料、。