昨天寫完了，然後點發表，竟然什麼都沒了，真是惆悵啊。難道是長時間沒響應？之前好象不會把今天重寫把。

最近因為在公司因為搞效能測試的沒什麼人了，我也就逐漸轉向效能測試方面的學習了。學習了大概有3個星期了，也用了LR跑了一些場景，不過覺得首先還是要把一些基本概念理解清楚，所以就把一些基本的東西寫下來。讓自己加深理解。也希望幫助大家瞭解一些。

一. 軟體效能測試

在我們學習效能測試之前，首先要明白什麼是效能。汽車有他的效能，比如速度，加速時間，穩定性；電腦硬體有他的效能，比如CPU的頻率，處理的速度，遊戲的效能。而計算機軟體也有他的效能，比如軟體執行速度如何，系統穩定性如何等等。效能的好壞不能憑空想象。必須有一些資料來說明來比較。所以我們軟體效能測試就是通過得到軟體在各種執行情況下的資料來進行分析，來判斷軟體的效能。一個軟體對於不同的人群，他所關注的效能方面是不一樣的。比如對於使用者來說，他關心的是程式響應的時間，也就是他點一個提交按鈕，多長時間可以得到結果。而對於系統管理員他關注的可能是軟體在執行時，對系統資源的使用情況，在大量使用者使用時的表現如何，能否長時間穩定的工作；而對於開發人員，他們更關心的是系統結構是否合理，SQL執行速度是否夠快，有沒有記憶體洩漏等情況。而對於我們測試人員來說，我們需要站在多個 角度來關心效能問題。

二 效能測試主要術語

1：響應時間：

響應時間的定義是：對請求作出響應所需要的時間。我們一般把響應時間作為使用者角度衡量軟體效能的主要指標。

畢竟系統是給使用者使用的，使用者對系統性能是否滿意是使用者說了算的。一般情況下響應時間是分為多個步驟的，首先從客戶端發出請求，經過網路達到伺服器N1，應用伺服器處處理S1，訪問資料庫伺服器N2，資料庫伺服器處理時間為D1，然後返回給應用伺服器的網路時間為N3，應用伺服器處理時間S2，在傳個客戶端的網路時間是N4。那麼整個響應時間應該為T=N1+S1+N2+D1+N3+S2+N4,當然如果還用到其他伺服器，還要加上其他時間。而實際上，除開這T，還有一個客戶端的顯示時間也要可以算做響應時間。所以時間Tx = T +Ts。但實際上Ts很大程度上是由使用者的機器決定的，所以我們一般只關注T，所以通常把T稱做響應時間。

一般一個網站，被普遍接受的響應時間是2/5/10，就是說2秒內給使用者響應是很滿意的，5秒是可以接受，而我一般是等不到10秒就會ALT+F4了！但不同的軟體，響應時間的標準要根據實際情況來定。比如一個數據庫備分軟體，你能要求他5秒內搞定一個1G的資料庫嗎？

2：併發使用者數

對於一個系統來說，併發使用者數是很重要的一個指標。併發使用者數也分為兩種，分別是業務併發使用者數和服併發訪問數。在具體談這之前我們先討論下併發這個概念，並舉個例子幫助大家瞭解。

學習過作業系統的朋友都知道。併發性，又稱共行性，是指能處理多個同時性活動的能力；與之類似的還有一個並行，它是指同時發生的兩個併發事件，具有併發的含義。而併發則不一定並行，也亦是說併發事件之間不一定要同一時刻發生。舉個列子，我有10輛車，但只有一條路。我10輛車同時提出請求，要走這條路。但同一個時刻，只有一輛車能出發。這個時候我們就稱為併發。如果我修了2條路，那麼同一時刻有2輛車可以同時出發，我們可以說這2個車是並行的，而所有的車一起看來是併發的。如果我修了10條路，那麼10輛車同時出發，那麼就可以說他們是並行的。

作業系統中的CPU就好象這條路，如果只有一個CPU核心，那麼同時只能處理一個程序，其他程序就必須等待，這些程序可能同時提出CPU請求，那麼他門是併發的。如果有多個CPU，就可以同時處理多個程序。同時處理的程序是並行的。我們從巨集觀角度看不出兩者的區別，但微觀上，並行是永遠同時進行的，而併發則不是。

理解了併發大概的意思，在來談我們前面說的2種併發使用者的概念。

業務併發數是指從業務的角度來看，就是一端時間內有多少個使用者在使用我們的系統。但這些使用者的操作可能不同，比如有的再瀏覽，有的在提交請求，有的在發呆。要注意的是這個時候所以使用者都算如業務併發使用者數。而不是僅僅只看在象伺服器請求的使用者。這個地方的併發和前面概念有點不一樣。就好比理髮店有一個師傅，同一時間只能給一個人理髮，這個時候來了5個使用者，我們就可以說這5是業務併發使用者數。我們並不需要了解這些使用者到底是不是都是來理髮的，或許只是來和老闆聊天的。而另一個概念是伺服器承受的併發訪問數。聯絡到我們系統就是在同一個時間點，向伺服器發起的請求數。也就是前面那部分在提交請求的使用者數。還是看上面理髮店的例子。來的5個使用者，有3個是需要理髮的。他們同時象師傅提出理髮的請求，這就是對伺服器而言的併發使用者數了。

而對於我們測試，關注比較多的就是業務併發數。而伺服器併發是用來了解在最大壓力情況下伺服器對於資源競爭引起的問題。所以我們必須分清測試時要測那一種併發的情況。而我們通常直接把業務併發數稱為併發使用者數。

3： 其他相關使用者數

瞭解了併發使用者數的概念，在看下其他一些相關的使用者概念。

系統使用者數：

是我們經常聽到的，他是指一個系統可以支援多少個使用者。也就是可能使用系統的最大使用者數。這是一個靜態的概念。並不代表系統可以同時應付這麼多使用者，只是說可以支援這麼多擁護。

同時線上人數：

我門經常聽到一個網站會說我們有多少多少使用者同時線上。這就是一個動態的概念。他們只是連線到了系統，但不一定都對系統產生了很大的壓力。而一個系統最多能容納多少使用者同時線上，就是系統能支援的同時線上人數。也可以理解為前面的業務併發使用者數，但是系統最大支援的業務併發數。超過這個數的使用者連線系統可能就會遇到習效能障礙。

具體場景的併發使用者數：

前面已經說到了併發使用者數，就是在一段時間類連線到系統的使用者數。但前面的的定義並不嚴格。因為不同使用者處於的場景不同，那麼對伺服器的壓力也不同。比如100%的使用者都在發呆和100%使用者都在請求資源的壓力肯定不同，那我們就不能說系統是否支援100個併發使用者。  所以談到併發數，我們必須結合實際的場景。所以千萬不要脫離場景去談併發。就好象在美國買IBM你說會說IBM很便宜，但你不知道在中國很貴。你必須結合你的場景--美國來說IMB很便宜。

PS：這個問題是我在使用LR中一直很困惑的。因為當時就想，我讓100個使用者不斷進入系統，如果最後一個進來是，前面的10個已經完成了任務，退出了，那就不能說支援100併發啊。這就是忽略的場景。因為那10個使用者推出的這個業務，不屬於這個場景了。這個時候在按100來談併發就沒有了意義。但也不是說我們只能針對單一的場景來談併發，在綜合場景測試中就會象前面說的，一些使用者在發呆，一些使用者在請求。那麼這個時候我們就要說在綜合場景下的併發是多少。總之併發數不能脫離場景。

看到書上還有寫計算併發使用者的一些公式，自己暫時不想去研究，也不知道作用如何。大家可以自己去看。有一個經驗公司就是把每天系統訪問數的10%作為平均併發使用者數（這裡應該是指綜合場景），最大併發一般為平均值的2-3倍。

4：吞吐量

吞吐量是指單位時間內系統處理客戶請求的數量，他直接體現了軟體系統的效能承載能力。

一般來說可以從業務角度的‘頁面數/秒’，‘請求數/秒’來衡量，也可以通過‘位元組數/秒’等多個方面來衡量。我們可以通過前面的響應時間和併發數來確定一個互動系統的效能。而對於非互動系統，吞吐量更能反映效能。而對於互動系統，吞吐量反映了伺服器承受的壓力，他能夠說明系統級別的負載能力而且在效能調優過程中也有重要作用。比如通過‘位元組數/秒’反映網路，伺服器架構的制約，用‘單擊數/秒’表示主要受伺服器和應用程式碼的限制。

通過吞吐量，併發數和響應時間，我們可以大概瞭解一個系統的效能。當併發數增大時，吞吐量會增大，響應時間有所增加。但併發數繼續增加時，響應時間增大的幅度變大，而吞吐量逐漸平緩穩定。當併發數繼續增大，響應時間會明顯快速增大，而吞吐量可能因為伺服器壓力過大，反而出現下降。所以一定要結合起來一起看。

5：效能計數器和資源利用率

效能計數器是伺服器或作業系統效能的一些資料指標。比如WINDWOS中的程序時間，使用記憶體數等計數器。

資源利用率是系統各個資源的使用情況。比如WINDOWS的資源管理器，Linux下top命令，以及sysstat工具都可以用來監視系統資源。通過這些資源，結合前面的響應時間，吞吐量，併發來進一步分析系統性能。

6：思考時間

從業務角度來說，就是在操作過程中停頓的時間，不如使用者想自己密碼的時間。使用思考時間，是為了更好的模擬真實的應用環境。具體設定多少時間也有一個公式來計算，但我並不太清楚。只是在LR錄製指令碼時，儘量安裝正常的操作時間來操作，LR會自動把你未操作的時間設為思考時間。

三：效能測試的方法

1：效能測試(Performance Testing)

通過模擬系統生產執行的壓力量和使用場景組合，測試系統是否滿足效能要求。也就是說在指定的環境下執行，來驗證系統能力。這種測試首先需要對測試的場景的業務比較熟悉，在就是要有一個明確的目標，比如能否達到100使用者併發時響應時間不超過5秒。最後就是這種測試的環境是確定的。

2：負載測試（Load Testing）

負載測試是在被測系統上不斷增加壓力，直到效能指標。比如響應時間超過指標或資源飽和。這種方法被稱為Scalability Testing可量性測試。主要目的是找到系統處理能力的極限。一般會給定一些條件，比如響應時間不超過10秒，CPU利用率底於65%。同樣這個測試也需要一個給定的環境，也要考慮執行時的場景。而且在效能調優時也用這種方法來檢視前後的差異。

3：壓力測試(Stress Testing)

是指系統在一定飽和狀態下，如CPU，記憶體在飽和狀態下處理的能力。主要觀察的是系統在壓力情況下的效能表現，重點觀察是否會出現錯誤,響應時間如何。通常這些測試的描述會為，當CPU使用率在75%以上，記憶體使用70%以上，等作為測試依據。這種測試一般用於系統穩定性測試。

4：配置測試（Configuration Testing）

通過對系統軟硬體的調整，瞭解不同環境對效能的影響，找到最優的分配方式。一般是在對系統性能有一定了解的基礎上，多用於效能調優。

5：併發測試（Concurrency Test）

這就是前面說的使用者同時對一個資源或模組資料發出請求的情況。通過這種測試手段可以發現系統中一些效能問題，比如資源競爭，死鎖，記憶體洩露等問題。他可以在各個測試階段使用。

6：可靠性測試（Reliability Testing）

通過給系統載入一定壓力的情況下，讓系統長時間執行，測試他在這種條件下能否穩定執行。主要是驗證系統能否長期穩定執行。測試過程中，需要關注系統的資源情況。

7：失效恢復測試（Failover Testing）

這個主要是測試系統在部分發生故障時，使用者能否繼續使用，多少使用者會受到影響。一般測試時要指出系統發生鼓掌時能支援多少使用者訪問，採取什麼應急措施。