在模拟有效并发方面,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://www.baidu.com"
min_wait = 1000
max_wait = 5000
在这个示例中,定义了针对http://www.baidu.com
网站的测试场景:先模拟用户登录系统,然后随机地访问首页(/
)和关于页面(/about/
),请求比例为2:1
;并且,在测试过程中,两次请求的间隔时间为1~5
秒间的随机值。
那么,如上Python脚本是如何表达出以上测试场景的呢?
从脚本中可以看出,脚本主要包含两个类,一个是WebsiteUser
(继承自HttpLocust
,而HttpLocust
继承自Locust
),另一个是WebsiteTasks
(继承自TaskSet
)。事实上,在Locust
的测试脚本中,所有业务测试场景都是在Locust
和TaskSet
两个类的继承子类中进行描述的。
那如何理解Locust
和TaskSet
这两个类呢?
简单地说,Locust类
就好比是一群蝗虫,而每一只蝗虫就是一个类的实例。相应的,TaskSet类
就好比是蝗虫的大脑,控制着蝗虫的具体行为,即实际业务场景测试对应的任务集。
这个比喻可能不是很准确,接下来,我将分别对Locust
和TaskSet
两个类进行详细介绍。
在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
步骤,直至测试任务终止。再说下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
来更优雅地实现元素定位。
然后再来看参数化这一项。这一项极其普遍,主要是用在测试数据方面。但通过归纳,发现其实也可以概括为三种类型。
通过以上归纳,可以确信地说,以上三种类型基本上可以覆盖我们日常性能测试工作中的所有参数化场景。
在LoadRunner
中是有一个集成的参数化模块,可以直接配置参数化策略。那在Locust
要怎样实现该需求呢?
答案依旧很简单,使用Python的list
和queue
数据结构即可!具体做法是,在WebsiteUser
定义一个数据集,然后所有虚拟用户在WebsiteTasks
中就可以共享该数据集了。如果不要求数据唯一性,数据集选择list
数据结构,从头到尾循环遍历即可;如果要求数据唯一性,数据集选择queue
数据结构,取数据时进行queue.get()
操作即可,并且这也不会循环取数据;至于涉及到需要循环取数据的情况,那也简单,每次取完数据后再将数据插入到队尾即可,queue.put_nowait(data)
。
最后再说下检查点。该功能在LoadRunner
中通常是使用web_reg_find
这类注册函数进行检查的。在Locust
脚本中,处理就更方便了,只需要对响应的内容关键字进行assert xxx in response
操作即可。
针对如上各种脚本增强的场景,我也通过代码示例分别进行了演示。但考虑到文章中插入太多代码会影响到阅读,因此将代码示例部分剥离了出来,如有需要请点击查看
使用了一下,缺少东西,缺少RT50-99的值;报告不明显