ApiTestEngine 集成 Locust 實現更好的性能測試體驗

最新 08-28

不是介面測試框架么，也能實現性能測試？

是的，你沒有看錯，集成了性能測試框架，只需一份測試用例，就能同時實現介面自動化測試和介面性能測試，在不改變任何特性的情況下，甚至比本身更易用。

如果你還沒有接觸過這款性能測試工具，那麼這篇文章可能不適合你。但我還是強烈推薦你了解一下這款工具。簡單地說，是一款採用語言編寫實現的開源性能測試工具，簡潔、輕量、高效，並發機制基於協程，可以實現單機模擬生成較高的並發壓力。關於的特性介紹和使用教程，我之前已經寫過不少，你們可以在我的博客中找到對應文章。

如果你對實現的過程沒有興趣，可以直接跳轉到文章底部，看章節。

靈感來源

在當前市面上的測試工具中，介面測試和性能測試基本上是兩個涇渭分明的領域。這也意味著，針對同一個系統的服務端介面，我們要對其實現介面自動化測試和介面性能測試時，通常都是採用不同的工具，分別維護兩份測試腳本或用例。

之前我也是這麼做的。但是在做了一段時間後我就在想，不管是介面功能測試，還是介面性能測試，核心都是要模擬對介面發起請求，然後對介面響應內容進行解析和校驗；唯一的差異在於，介面性能測試存在並發的概念，相當於模擬了大量用戶同時在做介面測試。

既然如此，那介面自動化測試用例和介面性能測試腳本理應可以合併為一套，這樣就可以避免重複的腳本開發工作了。

在開發的過程中，之前的文章也說過，完全基於庫實現HTTP的請求處理，可以在編寫介面測試用例時復用到的所有功能特性。而之前在學習的源碼時，發現在實現HTTP請求的時候，也完全是基於庫。

在這一層關係的基礎上，我提出一個大膽的設想，能否通過一些方式或手段，可以使中編寫的格式的介面測試用例，也能直接讓直接調用呢？

靈感初探

想法有了以後，就開始探索實現的方法了。

首先，我們可以看下的腳本形式。如下例子是一個比較簡單的場景（截取自官網首頁）。

在的腳本中，我們會在子類中描述單個用戶的行為，每一個帶有裝飾器的方法都對應著一個HTTP請求場景。而的一個很大特點就是，所有的測試用例腳本都是文件，因此我們可以採用Python實現各種複雜的場景。

等等！模擬單個用戶請求，而且還是純粹的Python語言，我們不是在介面測試中已經實現的功能么？

例如，下面的代碼就是從單元測試中截取的測試用例。

是已經在中實現的方法，作用是傳入測試用例（）的路徑，然後就可以載入測試用例，運行整個測試場景。並且，由於我們在測試用例中已經描述了，即介面的校驗部分，因此我們也無需再對介面響應結果進行校驗描述了。

接下來，實現方式就非常簡單了。

我們只需要製作一個的模板文件，內容如下。

可以看出，整個文件中，只有測試用例文件的路徑是與具體測試場景相關的，其它內容全都可以不變。

於是，針對不同的測試場景，我們只需要將替換為介面測試用例文件的路徑，即可實現對應場景的介面性能測試。

後面的操作就完全是的內容了，使用方式完全一樣。

優化1：自動生成locustfile

通過前面的探索實踐，我們基本上就實現了一份測試用例同時兼具介面自動化測試和介面性能測試的功能。

然而，在使用上還不夠便捷，主要有兩點：

需要手工修改模板文件中的路徑；

模板文件的路徑必須放在的項目根目錄下。

於是，我產生了讓框架本身自動生成文件的想法。

在實現這個想法的過程中，我想過兩種方式。

第一種，通過分析的源碼，可以看到在中具有一個方法，可以載入Python格式的文件，並提取出其中的（也就是的子類）；後續，就是將作為參數傳給的了。

若採用這種思路，我們就可以實現一個類似的方法，將文件中的內容動態生成，然後再傳給的。這裡面會涉及到動態地創建類和添加方法，好處是不需要生成中間文件，並且可以實現最大的靈活性，但缺點在於需要改變的源碼，即重新實現的中的多個函數。雖然難度不會太大，但考慮到後續需要與的更新保持一致，具有一定的維護工作量，便放棄了該種方案。

第二種，就是生成這樣一個中間文件，然後將文件路徑傳給。這樣的好處在於我們可以不改變的任何地方，直接對其進行使用。與的傳統使用方式差異在於，之前我們是在中通過參數啟動，而現在我們是在框架中通過Python代碼啟動。

具體地，我在的中新增了一個命令，並綁定了對應的程序入口。

在中新增了函數，作為命令的入口。

若你執行或，會發現效果與的特性完全一致。

事實上，通過上面的代碼（）也可以看出，命令只是對進行了一層封裝，用法基本等價。唯一的差異在於，當參數指定的是格式的用例文件時，會先轉換為Python格式的，然後再傳給。

至於解析函數，實現起來也很簡單。我們只需要在框架中保存一份的模板文件（），並將採用佔位符代替。然後，在解析函數中，就可以讀取整個模板文件，將其中的佔位符替換為用例文件的實際路徑，然後再保存為，並返回其路徑即可。

具體的代碼就不貼了，有興趣的話可自行查看。

通過這一輪優化，就繼承了的全部功能，並且可以直接指定格式的文件啟動執行性能測試。

優化2：一鍵啟動多個locust實例

經過第一輪優化後，本來應該是告一段落了，因為此時已經可以非常便捷地實現介面自動化測試和介面性能測試的切換了。

直到有一天，在論壇討論的一個回復中，@keithmork 說了這麼一句話。

期待有一天的熱度超過本身

看到這句話時我真的不禁淚流滿面。雖然我也是一直在用心維護，卻從未有過這樣的奢望。

但反過來細想，為啥不能有這樣的想法呢？當前已經繼承了的所有功能，在不影響已有特性的同時，還可以採用格式來編寫維護測試用例，並實現了一份測試用例可同時用於介面自動化和介面性能測試的目的。

這些特性都是所不曾擁有的，而對於使用者來說的確也都是比較實用的功能。

於是，新的目標在內心深處萌芽了，那就是在中通過對更好的封裝，讓的使用者體驗更爽。

然後，我又想到了自己之前做的一個開源項目，。當時做這個項目的初衷在於，當我們使用進行壓測時，要想使用壓測機所有CPU的性能，就需要採用模式。因為默認是單進程運行的，只能運行在壓測機的一個CPU核上；而通過採用模式，啟動多個，就可以讓不同的運行在不同的CPU核上，從而充分發揮壓測機多核處理器的性能。

而在實際使用的時候，每次只能手動啟動，並依次手動啟動多個。若遇到測試腳本調整的情況，就需要逐一結束的所有進程，然後再重複之前的啟動步驟。如果有使用過的同學，應該對此痛苦的經歷都有比較深的體會。當時也是基於這一痛點，我開發了，目的就是可以一次性啟動或銷毀多個實例。這個腳本做出來後，自己用得甚爽，也得到了上一些朋友的青睞。

既然現在要提升針對的使用便捷性，那麼這個特性毫無疑問也應該加進去。就此，項目便被廢棄，正式合併到。

想法明確後，實現起來也挺簡單的。

原則還是保持不變，那就是不改變本身的特性，只在傳參的時候在中間層進行操作。

具體地，我們可以新增一個參數。當不指定該參數時，使用方式跟之前完全相同；而指定參數後，就可以採用多進程的方式啟動多個實例（實例個數等於壓測機的處理器核數）。

具體實現邏輯在中：

由此可見，關鍵點也就是使用了，在不同的進程中分別調用的函數，實現邏輯十分簡單。

最終實現效果

經過前面的優化，採用執行性能測試時，使用就十分便捷了。

安裝後，系統中就具有了命令，使用方式跟框架的幾乎完全相同，我們完全可以使用命令代替原生的命令。

例如，下面的命令執行效果與完全一致。

差異在於，具有更加豐富的功能。

在中編寫的格式的介面測試用例文件，直接運行就可以啟動運行性能測試。