1．負載測試
在這裡，負載測試指的是最常見的驗證一般效能需求而進行的效能測試，在上面我們提到了使用者最常見的效能需求就是「既要馬兒跑，又要馬兒少吃草」。因此負載測試主要是考察軟體系統在既定負載下的效能表現。我們對負載測試可以有如下理解：
（1）負載測試是站在使用者的角度去觀察在一定條件下軟體系統的效能表現。
（2）負載測試的預期結果是使用者的效能需求得到滿足。此指標一般體現為響應時間、交易容量、併發容量、資源使用率等。
2．壓力測試
壓力測試是為了考察系統在極端條件下的表現，極端條件可以是超負荷的交易量和併發使用者數。注意，這個極端條件並不一定是使用者的效能需求，可能要遠遠高於使用者的效能需求。可以這樣理解，壓力測試和負載測試不同的是，壓力測試的預期結果就是系統出現問題，而我們要考察的是系統處理問題的方式。比如說，我們期待乙個系統在面臨壓力的情況下能夠保持穩定，處理速度可以變慢，但不能系統崩潰。因此，壓力測試是能讓我們識別系統的弱點和在極限負載下程式將如何執行。
例子：負載測試關心的是使用者規則和需求，壓力測試關心的是軟體系統本身。對於它們的區別，我們可以用華山論劍的例子來更加形象地描述一下。如果把郭靖看做被測試物件，那麼壓力測試就像是郭靖和已經走火入魔的歐陽峰過招，歐陽鋒蠻打亂來，毫無套路，盡可能地去打倒對方。郭靖要能應對住，並且不能丟進小命。而常規效能測試就好比郭靖和黃藥師、洪七公三人約定，只要郭靖能分別接兩位高手一百招，郭靖就算勝。至於三百招後哪怕郭靖會輸掉那也不用管了。他只要能做到接下一百招，就算通過。
思考我們在做軟體壓力測試時，往往要增加比負載測試更多的併發使用者和交易，這是為什麼？
3．併發測試
驗證系統的併發處理能力。一般是和伺服器端建立大量的併發連線，通過客戶端的響應時間和伺服器端的效能監測情況來判斷系統是否達到了既定的併發能力指標。負載測試往往就會使用併發來創造負載，之所以把併發測試單獨提出來，是因為併發測試往往涉及伺服器的併發容量，以及多程序/多執行緒協調同步可能帶來的問題。這是要特別注意，必須測試的。
4．基準測試
當軟體系統中增加乙個新的模組的時候，需要做基準測試，以判斷新模組對整個軟體系統的效能影響。按照基準測試的方法，需要開啟/關閉新模組至少各做一次測試。關閉模組之前的系統各個效能指標記下來作為基準（benchmark），然後與開啟模組狀態下的系統效能指標作比較，以判斷模組對系統效能的影響。
5．穩定性測試
「路遙知馬力」，在這裡我們要說的是和效能測試有關的穩定性測試，即測試系統在一定負載下首席執行官時間後是否會發生問題。軟體系統的有些問題是不能一下子就暴露出來的，或者說是需要時間積累才能達到能夠度量的程度。為什麼會需要這樣的測試呢？因為有些軟體的問題只有在執行一天或乙個星期甚至更長的時間才會暴露。這種問題一般是程式占用資源卻不能及時釋放而引起的。比如，記憶體洩漏問題就是經過一段時間積累才會慢慢變得顯著，在執行初期卻很難檢測出來；還有客戶端和伺服器在負載執行一段時間後，建立了大量的連線通路，卻不能有效地復用或及時釋放。
6．可恢復測試
常見的效能測試方法
負載 壓力 併發 基準 穩定性 可恢復性 負壓並基穩可 1 負載測試 考察軟體系統在既定負載下的效能表現指標。此指標一般體現為響應時間 交易容量 併發容量 資源使用率等。2 壓力測試 壓力測試是為了考察系統在極端條件下的表現，極端條件可以是超負荷的交易量和併發使用者數。注意，這個極端條件並不一定是使...
常見的效能測試方法
負載 壓力 併發 基準 穩定性 可恢復性 負壓並基穩可 1 負載測試 考察軟體系統在既定負載下的效能表現指標。此指標一般體現為響應時間 交易容量 併發容量 資源使用率等。2 壓力測試 壓力測試是為了考察系統在極端條件下的表現，極端條件可以是超負荷的交易量和併發使用者數。注意，這個極端條件並不一定是使...
常見的軟體測試方法
1.發煙測試 速度很快，通常用在解決方案很清晰的時候 2.構建測試 介面，針對資料庫操作的測試，例如 構建資料 3.回歸測試 迭代時，每發布乙個功能，有修改 這些 可能影響某乙個模組，針對模組，執行一段完整的測試 4.效能測試 併發性的測試 針對有限的網路 有限的記憶體的運 況，某乙個前提下的 5....