LoadRunner性能測試的幾種業務模型設計
一個訪問量達到百萬級別的門戶網站及奧運會訂票系統等這中用戶數較多的系統，進行性能測試是必須的。要不就和產品演示會上出現的笑話一樣，風險投資商提出的問題是這個網站能支持多少用戶同時上線，項目經理居然說沒有進行這方面的測試。全場嘩然。。。。
對于性能測試的第一步是怎么去根據業務的實際模型分析出具體的測試場景及性能測試的指標。
一、 性能測試業務邏輯理解的一些基本概念
1、負載測試和壓力測試的區別：負載測試在于確定最終滿足系統指標的前提下，系統所能承受的最大負載測試，壓力測試的目標則在確定什么條件下系統性能處于失效狀態。
2、吞吐量(Throughput)：指單位時間內處理的客戶段請求數量，直接體現軟件系統的性能承載能力。
3、并發(Concurrency)：多個同時發生的業務操作。例如100個用戶同時點登錄21CN郵箱和同時在線人數不一樣。比如說21CN通行證用戶登錄的有1萬個可能只有20%的人在看博客，10%的人在看相冊，30%的人在查看郵件，10%的人在查看播客，10%的人在看視頻點播，10%的人在逛論壇等等
但是同時在線人數就是1萬，并發用戶就是針對每個系統的具體人數。
二、幾種常見的業務模型設計
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個
2、集團郵箱：
(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、為分清各個不同事物的響應時間請務必在多事物的腳本中添加事物以便區分，請在要用到多個帳戶或者多個用戶的迭代或者循環操作的時候請務必進行參數化(很多系統都限制了同一帳戶在多長時間的操作，或者防止數據沖突)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
