效能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以後的回歸測試建立乙個基準。而效能測試的操作，實際上就是乙個非常小心受控的測量分析過程。在理想的情況下，被測軟體在這個時候已經是足夠穩定了，所以這個過程得以順利的進行。
一組清晰已定義好的預期值是讓一次有意義的效能測試的基本要素。如果連你自己都不知道系統效能有些什麼是要測的，那麼它對於你要測試的方法手段是沒有指導意義的*。例如，給乙個web應用做效能測試，你要知道至少兩樣東西：
在不同併發使用者數或者http連線數情況下的負載預期值*
可接受的響應時間
當你知道你的目標後，你就可以開始使用對系統持續增加負載的方法來觀察系統的瓶頸所在。重新拿web應用系統來做例子，這些瓶頸可存在於多個層次，你可以使用多種工具來查明它們的所在：
在應用層，開發人員可以通過profilers來發現低效率的**，比如說較差的查詢演算法
在資料庫
層，開發人員和資料庫管理員（dba）可以通過特定的資料庫profilers及事件探查器*（query optimizers）
在作業系統層，系統工程師可以使用一些工具如在unix類的作業系統中的top,vmstat,iostat,在windows系統中的perfmon來監控cpu，內在，swap,磁碟i/o等硬體資源；專門的核心監控軟體也可以在這一層面上被使用。
在網路層上，網路工程師可以使用報文探測器（如tcpdump）,網路協議分析器（如ethereal）,還有其它的工具（如netstat,mrtg,ntop,mii-tool）
從測試的觀點來看，上面所有描述的活動都是一種白盒的方法，它對系統從內到外及多角度進行審查及監控。測度資料*被取得及分析後，對系統的調整則成為理所當然的下乙個步驟。
然而，（除了上面的方法外）測試人員在給被測系統執行負載試驗*（這裡為了不與我們所理解的負載測試-load testing的概念搞混，特譯做負載試驗）的時候，也採取了黑盒的方法。像對於web應用來講，測試人員可以使用工具來模擬併發使用者或者http連線及測量響應時間。在我以前使用過的輕量級的負載測試開源工具有ab,siege,httperf。乙個更重量級的工具是opensta，但我沒用過。我也還沒有用過the grinder這個工具，但它在我將要做的事情中排名靠前。
當負載試驗*的結果顯示出系統的效能來沒有達到它的預期目標時，這就是要對應用和資料庫的調整的時候了。同時你要確保讓你的**執行得盡可能高效，以及資料庫在給定的作業系統和硬體配置的情況下最優化。測試驅動開發（tdd）的實踐者會發現這種上下文結構框架是非常有用的*，如可以通過負載試驗*及時間試驗的函式性*來增強現存單元測試
**的mike clark的junitperf*。當乙個特定的函式或者方法被剖析過*和除錯過後，開發人員就可以在junitperf中，放入它的單元試驗*來確保它可以達到負載及時間上的效能需求。mike clark稱這為「持續效能測試」。我順便也提一下我已經做了乙個基於python的junitperf的初步研究，我稱之為pyunitperf.
假若在除錯過應用程式及資料庫後，系統還是沒有達到效能的預期目標，在這種情況下，還是有一些其它的除錯的流程*可以針對前面講過的那幾個層次來使用的。下面就是一些在應用程式***之外仍可以提高web應用系統效能的例子：
使用web快取裝制，如squid提供的裝置
將高訪問量的網頁靜態化，以避免這些高訪問量對資料庫進行大量的呼叫
通過負載平衡的方法來水平縮放web伺服器的結構*
在水平縮放資料庫群及將它們分為讀寫伺服器和唯讀伺服器後，還要對唯讀伺服器群負載平衡。*
通過增加更多的硬體資源（cpu，記憶體，磁碟等）縱向的縮放web及資料庫伺服器群
增加網路的頻寬
由於現在的web應用系統都是十分複雜的系統，效能除錯有時要具有一些藝術性才行。在每次修改乙個變數及重新測度的時候一定要非常小心，否則的話，在變化中將會有很多難於確定和重複的不確定因素*。
在乙個規範的測試環境比如說乙個測試實驗試，它是不會常常的重現實際應用時的伺服器配置環境。在這樣的情況下，分段測試環境，也就是生產實際環境的乙個子集就可以派上用場了。但同時系統的期望效能也需要相應的調低一點。
「執行負載試驗*->測度效能->除錯系統」這個迴圈一直要被重複執行到被測試系統達到了期望的效能標準了才可以停。在這個時候，測試人員就可以明了在正常條件下的系統運轉怎麼樣，同時這些就可以做為以後在回歸測試中，評價新版本的軟體效能的乙個標準了。
效能測試還有另乙個目標就是建立一組被測系統的基準資料。在很多行業中都會有這種行業標準的基準資料，比如說tpc公布的。還有很多軟硬體廠家都為了在tcp排名中靠前而對他們的機器進行精心除錯。所以說你應當非常謹慎的說明在你進行測試的時候，並沒有在種類繁多的軟硬體產品中進行全部測試*。
負載測試
我們都已經在效能測試除錯的過程中，見識過負載測試了。在那種環境中，它意味著通過自動化工具來持續對系統增加負載。但對於web應用來講，負載則是併發使用者或者http連線的數量。
術語「負載測試」在測試文獻資料中通常都被定義為給被測系統加上它所能操作的最大任務數的過程。負載測試有時也會被稱為「容量測試」，或者「耐久性測試/永續性測試」*
容量測試的例子：
通過編輯乙個巨大的檔案來測試文字處理軟體
通過傳送乙個巨大的作業來測試印表機
通過成千上萬的使用者郵箱來測試郵件伺服器
有一種比較特別的容量測試是叫作「零容量測試」，它是給系統加上空任務來測試的。
耐久性測試/永續性測試的的例子：
在乙個迴圈中不停的執行客戶端超過乙個擴充套件時間段*。
負載測試的目的：
找到一些在測試流程中前面的階段所進行的粗略測試中沒有被找出的bugs,例如，記憶體管理bugs,記憶體洩露，緩衝器溢位等等。
保證應用程式達到效能測試中確定的效能基線。這個可以在執行回歸試驗時，通重載入特定的最大限度的負載來實現。
儘管效能測試和負載測試似乎很像，但他們的目的還是有差異的。一方面，效能測試使用負載測試的技術，工具，以及用不同的負載程度來測度和基準化系統。在另一方面來講，負載測試是在一些已經定義好的負載程度上進行測試的，通常對系統加上最大負載之後，系統應該仍然可以提供全部功能。這裡需要明確一點，負載測試並不是要對系統載入上過度的負載而使系統不能工作
都可以勝任這些工作。
壓力測試
效能測試vs負載測試vs壓力測試 概念普及
下面我們主要介紹效能測試 負載測試和壓力測試。效率作為iso 9126內部和外部質量的重要質量屬性之一，其含義是在規定條件下，相對於所用的資源的數量，軟體產品可提供適當效能的能力。資源可能包括其他軟體產品或系統的軟體和硬體配置，以及其他相關的資源 例如 列印紙 磁碟等 效率測試主要關注產品的時間和資...
效能測試 壓力測試 負載測試
負載測試 load testing 壓力測試 stress test，應稱為強度測試 和效能測試，這三個概念常常引起混淆，難以區分，從而造成不正確的理解和錯誤的使用。負載測試 壓力測試和效能測試的測試目的不同，但其手段和方法在一定程度上比較相似，通常會使用相同的測試環境和測試工具，而且都會監控系統所...
（一）效能測試（壓力測試 負載測試）
一 專案經理經常安排測試工程師進行下面的工作 二 效能測試概念 三 負載測試 四 壓力測試 五 壓力測試與負載測試兩者區別 相同點 都是效能測試 負載測試強調系統正常工作情況下的效能指標 壓力測試的目的是發現在什麼條件下系統的效能變得不可接受，發現應用程式效能下降的拐點。舉例 工人建橋，橋身上表明，...