系列二：通用HTTP测试工具开发详解
一、前言
小米分布式测试平台（Pecker）是一款集成各种测试的平台。包括但不限于性能测试、功能回归测试、上线准入测试等。测试种类不限于 RPC、HTTP、自定义 Java 接口等等。
二、背景
你的服务跑的有多快？你的服务平均响应时间是多长？你的服务能抗多少流量，能抗多久？每次新服务上线或新活动上线前，相关研发同学通常会思考这几个问题。“这也许只有QA同学应该知道吧”。
流量猛增，服务雪崩，不应该啊！服务容量已经算上buffer了，为什么还是败在大流量之下？
在这样的背景之下，我们着手开发了小米分布式测试平台-Pecker。旨在尽最大可能解放研发人员生产力，提前发现服务瓶颈和缺陷，保证服务稳定运行。
小米分布式测试平台（Pecker）是一款集成各种测试的平台。包括但不限于性能测试、功能回归测试、上线准入测试等。测试种类不限于RPC、HTTP、自定义Java接口等等。
三、小米分布式测试平台介绍
测试平台采用了业界比较成熟的三层架构方案。如下：
最上层为控制台，用户在此层操作。例如创建相关测试任务、查看执行历史、报表等数据。
中间层为调度层，对测试任务进行调度。
最底层为容器云，即任务执行层。每个测试任务最终都是在Pod中执行并完成。
1、性能测试种类
目前我们实现了三种压测种类，分为RPC、HTTP和自定义Java接口压测。
其中针对HTTP服务，我们引入了变量替换模式。
一个生动的栗子：假设现有一个HTTP GET请求为：http://www.mi.com/test?item=a，其返回值为：{"res": "a"}。针对这样的接口，我们不可能一直构造一个不变的请求，也不可能创建成千上百个类似的任务。
在测试平台上创建该任务时，可以定义为：http://www.mi.com/test?item=${item}，其返回值为：{"res": "${res}"}。用户只需要上传包括${item}和${res}的CSV文件，平台则会在请求前自动进行替换。
而且，对于HTTP的结果集验证，我们提供了三种校验。分别为：请求过程验证、HTTP状态码验证和用户自定义断言验证，下图为用户自定义响应断言：
平台提供的功能过于通用，用户想测试SQL操作，怎么办？
对于这种情形，我们在架构上完成了解耦的工作，将测试模块与测试客户端进行解耦，将测试模块与统计数据模块进行解耦。用户完全可以通过实现我们的接口完成测试。
public interface TestClient {
default void setUp();
SampleResult runTest();
default void tearDown();
}
2、性能测试方式
性能测试平台目前提供了两种测试模式：用户增长模式和QPS增长模式。
用户增长模式：每个测试阶段内用户数量固定，随着阶段的增加定量增加用户数。
例如：我们总共需要压测10个阶段，每阶段持续10分钟。初始阶段用户为1W，每个阶段递增1W。此模式现支持分布式测试模式。
QPS增长模式：每个测试阶段内固定QPS发送请求，随着阶段的增加定量增加QPS。
例如：我们总共需要压测10个阶段，每阶段持续10分钟。初始阶段期望QPS=1W，每个阶段期望QPS递增1W。此模式暂不支持分布式测试模式。
其底层实现方式为：动态计算响应时间、线程数和Delay方程式。
3、报表数据展示
报表数据我们提供了基础数据数据以及错误数据展示，如下：
为了展示数据更加直观，我们同样提供了图数据：
4、其他功能
因为性能测试多数为自动执行任务，使用者并不想每次都去控制台上手动操作。针对这种情况，我们开放了一些接口便于用户进行脚本运行或者Jenkins调度。
测试平台实际上模拟Client端操作，但用户想实时获取被压测服务的运行状态。针对这种情况，我们的统计模块可以动态展示打开JMX服务的CPU、内存以及GC相关数据。
5、与主流测试工具对比
与Jmeter和Gatling对比
| 性能 | 功能 | 数据展示 |
|---|---|---|
| 测试平台性能优于Gatling，与Jmeter相近 | 测试平台作为自研平台，其功能完备性要差于其他两个工具 | 测试平台在数据展示上要优于其他两个工具 |
四、未来规划
1、基准测试完善
测试平台目前处于高速开发阶段，为了不影响其性能，需要完善其基准测试，提供更多的测试场景以及基准数据。
2、接口平台
可以看到，极大多数性能压测都是对某些接口进行发起。后期我们提供更完备的接口平台。接口管理更方便，性能/功能测试一目了然。
3、功能测试平台
目前测试平台主要实现了性能测试功能，现正在开发功能测试平台。支持上传测试用例并发起功能测试。
