压测平台设计思路简介

本文由作者孙禹达授权网易易盾发布

在项目中,服务器的压力测试是我们比较关注的一个点,但是实际在测试中,我们经常会遇到很多问题,比如测试过程不透明,服务器环境准备困难,上手门槛较高等等,因此我们尝试将服务端压力测试平台化,来解决目前现有的一些痛点及方便更多的人使用,进一步将项目质量透明化,方便提升整个产品的质量。

首先我们针对于这些痛点做一些简要分析:

1.测试结果可视化

一般而言,压力测试都是由程序或者测试开发去手动跑的,并且测试的结果也都是想办法自己搞成可视化数据,并没有一个统一的渠道和平台能够系统的将测试结果展示出来。

2.环境准备

无论是代码版本,分支还是项目的一些配置,每次压测都免不了要重新搞一套专门的配置,而如果再有一个需要准备,就需要继续一套配置,比较浪费精力。

3.服务器控制

如果是接入了阿拉丁之类的类似管理系统的线上服务器,也需要长长的流程去确认及和处理,如果要是私服的话,也需要程序或者测开自己去shell里面敲指令,相对不是很方便。

4.测试不够透明

在开发中的项目经常是不稳定的,可能压测压着压着到一半的时候其实就已经挂了,虽然有通过抛错等方式去知道服务器已经挂了,但是有时候只是压力过高的情况下也需要进行优化,却没有一个比较实时的方式能够知道目前的服务器状态。

5.测试目标不明确

一般没有进行过压测的新项目,不大清楚自己的压力负载极限在什么程度,很多时候程序反而想通过测试来确定自己的压力负载极限,有点类似于摸底考试一样的感觉。

6.执行门槛较高

一般测试脚本的话,有代码功底的功能测试也都比较容易写出来,但是要批量启动,又要控制频率和内容等等,就会难度稍微大些,所以都是由测试开发或者程序来完成这部分内容,但是如果让测试开发完全自己去写测试用例,他们对于功能的理解和用例点的重要度是不如功能测试的,所以这部分工作交给功能测试去做,能更好的保证项目的质量。

7.服务器资源占用成本过高

基本上每有一个项目要做压测,都会自己去单开服务器,如果是外网服务器,无论是管理费还是流量费的成本都是非常高额的,但是实际上项目可能只在某个里程碑版本的测试需求会比较多,每个项目都要自己搞一组或者几组的服务器,大部分时间却在闲着,其实是比较大的资源浪费,如果能够合理的分配和调度服务器资源,能够极大的节省这部分的成本。

8.数据采集比较麻烦

如果是单服的机器人还好,只需要把这个物理机上的所有进程搞过来就行了,但是对于搭在在多个物理机器上的集群服务器,数据的采集和同步对齐就是一个比较困难的问题了。

基于以上的一些痛点(其实主要就是我个人作为测试开发去做压测的时候觉得存在的问题),压测平台的思路便诞生了,目的就是尽可能的解决目前所存在的痛点。初版的压测平台就诞生了。首先通过web的方式能够比较简单的进行操作,大幅度的释放了测开的手动压力(原来的工作主要包括去服务器敲shell指令,拉性能数据,性能数据可视化这种),并且也有程序和QA可以参与使用进来,虽然还存在很多痛点,但是已经能解决了部分问题。

基于这些分析搞了个初步的设计思路,尝试着手去开发压测平台。


相关阅读:

中间件容灾测试与压力测试的一些总结

如何进行DDoS防御?