本文我们将讨论对开源压测工具进行二次开发，从而构建一个压测平台时，我们应该考虑哪些特性。

从工具到平台

就开源性能测试工具而言，种类之多让人咋舌，从单纯的单机命令行工具，到分布式的压测框架，可以选择的实在太多了。有兴趣的朋友可以看这里 性能测试工具对比(2020)。在我看来，具有代表性的工具主要是wrk、jmeter以及locust，wrk在性能上是完全碾压后两者的，然而它仅仅只是一个http协议的压测工具，并且本身并不支持分布式压测所以并未成为主流，而locust使用Python实现，如果施压脚本使用python编写，性能跟不上。这也就使得jmeter成为了国内外测试界主流的性能测试工具。

然而，工具并不是平台，工具只提供了基础的压测功能，平台化的功能是需要二次开发的，最近一直在思考，一个优秀的性能测试平台（或者说框架），应该具备哪些能力，这些能力（功能）不仅覆盖大部分的使用场景，在一定程度上也提高了使用者的效率。

优秀压测平台应具备的能力

a、完整的压测过程和结果展示

压测过程的展示对于压力测试来说是非常重要的，有些命令行工具在执行时没有展示过程，这是非常不友好的，当然真正的压测除了关注客户端的过程，被测系统的监控也是需要关注的。好看，好用的UI不仅能够让人赏心悦目，还能帮助发现异常。过程和结果应该是可以跨平台的，不受系统制约的，并且可以持久化存储的。比如下面的UI：

b、分布式架构

单纯的单机命令行工具是比较难大批量部署的，压测数据的计算和采集也容易受到限制。一个优秀的平台从设计上应该就是分布式的，支持横向扩展，随时能够根据不同的压测场景，扩缩施压机器。如果平台基于容器化部署，那么对于实现实例的动态扩缩就变得简单。

c、高性能的压测脚本（足够的性能）

压测脚本的性能好坏决定了压测时的资源消耗情况，显然，如果使用类似python的脚本语言编写施压脚本，那么需要占用更多的机器资源才能产生符合预期的并发能力。平台应该采用性能优秀的语言来编写压测脚本，最大程度地利用现用的机器资源。

d、慢启动（阶梯并发）或瞬时并发

压测场景除了能够支持瞬时并发量，还应该支持慢启动（阶梯并发），既能同时指定并发用户数和孵化速率。

e、指定最大tps

支持指定最大tps，对于一些特殊场景，保证了施压端不会产生大于用户指定的压力，保证系统的稳定，尤其是线上系统。

f、支持任意协议压测

除了支持常见的http协议，也能支持rpc、websocket等协议的压测。

g、指定压测时长

支持指定压测时长，开启压测后，只需静静等待压测结果。

h、指定压测自动终止条件

支持指定压测终止条件，比如失败率、响应时间达到某些值时自动终止压测等。

i、施压机器监控

在施压机器有限的情况下，有时候会因为施压机的性能达到瓶颈而误认为目标服务已经达到最大处理能力。我曾经压测过webrtc服务，非常消耗施压端机器资源，一个施压节点一般只能开2个房间，如果能实时查看施压机的资源情况，及时更换问题节点对压测过程分析和结果是很重要的。

j、封装脚本，提供简洁的脚本编写规则

我认为这一点对压测平台的推广非常关键，如何能做到这一步，那么初次的使用成本相对较低，其他测试同学，甚至开发也愿意使用。这里举个例子，http压测，如果可以封装成类似json这样的编写方式，构建json时去指定每个接口的header \ body \ query以及接口的比例，然后适当地提供参数化能力。

k、参数化能力

如果用户可以编写代码，那么参数化可以自己使用代码实现。如果是使用平台提供的封装脚本协议，那平台需要提供类似模板方法或文件上传的功能，从而满足用户参数化的需求。

最佳实践

什么才是真实的业务场景？

压测脚本和并发压力是比较容易构造的，难点在于如何才能产生贴近生产环境的请求，比如各个接口的请求比例，单个用户的请求行为，思考时间。再比如在分布式缓存的架构下，是否命中缓存，对接口的tps影响也会比较大，压测脚本只能最大程度地贴近业务场景，无法做到与真实的业务场景完全一致。

全链路压测？

目前比较流行的线上压测方式，通过录制线上的真实流量，回放到目标环境，对回放流量打上标识，同时引入Mock，影子库等方案，不产生脏数据，最大程度地模拟了线上的真实业务场景，或许这才是线上性能测试的未来。