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。
PV（page view）即頁面瀏覽量。一個用戶有可能創造十幾個甚至更多的 PV。它是目前判斷網站訪問流量最經常使用的計算方式，也是反映一個網站受歡迎程度的重要指標之一。
2）著名的經典理論80-20原則。
3）參考段念老師在《軟件性能測試過程詳解與案例剖析》一書中提到的估算方法。
固然，上面的方法僅供參考，須要根據實際的系統特色、業務特色來衡量。
3.負載測試
負載測試能夠理解爲肯定所要測試的業務或系統的負載範圍，而後對其進行測試。它的主要目的是驗證業務或系統在給定的負載條件下的處理性能。此外，還要關注響應時間、每秒經過事務數和其餘相關指標。
從另外一個角度理解，負載測試能夠看做是性能測試的一部分，但它們二者的目的是不一樣的，負載測試是爲了發現性能問題，而性能測試是爲了獲取性能指標。由於在性能測試過程當中，也能夠不調整負載，而是在一樣負載狀況下經過改變系統的結構、算法、硬件配置等來獲得性能指標。
4.壓力測試
壓力測試能夠理解爲沒有預期的性能指標，不斷地加壓，看系統何時崩潰，以此來肯定系統的瓶頸或者不能接受的性能拐點，以得到系統的最佳併發數、最大併發數。仍然以生活中的例子來講明，壓力測試就比如跑馬拉松，看你到底能跑多久，何時就堅持不住了。
壓力測試也能夠看做是負載測試的一種，即高負載下的負載測試。經過壓力測試，能夠更快地發現內存泄漏問題，還能夠更快地發現影響系統穩定性的問題。例如，在正常負載狀況下，某些功能能夠正常使用或者出錯的機率比較低，但在壓力測試下可能很快就會出現，幫助咱們提前發現性能問題。
小白想起，公司以前有個網站，在用戶少的時候沒有什麼問題，但在用戶多時就暴露出了一些問題，常常會有異常報錯產生。看來公司的網站真的須要進行性能測試來評估了，小白內心暗想。
負載測試與壓力測試的概念並不是徹底獨立，讀者大可沒必要糾結於文字概念。在實際應用中通常兩者都是相互結合、相互補充的。
5.穩定性測試
穩定性測試顧名思義重點在於「穩定」二字，要想知道系統穩定的狀況，就須要長時間運行，在這段時間內觀察系統的出錯概率、性能變化趨勢等。進而大大減小系統上線後的崩潰等現象。通常都會進行所謂的7×24小時的穩定性測試。
但穩定性測試也有和其餘分類不同的地方，這裏須要強調如下兩點。
1）通常穩定性測試須要在系統成型後進行，而且沒有嚴重的Bug存在。
2）場景的設計以模擬真實用戶的實際操做爲佳。
6.失效恢復測試
失效恢復測試重在關注系統出現問題後可否根據預先制定的策略恢復，且恢復後可否正常運行。怎麼理解呢？很簡單，以跑馬拉松爲例，爲了預防出現跑不動的狀況，預先準備了一瓶紅牛（應該給我廣告費），當選手累得躺下後，拿出這瓶紅牛一口氣喝了，而後你有力量了，恢復了原來的狀態，站起來繼續跑。這下理解了吧。
不過失效恢復測試通常是對具備負載均衡的系統進行的，主要是爲了測試當系統局部發生故障時，是否會對全局產生大的影響，產生的影響是否在能夠接受的範圍內，以及用戶可否繼續使用系統。
在實際應用過程當中，能夠模擬一臺或幾臺負載均衡機器出現故障來進行失效恢復測試，但須要注意的是，不只要關心失效後，用戶是否能夠正常訪問或者恢復後系統是否能夠正常工做，也要關注失效後，系統還能支持多少併發用戶，以及採用哪些備選方案來快速響應。
小白學到這裏也明白了原來性能測試中須要關注許多點，既要有對某個點的思考，也要有擴展點的思考，不然容易遺漏或得出片面的結論，而不能從根本上來預防解決問題。
7.現網性能測試
所謂現網性能測試，就是在實際網絡、實際環境中進行測試，徹底和真實用戶同樣。固然這樣的測試有必定的風險，須要注意如下幾點。
1）時間段的選擇。現網性能測試可能會影響正經常使用戶，因此這樣的時間段要儘可能避開高峯期，選擇半夜或者凌晨來進行。
2）垃圾數據處理。若是現網性能測試涉及了寫數據的操做，那麼確定會帶來很多的垃圾數據，這些數據後期必定要清理，爲了清理方便，前期數據的設計要有規律可循。
3）網絡限制。和在內網測試不一樣，現網的測試若是忽然間產生大的數據量，可能會被網絡帶寬限制，甚至路由會認爲是非法數據請求而產生攔截等。因此若是在現網進行性能測試，那麼壓力機須要和被測服務器部署在同一個網段機房內，這樣能夠避免網絡限制，最後遠程收集數據便可。
若是沒有特殊狀況，儘可能不要進行現網的性能測試，風險比較大，若是非要進行，必定要事先充分評估風險以及應對的解決方案，這樣出了問題能夠快速響應，把影響控制到最小。
轉至：http://book.51cto.com/art/201502/465236.htm