本文由作者孙禹达授权网易易盾发布
在项目中，服务器的压力测试是我们比较关注的一个点，但是实际在测试中，我们经常会遇到很多问题，比如测试过程不透明，服务器环境准备困难，上手门槛较高等等，因此我们尝试将服务端压力测试平台化，来解决目前现有的一些痛点及方便更多的人使用，进一步将项目质量透明化，方便提升整个产品的质量。
首先我们针对于这些痛点做一些简要分析：
1.测试结果可视化
一般而言，压力测试都是由程序或者测试开发去手动跑的，并且测试的结果也都是想办法自己搞成可视化数据，并没有一个统一的渠道和平台能够系统的将测试结果展示出来。
2.环境准备
无论是代码版本，分支还是项目的一些配置，每次压测都免不了要重新搞一套专门的配置，而如果再有一个需要准备，就需要继续一套配置，比较浪费精力。
3.服务器控制
如果是接入了阿拉丁之类的类似管理系统的线上服务器，也需要长长的流程去确认及和处理，如果要是私服的话，也需要程序或者测开自己去shell里面敲指令，相对不是很方便。
4.测试不够透明
在开发中的项目经常是不稳定的，可能压测压着压着到一半的时候其实就已经挂了，虽然有通过抛错等方式去知道服务器已经挂了，但是有时候只是压力过高的情况下也需要进行优化，却没有一个比较实时的方式能够知道目前的服务器状态。
5.测试目标不明确
一般没有进行过压测的新项目，不大清楚自己的压力负载极限在什么程度，很多时候程序反而想通过测试来确定自己的压力负载极限，有点类似于摸底考试一样的感觉。
6.执行门槛较高
一般测试脚本的话，有代码功底的功能测试也都比较容易写出来，但是要批量启动，又要控制频率和内容等等，就会难度稍微大些，所以都是由测试开发或者程序来完成这部分内容，但是如果让测试开发完全自己去写测试用例，他们对于功能的理解和用例点的重要度是不如功能测试的，所以这部分工作交给功能测试去做，能更好的保证项目的质量。
7.服务器资源占用成本过高
基本上每有一个项目要做压测，都会自己去单开服务器，如果是外网服务器，无论是管理费还是流量费的成本都是非常高额的，但是实际上项目可能只在某个里程碑版本的测试需求会比较多，每个项目都要自己搞一组或者几组的服务器，大部分时间却在闲着，其实是比较大的资源浪费，如果能够合理的分配和调度服务器资源，能够极大的节省这部分的成本。
8.数据采集比较麻烦
如果是单服的机器人还好，只需要把这个物理机上的所有进程搞过来就行了，但是对于搭在在多个物理机器上的集群服务器，数据的采集和同步对齐就是一个比较困难的问题了。
基于以上的一些痛点（其实主要就是我个人作为测试开发去做压测的时候觉得存在的问题），压测平台的思路便诞生了，目的就是尽可能的解决目前所存在的痛点。初版的压测平台就诞生了。首先通过web的方式能够比较简单的进行操作，大幅度的释放了测开的手动压力（原来的工作主要包括去服务器敲shell指令，拉性能数据，性能数据可视化这种），并且也有程序和QA可以参与使用进来，虽然还存在很多痛点，但是已经能解决了部分问题。
基于这些分析搞了个初步的设计思路，尝试着手去开发压测平台。
相关阅读：