乙個訪問量達到百萬級別的門戶**及奧運會訂票系統等這中使用者數較多的系統，進行效能測試是必須的。要不就和產品演示會上出現的笑話一樣，風險投資商提出的問題是這個**能支援多少使用者同時上線，專案經理居然說沒有進行這方面的測試。全場譁然。。。。
對於效能測試的第一步是怎麼去根據業務的實際模型分析出具體的測試場景及效能測試的指標。
一、 效能測試業務邏輯理解的一些基本概念
1、負載測試和壓力測試的區別：負載測試在於確定最終滿足系統指標的前提下，系統所能承受的最大負載測試，壓力測試的目標則在確定什麼條件下系統效能處於失效狀態。
2、吞吐量(throughput)：指單位時間內處理的客戶段請求數量，直接體現軟體
系統的效能承載能力。
點播，10%的人在逛論壇等等
二、幾種常見的業務模型設計
1、e家廣告系統：
(1)具體的業務引數要求：
系統要達到4000萬日均pv，則需要平台可以處理4000併發/秒。根據選中的伺服器
的效能，處理能力約為2000個http併發/秒或1000個流**併發/秒。假設這4000萬pv中有的pv佔3000萬，流**的pv佔1000萬，則需要web伺服器
及流**伺服器各兩台。
(2)具體的測試設計方法：
(a)平台的處理能力與要達到的日均pv的能力的計算關係為：
引數說明：
x：表示整個系統的日均pv值，單位為：萬pv/天
m：平台最大有效併發數(即用來服務於廣告物料顯示的併發數)，單位為：併發/秒，每小時是3600秒，即每個小時處理的併發數為3600m併發，即0.36m萬併發/小時。
y：非高峰時期的平均併發數與平台最大併發數的比例，0
y：高峰期(平台達到最大併發數的70%，平台負載超過70%以後，將變得不穩定)小時數,0
那麼：日均pv=高峰期併發數*高峰期小時數+非高峰期平均併發數*(24-高峰期小時數) 即：
x=0.7*0.36my+y*0.36m*(24-y)
即最後結論：
x=(0.252y+8.64y-0.36yy)*m
根據經驗值，y=3，y=30%時，m/x=0.33。而m是平台最大有效併發數，即用來服務於廣告物料顯示的併發數，而對於每次廣告物料的顯示，客戶端還有訪問其它資源如js**等，假設每一次廣告物料的訪問會有伴隨另外2個資源的訪問。
那麼平台支撐的總的併發數與需要達到的日均pv的比大約為0.33*3=1。
(b)實際測試模型設計中結果：
對廣告鏈結頁面的併發使用者數只需要達到n1=0.33*40000000*0.7/24*0.3*3600=356個
對於流**伺服器併發使用者數：n2=10000000*0.7/24*0.3*3600/2=135個
對於伺服器併發使用者數：n3=30000000*0.7/24*0.3*3600/2=405個
(1)具體的業務引數要求：集團郵箱支援支援2000萬使用者，對效能有要求的操作有郵箱登入，讀信，翻頁，發郵件(分別是8秒內，2秒內，2秒內，5秒內)。所有的操作均返回http200的狀態**。其中伺服器資源分別是登入5臺機器(連線passport)，收發郵件5臺(不包括pop收發信)，其它郵件處理伺服器5臺，pop/smtp伺服器5臺。
(2)具體的測試設計方法：具體的設計2000萬個使用者登入時間大概在會在8點到下午18點前操作，而該類業務模型滿足80~20原則，比如80%的業務會在20%的時間內處理。則登入的併發使用者數設計成多少好呢? vulogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此類推。
(3)當然如果業務在要求吞吐量的時候，就要更根據吞吐量來設計效能瓶頸所需要的併發使用者數這在我們21cn**和電子商務**中經常出現。這裡引進乙個公式vu=f /r*t(vu併發虛擬使用者數,f吞吐量,t效能測試時間,r每個vu的請求數量)舉例說明(某**的吞吐量為90億kb，每個使用者每秒50萬kb，執行時間30分鐘設計出來的每秒使用者數vu=9000000000/(500000*30*30))
(4)如辦公系統(業務比較頻繁的系統)：每天內的一些典型使用者固定可以考慮採用一種更準確的計算併發使用者數的的方法。公式引進：c=n*l/t,c1=c+ (c是平均併發使用者數，n是login session的數量，l是login session的時長，t是考察的時間長度，c1是最高峰值)(*這裡的使用者是指明確每天都要使用的系統的大概數量來自需求，而這裡的使用者都是當做乙個典型的使用者來分析就是登入後會進行正常的流程操作)如21cneip每天有320個典型使用者訪問，系統平均時間為4小時，在一天內使用者使用該系統的時間都在8小時內。得出c=320*4/8,c1=c+3 (5)針對這幾種模式做一些歸納無論那種模型都是**於需求根據需求的實際模型是最真實的也是最有效的效能測試模型，在沒有典型使用者的前提下選擇2-8原則(在測試環境中要考慮到等價這個概念就是測試環境伺服器數量沒有實際環境哪麼多的時候要折算過來)，有典型使用者的情況下選擇最大併發數的計算方法，在要求有吞吐量的情況下用吞吐量的計算方法(但是吞吐量的資料要採用上一次測試或者經驗值中沒有突破系統瓶頸的部分資料要不結果不準確，其中每秒事物數取的是平均值)
三、其它值得注意部分
1、設定測試場景中併發使用者為每隔一段時間增加x個虛擬使用者(預熱，ramp up設定)，與同時載入所有的併發使用者的測試結果不同，實際的測試中要根據具體業務情況設計。另外實際的資料庫記錄數和網路
環境等都會影響到測試結果。
2、建議在實際的測試過程中能多次測試取平均值。
3、效能測試的」拐點論」:產生拐點的情況是效能測試產生某種瓶頸，主要原因是某種資源達到了極限。此時表現為隨著壓力的增大，系統效能出現急劇下降。
4、效能測試的系統能力驗證: (a)是系統穩定性的乙個基本要求，通常表現為系統在要求的平均併發使用者下伺服器的cpu
平均使用率不高於75%，記憶體
的使用率不高於75%。(b)系統在要求的併發使用者數達到峰值情況下伺服器的cpu平均使用率不高於95%，記憶體的使用率不高於90%。(c)系統能在高於實際系統執行壓力1倍的情況下，穩定的執行72小時。 5
、為分清各個不同事物的響應時間請務必在多事物的指令碼中新增事物以便區分，請在要用到多個帳戶或者多個使用者的迭代或者迴圈操作的時候請務必進行引數化
(很多系統都限制了同一帳戶在多長時間的操作，或者防止資料衝突)。
Moqui訂單業務模型分析
h1.通用訂單服務 h2.通用的下單和商業用法 create customer 新建客戶 customerservices.create account create update delete customer address 新增 修改 刪除 客戶位址 contactservices.creat...
LR通用的效能分析流程
step1 從分析summary的事務執 況入手 summary主要是判定事務的響應時間與執 況是否合理。如果發現問題，則需要做進一步分 析。通常情況下，如果事務執 況失敗或響應時間過長等，都需要做深入分析。下面是檢視分析概要時的一些原則 1 使用者是否全部執行，最大執行併發使用者數 maximum...
彈性盒模型的實際應用
現在是凌晨4.45分，剛才解決了乙個棘手的問題，乘著這股餘勁，我要把剛才查閱的 測試的以及平時不怎麼關注的知識點再理一遍。今天收穫真的大。1 css清除浮動。父元素如果沒有設定高度，將預設由子元素撐開父元素的高度。如果子元素設定了浮動，也不能撐開父元素的高度。2 使用 media only scre...