小米分布式测试平台 (一)- 初识 Pecker
系列二:通用HTTP测试工具开发详解
一、前言
小米分布式测试平台(Pecker)是一款集成各种测试的平台。包括但不限于性能测试、功能回归测试、上线准入测试等。测试种类不限于 RPC、HTTP、自定义 Java 接口等等。
二、背景
你的服务跑的有多快?你的服务平均响应时间是多长?你的服务能抗多少流量,能抗多久?每次新服务上线或新活动上线前,相关研发同学通常会思考这几个问题。“这也许只有QA同学应该知道吧”。
流量猛增,服务雪崩,不应该啊!服务容量已经算上buffer了,为什么还是败在大流量之下?
在这样的背景之下,我们着手开发了小米分布式测试平台-Pecker。旨在尽最大可能解放研发人员生产力,提前发现服务瓶颈和缺陷,保证服务稳定运行。
小米分布式测试平台(Pecker)是一款集成各种测试的平台。包括但不限于性能测试、功能回归测试、上线准入测试等。测试种类不限于RPC、HTTP、自定义Java接口等等。
三、小米分布式测试平台介绍
测试平台采用了业界比较成熟的三层架构方案。如下:
Pecker架构-
最上层为控制台,用户在此层操作。例如创建相关测试任务、查看执行历史、报表等数据。
-
中间层为调度层,对测试任务进行调度。
-
最底层为容器云,即任务执行层。每个测试任务最终都是在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相关数据。
JVM相关信息5、与主流测试工具对比
与Jmeter和Gatling对比
性能 | 功能 | 数据展示 |
---|---|---|
测试平台性能优于Gatling,与Jmeter相近 | 测试平台作为自研平台,其功能完备性要差于其他两个工具 | 测试平台在数据展示上要优于其他两个工具 |
四、未来规划
1、基准测试完善
测试平台目前处于高速开发阶段,为了不影响其性能,需要完善其基准测试,提供更多的测试场景以及基准数据。
2、接口平台
可以看到,极大多数性能压测都是对某些接口进行发起。后期我们提供更完备的接口平台。接口管理更方便,性能/功能测试一目了然。
3、功能测试平台
目前测试平台主要实现了性能测试功能,现正在开发功能测试平台。支持上传测试用例并发起功能测试。