我爲何選擇Locust性能測試工具

         最近一直在GCP平臺上作一些性能測試任務。也一直在思考，到底應該使用什麼樣的壓測工具纔是適合的，畢竟「工欲善其事，必先利其器」。

        原本在性能測試中使用的工具是JMeter，JMeter是一款免費的利用pure Java編寫的壓測工具，它自己功能和周邊擴展仍是比較強大的。在免費軟件領域使用的範圍很廣，包括擴展插件等，整個生態仍是比較好的。可是仍是那句話，適合本身的纔是最好的。因爲是在GCP上測試，而測試環境（包括測試機器）也必須搭建在此雲平臺上，那麼有個問題是，穩定性和費用問題。至少對於我來講是這樣。好比我申請了一個16GB的VM，可是最終發現單臺JMeter slave 節點能模擬的用戶數仍是不能另人滿意。並且偶爾也有穩定性問題，如某個節點會有不規律的JMeter相關進程異常退出問題。還有一個問題，就是JMeter在真正進行高併發性能測試時，是很吃內存的。這就又涉及到了費用問題，不少時候這也是要考慮的因素之一。
    結合實際的須要，最後評估發現工具Locust更適合項目的性能測試須要。主要基於如下幾點：

• 資源（如內存）佔用少。這個是Locust比較顯著的優點。

• "Test as code", 針對這個特性，Locust是可使用Python進行場景模擬的，因此在腳本實現上比較靈活。可是反過來講，使用Locust要有必定的Python編程基礎。

• 雲平臺集成分佈式測試。若是後期須要把本地（或項目環境）的分佈式測試環境搭建在雲平臺的分佈式測試上，那麼就須要考慮一個通用性的問題了，以下圖，利用GCP平臺，結合K8S能夠像搭建一個產品框架同樣搭建一個性能測試平臺。GCP官方對此是支持的。

       後期也會分享在使用中遇到的問題和解決方式。

     註解：須要說明的幾點:

• 若是項目安排比較緊急，可能對新工具的引入不利。

• 若是不瞭解Python編程的基礎等，可能會有更多的學習成本，須要考量。

• 若是項目使用的協議非HTTP,那麼能夠暫時先不要考慮Locust的了。好比H5頁面（web socket)協議等。

 你們也能夠掃描並關注以下公衆號「TimTest」，會有更多性能測試相關內容分享。