1.基準測試
基準最簡單的理解就是有基礎的標準，這樣能通過對比發現系統的不同點與變化。一般情況下，基準測試有以下幾種應用場景。
1）可以在制定的標準下通過基準測試建立乙個效能基準，這樣以後當系統的環境、引數發生變化之後，再進行一次相同標準下的測試，即可看出變化對效能的影響。例如，資料庫的基準效能測試。
2）系統進行基準測試可以在較早的階段發現效能問題。例如，如果對besttest**進行10個使用者併發測試時，系統出現了宕機的現象，那麼就沒有必要進行後續的測試了。
3）某系統從來沒有進行過任何效能測試，需要對該系統做一次效能評估作為後續開發調優的參考。這是基準測試常見的一種場景，也是大部分沒有做過效能測試的公司最需要的。
雖然基準測試不難理解，但實踐起來常常被誤解。以對某個系統的資料搜尋進行效能基準測試為例，這個系統的資料量會隨著時間的增長而增長，所以必須頻繁地進行基準測試，這樣才能準確地把握資料量的增長對系統效能的影響。但因為進行的基準測試又恰恰是在應用程式級別的，並不能客觀地反映全域性性的效能。所以，比較好的做法是每次只修改乙個地方，這樣就能準確地判斷出哪個地方會對效能產生影響。
2.併發測試
併發測試可以理解為很多的使用者按照預定的場景併發請求某個業務或功能時是否出現併發問題。例如，記憶體洩露、執行緒鎖、資源爭用等，幾乎所有的效能測試都會涉及併發測試。併發測試的主要目的是找出併發引起的問題。
那併發數又如何確定呢？小白通過查詢資料得知，一般可以通過以下幾種方法推算需要的併發數。
1）併發數=pv / pv time×頁面連線次數×http響應時間×因數/ web伺服器數量。
其中，pv time是pv的統計時間，換算成秒，一天是86 400s。頁面連線次數包括外部的js、css、等，一般為10。http響應時間一般可為1s或更少。因數一般為5。
假設，besttest官網每天有6萬pv，其餘引數保持預設，那麼推算出來的併發數大致為35。
2）著名的經典理論80-20原則。
3）參考段念老師在《軟體效能測試過程詳解與案例剖析》一書中提到的估算方法。
當然，上面的方法僅供參考，需要根據實際的系統特點、業務特點來衡量。
3.負載測試
負載測試可以理解為確定所要測試的業務或系統的負載範圍，然後對其進行測試。它的主要目的是驗證業務或系統在給定的負載條件下的處理效能。此外，還要關注響應時間、每秒通過事務數和其他相關指標。
從另乙個角度理解，負載測試可以看作是效能測試的一部分，但它們兩者的目的是不同的，負載測試是為了發現效能問題，而效能測試是為了獲取效能指標。因為在效能測試過程中，也可以不調整負載，而是在同樣負載情況下通過改變系統的結構、演算法、硬體配置等來得到效能指標。
4.壓力測試
壓力測試可以理解為沒有預期的效能指標，不斷地加壓，看系統什麼時候崩潰，以此來確定系統的瓶頸或者不能接受的效能拐點，以獲得系統的最佳併發數、最大併發數。仍然以生活中的例子來說明，壓力測試就好比跑馬拉松，看你到底能跑多久，什麼時候就堅持不住了。
壓力測試也可以看作是負載測試的一種，即高負載下的負載測試。通過壓力測試，可以更快地發現記憶體洩漏問題，還可以更快地發現影響系統穩定性的問題。例如，在正常負載情況下，某些功能可以正常使用或者出錯的概率比較低，但在壓力測試下可能很快就會出現，幫助我們提早發現效能問題。
小白想起，公司之前有個**，在使用者少的時候沒有什麼問題，但在使用者多時就暴露出了一些問題，經常會有異常報錯產生。看來公司的**真的需要進行效能測試來評估了，小白心裡暗想。
負載測試與壓力測試的概念並非完全獨立，讀者大可不必糾結於文字概念。在實際應用中一般二者都是相互結合、相互補充的。
5.穩定性測試
穩定性測試顧名思義重點在於「穩定」二字，要想知道系統穩定的情況，就需要長時間執行，在這段時間內觀察系統的出錯機率、效能變化趨勢等。進而大大減少系統上線後的崩潰等現象。一般都會進行所謂的7×24小時的穩定性測試。
但穩定性測試也有和其他分類不一樣的地方，這裡需要強調以下兩點。
1）一般穩定性測試需要在系統成型後進行，並且沒有嚴重的bug存在。
2）場景的設計以模擬真實使用者的實際操作為佳。
6.失效恢復測試
失效恢復測試重在關注系統出現問題後能否根據預先制定的策略恢復，且恢復後能否正常執行。怎麼理解呢？很簡單，以跑馬拉松為例，為了預防出現跑不動的情況，預先準備了一瓶紅牛（應該給我廣告費），當選手累得躺下後，拿出這瓶紅牛一口氣喝了，然後你有力量了，恢復了原來的狀態，站起來繼續跑。這下理解了吧。
不過失效恢復測試一般是對具有負載均衡的系統進行的，主要是為了測試當系統區域性發生故障時，是否會對全域性產生大的影響，產生的影響是否在可以接受的範圍內，以及使用者能否繼續使用系統。
在實際應用過程中，可以模擬一台或幾台負載均衡機器出現故障來進行失效恢復測試，但需要注意的是，不僅要關心失效後，使用者是否可以正常訪問或者恢復後系統是否可以正常工作，也要關注失效後，系統還能支援多少併發使用者，以及採用哪些備選方案來快速響應。
小白學到這裡也明白了原來效能測試中需要關注許多點，既要有對某個點的思考，也要有擴充套件點的思考，否則容易遺漏或得出片面的結論，而不能從根本上來預防解決問題。
7.現網效能測試
所謂現網效能測試，就是在實際網路、實際環境中進行測試，完全和真實使用者一樣。當然這樣的測試有一定的風險，需要注意以下幾點。
1）時間段的選擇。現網效能測試可能會影響正常使用者，所以這樣的時間段要盡量避開高峰期，選擇半夜或者凌晨來進行。
2）垃圾資料處理。如果現網效能測試涉及了寫資料的操作，那麼肯定會帶來不少的垃圾資料，這些資料後期一定要清理，為了清理方便，前期資料的設計要有規律可循。
3）網路限制。和在內網測試不同，現網的測試如果突然間產生大的資料量，可能會被網路頻寬限制，甚至路由會認為是非法資料請求而產生攔截等。所以如果在現網進行效能測試，那麼壓力機需要和被測伺服器部署在同乙個網段機房內，這樣可以避免網路限制，最後遠端收集資料即可。
如果沒有特殊情況，盡量不要進行現網的效能測試，風險比較大，如果非要進行，一定要事先充分評估風險以及應對的解決方案，這樣出了問題可以快速響應，把影響控制到最小。
轉至：
效能測試 測試分類
效能測試 通過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能能否滿足生產效能要求。特點 1，目的是驗證系統是否有系統宣稱的能力。2，需要事先了解被測試系統經典場景，並具有確定的效能目標 3，要求在已確定的環境下執行 負載測試 通過被測系統上不斷加壓，直到效能指標達到極限，例如 響應時間 超過...
效能測試分類
常會別人說到效能測試 負載測試 壓力測試 併發測試，很多人都是混合使用，或者一會叫壓力測試，一會叫併發測試。這些概念除了非測試人員分不清楚，甚至許多專業測試人員也對這些名詞也很模糊。關於這個分類我翻閱了幾個本比較好的書籍，他們講的也比較模糊，沒有給出本質上的區別。只是從不同角度和關 注點來解釋。好吧...
效能測試分類
效能測試 狹義 效能測試方法是通過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能是否滿足生產效能要求。通俗地說，這種方法就是要在特定的執行條件下驗證系統的能力狀態。特點 1 這種方法的主要目的是驗證系統是否有系統宣稱具有的能力。2 這種方法要事先了解被測試系統經典場景，並具有確定的效能目標。...