用平均值來衡量響應時間是性能測試中較常見的誤區。隨著吞吐量的增大，響應時間會逐漸變長，當達到較大吞吐量之后，響應時間會開始加速上升，尤其是排在后面的請求。在這個時刻，如果只看平均值，你往往察覺不到問題，因為大部分請求的響應時間還是很短的，慢請求只占一個很小的比例，所以平均值變化不大。但實際上，可能已經有超過1%，甚至5%的請求的響應時間已經超出設計的范圍了。

更科學、更合理的指標是看TP95或者TP99響應時間。TP是Top Percentile的縮寫，是一個統計學術語，用來描述一組數值的分布特征。以TP95為例，假設有100個數字，從小到大排序之后，第95個數字的值就是這組數字的TP95值，表示至少有95%的數字是小于或者等于這個值。

總共有1000次請求，平均響應時間是58.9ms，TP95是123.85ms(平均響應時間的2.1倍)，TP99是997.99ms(平均響應時間的16.9倍)。假設應用設計的較大響應時間是100ms，單看平均時間是完全符合要求的，但實際上已經有超過50個請求失敗了。如果看TP95或者TP99，問題就很清楚了。

只關注響應時間和吞吐量，忽視請求成功率

雖說衡量應用性能好壞較主要是看響應時間和吞吐量，但這里有個大前提，所有請求(如果做不到所有，至少也要絕大多數請求，比如99.9%)都被成功處理了，而不是返回一堆錯誤碼。如果不能增加這一點，那么再低的響應時間，再高的吞吐量都是沒有意義的。

忘了測試端也存在性能瓶頸

性能測試的第三個誤區是只關注服務端，而忽略了測試端本身可能也存在限制。比如測試用例設置了10000并發數，但實際運行用例的機器較大只支持5000并發數，如果只看服務端的數據，你可能會誤以為服務端較大就只支持5000并發數。如果遇到這種情況，或者換用更高性能的測試機器，或者增加測試機器的數量。

如何進行性能測試?

介紹完性能測試相關的一些概念之后，再來看一下有哪些工具可以進行性能測試。

JMeter可能是較常用的性能測試工具。它既支持圖形界面，也支持命令行，屬于黑盒測試的范疇，對非開發人員比較友好，上手也非常容易。圖形界面一般用于編寫、調試測試用例，而實際的性能測試建議還是在命令行下運行。

更多培訓課程： 江北區軟件測試 更多學校信息： 重慶江北達內IT教育培訓 咨詢電話：