性能測試顧名思義，測試服務（
web服務，
數據庫服務，其他網絡應用服務，本地服務）的性能如何？如何衡量性能？最表面的無非就是看能支撐多少個用戶同時使用該服務。且關注用戶使用過程中的用戶體驗。
Transactions per Second（每秒通過事務數）
“每秒通過事務數/TPS”顯示在場景運行的每一秒鐘，每個事務通過、失敗以及停止的數量，使考查系統性能的一個重要參數。通過它可以確定系統在任何給定時刻的時間事務負載。分析TPS主要是看曲線的性能走向。
將它與平均事務響應時間進行對比，可以分析事務數目對執行時間的影響。
例：當壓力加大時，點擊率/TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸。
Average Transaciton Response Time（事務平均響應時間）
“事務平均響應時間”顯示的是測試場景運行期間的每一秒內事務執行所用的平均時間，通過它可以分析測試場景運行期間應用系統的性能走向。
例：隨著測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨著投產時間的變化，整體性能將會有下降的趨勢。
通常web服務還需要關心如下點：
Hits per Second（每秒點擊次數）
“每秒點擊次數”，即使運行場景過程中虛擬用戶每秒向Web服務器提交的HTTP請求數。
通過它可以評估虛擬用戶產生的負載量，如將其和“平均事務響應時間”圖比較，可以查看點擊次數對事務性能產生的影響。通過對查看“每秒點擊次數”，可以判斷系統是否穩定。系統點擊率下降通常表明服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。
性能測試工具一般都會根據實際測試的場景和結果，畫出tps，average response time，點擊率等曲線圖表。 同時還會算出其他一些非常參考意義的數值和圖表。
1、當壓力加大時，TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸。
解析：tps 曲線為什么會變平坦？因為系統處理事務的線程數往往是固定的一個數值。（一般是由程序設定或者服務器配置決定），假設響應時間是固定的一個值時，那么每秒 中系統能夠處理的事務數是固定的數值。不會因為壓力的增大，TPS也會一直增大。實際上，響應時間并不是一個固定的值，而是隨著壓力變大，響應時間往往會 增加。那么，實際上，系統最大的TPS值，往往會比根據基準值估算出來的TPS要小。
2、當壓力加大時，點擊率曲線變化緩慢或者平坦，很有可能是服務器開始出現瓶頸。
解析：在web服務測試當中，點擊率和模擬的用戶數是能夠反映出服務壓力的大小。當壓力變大時，事務的響應時間變長，則導致點擊率會受到響應時間的影響，不會因為用戶增多，而增加。點擊率在服務器出現瓶頸時，壓力的增加不會增加點擊率。
3、事務平均響應時間增長
解析：事務平均響應時間增加，必然是指服務器性能有所下降。服務器壓力的加大，是主要原因。
a）壓力增大到每秒鐘事務的請求數，超過了系統每秒處理事務占用的線程數。這時，一些事務開始排隊。排隊的事務請求的響應時間必然大于之前的平均響應時間。