一、 性能測試術語解釋
1. 響應時間
響應時間即從應用系統(tǒng)發(fā)出請求開始，到客戶端接收到最后一個字節(jié)數(shù)據(jù)為止所消耗的時間。響應時間按軟件的特點再可以細分，如對于一個 C/S 軟件的響應時間可以細分為網(wǎng)絡傳輸時間、應用服務器處理時間、數(shù)據(jù)庫服務器處理時間。另外客戶端自身也存在著解析時間、界面繪制呈現(xiàn)時間等。

響應時間主要站在客戶端角度來看的一個性能指標，它是用戶最關心、并且容易感知到的一個性能指標。
2. 吞吐率
吞吐率指單位時間內系統(tǒng)處理用戶的請求數(shù)，從業(yè)務角度看，吞吐率可以用每秒請求數(shù)、每秒事務數(shù)、每秒頁面數(shù)、每秒查詢數(shù)等單位來衡量。從網(wǎng)絡角度看，吞吐率也可以用每秒字節(jié)數(shù)來衡量。
吞吐率主要站在服務端的角度來看的一個性能指標，它可以衡量整個系統(tǒng)的處理能力。對于集群或者云平臺來說，吞吐率指標反映的是服務器集群對外整體能夠承受的壓力，該指標比用戶數(shù)更容易對比。
備注：吞吐量 = 吞吐率 * 單位時間
3. 用戶數(shù)
對于服務器集群或者云平臺，幾乎都是多用戶系統(tǒng)，系統(tǒng)能提供給多少用戶正常使用，也是一個非常重要的度量指標。我們把這些用戶按照使用系統(tǒng)的時機不同，做如下區(qū)分。
系統(tǒng)用戶數(shù)（System Users）：指系統(tǒng)能夠存儲的用戶量。
在線用戶數(shù)（Online Users）：指用戶通過身份確認后，處于能正常使用狀態(tài)的用戶個數(shù)。
并發(fā)用戶數(shù)（Concurrent users）：指在某個時間范圍內，同時正在使用系統(tǒng)的用戶個數(shù)。
嚴格并發(fā)用戶數(shù)（Strictly the number of concurrent users）：指同一時刻都操作某個業(yè)務的用戶數(shù)。
在性能測試過程中，我們要去模擬實際用戶來發(fā)請求。但是為了吐服務器產(chǎn)生更大的壓力，我們模擬的用戶操作和實際的用戶操作存在一定的差異（比如模擬的用戶請求比實際用戶的請求更頻繁），而且返種模擬的用戶數(shù)和實際的用戶數(shù)也難以相互換算。所以在度量服務器集群能力時，吞吐率指標比用戶數(shù)指標更實用。
二、 性能測試方法及目標
1. 性能測試方法
1.1 基準測試（Benchmark Testing）
基準測試是基于一定規(guī)模的數(shù)據(jù)量上進行單業(yè)務或按實際用戶操作同比例組合業(yè)務的測試，目的在于量化響應時間、吞吐率的指標，便于后續(xù)比對。
方法是做多組不同場景的測試，觀察結果，抽取出幾個關鍵數(shù)據(jù)做好記彔，用于以后進行性能對比和評價。
1.2 性能測試（Performance Testing）
通過模擬生產(chǎn)運行的業(yè)務壓力量和使用場景組合，測試系統(tǒng)的性能是否滿足生產(chǎn)性能要求。
特點：
（1） 主要目的是驗證系統(tǒng)是否具有系統(tǒng)宣稱的能力。
（2） 需要事先了解被測系統(tǒng)的典型場景，并具有確定的性能目標。
（3） 要求在已確定的環(huán)境下運行。
1.3 負載測試（Load Testing）
通過在被測系統(tǒng)上不斷增加壓力，直到性能指標，例如“響應時間”超過預定指標或者某種資源使用已經(jīng)達到飽和狀態(tài)。
特點：
（1） 主要目的是找到系統(tǒng)處理能力的極限。
（2） 需要在給定的測試環(huán)境下進行，通常也需要考慮被測系統(tǒng)的業(yè)務壓力量和典型場景，使得測試結果具有業(yè)務上的意義。
（3） 一般用來了解系統(tǒng)的性能容量，或是配合性能調優(yōu)使用。
1.4 壓力測試（Stress Testing）
測試系統(tǒng)在一定飽和狀態(tài)下，例如CPU、內存等在飽和使用情況下，系統(tǒng)能夠處理的會話能力，以及系統(tǒng)是否會出現(xiàn)錯誤。
特點：
（1） 主要目的是檢查系統(tǒng)處于壓力情況下是應用的表現(xiàn)。
（2） 一般通過模擬負載等方法，使得系統(tǒng)的資源使用達到較高水平。
（3） 一般用于測試系統(tǒng)的穩(wěn)定性。
1.5 配置測試（Configuration Testing）
通過對被測系統(tǒng)的軟/硬件環(huán)境的調整，了解各種不同環(huán)境對系統(tǒng)性能影響的程度，從而找到系統(tǒng)各項資源的最優(yōu)分配原則。
特點：
（1） 主要目的是了解各種不同因素對系統(tǒng)性能影響的程度，從而判斷出最值得進行得調優(yōu)操作。
（2） 一般在對系統(tǒng)性能狀況有初步了解后進行。
（3） 一般用于性能調優(yōu)和規(guī)劃能力。
1.6 并發(fā)測試（Concurrency Testing）
通過模擬用戶的并發(fā)訪問，測試多用戶并發(fā)訪問同一個應用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題。
特點：
（1） 主要目的是發(fā)現(xiàn)系統(tǒng)中可能隱藏的并發(fā)訪問時的問題。
（2） 主要關注系統(tǒng)可能存在的并發(fā)問題，例如系統(tǒng)中的內存泄露、線程鎖和資源爭用方面的問題。
（3） 可在在開發(fā)的各個階段使用，需要相關的測試工具的配合和支持。
1.7 可靠性測試（Reliability Testing）
通過給系統(tǒng)加載一定的業(yè)務壓力（例如資源在70%~90%的使用率）的情況下，讓應用持續(xù)運行一段時間，測試系統(tǒng)在這種條件下是否能穩(wěn)定運行。
特點：
（1） 主要目的是驗證系統(tǒng)是否支持長期穩(wěn)定的運行。
（2） 需要在壓力下持續(xù)一段時間的運行。
（3） 需要關注系統(tǒng)的運行狀況。
1.8 失效恢復測試（Failover Testing）
針對有冗余備份和負載均衡的系統(tǒng)設計的，可以用來檢驗如果系統(tǒng)局部發(fā)生故障，用戶是否能夠繼續(xù)使用系統(tǒng)；以及如果這種情況發(fā)生，用戶將受到多大程度的影響。
特點：
（1） 主要目的是驗證在局部故障情況下，系統(tǒng)能否繼續(xù)使用。
（2） 還需要指出，當問題發(fā)生時“能支持多少用戶訪問”的結論和“采取何種應急措施”的方案。
（3） 一般來說，只有對系統(tǒng)持續(xù)運行指標有明確要求的系統(tǒng)才需要進行這種類型的測試。
2. 性能測試目標
概況來說，可分為4個方面：
2.1 能力驗證
在系統(tǒng)測試或驗收測試時，我們需要評估系統(tǒng)的能力，衡量系統(tǒng)的性能指標。系統(tǒng)的能力可以是容納的并發(fā)用戶數(shù)，也可能是系統(tǒng)的吞吐率；系統(tǒng)的性能指標可以是響應時間，也可以選擇 CPU、內存、磁盤、網(wǎng)絡的使用情況。
特點：
（1） 要求在已確定的環(huán)境下進行。
（2） 需要根據(jù)典型場景設計測試方案和用例。
一般采用的方法是：性能測試、壓力測試、可靠性測試、失效恢復測試。
2.2 能力規(guī)劃
評估某系統(tǒng)能否支持未來一段時間內的用戶增長或是應該如何調整系統(tǒng)配置，使得系統(tǒng)能夠滿足增長的用戶數(shù)的需要。
特點：
（1） 屬于一種探索性的測試
（2） 可被用來了解系統(tǒng)的性能以及獲得擴展性能的方法，例如系統(tǒng)擴容規(guī)劃。系統(tǒng)容量可以是用戶容量，也可能是數(shù)據(jù)容量，或者是系統(tǒng)的吞吐量（系統(tǒng)的處理能力）。對于集群服務我們更多的是用吞吐率作為容量。
方法是①先對各子系統(tǒng)、組件進行性能測試，找出它們之間的最優(yōu)配比；②然后再通過各環(huán)節(jié)的水平擴展，計算出整體的擴容機器配比。
一般采用的方法是：負載測試、壓力測試、配置測試。
2.3 性能調優(yōu)
為了更好的發(fā)揮系統(tǒng)的潛能，定位系統(tǒng)的瓶頸，有針對性的進行系統(tǒng)優(yōu)化。
方法是在進行系統(tǒng)調優(yōu)時，我們需要做好基準測試，用以對比性能數(shù)據(jù)的變化，并反復調整系統(tǒng)軟硬件的設置，以使系統(tǒng)發(fā)揮最優(yōu)性能。當然在進行系統(tǒng)優(yōu)化時，我們會選取關鍵的指標進行優(yōu)化，返時可能要犧牲其他的性能指標。如目標是優(yōu)化響應時間，我們可能選取的策略是以空間換時間，以犧牲內存或擴大緩存為代價，還需要我們在各個性能指標中找到平衡點。
一般對系統(tǒng)的調整包括以下3個方面：
（1） 硬件環(huán)境的調整
（2） 系統(tǒng)設置的調整
（3） 應用級別的調整
一般采用的方法是：基準測試、負載測試、壓力測試、配置測試和失效恢復測試。
2.4 發(fā)現(xiàn)缺陷
和其他測試一樣，性能測試也可以發(fā)現(xiàn)缺陷。特別是嚴格并發(fā)訪問時是否存在資源爭奪導致的響應時間過慢，或大量用戶訪問時是否導致程序崩潰。
方法是設置集合點，實現(xiàn)嚴格并發(fā)用戶訪問；或者設置超大規(guī)模用戶突發(fā)訪問等這樣的性能測試用例進行測試。
一般采用的方法是：并發(fā)測試。
三、 性能需求分析
1. 性能需求獲取
1.1 功能規(guī)格說明書
1.2 系統(tǒng)設計文檔
1.3 運營計劃
1.4 用戶行為分析記錄
2. 性能關鍵點選取
主要從以下4個維度進行選?。?
2.1 業(yè)務分析
確定被測接口是否屬于關鍵業(yè)務接口或先分析出關鍵業(yè)務以間接獲取該業(yè)務所訪問的接口。
2.2 統(tǒng)計分析
若接口系統(tǒng)訪問行為存在日志分析記錄，則直接獲取日訪問量高的接口；否則根據(jù)接口發(fā)布類型，選擇第3方日志分析工具間接獲取。
（1） IIS日志分析工具：Log Parser 2.2 + Log Parser Lizard GUI
下載地址：http://www./log_parser_lizard.aspx
（2） Tomcat日志分析工具：AWStats v7.3
下載地址：http://www.
（3） Nginx日志分析工具：GoAccess v0.9
若IIS或Tomcat等接口應用服務器使用Nginx進行負載，則日志訪問量要以負載為準，因避免接口在Nginx設置緩存（即未進行透傳）而導致統(tǒng)計不正確。
下載地址：http://www.

2.3 技術分析
（1） 邏輯實現(xiàn)復雜度高的接口（如判斷分支過多或涉及CPU/IO密集型運算等）
（2） 對系統(tǒng)（內存、CPU、磁盤IO）及網(wǎng)絡IO等硬件資源耗用高的接口
備注：若接口因邏輯修改而重構，則需重新分析。
2.4 運營分析
由于運營推廣活動導致日訪問突增高的接口。
備注：若運營計劃調整，則需重新分析。
3. 性能指標描述
3.1 響應時間
在一般情況下，弱交互類接口平均響應時間不超過1秒，強交互類接口平均響應時間不超過200毫秒。
3.2 成功率
在一般情況下，接口響應成功率需達到99.99%以上。
3.3 系統(tǒng)資源
若為最佳負載，則系統(tǒng)CPU及內存使用率建議區(qū)間[50%，80%]，否則建議不超過50%。
3.4 處理能力
立項申請書明確要求：在XX壓力下（并發(fā)數(shù)）TPS需達到XX或 接口系統(tǒng)可支撐XX萬實時在線訪問。
3.5 穩(wěn)定性
在實際系統(tǒng)運行壓力情況下，可穩(wěn)定運行N*24(一般 N >= 7 )小時。 在高于實際系統(tǒng)運行壓力1倍的情況下，可穩(wěn)定運行12小時。
3.6 特性指標
例：Java類應用 FullGC 次數(shù) <= 1次/天

四、 性能測試范圍
1. 業(yè)務范圍
關鍵業(yè)務功能點描述。
2. 設計范圍
網(wǎng)絡接入層、接口層、中間件、存儲層等被測組件及拓撲結構描述。
五、 并發(fā)數(shù)計算方法
做過一些性能測試的童鞋剛開始比較糾結某個或某一類接口的并發(fā)數(shù)如何計算，其實并發(fā)數(shù)可以從用戶業(yè)務和服務器的2個角度來看。
1. 80/X原則
適用范圍：無限制
以一項目為案例，母親節(jié)當天接口服務器訪問量分布如下所示，如何計算當天平均并發(fā)數(shù)和高峰并發(fā)數(shù)？

通過百度統(tǒng)計平臺 http://#baidu.com/ 查看母親節(jié)當天UV曲線分布 與 請求量呈線性關系，如下所示：

采用微積分的思想，將每個時間點視為一個矩形，可以通過求和的方式求出整個分布圖的面積，如下所示：

其實每個矩形的長度均為1（1小時），故求面積時只需考慮寬度，即考慮每小時請求量即可。
根據(jù)80/X原則，找出占據(jù)總體面積80%的時間，選擇盡可能大的點計算出占據(jù)總體面積80%的時間，發(fā)現(xiàn)點的個數(shù)是7，意味著此時間長度占總時間長度30%，則80/X原則轉換成80/30原則，如下所示：

故，平均并發(fā)數(shù)（每秒平均請求數(shù)）= 80% * 日請求量 / 1天 * 30%
進而計算出最高峰值與平均并發(fā)數(shù)的倍數(shù) = 2.25
故，高峰并發(fā)數(shù)（每秒高峰請求數(shù)）= 2.25 * 平均并發(fā)數(shù) =
2.25 * 80% * 日請求量 / 1天 * 30% = 6 * 日請求量 / 1天
因UV與請求量曲線分布呈線性關系，日請求量 = 9.25 * 日UV
故，高峰并發(fā)數(shù) = 6 * 9.25 * 日UV / 1天 = 55.5 * 日UV / 1天
2. 公式法
適用范圍：Web類訪問
公式（1）計算平均并發(fā)用戶數(shù)：C = n * L / T
C是平均的并發(fā)用戶數(shù)；n是login session的數(shù)量；L是login session的平均長度；T指考察的時間段長度。

公式（2）計算并發(fā)用戶數(shù)峰值： C’≈ C+3根號C

C’指并發(fā)用戶數(shù)的峰值，C就是公式（1）中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設用戶的login session產(chǎn)生符合泊松分布而估算得到的。

例1：
假設有一個OA系統(tǒng)，該系統(tǒng)有3000個用戶，平均每天大約有400個用戶要訪問該系統(tǒng)，對一個典型用戶來說，一天之內用戶從登錄到退出該系統(tǒng)的平均時間為4小時，在一天的時間內，用戶只在8小時內使用該系統(tǒng)。
C = 400 * 4 / 8 = 200
C’≈ 200 + 3 * 根號200 = 242
為了更好地理解上述公式，將其轉換為如下公式：
公式（3）并發(fā)用戶數(shù) = 吞吐率 * 場景業(yè)務時間 / 單位時間段
例2：
一個OA系統(tǒng)，1小時內有8000用戶登錄系統(tǒng)。用戶每次登錄系統(tǒng)，需啟動登錄頁面，然后輸入用戶名和密碼，進入首頁。一般情況下，用戶在上述操作過程中需耗時5秒，且要求從點擊登錄按鈕到首頁完全展現(xiàn)，需控制在5秒內。
分析：
吞吐率 = 8000 * 2（整個業(yè)務操作需加載2次頁面才能完成）
場景業(yè)務時間 = 5 + 5 = 10 秒
單位時間段 = 1小時 = 3600 秒
并發(fā)用戶數(shù)（登錄場景） = （8000 * 2）* 10 / 3600 = 45
通過以上方法得到業(yè)務并發(fā)數(shù)后，我們可以進一步分析業(yè)務訪問了哪些接口，我們只要模擬這些接口調用方式和調用時序就行了。
有時我們需要計算某一個或某一類接口的并發(fā)數(shù)，我們可以按如下步驟進行分析計算：
（1） 梳理出被測接口被訪問的業(yè)務場景和每個業(yè)務場景訪問的次數(shù)
（2） 通過上述方法計算出業(yè)務場景的并發(fā)用戶數(shù)
接口并發(fā)數(shù) = 場景1 并發(fā)用戶數(shù) * 業(yè)務場景接口調用次數(shù)1 + 場景2并發(fā)用戶數(shù) * 接口調用次數(shù)2 + …

假如一個系統(tǒng)需支撐10萬在線用戶數(shù)訪問，如何通過性能需求分析來計算并發(fā)用戶數(shù)？大家可以通過以上內容學習，獨立思考下？

六、 性能測試用例與場景

1. 腳本模板
   　 　 　 　 　
2. 場景模板
   　

七、 性能測試工具選擇
1. 數(shù)據(jù)建模工具
DataFactory是一種強大的數(shù)據(jù)產(chǎn)生器，它允許開發(fā)人員和QA很容易產(chǎn)生百萬行有意義的正確的測試數(shù)據(jù)庫,該工具支持DB2、Oracle、 Sybase、SQL Server數(shù)據(jù)庫，支持ODBC連接方式，無法直接使用MySQL數(shù)據(jù)庫，可間接支持。
2. 腳本開發(fā)工具
（1） 若考慮腳本運行效率，則可考慮底層開發(fā)語言C或支持異步通信的語言js,我們可以分別選擇：Loadrunner 或 Node.js 的IDE環(huán)境進行開發(fā)。
（2） 若考慮腳本開發(fā)效率，則可考慮代碼復用性，可以選擇面向對象語言C#或Java，為此我們可以分別選擇：VS2008及以上版本 + 對應LR.NET控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。
HTTP、Socket等協(xié)議接口性能測試腳本開發(fā)過程，請詳見附件：
HTTP接口性能測試之腳本開發(fā)與性能問題分析.pdf
利用LR.net控件完成性能測試腳本編寫方法.pdf
node.js學習入門手冊.pdf
3. 壓力模擬工具
（1） 若為Java類接口且單機并發(fā)數(shù)控制在500內，則可選擇Jmeter或者 Loadrunner。
（2） 若為WebService類接口且單機并發(fā)數(shù)控制在500內，則可選擇SoapUI或者Loadrunner。
（3） 若單機并發(fā)數(shù)超過500且控制在5000內，則可選擇Loadrunner。
（4） 若單機并發(fā)數(shù)超過5000，則建議采用負載集群，即采用“中控（Control Center）+ 多機部署（Load Generator）”方案。
4. 性能監(jiān)控工具
4.1 監(jiān)控工具
無論Windows或Linux平臺，一般存在的是一個或一組進程實例，我們可以選擇Loadrunner 或 Nmon 來監(jiān)控。有時為了獲取被測應用的一些特性指標，可以選擇被測組件自帶的性能工具集或監(jiān)控系統(tǒng)。常見應用服務器監(jiān)控工具推薦如下：

4.2 監(jiān)控平臺
監(jiān)控機器主要對被測集群服務器的服務或資源使用情況進行監(jiān)控，比如各種開源的監(jiān)控工具，MRTG：流量監(jiān)控；CACTI：流量預警，性能報告Smokeping:IDC 質量監(jiān)控；綜合監(jiān)控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：

4.3 第三方監(jiān)控云服務（APM）
APM提供端到端應用性能管理軟件及應用性能監(jiān)控軟件解決方案,包含移動,瀏覽器,應用,基礎設施,網(wǎng)絡,數(shù)據(jù)庫性能管理等，支持Java、.NET、PHP、Ruby、Python、Node.js、iOS、Android、HTML5等應用性能監(jiān)控管理，主流云服務包括聽云、OneAPM等，如下所示：

八、 性能測試結果分析
1. 指標分析
性能測試的指標可分為產(chǎn)品指標和資源指標兩類。對測試人員而言，性能測試的需求來自于用戶、開發(fā)、運維的三方面。用戶和開發(fā)關注的是與業(yè)務需求相關的產(chǎn)品指標，運維人員關注的是與硬件消耗相關的資源指標。

（1） 從用戶角度關注的指標
用戶關注的是單次業(yè)務相關的體驗效果，譬如一次操作的響應快慢、一次請求是否成功、一次連接是否失敗等，反映單次業(yè)務相關的指標包括：
a.成功率b.失敗率c.響應時間
（2） 從開發(fā)角度關注的指標
開發(fā)人員更關注的是系統(tǒng)層面的指標。
a.容量：系統(tǒng)能夠承載的最大用戶訪問量是多少?系統(tǒng)最大的業(yè)務處理量是多少?
b.穩(wěn)定性:系統(tǒng)是否支持7*24小時(一周)的業(yè)務訪問。
（3） 從運維角度關注的指標
運維人員更關注的是硬件資源的消耗情況。

以上說明了測試人員在選擇指標時需站在用戶角度去思考，另外為了后續(xù)能夠更好地分析問題，更需掌握與被測組件特性或運行原理相關的性能指標。

舉例來說，通常接口系統(tǒng)均會直接或間接地訪問數(shù)據(jù)庫層介質（如mysql、oracle、SQLServer等），此時我們需考慮由接口系統(tǒng)產(chǎn)生壓力下存儲介質的性能情況，通常我們會選擇分析指標如下：
（1） 連接數(shù)（Connections）
（2） 每秒查詢數(shù)/每秒事務數(shù)（QPS/TPS）
（3） 每秒磁盤IO數(shù)（IOPS）
（4） 緩存命中率（Buffer Hits）
（5） 每秒發(fā)生的死鎖數(shù)（Dead Locks/sec）
（6） 每秒讀/寫字節(jié)數(shù)（Read/Write Bytes/sec）
對于Windows或linux平臺具體指標監(jiān)控及分析方法，請詳見附件：
《Windows操作系統(tǒng)性能監(jiān)控工具和指標分析V1.0》.pdf
《Linux操作系統(tǒng)性能監(jiān)控分析手冊V1.0》.docx
2. 建模分析
2.1 理發(fā)店模型

圖中展示的是1個標準的軟件性能模型。在圖中有三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這里是指每秒事務數(shù)）以及響應時間（Response Time）。圖中坐標軸的橫軸從左到右表現(xiàn)了并發(fā)用戶數(shù)（Number of Concurrent Users）的不斷增長。
在這張圖中我們可以看到，最開始，隨著并發(fā)用戶數(shù)的增長，資源占用率和吞吐量會相應的增長，但是響應時間的變化不大；不過當并發(fā)用戶數(shù)增長到一定程度后，資源占用達到飽和，吞吐量增長明顯放緩甚至停止增長，而響應時間卻進一步延長。如果并發(fā)用戶數(shù)繼續(xù)增長，你會發(fā)現(xiàn)軟硬件資源占用繼續(xù)維持在飽和狀態(tài)，但是吞吐量開始下降，響應時間明顯的超出了用戶可接受的范圍，并且最終導致用戶放棄了這次請求甚至離開。
根據(jù)這種性能表現(xiàn)，圖中劃分了三個區(qū)域，分別是Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受并放棄請求）。在Light Load和Heavy Load 兩個區(qū)域交界處的并發(fā)用戶數(shù)，我們稱為“最佳并發(fā)用戶數(shù)（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個區(qū)域交界處的并發(fā)用戶數(shù)則稱為“最大并發(fā)用戶數(shù)（The Maximum Number of Concurrent Users）”。
當系統(tǒng)的負載等于最佳并發(fā)用戶數(shù)時，系統(tǒng)的整體效率最高，沒有資源被浪費，用戶也不需要等待；當系統(tǒng)負載處于最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)之間時，系統(tǒng)可以繼續(xù)工作，但是用戶的等待時間延長，滿意度開始降低，并且如果負載一直持續(xù)，將最終會導致有些用戶無法忍受而放棄；而當系統(tǒng)負載大于最大并發(fā)用戶數(shù)時，將注定會導致某些用戶無法忍受超長的響應時間而放棄。所以我們應該保證最佳并發(fā)用戶數(shù)要大于系統(tǒng)的平均負載。
2.2 壓力變化模型

隨著單位時間流量的不斷增長，被測系統(tǒng)的壓力不斷增大，服務器資源會不斷被消耗，TPS 值會因為這些因素而發(fā)生變化，而且符合一定的規(guī)律。

圖中：
a 點：性能期望值
b 點：高于期望，系統(tǒng)資源處于臨界點
c 點：高于期望，拐點
d 點：超過負載，系統(tǒng)崩潰
2.3 容量計算模型

以一網(wǎng)站性能測試為案例：
1. 通過分析運營數(shù)據(jù)，可以知道當前系統(tǒng)每小時處理的PV數(shù)
2. 通過負載測試，可以知道系統(tǒng)每小時最大處理的PV數(shù)

即整理得

系統(tǒng)每小時PV處理剩余量 = 系統(tǒng)每小時最大處理的PV數(shù) — 系統(tǒng)每小時處理的PV數(shù)

假設該網(wǎng)站用戶負載基本呈線性增長，現(xiàn)有系統(tǒng)用戶數(shù)為70萬，根據(jù)運營推廣計劃，1年內該網(wǎng)站發(fā)展用戶將達到1000萬，即增長了14倍。即整理得：

系統(tǒng)每小時PV處理增加量 = 當前系統(tǒng)每小時處理的PV數(shù) * 14 — 當前系統(tǒng)每小時處理的PV數(shù)

每天系統(tǒng)負載增加率 = 100% / 365 = 2.74 % （備注：此處將未來系統(tǒng)用戶數(shù)達到1000萬的負載定義為 100% ）

系統(tǒng)每天PV處理增加量 = 系統(tǒng)每小時PV處理增加量 * 每天系統(tǒng)負載增加率 * 24

所以，我們可以知道在正常負載條件下：

系統(tǒng)可支持正常運行天數(shù) = 系統(tǒng)每小時PV處理剩余量 * 24 / 系統(tǒng)每天PV處理增加量

假設該網(wǎng)站后續(xù)部署升級天數(shù)已知，這樣我們可以知道提前升級的天數(shù)：

系統(tǒng)可支持正常運行天數(shù) — 部署升級天數(shù)。
九、 性能測試通過標準
1. 所有計劃的測試已經(jīng)完成。
2. 所有計劃收集的性能數(shù)據(jù)已經(jīng)獲得。
3. 所有性能瓶頸得到改善并達到設計要求。
十、 性能測試書籍推薦

十一、 性能測試報告模板
詳見附件：
性能測試報告模板.doc