背景
云压测平台在测试领域并不是陌生的名词，简单来说就是在网页/移动端执行压测操作，同时压力机是部署在云端。
如压力节点机在云南，那就是云南产生压力，在北京，那就是北京产生压力。
现阶段云压测平台挺多的，我了解到的就有收费的如阿里云的PTS、XMeter，还有一些开源的，如nGrinder、云集微店的TITAN。
云压测平台要解决什么问题
1、压测任务和业务的关系：隶属层级。
2、压测任务和测试人员的关系：权限管理。
3、摒弃繁琐的手工操作，提高效率，完全线上操作。
4、实时查看结果：集成监控平台。
5、历史压测数据留存：在线测试报告。
6、统一压测工具，统一压测标准。
云压测平台为什么要自己实现
收费的就不提了。
开源的各种压测工具，总会面临各种问题：
1、脚本语言写的压测内核，创造压力的性能就不够。
2、冷门的压测软件，测试结果难以服众。
3、软件用的人少，容易出问题和出了问题不好解决。
4、热数据图形监控都不好。
5、系统较庞大，占用资源较多。
6、是否便于推广，真正减轻工作量。
同时，平台实现之后还有好处：
1、和其他测试工具/平台做集成对接。
2、和其他部门的工具/平台做对接。
3、全链路性能测试的起点，公司性能保障的开端。
实现语言及内核
开发语言
其实平台本身使用什么语言开发都可以，但是由于压力内核选择使用了Jmeter，为了要调用Jmeter的API，平台也选择使用Java开发。
Jmeter的优缺点
优点不详述了，最重要的还是顶级项目开源，社区活跃，Java语言性能好和跨平台。
说下缺点，目前发现的有：
1、代码还是庞大冗余，但这一定程度上保证了软件稳定性。
2、至少测试报告的核心开发，水平一般（我有实锤，要反驳的别在这吵）。
3、Jmeter的API设计的一般，调用时较麻烦。
4、分布式压测架构存在中心节点瓶颈，总压力上不去。
5、用大文件生成测试报告，时间较长。
Jmeter压测启动的方式
脚本执行
平台根据前端的操作，自动拼接出一行可执行的命令，然后在指定服务器上执行这段脚本。
相当于是手工敲的命令平台帮着拼接和回车执行了。
即便是前端来生成测试脚本，也可以先保存成jmx文件，再脚本执行。
特点是平台和Jmeter_Home完全分离，带来的：
1、平台代码可以不用Java写了，什么语言写都可以，仅仅是拼装命令。
2、毕竟是脚本执行，Jmeter随意切换版本。
3、平台和Jmeter可以不部署在同一台服务器上，即不是相同的进程内了。
4、Jmeter挂掉不影响平台运行。
程序内引用Jmeter的API来压测执行
平台代码直接调用Jmeter的API。
相对脚本执行的实现：
1、平台代码需要使用Java来写，毕竟要引入Jmeter的jar包了。
2、同样支持各种版本的Jmeter，但是不灵活。
3、同平台在一个进程内产生压力，Jmeter如果挂了，平台也危险，因为可以线程产生压力。
对比脚本执行的好处：
1、脚本执行得到的返回仅仅是窗口返回数据，太单薄且不稳定。
2、可以定制Jmeter功能，比如自实现压测监控数据。
从需求看实现
核心需求
网页/移动端可以启动压测和停止压测。
最最基本的要求了。
压测数据可以在线实时监控。
如果没有在线实时监控，那和Jmeter自身的脚本压测甚至和AB等工具，就没啥区别了。
可能生成测试报告，最好在线查看，最少也要导出查看。
Jmeter3开始支持测试报告，这也是选择Jmeter的原因之一。
支持分布式压测
即云压测的基础。
权限管理
权限管理是平台面向全公司/全网的基础。
业务层级展示
压测需要和具体业务有关系，这个关系在平台上要可以设置。
压测热数据实时监控要可控
图形监控的功能要非常丰富，比如放大缩小等。
删除，下载等操作
删除是让系统文件空间可控。下载是移动办公的基础。
分布式节点管理
分布式压测的衍生需求，有了分布式节点管理，能大大减轻手工操作。同时各种提示非常人性化。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
