根據經驗值，Y＝3，y=30%時，m/X=0.33。而m是平臺最大有效并發數，即用來服務于廣告物料顯示的并發數，而對于每次廣告物料的顯示，客戶端還有訪問其它資源如JS代碼等，假設每一次廣告物料的訪問會有伴隨另外2個資源的訪問。
那么平臺支撐的總的并發數與需要達到的日均PV的比大約為0.33*3=1。
�。╞）實際測試模型設計中結果：
對廣告鏈接頁面的并發用戶數只需要達到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小時。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
