性能測試連載-需求分析

性能測試的概念&意義

概念經過技術的手段模擬大量用戶同時訪問被測應用,觀察、記錄和分析系統的各項性能指標的過程。數據庫

目標:評估系統的性能瓶頸,預測系統的最大用戶負載能力安全

 

性能測試的意義架構

1)可以有效評估系統的性能指標,用於系統的性能評估2)可以識別系統的性能瓶頸,協助性能調優3)可以指導突發流量承載方案的制定4)可以用於系統運維成本的預算併發

 

性能需求分析

 

需求來源

測試:根據業務提出性能測試來規避風險運維

開發:以爲某些頁面加載慢性能

運維:對某個系統的服務能力提出性能評估測試

產品:線上性能問題反饋優化

用戶:提出某些硬性的性能要求spa

 

需求評估

關鍵性評估:有一下一項就要進行性能測試架構設計

涉及財產、生命、安全的系統。如:支付系統、電商系統、金融業務系統、醫療健康評估系統

首次投產的大型系統、具備大量用戶使用的核心業務(如:查票、搶票、支付)

系統核心數據庫、業務邏輯、軟硬件升級

歷史版本存在重大非功能缺陷or風險較大的未評估項

系統升級後,業務量、用戶量、節點增加30%以上

系統架構發生重大變化的場景

性能嚴重Bug修復後,是否會對正式環境形成不利

 

通常性評估:超過60分,則有必要進行性能測試

是否有升級,且升級內容中包含了外部系統對接接口、支付接口、Web Service調用接口等與其餘系統關聯接口(20分)

是否增長了性能風險較高的調整(20分)

是否存在客戶要求必須測試的組件or業務流程(20分)

是否在平臺中處於核心位置(15分)

是否存在部署方式調整or優化(15分)

是否涉及多個功能Bug的修復,且流程發生較大變化(10分)

 

需求調研

用戶視角:

1)頻繁使用,且存在大量用戶使用的場景

2)交易佔比較高,平常佔比 ≥80% 的場景

3)特殊交易日或峯值交易佔比 ≥80% 的場景

4)性能較差且有過調整的場景

 

項目團隊視角:

1)調整了架構設計的業務

2)邏輯複雜,比較關鍵的業務

3)可能消耗大量資源的業務

4)與外部系統存在接口調用,且有大量數據交互的業務

5)調用第三方業務組件,邏輯複雜的業務

 

運營視角:

1)知足將來業務發展規劃

2)系統需知足將來業務需求

 

需求分析

需求一:用戶數信息

1)調查系統當前和將來使用的用戶數

系統用戶數=系統目前註冊的用戶數,註冊用戶數並不表明他會天天而且無時無刻的使用。

在線用戶數=同時在線對系統進行操做的用戶數量(至關於混合場景)

併發用戶數=同時在線而且同時操做同一個功能(單場景添加集合點)

2)調查系統當前和將來的每日、月活躍用戶數

當前活躍用戶數,即某天大概有多少用戶使用本系統:那麼這部分數據就是當前真正對系統構成壓力的數據

 

需求二:業務數據量

1)調查當前和將來背景數據量

由於從100條數據中查10條也許很快,可是將來數據量變成100w。。。

2)調查當前和將來業務天天使用的總筆數

每一個用戶天天可能下多少筆單,平均須要多少次來執行這個操做?那麼根據用戶數,咱們就能夠肯定天天下單的筆數。如50人,平均每人天天下10次,每次下100筆,那麼總筆數就是50*10*100=50000筆。注意此數據根據TPS換算後,咱們能夠換算出系統的業務總處理量是否能達到這個數據,這也是一個很重要的指標。

3)調查當前和將來高峯時業務的總筆數

 

需求三:場景業務的調查

1)系統最關鍵、最核心的業務

從系統出發,以主要的業務邏輯點爲第一核心:這些功能對系統或公司來講每每具備舉足輕重的地位,不管怎樣都必需要優先執行知足這些功能的性能測試

2)高訪問量的功能,常常承受壓力的功能點

系統中表如今系統關鍵、核心業務前面必需要通過的地方:好比對於百度搜索來講,其核心業務是搜索功能,可是首先要面對的其高訪問量對是搜索輸入框加載的首頁,百度首頁加載即高訪問量的請求

3)業務複雜度高

每每說來業務邏輯複雜度的都具有一、2點的要素,可能其功能使用的人數較少可是對系統有很嚴重影響:這些功能因爲其業務邏輯具備的複雜度,每每出錯的可能性也比較高,因此這些功能也是必需要進行測試的

 

下一篇:性能測試方案

重磅福利!免費領取《jmeter接口自動化與性能實戰》

相關文章
相關標籤/搜索