來自：http://www.cnblogs.com/fnng/archive/2012/06/09/2543274.html  作者：蟲師

從這一篇開始，蟲師向性能方面發力。翻看自己的部落格，最早的時候熱衷於jmeter，於是寫了幾篇圖文並茂的文章（其實，主要是操作截圖加文字描述），之後，由於看到好多朋友關於效能的知識什麼都不知道，下載個loadrunner 就說要做效能測試，結果可想而知，遇到各種概念與使用問題。於是寫了《在做效能測試之前需要知道什麼》《在做效能測試之後需要知道什麼》，關於loadrunner的我沒有寫一篇部落格，因為介紹loadrunner的網站、資料、書籍和視訊太多了。我想這個系列我也會把關注點放在思想上。

效能測試常見分類                                                                   　　

　　常會別人說到效能測試、負載測試、壓力測試、併發測試，很多人都是混合使用，或者一會叫壓力測試，一會叫併發測試。這些概念除了非測試人員分不清楚，甚至許多專業測試人員也對這些名詞也很模糊。關於這個分類我翻閱了幾個本比較好的書籍，他們講的也比較模糊，沒有給出本質上的區別。只是從不同角度和關 注點來解釋。好吧我們先來看他們之間比較普遍的解釋。

效能測試（狹義）

　　效能測試方法是通過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能是否滿足生產效能要求。通俗地說，這種方法就是要在特定的執行條件下驗證系統的能力狀態。

特點：

1、這種方法的主要目的是驗證系統是否有系統宣稱具有的能力。
2、這種方法要事先了解被測試系統經典場景，並具有確定的效能目標。
3、這種方法要求在已經確定的環境下執行。

也就是說，這種方法是對系統性能已經有了解的前提，並對需求有明確的目標，並在已經確定的環境下進行的。

負載測試

通過在被測系統上不斷加壓，直到效能指標達到極限，例如“響應時間”超過預定指標或都某種資源已經達到飽和狀態。

特點：

1、這種效能測試方法的主要目的是找到系統處理能力的極限。
2、這種效能測試方法需要在給定的測試環境下進行，通常也需要考慮被測試系統的業務壓力量和典型場景、使得測試結果具有業務上的意義。
3、這種效能測試方法一般用來了解系統的效能容量，或是配合效能調優來使用。

也就是說，這種方法是對一個系統持續不段的加壓，看你在什麼時候已經超出“我的要求”或系統崩潰。

壓力測試（強度測試）

壓力測試方法測試系統在一定飽和狀態下，例如cpu、記憶體在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤

特點：

1、這種效能測試方法的主要目的是檢查系統處於壓力效能下時，應用的表現。
2、這種效能測試一般通過模擬負載等方法，使得系統的資源使用達到較高的水平。
3、這種效能測試方法一般用於測試系統的穩定性。

也就是說，這種測試是讓系統處在很大強度的壓力之下，看系統是否穩定，哪裡會出問題。

併發測試

併發測試方法通過模擬使用者併發訪問，測試多使用者併發訪問同一個應用、同一個模組或者資料記錄時是否存在死鎖或其者他效能問題。

特點：

1、這種效能測試方法的主要目的是發現系統中可能隱藏的併發訪問時的問題。
2、這種效能測試方法主要關注系統可能存在的併發問題，例如系統中的記憶體洩漏、執行緒鎖和資源爭用方面的問題。
3、這種效能測試方法可以在開發的各個階段使用需要相關的測試工具的配合和支援。

也就是說，這種測試關注點是多個使用者同時（併發）對一個模組或操作進行加壓。

配置測試

配置測試方法通過對被測系統的軟\硬體環境的調整，瞭解各種不同對系統的效能影響的程度，從而找到系統各項資源的最優分配原則。

特點：

1、這種效能測試方法的主要目的是瞭解各種不同因素對系統性能影響的程度，從而判斷出最值得進行的調優操作。
2、這種效能測試方法一般在對系統性能狀況有初步瞭解後進行。
3、這種效能測試方法一般用於效能調優和規劃能力。

也就是說，這種測試關注點是“微調”，通過對軟硬體的不段調整，找出這他們的最佳狀態，使系統達到一個最強的狀態。

可靠性測試

在給系統載入一定業務壓力的情況下，使系統執行一段時間，以此檢測系統是否穩定。

特點：

1、這種效能測試方法的主要目的是驗證是否支援長期穩定的執行。
2、這種效能測試方法需要在壓力下持續一段時間的執行。（2~3天）
3、測試過程中需要關注系統的執行狀況。

也就是說，這種測試的關注點是“穩定”，不需要給系統太大的壓力，只要系統能夠長期處於一個穩定的狀態。

上面的分類絕非全面，還有失效性測試，就是系統局部發生問題時，其它模組是否可以正常的執行。這個在極少數情況下進行，這裡就不介紹了。

效能測試分類之我見                                                                  

　　上面的類分完了，似乎得到不少專家的認同，並無不妥。但我們在效能測試過程中真的能把它們區別分的很清楚麼?你能嚴格區分出你這次的測試到底併發測試還是壓力測試。

　　筆者第一點不太贊同的是對“效能測試”的定義。筆者認為效能測式測試包含了上面的所有分類。而這種效能測試的定義只是一種狹義上的“效能測試”，屬於效能測試的一種。
　　效能測試是相對功能測試來說的。他們之間最本質的區別就是對系統有處理能力是否夠成壓力。如果一個使用者的一個操作（比如超大資料量的查詢）對系統夠成了壓力，我也可以視其為效能測試。

其實，可以這樣來劃分效能測試

　　上面定交了那麼多分類，是不是有點暈了。其實，以筆者認為我們進行效能測試時關注的就兩點。耐力和爆發力。

　　初高中時練過幾年體育，最好時代表學校參加縣體育比賽，不過是去墊底的。哈哈！哈一個體育運動員來說，那麼多的體育專案，其實，考核他的就兩方面。一是爆發力。二是耐力。

爆發力：拿一個舉重選手來說，他的重點在重量上，因為你只要能舉起三秒就算你成功了。關鍵是看你能舉起一個什麼樣的重量。

耐力：拿一個馬拉松運動員來說，你百米速度跑得再快沒用。關鍵是這40公里路程中，最先跑到終點的人才是贏家。

整體協調性：當然，身為一個教練員，我在選拔選手的時候，除了看這個運動員的耐力和爆發力，身體的整體協調性也是我考核的一個很重要的指標。比如一個執行員身體各位部位練得非常強壯，但右臂先天性萎縮。他的跑步成績雖然不錯。但他在跑的過程中，身體有各個部分都在分擔右臂的不足。右臂影響了整個體能的發揮。

　　再到系統的效能上說，爆發力就是這個系統能承受的最大壓力，沒準這個系統承受的壓力很大。但過半個小時之間就掛掉了。耐力就是這個每系統長時間處於壓力下的穩定性，這系統超級穩定，跑個幾十年都不用重啟伺服器。那麼整體協調性就是看系統有沒系統瓶頸，需不需要進行系統調優。

在做效能測試時請忘掉分類

這裡只是告訴在做效能測試時不要想這個測試是屬於效能測試的哪一類呢？是併發性測呢？還是壓力測試？

我們還拿上面的教練員選拔選手做例子。
　　記得我進校體隊的時候，教練說讓我跑兩圈。然後，我就開始圍繞著操場跑起來。你說教練讓我跑兩圈是想看我的什麼能力？
1、雙腿的考核，一個是步幅，就是步與步之間的距離。一個是頻率，兩腿交替的頻率。如果你一步拉得很大的話，那麼頻率一定會下降。如果想提高頻率的話，那麼一定會影響到步幅的大小。
2、雙臂的考核，肩膀是否放鬆，擺臂是否有力，雙臂的擺動與雙腿的擺動是否協調。
3、呼吸是否勻稱，目前的速度可以跑幾圈。

我只做了一項體育執行，就考核了我這麼多內容。我們在做一個性能測試時也不侷限在某一分類上，也可能我們的一個測試包含多個分類。

《web效能測試實戰》：
　　麼多型別的效能測試看起來很嚇人，實際上它他們大多是密切相關的。例如，執行8個小時來測試系統是否可靠，而這個測試極有可能包含了可靠效能測、強度測試、併發測試、負載測試，等等。因此，在實施效能測試時決不能割裂它們的內部聯絡去進行，而應該分析它們之間的關係，以一種高效率的方式來設計效能測試。