性能測試(二)在什么階段進行性能測試 ?進行性能測試需要哪些步驟?指標有哪些?


一、在什么階段開展性能測試工作?

二、性能測試需要哪些步驟?

三、性能測試的指標?

四、理發店模型和曲線拐點模型

五、做好性能測試需要掌握的知識

 

 

 

一、在什么階段開展性能測試工作?

一般情況下,是在被測系統已完成功能測試、系統趨於穩定的情況下,才會進行性能測試。

我個人認為是有條件的話是第一輪冒煙就可以進行,學校擴建地例子,如果研發架構選擇不對,會造成一定的問題,一般來說研發做好功能之后就要針對一些常駐穩定的功能進行負載測試再到壓力測試,增加功能后繼續進行負載測試再進行壓力測試。

 
 

二、性能測試需要哪些步驟?

一、准備工作
1. 組建測試團隊
根據被測系統的實際情況,組建一個性能測試團隊,團隊成員包括:開發人員、運維人員、DBA和測試人員等。
2. 性能需求調研
性能需求調研工作一般是有性能測試人員負責,產品經理、開發人員、運維人員配合完成。
調研系統線上環境的性能需求,包括性能需求、可靠性需求、可維護性需求等。
調研系統相關信息,如硬件參數配置、系統架構與部署方式等。
調研業務場景信息,如關鍵業務邏輯與處理流程、交易列表、交易量信息、業務分布規律等。
3. 工具的選擇
綜合系統設計、工具成本、測試團隊的技能來考慮,選擇合適的測試工具。
壓測工具:JMeter、Loadrunner、Locust等等。
監控工具:nmon、lepus、jvisualvm、prometheus、grafana等等。
 
二、性能測試計划
1. 分析性能測試背景
根據對項目背景和業務的了解,確定本次性能測試要解決的問題點。常見的情況有:
對於一個新系統,需要測試系統的承受能力。
對於運行中的系統不能滿足實際的需求,需要確定性能瓶頸。
增加了新的業務,需要重新評估系統的承受能力。
系統架構進行了調整,需要重新評估系統的承受能力。
2. 分析用戶場景
根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析,整理業務場景,為測試腳本開發提供依據。
3. 確定性能目標
針對具體的業務功能點,制定期望的性能目標。其中需要和其他業務部門進行溝通協商,以及結合當前系統的響應時間等數據,確定最終我們需要達到的響應時間和系統資源使用率等目標。
4. 制定性能測試實施計划
根據項目組的時間安排,計划本次性能測試的起止時間、參與人員、產出物等等。
 
三、性能測試設計
1. 測試環境設計
不同的軟件和硬件配置會制約系統的整體性能,所以需要部署多個不同的測試環境,在不同的硬件配置上檢查應用系統的性能,並對不同配置下系統的測試結果進行分析,得出最優結果。需要重點關注有數據庫服務器、應用服務器、軟件運行環境。
2. 測試場景設計
根據被測系統的業務特性,並通過和業務部門溝通以及以往用戶操作習慣,確定用戶操作習慣模式,以及不同的場景用戶數量,操作次數,確定測試指標,以及性能監控等。
3. 測試用例設計
根據設計的測試場景,編寫測試用例。用例的核心內容包括:用例編號、用例標題、前置條件、操作步驟、測試數據、預期結果、實際結果等等。
4. 編寫測試腳本
根據測試用例和選擇的工具,准備測試數據,編寫測試腳本。
 
四、性能測試執行
1. 部署測試環境
一般由運維或開發人員進行環境的部署,並進行資源協調。
2. 執行測試腳本
在已部署好的測試環境中,按照業務場景和測試用例,按順序執行我們已經設計好的測試腳本。
3. 性能監控和記錄
根據選擇的測試工具和監控工具,在壓測的過程中對各項性能指標進行監控和記錄。
 
五、性能測試分析
分析不同的測試環境下,硬件設備的性能指標與預期的性能指標進行對比,確定是否達到了我們需要的結果。針對沒有達到預期的指標,分析具體的瓶頸點。
分析不同的測試環境下,分析應用服務器、數據庫服務器、中間件等組件的性能指標。
在性能測試執行過程中,可能會發現某些功能上的不足或存在的缺陷,以及需要優化的地方。
 
六、性能測試調優
確定問題:根據性能分析的結果確定存在的性能問題。
分析問題:根據確定的問題進行具體詳細的分析出現問題的原因。
確定調整目標和解決方案。
測試解決方案:對調優后的系統再次進行測試。
分析調優結果:分析調優結果是否到達了預期目標。
 
七、性能匯總與報告
對性能測試的過程和結果進行匯總
編寫性能測試報告

 

 

 
 
 
 
 

 

 

 

 

  

三、性能測試基本指標

        1、響應時間

    a)定義:從用戶發送一個請求到用戶接收到服務器返回的響應數據這段時間就是響應時間

    b) 關鍵路徑:下圖為一次http請求經過的路徑,請求會經過網絡發送到web服務器進行處理,如果需要操作DB,再由網絡轉發到數據庫進行處理,然后返回值給web服務器,web服務器最后把結果數據通過網絡返回給客戶端。

    

    c) 計算方法:Response time = (N1+N2+N3+N4)+ (A1+A2+a3),即:(網絡時間 + 應用程序處理時間)

    d) 響應時間-負載對應關系:

         

     圖中拐點說明:

      1、響應時間突然增加

      2、意味着系統的一種或多種資源利用達到的極限

      3、通常可以利用拐點來進行性能測試分析與定位

  2、吞吐量

    a)定義:單位時間內系統處理的客戶端請求的數量

    b)計算單位:一般使用請求數/秒做為吞吐量的單位,出可以使用 頁面數/秒表表示。

      另外,從業務角度來說也可以使用 訪問人數 /天 或 頁面訪問量/天 做為單位。

    c)計算方法:Throughput = (number of requests) / (total time).

    d吞吐量-負載對應關系:

            

     圖中拐點說明:

      1、吞吐量逐漸達到飽和

      2、意味着系統的一種或多種資源利用達到的極限

      3、通常可以利用拐點來進行性能測試分析與定位 

  3、並發數:

    並發用戶數:某一物理時刻同時向系統提交請求的用戶數,提交的請求可能是同一個場景或功能,也可以是不同場景或功能。

    在線用戶數:某段時間內訪問系統的用戶數,這些用戶並不一定同時向系統提交請求

    系統用戶數:系統注冊的總用戶數據

    

    三者之間的關系:系統用戶數 >= 在線用戶數 >= 並發用戶數

  4、資源利用率

    a) 定義:指的是對不同系統資源的使用程度,通常以占用最大值的百分比來衡量

    b) 通常需要關注的服務器資源如下:

      1、CPU:就像人的大腦,主要負責相關事情的判斷以及實際處理的機制

      2、內存:大腦中的記憶塊區,將眼睛,皮膚等收集到的信息記錄起來的地方,以供cpu進行判斷,但是是臨時的,訪問速度快,如果關機或斷電這里的數據會消失。

      3、磁盤IO:大腦中的記憶區塊,將重要的數據保存起來(永久保存,關機或斷電不會丟失,速度慢),以便將來再次使用這些數據。

      4、網絡:

    c)資源利用-負載對應關系:

      

     圖中拐點說明:

      1、服務器某薦資源使用逐漸達到飽和

      2、通常可以利用拐點來進行性能測試分析與定位

  5、其它常用概念:

    a) TPS:Transactions Per Second,每秒事務數

    b) 思考時間:用戶每個操作后的暫停時間,或者叫操作之間的間隔時間,此時間內是不對服務器產生壓力的

    c) 點擊數:每秒鍾用戶向WEB服務器提交的HTTP請求數。這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,用戶發出一次申請,服務器就要處理一次,所以點擊是WEB應用能夠處理的交易的最小單位。如果把每次點擊定義為一個交易,點擊率和TPS就是一個概念。容易看出,點擊率越大,對服務器的壓力越大。點擊率只是一個性能參考指標,重要的是分析點擊時產生的影響。需要注意的是,這里的點擊並非指鼠標的一次單擊操作,因為在一次單擊操作中,客戶端可能向服務器發出多個HTTP請求.

    d)PV:訪問一個URL,產生一個PV(Page View,頁面訪問量),每日每個網站的總PV量是形容一個 網站規模的重要指標。

       UV:作為一個獨立的用戶,訪問站點的所有頁面均算作一個UV(Unique Visitor,用戶訪問)

 

四、理發店模型和曲線拐點模型

  上面介紹了很多性能測試中的基本概念,比較抽象,可以通過性能測試理發店模型 或 地鐵進站模型來幫忙我們更好的理解這些概念。這里不做詳細介紹了,需要的可直接查看原文。

 

五、做好性能測試需要掌握的知識

  • 掌握一門編程語言
  • 掌握計算機原理和操作系統知識
  • 良好的網絡基礎
  • 掌握數據庫知識
  • 中間件(apache,tomcat)
  • 常用抓包工具
  • 性能測試工具

 

 
 
 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM