在《【LocustPlus序】漫談服務端效能測試》中,我對服務端效能測試的基礎概念和效能測試工具的基本原理進行了介紹,並且重點推薦了Locust
這一款開源效能測試工具。然而,當前在網路上針對Locust
的教程極少,不管是中文還是英文,基本都是介紹安裝方法和簡單的測試案例演示,但對於較複雜測試場景的案例演示卻基本沒有,因此很多測試人員都感覺難以將Locust
應用到實際的效能測試工作當中。
經過一段時間的摸索,包括通讀Locust
官方文件和專案原始碼,並且在多個效能測試專案中對Locust
進行應用實踐,事實證明,Locust
完全能滿足日常的效能測試需求,LoadRunner
能實現的功能Locust
也基本都能實現。
本文將從Locust
的功能特性出發,結合例項對Locust
的使用方法進行介紹。考慮到大眾普遍對LoadRunner
比較熟悉,在講解Locust
時也會採用LoadRunner
的一些概念進行類比。
概述
先從Locust
的名字說起。Locust
的原意是蝗蟲,原作者之所以選擇這個名字,估計也是聽過這麼一句俗語,“蝗蟲過境,寸草不生”。我在網上找了張圖片,大家可以感受下。
而Locust
工具生成的併發請求就跟一大群蝗蟲一般,對我們的被測系統發起攻擊,以此檢測系統在高併發壓力下是否能正常運轉。
在《【LocustPlus序】漫談服務端效能測試》中說過,服務端效能測試工具最核心的部分是壓力發生器,而壓力發生器的核心要點有兩個,一是真實模擬使用者操作,二是模擬有效併發。
在Locust
測試框架中,測試場景是採用純Python指令碼進行描述的。對於最常見的HTTP(S)
協議的系統,Locust
採用Python的requests
庫作為客戶端,使得指令碼編寫大大簡化,富有表現力的同時且極具美感。而對於其它協議型別的系統,Locust
也提供了介面,只要我們能採用Python編寫對應的請求客戶端,就能方便地採用Locust
實現壓力測試。從這個角度來說,Locust
可以用於壓測任意型別的系統。
在模擬有效併發方面,Locust
的優勢在於其摒棄了程式和執行緒,完全基於事件驅動,使用gevent
提供的非阻塞IO
和coroutine
來實現網路層的併發請求,因此即使是單臺壓力機也能產生數千併發請求數;再加上對分散式執行的支援,理論上來說,Locust
能在使用較少壓力機的前提下支援極高併發數的測試。
指令碼編寫
編寫Locust
指令碼,是使用Locust
的第一步,也是最為重要的一步。
簡單示例
先來看一個最簡單的示例。
from locust import HttpLocust, TaskSet, task
class WebsiteTasks(TaskSet):
def on_start(self):
self.client.post("/login", {
"username": "test",
"password": "123456"
})
@task(2)
def index(self):
self.client.get("/")
@task(1)
def about(self):
self.client.get("/about/")
class WebsiteUser(HttpLocust):
task_set = WebsiteTasks
host = "http://debugtalk.com"
min_wait = 1000
max_wait = 5000複製程式碼
在這個示例中,定義了針對http://debugtalk.com
網站的測試場景:先模擬使用者登入系統,然後隨機地訪問首頁(/
)和關於頁面(/about/
),請求比例為2:1
;並且,在測試過程中,兩次請求的間隔時間為1~5
秒間的隨機值。
那麼,如上Python指令碼是如何表達出以上測試場景的呢?
從指令碼中可以看出,指令碼主要包含兩個類,一個是WebsiteUser
(繼承自HttpLocust
,而HttpLocust
繼承自Locust
),另一個是WebsiteTasks
(繼承自TaskSet
)。事實上,在Locust
的測試指令碼中,所有業務測試場景都是在Locust
和TaskSet
兩個類的繼承子類中進行描述的。
那如何理解Locust
和TaskSet
這兩個類呢?
簡單地說,Locust類
就好比是一群蝗蟲,而每一隻蝗蟲就是一個類的例項。相應的,TaskSet類
就好比是蝗蟲的大腦,控制著蝗蟲的具體行為,即實際業務場景測試對應的任務集。
這個比喻可能不是很準確,接下來,我將分別對Locust
和TaskSet
兩個類進行詳細介紹。
class HttpLocust(Locust)
在Locust類
中,具有一個client
屬性,它對應著虛擬使用者作為客戶端所具備的請求能力,也就是我們常說的請求方法。通常情況下,我們不會直接使用Locust
類,因為其client
屬性沒有繫結任何方法。因此在使用Locust
時,需要先繼承Locust類
,然後在繼承子類中的client
屬性中繫結客戶端的實現類。
對於常見的HTTP(S)
協議,Locust
已經實現了HttpLocust
類,其client
屬性繫結了HttpSession
類,而HttpSession
又繼承自requests.Session
。因此在測試HTTP(S)
的Locust指令碼
中,我們可以通過client
屬性來使用Python requests
庫的所有方法,包括GET/POST/HEAD/PUT/DELETE/PATCH
等,呼叫方式也與requests
完全一致。另外,由於requests.Session
的使用,因此client
的方法呼叫之間就自動具有了狀態記憶的功能。常見的場景就是,在登入系統後可以維持登入狀態的Session
,從而後續HTTP請求操作都能帶上登入態。
而對於HTTP(S)
以外的協議,我們同樣可以使用Locust
進行測試,只是需要我們自行實現客戶端。在客戶端的具體實現上,可通過註冊事件的方式,在請求成功時觸發events.request_success
,在請求失敗時觸發events.request_failure
即可。然後建立一個繼承自Locust類
的類,對其設定一個client
屬性並與我們實現的客戶端進行繫結。後續,我們就可以像使用HttpLocust類
一樣,測試其它協議型別的系統。
原理就是這樣簡單!
在Locust類
中,除了client
屬性,還有幾個屬性需要關注下:
task_set
: 指向一個TaskSet
類,TaskSet
類定義了使用者的任務資訊,該屬性為必填;max_wait/min_wait
: 每個使用者執行兩個任務間隔時間的上下限(毫秒),具體數值在上下限中隨機取值,若不指定則預設間隔時間固定為1秒;host
:被測系統的host,當在終端中啟動locust
時沒有指定--host
引數時才會用到;weight
:同時執行多個Locust類
時會用到,用於控制不同型別任務的執行權重。
測試開始後,每個虛擬使用者(Locust例項
)的執行邏輯都會遵循如下規律:
- 先執行
WebsiteTasks
中的on_start
(只執行一次),作為初始化; - 從
WebsiteTasks
中隨機挑選(如果定義了任務間的權重關係,那麼就是按照權重關係隨機挑選)一個任務執行; - 根據
Locust類
中min_wait
和max_wait
定義的間隔時間範圍(如果TaskSet類
中也定義了min_wait
或者max_wait
,以TaskSet
中的優先),在時間範圍中隨機取一個值,休眠等待; - 重複
2~3
步驟,直至測試任務終止。
class TaskSet
再說下TaskSet類
。
效能測試工具要模擬使用者的業務操作,就需要通過指令碼模擬使用者的行為。在前面的比喻中說到,TaskSet類
好比蝗蟲的大腦,控制著蝗蟲的具體行為。
具體地,TaskSet類
實現了虛擬使用者所執行任務的排程演算法,包括規劃任務執行順序(schedule_task
)、挑選下一個任務(execute_next_task
)、執行任務(execute_task
)、休眠等待(wait
)、中斷控制(interrupt
)等等。在此基礎上,我們就可以在TaskSet
子類中採用非常簡潔的方式來描述虛擬使用者的業務測試場景,對虛擬使用者的所有行為(任務)進行組織和描述,並可以對不同任務的權重進行配置。
在TaskSet
子類中定義任務資訊時,可以採取兩種方式,@task裝飾器
和tasks屬性
。
採用@task裝飾器
定義任務資訊時,描述形式如下:
from locust import TaskSet, task
class UserBehavior(TaskSet):
@task(1)
def test_job1(self):
self.client.get('/job1')
@task(2)
def test_job2(self):
self.client.get('/job2')複製程式碼
採用tasks屬性
定義任務資訊時,描述形式如下:
from locust import TaskSet
def test_job1(obj):
obj.client.get('/job1')
def test_job2(obj):
obj.client.get('/job2')
class UserBehavior(TaskSet):
tasks = {test_job1:1, test_job2:2}
# tasks = [(test_job1,1), (test_job1,2)] # 兩種方式等價複製程式碼
在如上兩種定義任務資訊的方式中,均設定了權重屬性,即執行test_job2
的頻率是test_job1
的兩倍。
若不指定執行任務的權重,則相當於比例為1:1
。
from locust import TaskSet, task
class UserBehavior(TaskSet):
@task
def test_job1(self):
self.client.get('/job1')
@task
def test_job2(self):
self.client.get('/job2')複製程式碼
from locust import TaskSet
def test_job1(obj):
obj.client.get('/job1')
def test_job2(obj):
obj.client.get('/job2')
class UserBehavior(TaskSet):
tasks = [test_job1, test_job2]
# tasks = {test_job1:1, test_job2:1} # 兩種方式等價複製程式碼
在TaskSet
子類中除了定義任務資訊,還有一個是經常用到的,那就是on_start
函式。這個和LoadRunner
中的vuser_init
功能相同,在正式執行測試前執行一次,主要用於完成一些初始化的工作。例如,當測試某個搜尋功能,而該搜尋功能又要求必須為登入態的時候,就可以先在on_start
中進行登入操作;前面也提到,HttpLocust
使用到了requests.Session
,因此後續所有任務執行過程中就都具有登入態了。
指令碼增強
掌握了HttpLocust
和TaskSet
,我們就基本具備了編寫測試指令碼的能力。此時再回過頭來看前面的案例,相信大家都能很好的理解了。
然而,當面對較複雜的測試場景,可能有的同學還是會感覺無從下手;例如,很多時候指令碼需要做關聯或引數化處理,這些在LoadRunner
中整合的功能,換到Locust
中就不知道怎麼實現了。可能也是這方面的原因,造成很多測試人員都感覺難以將Locust應用到實際的效能測試工作當中。
其實這也跟Locust
的目標定位有關,Locust
的定位就是small and very hackable
。但是小巧並不意味著功能弱,我們完全可以通過Python指令碼本身來實現各種各樣的功能,如果大家有疑問,我們不妨逐項分解來看。
在LoadRunner
這款功能全面應用廣泛的商業效能測試工具中,指令碼增強無非就涉及到四個方面:
- 關聯
- 引數化
- 檢查點
- 集合點
先說關聯這一項。在某些請求中,需要攜帶之前從Server端返回的引數,因此在構造請求時需要先從之前請求的Response中提取出所需的引數,常見場景就是session_id
。針對這種情況,LoadRunner
雖然可能通過錄制指令碼進行自動關聯,但是效果並不理想,在實際測試過程中也基本都是靠測試人員手動的來進行關聯處理。
在LoadRunner
中手動進行關聯處理時,主要是通過使用註冊型函式,例如web_reg_save_param
,對前一個請求的響應結果進行解析,根據左右邊界或其它特徵定位到引數值並將其儲存到引數變數,然後在後續請求中使用該引數。採用同樣的思想,我們在Locust
指令碼中也完全可以實現同樣的功能,畢竟只是Python指令碼,通過官方庫函式re.search
就能實現所有需求。甚至針對html頁面,我們也可以採用lxml
庫,通過etree.HTML(html).xpath
來更優雅地實現元素定位。
然後再來看引數化這一項。這一項極其普遍,主要是用在測試資料方面。但通過歸納,發現其實也可以概括為三種型別。
- 迴圈取資料,資料可重複使用:e.g. 模擬3使用者併發請求網頁,總共有100個URL地址,每個虛擬使用者都會依次迴圈載入這100個URL地址;
- 保證併發測試資料唯一性,不迴圈取資料:e.g. 模擬3使用者併發註冊賬號,總共有90個賬號,要求註冊賬號不重複,註冊完畢後結束測試;
- 保證併發測試資料唯一性,迴圈取資料:模擬3使用者併發登入賬號,總共有90個賬號,要求併發登入賬號不相同,但資料可迴圈使用。
通過以上歸納,可以確信地說,以上三種型別基本上可以覆蓋我們日常效能測試工作中的所有引數化場景。
在LoadRunner
中是有一個整合的引數化模組,可以直接配置引數化策略。那在Locust
要怎樣實現該需求呢?
答案依舊很簡單,使用Python的list
和queue
資料結構即可!具體做法是,在WebsiteUser
定義一個資料集,然後所有虛擬使用者在WebsiteTasks
中就可以共享該資料集了。如果不要求資料唯一性,資料集選擇list
資料結構,從頭到尾迴圈遍歷即可;如果要求資料唯一性,資料集選擇queue
資料結構,取資料時進行queue.get()
操作即可,並且這也不會迴圈取資料;至於涉及到需要迴圈取資料的情況,那也簡單,每次取完資料後再將資料插入到隊尾即可,queue.put_nowait(data)
。
最後再說下檢查點。該功能在LoadRunner
中通常是使用web_reg_find
這類註冊函式進行檢查的。在Locust
指令碼中,處理就更方便了,只需要對響應的內容關鍵字進行assert xxx in response
操作即可。
針對如上各種指令碼增強的場景,我也通過程式碼示例分別進行了演示。但考慮到文章中插入太多程式碼會影響到閱讀,因此將程式碼示例部分剝離了出來,如有需要請點選檢視《深入淺出開源效能測試工具Locust(指令碼增強)》。
GitHub專案地址
硬廣
歡迎關注我的個人部落格和微信公眾號。
- 個人部落格: debugtalk.com
- 微信公眾號:
DebugTalk