效能測試01

阿新 • • 發佈：2020-10-09

效能測試基礎知識

目標

1. 理解什麼是效能測試
2. 掌握效能測試基礎分類
3. 熟悉效能測試常用指標

為什麼學習效能測試

業務需求：
        1. 登入不得超過3秒鐘
        2. 開發一款Web電商網站，使用JSP還是PHP呢？
        3. OA辦公系統-我們公司20000左右員工需要使用此係統；
職場需求：
        1. 會效能測試嗎？
        2. 招聘資訊-技能需求：要求會使用效能測試工具LoadRunner、Jmeter

業務需求

1. 負載測試-根據客戶實際應用場景模擬測試應用軟體、伺服器是否滿足需求，如果不滿足，則定位問題問題，
   進行調整直到滿足需求；
2. 分別使用JSP和PHP寫個Demo，根據應用場景進行效能測試，找出最優符合應用場景的開發語言；
3. 根據二八定律統計出單位時間內(秒)最高請求數；

以上解決方案都為效能測試方面知識，我們暫無法解決，所以需要學習效能測試。

什麼是效能測試？重要

概念：效能測試是模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。

說明：
    1). 峰值：客戶指定指標數值或場景需求數值，如：CPU80%以內、登入3秒、記憶體空間40%...
    2). 負載：使用者(一個、多個)向伺服器傳送請求...

效能測試與功能測試焦點

功能測試：驗證軟體系統操作功能是否符合產品功能需求規格，主要焦點在功能（正向、逆向）；
效能測試：驗證軟體系統是否滿足業務需求場景，主要焦點是業務場景的滿足(時間、空間)；

說明：
    時間：軟體的響應時間...
    空間：伺服器的磁碟使用率、CPU使用率、記憶體空閒率...

效能測試與功能測試關係

功能測試和效能測試是相輔相成的，對於一款優秀的軟體產品來講，它們是不可減少的2個重要測試環節；

效能測試分類

為什麼要學習效能測試分類？

1. 效能測試是個綜合的概述
2. 效能測試指的是測試一種分類或多種分類
3. 任何一具體分類，都是效能測試

效能測試常用分類

1. 負載測試        
2. 壓力測試        
3. 併發測試    
4. 穩定性測試

提示：效能測試分類還有其他型別比如：配置測試、容量測試等，在於前期我們先熟悉以上常用分類

負載測試【重點】

說明：通過逐步增加系統負載，測試系統性能的變化，並最終確定在滿足系統的效能指標情況下，系統所能夠承受的
      最大負載量的測試。
    (負載：向伺服器傳送請求)
提示:負載測試是通過逐步加壓的方式來確定系統的處理能力、確定系統能夠承受的各項閥值。
    例如：逐步加壓，
    從而得到“響應時間不超過3秒”、“伺服器平均CPU利用率低於80%”等指標的閥值。
    * 閥值：關注的某一具體數值(比如：登入小於3秒、使用者數2000、業務成功率100%時的伺服器併發數)

壓力測試【重點】

說明：
    通過逐步增加系統負載，測試系統性能的變化，並最終確定在什麼負載條件下系統性能處於【失效】狀態。
提示：
    1. 壓力測試：是逐步增加負載，使系統某些資源達到飽和甚至失效。
       (如：測試系統最多支援同時處理多少請求，超過此數數量系統癱瘓)
    2. 負載測試：是逐步增加負載，確定在滿足效能指標情況下，系統能承受的最大負載測試。
       (如：登入3秒內，最多支援多少使用者同時登入；如超出此數量，可能需要5秒鐘或更多時間才能登入成功)

壓力和負載區別：壓力是逐步增加系統負載並在什麼負載條件下到系統癱瘓，也就是說負載到系統崩潰，負載是在某個限制條件下（登入3秒內）所能承受的最大負載率，系統不會崩潰，只是超過限制條件。

併發測試【重點】

說明：
    1. 概念：併發測試就是【多使用者】同時訪問【同一個應用】；
    2. 目的：測試應用伺服器 指定功能 的同時訪問數是否達到預期結果；

提示：
    1. 併發測試需要配合集合點來使用
    2. 集合點：我們在介面階段已瞭解，這裡做個簡單回顧...
       集合點作用：集合點用以同步虛擬使用者，以便恰好在同一時刻執行任務

穩定性測試【理解】

說明：通過給系統載入一定的業務壓力（如CPU資源在70%～90%的使用率）的情況下，執行一段時間，
      檢查系統是否穩定。
提示：
    1. 通常穩定性測試，我們測試一段時間即可；
       (如：24小時、3×24小時或7×24小時來模擬長時間執行)

效能測試常用指標【重要】

思考

以上效能測試分類都依賴那些指標來衡量相應的資料或峰值？

什麼是指標

說明：一些經過運算得出的結果，來衡量某種操作效能統稱；比如：錯誤率 0.5%

這裡羅列了效能測試常用指標

1. 吞吐量
2. 併發數
3. 響應時間
4. 點選數
5. 資源利用率
6. 錯誤率

吞吐量

說明：吞吐量（Throughput）：指的是單位時間內處理的客戶端請求數量，直接體現軟體系統的效能承載能力。
      通常情況下，吞吐量用“請求數/秒”或者“頁面數/秒”來衡量。
提示：
    1. 從業務角度來看，吞吐量也可以用“業務數/小時”、“業務數/天”、“訪問人數/天”、“頁面訪問量/天”來衡量。
    2. 從網路角度來看，還可以用“位元組數/小時”、“位元組數/天”等來衡量網路的流量。

併發數

說明：併發（Concurrency）：它最簡單的描述就是指多個同時發生的業務操作。
      （例如，100個使用者同時單擊登入頁面的“登入”按鈕操作。）
提示：併發性測試描述的是多個客戶端同時向伺服器發出請求，考察伺服器端承受能力的一種效能測試方式。

響應時間

說明：響應時間指使用者從客戶端發起一個請求開始，到客戶端接收到從伺服器端返回結果整個過程所耗費的時間

聊聊QPS/TPS/併發量/系統吞吐量

在學習效能測試時，經常會對qps、tps、併發量、系統吞吐量這些抽象概念混淆，故此寫下這些，幫助理解：

我們在日常工作中經常會聽到QPS/TPS這些名詞，也會經常被別人問起說你的系統吞吐量有多大。
這個問題從業務上來講，可以理解為應用系統每秒鐘最大能接受的使用者訪問量。或者每秒鐘最大能處理的請求數；

QPS“每秒查詢率”: 
    每秒鐘處理完請求的次數；注意這裡是處理完。具體是指發出請求到伺服器處理完成功返回結果。
    可以理解在server中有個counter，每處理一個請求加1，1秒後counter=QPS。

TPS每秒處理事務數：
	每秒鐘處理完的事務次數，一般TPS是對整個系統來講的。
    一個應用系統1s能完成多少事務處理，一個事務在分散式處理中，可能會對應多個請求，對於衡量單個介面服務的處理能力，用QPS比較多。

併發量：系統能同時處理的請求數

RT：響應時間，處理一次請求所需要的平均處理時間

計算關係：
	QPS = 併發量 / 平均響應時間 （每秒鐘能處理完的請求次數）
	併發量 = QPS * 平均響應時間

一、QPS/TPS
    QPS：
        Queries Per Second意思：是“每秒查詢率”，是一臺伺服器每秒能夠響應的查詢次數，
        					   是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
            
    TPS：
        是TransactionsPerSecond的縮寫，也就是事務數/秒。它是軟體測試結果的測量單位。
        一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，
        以此來計算使用的時間和完成的事務個數。

    Tps即每秒處理事務數，包括了   
        1）使用者請求伺服器
        2）伺服器自己的內部處理
        3）伺服器返回給使用者
        這三個過程，每秒能夠完成N個這三個過程，Tps也就是N(這裡不是3，看我的csdn收藏原版)；

    QPS與TPS區別：
        Qps基本類似於Tps，但是不同的是，對於一個頁面的一次訪問，形成一個Tps；
        但一次頁面請求，可能產生多次對伺服器的請求，伺服器對這些請求，就可計入“Qps”之中。
        例如：訪問一個頁面會請求伺服器3次，一次產生一個“T”，產生3個“Q”  （因為頁面中可能會有圖片等資源去請求伺服器）

二、系統吞吐量
    一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。
    單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。

    系統吞吐量幾個重要引數：QPS（TPS）、併發數、響應時間

            QPS（TPS）：每秒鐘request/事務 數量

            併發數： 系統同時處理的request/事務數

            響應時間：  一般取平均響應時間

理解了上面三個要素的意義之後，就能推算出它們之間的關係：
    QPS（TPS）= 併發數/平均響應時間    或者   併發數 = QPS*平均響應時間

點選數

說明：點選數是衡量Web伺服器處理能力的一個重要指標。它的統計是客戶端向Web伺服器發了多少次HTTP請求計算的。

提示：
    1. 點選數不是通常一般人認為的訪問一個頁面就是１次點選數，點選數是該頁面包含的元素
    	（訪問一個頁面並響應，那就是一個事務數了）
        （如：圖片、連結、框架等）向Web伺服器發出的請求數數量。
    2. 通常我們也用每秒點選次數（Hits per Second）指標來衡量Web伺服器的處理能力。
    點選數，檢視響應狀態碼，訪問一個頁面可能有多個點選數，用F12檢視伺服器端的響應狀態碼，就可知道這個頁面有多少個點選數。
    點選數的統計是在伺服器端完成的。
    
結論：和qps概念類似

資源利用率

說明：是指系統各種資源的使用情況，一般用“資源的使用量/總的資源可用量×100%”形成資源利用率的資料。
提示：通常，沒有特殊需求的話
      1). 建議CPU不高於80%；
      2). 記憶體不高於80%；
      3). 磁碟不高於90%；

錯誤率

說明：錯誤率指系統在負載情況下，失敗交易的概率。錯誤率＝(失敗交易數/交易總數)*100%。
提示：
    1. 不同系統對錯誤率要求不同，但一般不超過千分之五；
    2. 穩定性較好的系統，其錯誤率應該由超時引起，即為超時率。

效能測試常用工具

1. Jmeter    
2. Loadrunner 【本階段學習】

提示：效能測試工具與很多，目前最常用就是這兩款，我們作為效能測試初期入門掌握這兩款工具足矣；

Jmeter

說明：Apche公司使用Java平臺開發的一款測試工具
作用：效能測試、介面測試、Web測試(無Gui)
優點：免費、開源、小巧

LoadRunner

說明：HP公司使用C語言開發的一款效能負載測試工具
作用：模擬高併發負載測試、測試場景搭建、執行、監控 、結果分析
優點：支援多協議、自帶強大的圖表功能、可根據需求合併需要的圖表
缺點：收費

Jmeter and LoadRunenr

提示：
    1. Jmeter： 介面測試及介面效能壓測首選
    2. LoadRunner： Web效能測試首選(可以對事務進行測試)
說明：
    1. Jmeter已學過，本階段不在介紹
    2. LoadRunner本階段學習使用

LoadRunner11安裝

1. 瞭解LoadRunner11的安裝        
2. 瞭解LoadRunenr11註冊

一、安裝步驟

1. 解壓 - loadrunner-11.iso
2. 啟動安裝程式 - setup.exe(提示：滑鼠右鍵-相容性：xp；許可權-以管理員執行)；
3. 根據安裝提示進行配置並點選下一步操作,直到安裝完成；
   注意：
        1). 自動安裝loadrunner必要依賴檔案時，要重啟電腦才可安裝；
        2). 新建資料夾(如：c:\loadrunner11)避免安裝路徑中有中文和空格；
        (原因：預設安裝路徑自帶機票網站會出現登入異常；)
4. 修改註冊許可證

二、安裝圖解解壓loadrunner-11.iso後文件執行：setup.exe點選安裝選項
點選：LoadRunner 完整安裝程式
確定安裝loadrunner依賴程式點選：確定
異常【重要】處理：重啟電腦開始安裝loadrunner點選：下一步許可協議點選：同意、下一步客戶資訊處理：預設或根據需求填寫點選：下一步
選擇安裝資料夾【重要】處理：新建指定資料夾(避免中文及空格、避免預設路徑)點選：下一步
確認安裝點選：下一步
安裝中
安裝完成
檢視-安裝完成檔案

點選：開始選單-HP LoadRunner

註冊許可證-使用圖修改前說明：使用使用者型別：臨時
修改後

 說明：使用使用者型別：永久

操作步驟lf_file.rar檔案下載

1. 下載lf_file.rar檔案
2. 將 lm70.dll、mlr5lprg.dll 兩個檔案複製並替換到LR11安裝目錄下的bin資料夾下
3. 執行 lr刪除登錄檔.exe 檔案
4. 輸入註冊資訊(New License)
        1). 首先輸入globa-100的註冊碼:AEACFSJI-YJKJKJJKEJIJD-BCLBR
        2). 其次輸入web-10000的註冊碼：AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

1) lf_file.rar檔案

2) 複製替換 lm70.dll、mlr5lprg.dll(位置：lr安裝目錄下bin目錄)

3) 執行 lr刪除登錄檔.exe 檔案4) 輸入註冊資訊(New License)思考

效能分類、指標、工具我們都以介紹完成，那麼效能測試流程或步驟是什麼呢？

效能測試流程概述

為什麼要掌握效能測試流程

1. 功能測試需要按照流程來推進，效能測試也同樣，一套完整的測試流程是一次成功效能測試的基石；
2. 【面試】簡述下效能測試過程...

效能測試步驟

1. 效能測試需求分析
2. 效能測試計劃
3. 效能測試用例
4. 測試指令碼編寫
5. 測試場景設計
6. 測試場景執行
7. 場景執行監控
8. 執行結果分析
9. 系統性能調優
10. 效能測試總結

需求分析

說明：需求分析就是把真正需求搞清楚；
例如：
    1). 我們需要貴單位對所有的功能都進行效能測試;
    2). 系統使用者登入響應時間小於3秒鐘;
    3). 系統支援20萬用戶併發訪問;

效能測試計劃

說明：
    1). 效能測試計劃是對效能測試的重要過程。
    2). 在對需求文件經過認真分析後，作為效能測試管理人員，需要編寫的第一份文件就是效能測試計劃;
    3). 效能測試計劃中，需要闡述產品、專案的背景，將前期的需要測試效能需求明確，並落實到文件中。

效能測試用例

說明：效能測試需求最終要體現在效能測試用例設計中，效能測試用例應結合使用者應用系統的場景，設計出相應的效能
      測試用例，用例應能覆蓋到測試需求。
提示：
    1). 明確那些業務功能使用頻繁；
    2). 明確系統預期的使用者規模、併發使用者數、線上使用者數；
    3). 明確系統業務的處理能力要求，如：TPS、響應時間、系統資源利用率等；
        TPS ：(Transaction per second)事務數/秒

指令碼編寫

說明：效能測試用例編寫完成以後，接下來就需要結合用例的需要，進行測試指令碼的編寫工作。
提示：
    1). 協議的正確選用;
    2). 指令碼保證其正確性，去除冗餘程式碼;
    3). 注重編碼的規範和程式碼的編寫質量；

場景設計

說明：測試場景的設計一個重要的原則就是依據測試用例，把測試用例設計的場景展現出來。
提示：
    1). 虛擬使用者數量及啟動虛擬使用者方式
    2). 場景的相關設定(如：集合點)
    3). 指令碼是否存在依賴關係(登入與註冊)

場景執行

說明：測試場景執行是關係到測試結果是否準確的一個重要過程。
注意事項：
        1). 負載的測試機不能夠執行設定的虛擬使用者數；
        2). 沒有“預熱”過程；（預熱：先將系統跑一遍）
        3). 沒有模擬使用者的真實環境；
        4). 效能用例執行次數過少。

場景執行監控

說明：場景執行監控，可以在場景執行時決定要監控那些資料，便於後期分析效能測試結果。
提示：
    1). 應用效能測試工具的重要目的就是可以提取到本次測試關心的資料指標內容;
    2). 效能測試工具利用應用伺服器取得在負載過程中相關計數器的效能指標。
    (計數器：計算、統計效能指標的工具)
注意：
    1). 負載機的時鐘要一致，保證在監控過程中的資料是同步的；
    2). 儘量蒐集與系統測試目標相關資訊，無關內容不必進行監控；
    3). 要以管理員的身份登入後

執行結果分析

說明：效能測試執行過程中，效能測試工具蒐集相關效能測試資料，待執行完成後，這些資料會儲存到資料表或者其他
      檔案中,為了定位系統性能問題，我們需要系統分析這些效能測試結果。
提示：
    1). 一般使用“拐點分析”方法，利用效能計數器曲線圖上的拐點進行分析的方法。
    （基本思想就是效能產生瓶頸的主要原因就是因為某個資源的使用達到了極限，此時表現為隨著壓力的增大，
     系統性能卻出現急劇下降，就產生了“拐點”現象。）

系統調優

說明：效能測試分析人員經過對結果的分析以後，有可能提出系統存在效能瓶頸。
提示：
    1). 調優人員(開發人員、資料庫管理員、系統管理員、網路管理員、效能測試分析人員)相關人員對系統進行調整;
    2). 驗證-效能測試人員繼續進行第二輪、第三輪……的測試，與以前的測試結果進行對比，從而確定經過調整以後
        系統的效能是否有提升。
注意:
    系統調優由易到難的先後順序如下：
    1. 硬體問題；
    2. 網路問題；
    3. 應用伺服器、資料庫等配置問題；
    4. 原始碼、資料庫指令碼問題；
    5. 系統構架問題。