軟體效能測試 - 基礎與方法

阿新 • • 發佈：2021-02-13

技術標籤：測試

文章目錄

基本概念
效能測試應用
- 效能測試方法

基本概念

Web前端效能

Web應用的前端響應時間指瀏覽器的頁面載入時間。一般而言，瀏覽器的頁面載入時間包括對HTML的解析、對頁面上的圖片及CSS等檔案的獲取和載入、客戶端指令碼（JavaScript）的執行時間以及對頁面進行展現所花費的時間，這部分效能體現就被稱為前端效能。

前端效能與併發使用者量的大小無直接的關係，主要考察瀏覽器的展現和指令碼之心時間。

故主要關注：

瀏覽器展示頁面的方式
瀏覽器各種機制的合理應用
指令碼的合理性

主要術語

響應時間

【概念】對請求做出響應需要的時間。

呈現時間：客戶端收到資料後呈現給使用者所消耗的時間
服務端響應時間：系統從請求發出到客戶端接收到資料所消耗的時間
- 通常由網路傳輸時間+應用延遲時間（資料庫延遲時間、應用伺服器延遲時間）

併發使用者數

【概念】在同一個時間段內訪問系統的使用者數量。

服務端承受的最大併發訪問數：不從業務角度出發，而從服務端承受的壓力出發，描述同時向客戶端傳送請求的客戶數量。
系統使用者數：使用該系統的使用者總數

平均併發使用者數：

C = \frac{nL}{T}

在這裡插入圖片描述

login session: 使用者從登入進入系統到退出系統之間的時間段（A login session is a time interval defined by a start time and end time. Take any web application that requires user authntication as an example,a login session starts from the time the user logs on to the system and ends when the users logs out.）

n: login session 的數量

L: login session 的平均長度

T: 考察的時間段長度

併發使用者數峰值：

C_1 = C+3\sqrt{C}

在這裡插入圖片描述

系統總的吞吐量

u·C

在這裡插入圖片描述

u：平均每個使用者發出的請求數

通過日誌分析法log analyzer瞭解系統使用者的使用狀態，從日誌中計算得出伺服器承受的最大併發使用者訪問數。

吞吐量

吞吐量直接體現軟體系統的效能承載能力，指單位時間內系統處理的客戶請求的數量。

衡量單位
- 一般：請求數（單擊數）/秒 or 頁面數/秒
- 業務角度：訪問人數/天 or 處理的業務會數/小時
- 網路角度：位元組數/天

單擊數Hits: 指客戶端發出的http請求的數量而非html頁面上的單擊事件。（一次單擊事件可以請求多個資源，產生多個Hits）

吞吐量計算
- 在沒有遇到效能瓶頸時，吞吐量可以採用以下公式計算

F = \frac{N_(vu)·R}{T}

在這裡插入圖片描述

F：吞吐量

Nvu：vu的個數

R：每個vu發出的請求（單擊）數量

T：效能測試所用的時間

吞吐量往往在VU數量增長到一定程度時會產生效能瓶頸

效能計數器

Counter是描述伺服器或作業系統效能的一些資料指標，在效能測試中發揮監控和分析的作用。

Think Time

思考時間，也稱為休眠時間。

R = \frac{T}{T_s}

在這裡插入圖片描述

R：每個vu發出的請求（單擊）數量

T：效能測試所用的時間

Ts:思考時間

軟體效能測試方法論

SEI Load Testing Planning Process

關注於負載測試計劃的方法，目標是產生清晰、易理解、可驗證的負債測試計劃。
關注點：

目標
使用者
- 必須對使用者行為進行分析，依據使用者行為模型建立用例和場景。
用例
- 用例是使用者使用某種順序和操作方式對業務過程進行實現的過程，對負載測試來說主要在於分析和分解出關鍵的業務 -> 判斷每個業務發生的頻度、業務出現效能問題的風險等。
生產環境
測試環境
- 由於負載測試環境與實際的生產環境存在一定的差異，很大概率不能準確反映該應用系統在生產環境上的實際效能表現，故須仔細設計測試環境。
測試場景

RBI(Rapid Bottleneck Identify)

關注快速識別系統性能瓶頸的方法，此方法基於以下事實：

發現的80%系統到效能瓶頸都由吞吐量制約
併發使用者數和吞吐量瓶頸之間存在一定關聯
採用吞吐量測試可以更快速地定位問題

分析方法(自上而下)：

首先分析由併發還是吞吐量引發的效能表現限制
從網路、資料庫、應用伺服器和程式碼本身確定系統性能具體的瓶頸

效能下降曲線分析

效能下降曲線是描述效能（響應時間、吞吐量、單擊數/秒）隨使用者數增加而出現下降趨勢的曲線。

曲線階段

單使用者區域：對系統的一個單使用者的響應時間
效能平坦區：在不進行更多效能調優的情況下所能期望達到的最佳效能。此區域被用作基線或benchmark
壓力區：效能輕微下降的區域。典型的、最大的建議使用者負載時壓力區域的開始。
拐點：效能開始急劇下降的點

敏捷效能測試

特點：

在每個迭代目標中包含明確的效能目標

迭代目標中的效能目標可能是基於端到端的，也可能是基於介面的，甚至可能是面向具體的函式的。例如：
- 在吞吐量為40 QPS的情況下，X頁面的服務端響應時間小於5秒。
- 模組B能夠每秒處理來自模組A的1000個請求。
- Employee類從服務端獲取給定Employee資訊的方法耗時不超過100毫秒。
建立不同層次的效能測試
- 面向函式的效能：
  - 通過Junit 4 或 TestNG中的@Test 來設定驗證標準。
  - 函式級別的效能測試對環境的依賴性小，對其他模組和函式也不存在很強的依賴性，因此可以很容易地放置在持續整合中與其他單元測試一同執行。
- 面向介面的效能：
  - 通過Junit 4等工具進行介面級別的效能測試。
  - 要求將模組或子系統執行起來，並設定好測試的支撐環境。
- 面向端到端的效能：
  - 端到端的效能結果與所在環境存在極大的依賴性，需要在嚴格定義的環境上執行。
  - 需要為被測應用準備號一鍵部署指令碼
  - 使用合適的工具和指令碼進行效能測試。
完全或接近完全自動化的效能測試
- 效能測試工具
  - HP LoadRunner
  - Jmeter
  - Junit
- 設定環境的指令碼
- 效能壓測指令碼
使用測試驅動的犯法保證效能於優化效能

TDD , 需要在編寫程式碼前設定測試。一旦測試通過，意味著程式碼實現完成。