JMeter在整個負載測試的優越性是毋庸置疑的，它覆蓋了常見的各種測試類型，如HTTP, JDBC, JMS 和SOAP。單就Web Service測試，作者做了一個簡單的實驗，但并沒有涉及太多的細節。
試驗準備：本地Web Service，運行于JBoss 4.0.3SP1，每個簡單請求在4種不同負載下執行5000次，分別是1線程，5線程，10線程和25線程。在SoapUI中為簡單起見均使用簡單負載策略，并且五執行延時。要分別記錄關閉連接和非關閉連接方式的數據。關閉連接方式是指每次請求完畢后關閉連接。反之則是讓連接仍然保持打開以等待下個請求，顯然會省去很多額外開銷。在JMeter中也可以做類似配置，如線程數為1，循環次數5000或線程數25，循環200次。
環境：WinXP SP2, Pentium M 1.8 1 G RAM, JRE 1.5.0_06.
結果：
Threads jmeter soapUI soapUI (*) soapUI cmdline soapUI cmdline (*) 1 8 ms, 105 TPS 6.78 ms, 147 TPS 10.7 ms, 94 TPS 5.75 ms, 174 TPS 10 ms, 99 TPS 5 43 ms, 110 TPS 38.7 ms, 128 TPS 23.7 ms, 211 TPS 30.4 ms, 164 TPS 24 ms, 210 TPS 10 86 ms, 112 TPS 82 ms, 122 TPS 46.5 ms, 215 TPS 61 ms, 164 TPS 38 ms, 262 TPS 25 214 ms, 114 TPS 204 ms, 123 TPS 124 ms, 202 TPS 159 ms, 157 TPS 95 ms, 263 TPS其中帶*的是非關閉連接模式下測試的結果。從結果中看出Jmeter的測試值均較SoapUI偏大，但與UI連接關閉模式下執行結果相差無幾。實驗未給出JMeter命令行下的測試結果。但從經驗來講，命令行執行方式避免了測試工具本身帶來的巨大資源消耗，更接近真實值。soapUI在命令行連接不關閉模式下TPS隨線程的增加在初期有明顯上升的。
從計時機制來看，JMeter 用的是System.currentTimeMillis(),而soapUI用的是更為精確的System.nanoTime().
綜上所述（文中沒有點明，但這是顯而易見的），soapUI在單純的Web Service 測試時有明顯的優勢，當要綜合其他測試時可以組合使用多種工具。
當然這是soapUI自己做的實驗，難免有王婆賣瓜之嫌，有興趣的朋友可以自己設計實驗來測試一下。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
