目前在性能測試領域市場jmeter占有率是非常高的，主要原因是相對比其他性能測試工具使用更簡單（開源、易擴展），功能更強大（滿足多種協議的接口），但是隨著研發協同的升級，平臺化的性能測試工具更能高效的基于團隊開展協作，比如我們今天要說的開源測試平臺RunnerGo。

性能測試工具平臺化優勢

RunnerGo作為web平臺能在線做到接口管理，腳本編輯，場景編輯，報告管理這是jmeter這種工具不具備的。

RunnerGo支持實時查看服務器狀態、測試報告、debug日志并且支持發送測試報告到指定郵箱，而jmeter默認不支持性能監控，只能是在GUI模式下，通過擴展監聽器插件來實現，并且No-GUI模式下只能生成結果報告。

在使用jmeter時接口管理和性能測試一般是分開去做的，或者用其他Api調試工具去做接口管理（比如Apipost）然后再去jmeter中配置腳本，但其實性能測試應該是基于接口管理的基礎上做的，RunnerGo可以直接從接口管理中引用調試好的接口，配置好一條場景，然后在此基礎上進行持續性測試，自動化測試，這樣在接口測試階段就可以直接執行性能測試。

RunnerGo與jmeter結構分析

jmeter的單機模式在一般的壓力機配置下，會受限于jmeter自身的機制和硬件配置，最多可以支持幾百至一千左右的模擬請求線程。想部署分布式集群測試會帶來非常多的運維管理問題。同時，Master-Slave模式，還會給主節點帶來很大的交互壓力，部署大規模的分布式集群壓測非常難做到。

RunnerGo自帶分布式結構輕松支持大規模并發。

?

對于RunnerGo的真實性能我做了一個小的實驗進行對比，結果如下：

一條使用查看新聞的場景：六個接口，使用并發模式，20的并發，執行10分鐘。

相同的配置下進行壓測

jmeter聚合報告：

RunnerGo直接發送到郵箱的測試報告

?

由于計算方式不同這里只對比總請求數，匯總下來：

RunnerGo總請求數：98640個，錯誤率：0

jmeter總請求數：91219個，錯誤率：0

?

?

?