通用HTTP测试工具开发详解

声明：原创文章，转载请注明出处。https://www.jianshu.com/p/a30e2a77f62a

一、背景

由于最近题主在做一些分布式测试工具的开发，想分享一些思路或者想法出来。
具体的产品可见，小米分布式测试平台 (一)- 初识 Pecker。
因为涉及公司的项目以及保密性，故只分享一些这种工具的开发思路。

HTTP协议无论在公司内网或者公司外网来讲，尤其重要。但对其进行性能压测和功能压测的工具基本就那几种。且每个公司业务和环境不同，移植或者二次开发难度很大。

因此，大公司在这件事情基本上都投入很多人力，但核心功能还是下面讲到的这些。

声明：原创文章，转载请注明出处。https://www.jianshu.com/p/a30e2a77f62a

还是搬出下面这个图，HTTP测试功能只是在容器云上运行的一个客户端。
这样做的原因是：控制台和调度层相对独立，功能保持不变。容器云的Pod提供运行时环境，真正跑的任务为一个HTTP测试客户端。

三层架构

清楚了，HTTP测试功能的整体所处的位置后，我们再考虑HTTP功能的各个模块。

整个HTTP测试功能，一般需要以下四个模块。分别为：任务基本配置、测试配置、客户端特殊配置以及服务端配置。

我画了一张草图，基本上HTTP测试就是下面这个样子：
题外音：原谅一个不会画原型图的程序员吧！！

HTTP任务编辑

HTTP任务作为一种任务形态依附于项目，因此需要定义相关的项目和任务名称。基本配置作用于各个任务形态（RPC、HTTP、Jar）。

也是整个测试平台的通用配置，主要包括压测方式设置以及压力机配置。

压测方式：可设置为用户数模式和TPS模式。二者的主要区别在于用户数模式，客户端会模拟等量的用户进行不间断测试；而TPS模式仅仅是保证在一个自然数周围进行测试（如设置TPS=1000，则客户端会尽量保证在这附近进行测试）
压力机配置：需要配置压力机的数量、CPU核数以及内存大小。其实就是对Pod的设置。

该模块作为HTTP任务的专用模块。可配置一些HTTP的常见基本参数。

path：/demo
参数：id=?
返回值：id
示例1：www.test.com/demo?id=1&name=1    返回：1
示例2：www.test.com/demo?id=2&name=2    返回：2

对这样的接口测试，我们不可能只请求一个不变的例子（如id===1），也不可能穷举N个任务，每个任务发送一个固定的请求。
所以，我们需要使用变量替换掉id，即：

www.test.com/demo?id=${id}&name=${name}

然后，在CSV中保证有id列和name列，即可。这样平台在测试过程中，会一行行进行遍历和替换。

检查点：对结果进行断言验证。提取点包括：ResponseHeader和ResponseBody；其中ResponseHeader只支持键值对匹配，ResponseBody支持JSON提取、文本提取和正则匹配等。

对被压测的服务进行监控，其实现思路常见有2种：服务端开启JMX或者服务端使用我们提供的Agent进行数据回传。

声明：原创文章，转载请注明出处。https://www.jianshu.com/p/a30e2a77f62a

如果任务保存后，再执行。通常会进行一个：保存、Pod测试、报表收集等过程。
假设用户在编辑任务表单时输错了一个字符，仍需要进行以上步骤，其效率将大大折扣。

基于此，我们需要用户在编辑任务表单时，实时调试自己的任务，如下：

HTTP任务调试

其中，概览包括请求及响应头信息、请求Body为POST时请求的数据、响应信息为服务端的真实响应数据。

备注：由于调试功能仅为校验表单的作用，是不能CSV替换模型同时使用。

声明：原创文章，转载请注明出处。https://www.jianshu.com/p/a30e2a77f62a

多数情况下，我们的任务不仅要执行一次，而是多次执行。那任务本身如果支持定时测试，那真是极好的，至少不用外接Jenkins进行定时调度。
通常，我们为用户支持两种方式来支持定时调度，分别为Crontab模式和闹钟模式。

Crontab模式

闹钟模式

至于任务本身的定时调度实现，我们可以使用Spring Schedule或者Quartz组件，但是需要保证多节点不会同时调度的问题。

针对HTTP功能来讲，无非就是跑一些case，能够输出判断结果。
可以精简性能测试模块，去掉压力机的相关配置。
任务须配置为CSV模式，其中包括请求参数变量以及检查点变量。具体不再详述。

声明：原创文章，转载请注明出处。https://www.jianshu.com/p/a30e2a77f62a