## 前言
首先我给大家带来一个`Locust`教程；
locust 的官方 Github 是：[https://github.com/locustio/locust](https://github.com/locustio/locust)
locust 这个工具，需要根据你的实际情况来决定是不是适合你；
如果你对编程了解比较多，并不是只会 jmeter 的测试人员；
那么完全可以代替笨拙的 jmeter 处理你的测试，它在自定义方面处理的非常好，这也就带来一个弊端，就是什么都需要你来做，而且对你的代码能力和逻辑思维有一定的要求；
如果你对 编程是一脸懵逼的状态，那么建议你还是 jmeter 为主（毕竟要干活），然后了解下`Locust`，看看它是怎么工作的，了解下它的处理思维；
<br>
<br>
## Locust 是什么？
Locust 是一个比较容易上手的分布式用户负载测试工具。
它旨在对网站（或其他系统）进行负载测试，并确定系统可以处理多少个并发用户，Jmeter 也可以处理这种场景，但是个人感觉 Jmeter 在这方面做的不如 Locust 专业。
Locust 在英文中是`蝗虫`的意思：
作者的想法是，在测试期间，放一大群[蝗虫]()攻击您的网站。
当然事先是可以用 Locust 定义每个蝗虫（或测试用户）的行为，并且通过 Web UI 实时监视围攻过程。
这将帮助您在项目上线之前测试并确定项目的瓶颈；
如果上线几个人访问就跪了，被老板拉出去祭天就懵逼了，有了 locust 可以让项目更加快乐的上线；
Locust 可以让测试工程师对开发人员和项目经理的回复的更专业，
>>>可以想象一下，当项目经理或领导问你这个项目的性能如何，可以承受多少压力的时候；
你回答说这个项目的瓶颈在 2341 人同时访问，超过就会挂掉 / 宕机 / 出错等，当在 1834 人同时访问时候，会变慢；具体访问时间的饼图如 XXX）
这样的回答是不是逼格很高？
## 我是如何开始了解 Locust 的
但是真正进行并发接口时，发现 jmeter 在单机下并发超过 1000 的时候，单台台式电脑机器的资源早就被使用完，jmeter 都动不了，基本就算凉了；
也可能是我的 jmeter 压测接口研究得不够，不会用吧 - -，如果有优雅的方法，欢迎来告诉我；
通过搜索发现基于 Python 开发的 Locust 的单机并发能力很理想，在测试环境拿来压测，好像真的可以实现几千的并发，然后就打开了 Locust 的大门。
## Locust 的 特征
* **用 Python 编写测试方案**
* 不需要在 UI 界面上傻乎乎的点击，只需正常的写写代码就可以了。
* Locust 基于协程而不是回调，这样会让您的代码类似于正常的 Python 阻塞代码那样同步执行。
* **分布式 & 可扩展**
* 支持模拟数十万的用户行为（还是非常给力的）
* Locust 支持分布在多台计算机上的运行负载测试（可以多台机器并行开搞）。
* 由于基于事件，因此即使一个蝗虫节点也可以在单个过程中处理数千个用户。
* 不过即使您模拟了这么多用户，也并非所有人都是这种频率的使用您的系统，通常，用户会有思考的时候，会想一想下一步该怎么做。
* 需要明白**每秒请求数 不等于 在线用户数**。
* **统计结果基于 Web 界面**
* Locust 有一个简单的用户界面，可实时显示相关的测试详细信息。
* 统计结果界面是基于网页的，而网页是天生跨平台的，所以 Locust 是跨平台且易于扩展的（Locust 作者的这种思维还是很不错的）。
* **可以测试任何网页 / 应用 / 系统**
* 即使 Locust 是面向 Web 的，它也可以测试几乎所有项目
* 只需用 python 编写想要测试的方案，然后放”蝗虫”去怼需要测试的项目就可以了，非常简单！
* 虽然官方是这么宣传的，但是如果你对 python 了解的不怎么样，那可能就没有那么简单啊；就像商家把兰博基尼的操作宣传的再简单，我没钱买也是白搭（老铁，我太难了！）
* 如果你对编程是懵逼的状态，那还是回去用 jmeter 吧，优雅不优雅的先不说，最起码你可以用它来干活；
* **容易被入侵**
* Locust 放出去的蝗虫很小，很容易被入侵，开发团队是一只打算保持这种状态的。
* 事件 I/O 和协程的所有繁重工作都委托给 gevent
* 团队是看到 jmeter 等其它测试工具，处理的太 low，太死板了，所以才写的 locust；
## Locust 是完全基于 Python
http 请求完全是基于 requests 库；
Locust 支持 http、https 协议，还支持测试其他协议，websocket 等；
只要采用 Python 调用对应的库就可以了。
* http/https 采用 requests；
* websocket 采用 websocket ；
## Locust 的创作背景
`Locust`之所以创建，是因为作者受够了现有的解决方案。
作者认为他们都没有解决正确的问题，没有抓住要点，简单的讲，就是作者认为他们太 low 了，一个能打的都没有，于是自己撸了一个 Locust 给大家用。
作者也深度尝试过 Apache JMeter 和 偶尔用用 Tsung。
JMeter 带有一个 UI，很多人可能会认为这是一件好事，只需要点点就好。
但是如果你是一个测试测试，很快就会意识到，通过某些点击界面“编码”您的测试方案是一种 PITA。
其次，JMeter 是线程绑定的，这意味着对于每个要模拟的用户，都需要一个单独的线程。这也就导致了，在一台计算机上模拟成千上万的用户进行基准测试是不可行的。
另一方面，Tsung 没有用 Erlang 编写的线程问题。
它可以利用 BEAM 自身提供的轻量级工艺，并且可以愉快地扩展规模。
但是在定义测试方案时，Tsung 和 JMeter 一样有限。
它提供了基于 XML 的 DSL 来定义用户在测试时的行为方式（这种格式还是很 low 的，但是却很直观）。完成后显示任何种类的图形或报告，都需要对测试生成的日志文件进行后处理，只有这样，您才能了解测试的进行方式。
作者在创建 locust 时试图解决这些问题。
