我對性能測試、壓力測試、負載測試的了解（轉）

鬥膽在此發表一些個人了解與看法，權作抛磚引玉，望各路英雄能各抒己見，不吝賜教。

　　首先，我們看一下來自百度百科的定義：

　　1、性能測試：是通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試。

　　2、負載測試：負載測試，确定在各種工作負載下系統的性能，目标是測試當負載逐漸增加時，系統各項性能名額的變化情況。

　　3、壓力測試：是通過确定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級别的測試。

　　我在這裡簡單談一下我對三個概念的看法。

　　一、性能測試

　　性能測試的目的是找到系統在某種條件下的瓶頸，前提是這種條件在軟體或服務的實際應用中可能發生。例如百度首頁會同時有10萬人通路，這是可能的。是以測試10萬個Vuser同時Hit是有意義的，但是會不會有10億人同時通路?顯然不會，至少在當今不會，是以測試的資料量定在10億個Vuser是無意義的，這種行為不靠譜。是以，在這一點上我們可以得出結論，具有清晰的、有意義的并且意義确定的預期值是進行一次性能測試的關鍵要素。

　　是以，我們在進行性能測試之前，首先要明确兩個值：一個是系統負載預期值，一個是系統響應時間的預期值。有了這兩個目标，才可以使用對系統持續增加負載的方法來觀察系統的瓶頸所在。

　　那麼性能測試就是簡單的添加負載測試嗎？顯然不是。前面說過，性能測試的目的是要找出系統的瓶頸所在，而系統的瓶頸可能存在于各種方面。在代碼方面，比較差的算法、硬代碼多的子產品等低效率的代碼可能産生瓶頸；在資料庫方面，備援或者複雜的資料可能産生瓶頸；作業系統方面，CPU、磁盤、I/O系統、總線及相容性等方面可能産生瓶頸；而在通信傳輸層面上，交換（路由）的轉發效率、網絡硬體品質等都可能引發系統瓶頸。對于以上這些可能引發瓶頸的原因，我們可以進行所謂白盒測試來找到問題的關鍵。各種層面上的問題，都有相應的測試工具或測試裝置的支援，如果沒有合适的工具，也可以自己進行設計。例如一些CPU監控工具、代碼檢測、資料庫事件探查器、Chariot等，以及網絡分析儀、資料分析儀等通信分析儀器。這些都是性能測試的利器。

　　我們在性能測試出現瓶頸時，需要及時的調試對應的系統問題，但是如果在調試完成之後，系統表現好了一些，但是仍然沒有達到預期目标，這個時候我們就應該把目光放在系統的其他層面上。由于一個系統是由多個子系統協作的，是以各個子系統之間有着密切的關聯性。以WEB系統為例，當代碼層以及資料庫層都進行清洗之後，還可以通過其他途徑提高系統的性能，以突破瓶頸，達到預期目标。

　　性能測試的另外一個目的是要建立一組被測系統的基準資料，系統在同樣的測試環境與測試條件下，表現應當符合或優于基準資料的要求，否則測試不通過。另外，基準資料也可以為其他類似的系統提供預期資料及預期傳回時間的數值參考。

　　本文出自alitester的51Testing軟體測試部落格：http://www.51testing.com/?271947

　　二、負載測試

　　負載測試的範圍個人認為比性能測試要狹窄一些，負載測試通常定義為給被測系統加上它所能操作的最大任務數的過程。負載測試考驗系統的兩個名額，一個是系統的容量，一個是系統的耐久性。

　　測試系統容量是指給系統添加大資料量的檔案或者資料，讓系統進行處理并實時觀察系統的表現情況。例如大資料量檔案輸入讓系統處理（我們很熟悉的操作，親們知道是啥意思吧？），大通路量的輸入處理等。目的是找到系統能添加負載的最大量。而測試系統耐久性則指的是給出數量巨大的任務，讓系統始終處于高負荷量的運作狀态，并觀察記錄系統表現情況的測試方式。目的是找到系統所謂的“疲勞點”。例如運作多少時間之後系統傳回時間開始變大，系統什麼時候處理時間變得緩慢等都是考察的内容。

　　負載測試實作的前提是要先準備巨大的資料量，例如上百兆的檔案、上萬的使用者等。負載測試不會以使系統崩潰為目的，是以負載測試的期望值一般以滿足使用需求為主，不需要太誇張的數值。

　　三、壓力測試

　　任何能使系統崩潰的測試都可以稱之為壓力測試。這一點我在會上已經多次說過了。比如給出超出系統期望值兩倍（一般業内共識是兩倍）的資料量讓系統處理，或者突然斷開與資料庫的連接配接然後再恢複，甚至是在伺服器上運作消耗CPU、磁盤等資源的任務，總而言之，壓力測試就是要想方設法的給系統添加壓力，讓系統出現故障，然後觀察系統在出現故障時的反應以及故障恢複的能力。例如系統是緩慢死亡的還是猝死的，是不是儲存了崩潰前的資料，故障恢複的時間有多久，恢複之後能不能傳回原先的工作狀态等等，隻要是有利于提高系統在大壓力情況下的表現的，都是考察的内容。

　　綜上所述，性能測試、負載測試以及壓力測試貌似是差别很大的測試方式，到底是不是這樣呢？讓我們回到我在會上提到的測試一個Wiki系統并發500次點選量的例子。

　　在這個例子中，我提到我們的測試者使用了LoadRunner，讓Vuser從50一直增加到1000的過程中，觀察系統的表現，重點關注響應數以及響應時間這兩個量。在這個例子中，當系統添加到50個Vuser時點選數及響應數都保持在100左右，系統表現良好，而當添加到250直至1000個 Vuser之後，系統點選數仍然保持在100，而響應時間最後超過了150秒，最後系統崩潰。

　　那麼這次測試到底測了些什麼呢？或者這次測試到底算什麼方式的測試呢？我們來分析一下。首先，我們設定了一個系統預期值500次點選量，沒有設定響應時間，因為在正常情況下，點選就應該馬上有響應，是以響應時間應該為零。這是性能測試和負載測試的基本要求。其次，當系統添加到250個Vuser之後，點選數仍然還是100，出現瓶頸了，而找系統的各種瓶頸正是性能測試的主要任務（此時CPU監控顯示使用率為96％）。然後，我們給出了一個大資料量的通路，500個Vuser，這個值系統在4分鐘到6分鐘的時間之内，勉強還能跑起來，這是負載測試的典型情況，當然500個Vuser是期望值所定的，負載測試是否最大隻能是這個數值還有待商榷。最後Vuser增加到1000，系統崩潰，這是壓力測試的目的。在這次測試實踐中，我們通過性能測試知道了系統目前的最大瓶頸在哪裡；通過負載測試了解到500個Vuser條件下至少還能跑起來，是以可以試一下提高CPU性能是否能提高系統性能；通過壓力測試了解到系統的響應時間是緩慢增加的，崩潰過程是逐漸進行的。是以可以着手進行系統優化，然後準備下一次測試。

　　上面這個例子說明，一次測試可以包含性能測試、負載測試以及壓力測試三個方面的内容。它們并不是必須獨立進行測試的。其實真正到了測試操作環節，性能測試、負載測試、壓力測試都是基本一緻的，隻是各自所關注的東西不一樣罷了。

　　吾輩愚見，實屬班門弄斧。望各位達人體諒伏案打字之苦，不吝賜教一二，授業解惑，不勝感激。此緻。

http://www.51testing.com/html/96/n-106496.html