性能測試方案

前言

 

性能測試方案需包含測試測試需求分析、測試對象分析、測試重點分析、測試環境分析、測試場景構建幾個關鍵點，其中：

 

• 測試需求分析：測試中涉及的性能指標的定義

• 測試對象分析：測試中涉及的業務及系統內部模塊的定義

• 測試重點分析：測試執行策略、測試監控策略、測試風險的定義

• 測試環境分析：測試中涉及到的服務器資源、測試軟件、測試數據、測試樁定義

• 測試場景構建：從性能負載、接口、疲勞角度定義測試場景

 

定義

 

測試場景構建：從性能負載、接口、疲勞角度定義測試場景

 

項目：

 

我們先定義一個性能測試項目，用戶手機連上wifi，然后打開瀏覽器鏈接任意一網址，頁面被刷新到登錄頁面，用戶輸入用戶名加密碼后點擊登錄，以此進行下面的性能方案講解。

 

1、測試需求分析

 

可從需求文檔、市場調研去收集性能測試指標

 

 

1.1、需求文檔

 

1.1.1、客戶明確需求

 

通常情況，客戶有明確的需求，定義一些性能測試指標，例：每秒用戶登錄頁面刷新多少、每秒登錄用戶量多少，用戶在線總量多少，我們明確性能測試指標。

 

1.1.2、客戶隱形需求

 

基於客戶明確指標下，會有一些隱性指標，例：100萬在線用戶的查詢在5秒響應，我們也許納入性能測試指標內。

 

1.1.3、用戶模型確定

 

有了以下的性能測試指標后，我們可以創建我們的用戶模型，如下：

 

1. 用戶指標：用戶登錄TPS需達到50、用戶登錄頁面刷新TPS需達到250；

2. 用戶總量：總用戶量100萬；

3. 用戶模型：系統每天用戶在線量在100萬左右，平均在早晨8、11點期間登錄，其中登錄頁面刷新與登錄比例為5:1。

 

1.2、市場調研

 

1.2.1、客戶無明確需求

 

也有特殊的情況，客戶只會提供一些基礎數據，例：2000個機構下，500萬的用戶總量，我們需要根據這些基礎數據提煉出我們的性能指標。

 

1.2.2、市場調研需求

 

有了基礎數據后，還需要對我們所關心的性能指標做市場調研，最終得出我們的性能指標

 

例：對其中1個機構1個月的用戶登錄數進行數據采集（每天早晨8-9點是登錄高峰期，每天大約是1小時內登錄100人次，平均到每秒100÷3600約為0.027次/秒），然后在推算2000個機構下，用戶每秒登錄0.027*2000約50次，在根據后台日志推算出，登錄與登錄頁面刷新比例為1:5，登錄頁面刷新TPS為2500。

 

1.2.3、用戶模型確定

 

確定性能指標后，我們可以創建我們的用戶模型，如下：

 

1. 用戶指標：用戶登錄TPS需達到50、用戶登錄頁面刷新TPS需達到250；

2. 用戶總量：根據用戶指標推算出用戶總量，或者由相關系統推算出用戶總量；

3. 用戶模型：系統每天用戶在線量在100萬左右，平均在早晨8、11點期間登錄，其中登錄頁面刷新與登錄比例為5:1。

 

02

測試對象分析

 

可從測試對象分析、測試模型分析、測試指標分析、模塊耦合性分析考慮。

 

 

 

 

2.1、測試對象分析

 

測試對象分析從業務流程、后台系統模塊分析，然后明確測試對象。

 

 

2.1.1、按照業務流程拆解

 

根據業務提煉出用戶基礎流程：登錄頁面刷新、登錄

 

1.  登錄頁面刷新：手機連上wifi，瀏覽器任意訪問一地址，請求會被接入層的設備重定向到后台,后台經過邏輯計算，推送給用戶一個登錄頁面；

2. 登錄:用戶輸入用戶名加密碼，然后點擊登錄，后台系統進行登錄，返回成功或者失敗。

 

2.1.2、按照后台系統模塊拆解

 

根據業務分析后台的系統模塊，登錄頁面刷新模塊、登錄模塊：

 

1. 登錄頁面刷新模塊：用戶的HTTP請求經過系統層面的中間件處理分發到后台系統，然后被推送模塊接收，再進行計算，推送出相應的登錄頁面，這里的計算可能跟用戶類型以及所在機構有關系。

2. 用戶登錄模塊：用戶輸入的用戶名加密碼請求同樣經系統層面中間件處理分發到后台系統，然后登錄模塊接收，再進行用戶名密碼的校驗（這里可能會到數據庫內去進行查詢或者更改數據），最后返回結果。

3. 最后提煉出關鍵系統模塊：HTTP、中間件、推送模塊、登錄模塊，最后這些系統模塊會在性能瓶頸定位中起到方向作用。

 

2.1.3、明確測試對象

 

根據業務流程分析與后台系統模塊分析，明確測試對象的業務、系統模塊、指標。

 

1. 業務：用戶連接wifi后，瀏覽器訪問網頁，被重定向到用戶登錄頁面，然后輸入用戶名+密碼進行登錄的一種場景；

2. 模塊：整個流程包括HTTP請求、中間件、推送模塊、登錄模塊；

3. 指標：登錄頁面刷新：TPS250、登錄動作：TPS50、在線總量：100萬。

 

2.2、測試模型分析

 

2.2.1、用戶模型場景分析

 

根據用戶模型設計出典型應用場景與可靠性應用場景

 

典型應用測試主要從常規測試指標、測試環境去分析，例：

 

1. 常規測試指標是登錄頁面刷新250TPS，登錄50TPS，用戶量100萬。

2. 常規測試環境是網絡是無限流、無有延遲，測試硬件的CPU、內存、磁盤的正常情況設計場景。

 

可靠性應用場景主要從非常規測試指標、測試環境去分析，例：

 

1. 非常規測試指標是高於指標的20%的情景下驗證；

2. 非常規測試環境是網絡存在限流、延遲情況很大，測試硬件的CPU、內存、磁盤受限的異常情況下設計場景。

 

2.2.2、用戶模型場景設計

 

根據用戶模型分析設計出用戶模型場景，例：

 

1. 用戶典型應用場景：在10MB/秒限流與20ms延遲網絡情況，對CPU16核、內存32G、磁盤10K轉/秒的服務器進行TPS250的登錄頁面刷新動作，以及TPS50用戶登錄動作，持續時間約5.5小時，最終上線用戶量達100萬左右；

2. 用戶可靠性應用場景：在1MB/秒限流與100ms延遲網絡情況，對CPU4核、內存16G、磁盤7200轉/秒的服務器進行TPS300的登錄頁面刷新動作，以及TPS60用戶登錄動作，持續時間約5.5小時，最終上線用戶量達100萬左右。

 

2.3、測試指標分析

 

2.3.1、提煉出關鍵指標

 

根據用戶模型提煉出用戶關鍵指標，例：

 

 

2.4、模塊耦合性分析

 

根據后台系統模塊分析出可能會涉及到的模塊耦合性，例：

 

 

1. HTTP請求中的cookies貫穿整個業務交互過程，在測試腳本中應該緩存cookies，保證業務正常，同時后台考慮cookies的存取方式，保證大並發下cookies不會出現丟失或者寫滿的情況；

2. 中間件反向代理將不同請求分發到內部模塊：推送模塊、登錄模塊、其他模塊，考慮中間件本身會不會存在瓶頸，對業務照常影響。

 

測試重點分析

 

可從測試執行策略、測試監控策略、測試風險與輸出方向去考慮。

 

3、測試重點分析

 

可從測試執行策略、測試監控策略、測試風險與輸出方向去考慮。

 

 

3.1、測試執行策略分析

 

3.1.1、分析本次性能測試的重點

 

根據咨詢研發人員，確認后台系統模塊的代碼編寫情況，可分為重構、繼承、新增，不同情況測試策略不同。

 

 

1. 關於繼承模塊測試：進行回歸驗證即可，不做探索性的性能測試。

2. 關於關於重構或新增模塊測試：進行全面的測試，優先覆蓋典型場景，可靠性場景在集成測試后驗證。

 

3.1.2、分析本次性能測試測試輪次

 

根據系統性能測試介入時間，來制定測試達標要求。

 

 

1. 集成測試輪次：確保單業務指標達標80%；

2. 阿爾法測試輪次：確保單業務指標達到100%；

3. 系統測試輪次：確保混合業務指標達到100%。

 

3.2、測試監控策略分析

 

主要從系統用到一些資源進行監控，例：數據庫、系統CPU、內存、磁盤等。

 

 

1. 數據庫可用所在數據庫層面自帶監控工具，或者第三方層面的監控器；

2. 系統資源監控可用系統層面的一些自帶工具：例：nmon工具,Top命令。

 

3.3、測試風險與輸出

 

主要從測試硬件、測試人力、測試技術這些方面考慮。

 

 

1. 1、測試硬件風險：找不到合適硬件資源，需測試前期識別出來，並使用相近配置進行驗證，后期需在測試風險中提出。

2. 測試人力風險：由於測試周期緊張，需要多名測試人員同時進行測試，但具備性能測試的人員不足，前期提出風險，並考慮延長測試周期，或在前期培訓相應人員。

3. 測試技術風險：根據業務與后端系統選取合適的性能測試工具，例：Loadrunner、jemter等。

04

4、測試環境分析

 

主要從測試硬件、測試儀器、測試樁准備、測試數據准備、測試環境准備這些方向考慮。

 

 

4、 測試環境分析

 

4.1、測試硬件

 

 

 

1. 服務器硬件配置：考慮硬件的CPU、內存、磁盤讀寫、硬盤；

2. 壓力機硬件配置：考慮硬件的CPU、內存、磁盤讀寫、硬盤。

 

4.2、測試儀器

 

 

1. 性能測試模擬器：測試中用於模擬壓力端的工具，可以是企業級的工具，例：LR，jmter,AB.也可以是用JAVA、C或python言語寫的壓力器；

2. 性能測試軟件：測試中用於性能調優，內存分析以及數據庫方面的輔助工具。

 

4.3、測試樁准備

 

 

• 測試樁作用：用於性能瓶頸定位、用於規避測試中一些非主要流程，通常有研發人員提供。

• 模塊之間的測試樁：流程中包含AB模塊，性能定位時AB模塊性能瓶頸時，需在AB模塊之間做樁，讓其支持單壓A，或者單壓B模塊。

• 輔助測試樁：測試流程中的一些非主要流程，同時腳本不易實現，例：登錄時安全校驗輸入驗證，可適當地讓研發人員進行前段安全校驗的屏蔽。

 

4.4、測試數據准備

 

根據前面的用戶模型里涉及到的數據，測試前期進行准備，例：用戶登錄場景，登錄名是手機號，登錄終端是手機，場景下共有2000個機構，即：需500萬的手機號、500萬的MAC地址、2000個組織機構。

 

4.5、測試環境准備

 

根據性能測試場景，可分為負載場景、混合場景、疲勞場景，所以根據實際情況，可分為負載環境、混合環境、疲勞環境、研發調試環境。

 

 

 

• 負載環境：用於進行單業務負載測試。

• 綜合環境：用於進行綜合業務負載測試。

• 疲勞環境：用於進行7*24小時疲勞測試。

• 研發調試環境：用於進行性能瓶頸定位分析。

 

為什么需要區分這么多場景，可能有人會問，因為在測試前期負載場景測試時，10項性能指標通過7項，剩余3項還沒達標，其實這時可以同步進行綜合場景測試，負載環境單獨調優剩余3項沒過指標，綜合場景單獨進行綜合場景測試，其實就是多環境好處在於可以並行進行測試，不至於讓某一個測試因為環節問題卡住我們。

505

5、測試場景構建

 

5.1、負載場景測試

 

負載場景測試主要驗證各個單業務是否性能指標需求。

 

• 例：驗證登錄頁面刷新TPS250是否滿足

• 例：驗證登錄TPS50是否滿足

 

5.2、接口場景測試

 

接口場景測試主要驗證系統中第三方接口驗證，例：登錄時的第三方短信接口驗證。

 

5.3、混合場景測試

 

綜合場景測試驗證用戶的典型場景與可靠性場景是否滿足性能指標需求。

 

• 例：在10MB/秒限流與20ms延遲網絡情況，對CPU16核、內存32G、磁盤10K轉/秒的服務器是否滿足TPS250的登錄頁面刷新、是否滿足TPS50用戶登錄，是否滿足持續時間約5.5小時后上線用戶量達100萬。

• 例：在1MB/秒限流與100ms延遲網絡情況，對CPU4核、內存16G、磁盤7200轉/秒的服務器是否滿足TPS350的登錄頁面刷新、是否滿足TPS60用戶登錄，是否滿足持續時間約5小時后上線用戶量達100萬。

 

5.4、疲勞場景測試

 

疲勞場景測試主要驗證系統在長時間負載下的表現是否正常。

 

通常是按照負載場景指標的60%左右對系統進行7*24小時的長時間負載測試，觀察系統長時間運行下，是否滿足負載指標的60%，在業務波峰時系統后台資源（CPU、內存、磁盤IO）消耗不高於系統的80%，在業務波谷時系統后台資源恢復到正常的20%到40左右。