Pv和併發的換算

pv和併發的換算

l 併發數=pv/（pv統計時間，換算成s，一天是86400s）*（頁面鏈結次數，包括外部的js css等，一般可用10）*（http響應時間，一般可用1或者更少）*（因數，一般用5）/web伺服器數量；

l pv=併發使用者數*（pv統計時間，換算成s，一天是86400s）*（頁面鏈結次數，包括外部的js css等，一般可用10）*（http響應時間，一般可用1或者更少）*（因數，一般用5）/web伺服器數量；

分為分線上系統和新系統

1）已上線專案，如果公司有日誌分析和監控的話，可以從監控日誌中獲取測試目標

a）從線上日誌獲得每個功能的併發量。

b）日誌中獲取場景，看pv總量，使用多的url和開發、產品確認的重要功能，從日誌中獲取的資料都只是基準值，還需要考慮增量。

c）分析增量，根據統計增長趨勢來大概預估乙個未來增量的併發數量。

d）新的功能加入後，平均處理時間不能超過線上先有的值。

e）如果線上無日誌可以分析，可以從資料庫入手，dba和op都可以獲得每天的增量，來計算增加趨勢。只有pv值，並且是pv總量，只能以20/80原則來計算時間上演算法就是60*1/4，如果按60來算就是整個系統的併發量。

f）修改的功能，找相應的場景的併發量和響應時間，修改後的值不能大於線上值

g）線上新增的全新功能，併發量和響應時間找平級功能的增刪改查等值作為參考值

a）資料全部重新獲取，需要市場、直屬領導給乙個值，測試只是協助角色，測試目標一定要明確，其中包括併發量、響應時間、tps（多少併發量，在什麼響應時間內，其中的效能情況給出乙份結果）

b）測試場景請需求、開發、市場一起定乙個初稿(需求：哪些功能/場景需要做效能測試？開發：哪些覺得有問題？核心功能和有風險的)

c）功能測試階段，去找功能測試了解功能測試中比較慢的功能，加入到效能測試場景中，還可以自己從功能測試角度去檢查是否有遺漏

d）需求、開發定了乙個效能指標後，還需要考慮乙個增量，增量只是乙個預估值，增量不大的話可以按一年20%來測試