聊聊性能测试平台

1. 背景

在刚过去的2020年，我司的全链路压测平台已成功落地。今天呢，宝路就来聊聊本身对性能测试平台设计的一些想法与思考！

2. 平台思惟导

 

2.1 需求工做流

工做流确保了测试按约定步骤推动，同时让工做的透明度和可再现性。咱们工做中经常使用的有JIRA、TAPD等。平台是彻底能够与之进行对接的。

一般状况下压测需求可能由开发部门、业务部门、运维部门发起，测试组接收到压测需求后须要对测试需求调研、评估。

压测需求经过评审后，测试组根据实际状况进行排期、制定压测方案计划。测试组完成压测方案计划后可向项目发起方案评审。多方会议评审经过后，则可进入压测实施、直至测试组完成压测工做，发出性能测试报告。

上面所述的是一个大体的流程，在实施的过程会遇到各类各样的困境，致使流程很难推动下去。

每每不少时候你们对系统性能的认知还不够深入。本应该作压测的项目却被项目组忽视性能测试，在系统上后引起性能问题；测试跟开发的关系一直很微妙，测试发现的问题多，开发就不happy了（又该挨批了）！测试发现的问题少，上面领导就不happy了（养测试时干什么吃的。。。。）！

开发人员心理叫苦，测试人员也是黯然神伤！今天就不过多展开聊，宝路后面计划专门开一篇 “如何作好性能测试”的文章。

 

2.2 测试脚本管理

脚本在线编辑：支持测试人员调整脚本，如调整并发用户、压测环境、参数数据等。

脚本克隆：为了测试人员在不改动父脚本的前提下，快速拷贝以达到测试人员快速编写调整脚本。

脚本录制：目前大概有四种脚本编写方式：1.纯手工编写（相对比较慢）、2.JMeter代理录制（感受很差用）3.Fiddler抓包工具插件转jmx脚本（目前对脚本的兼容性有待考察）4.采用meterSphere的录制插件（目前开源，很是推荐使用）。

脚本一键上传：两种方式：1.传统的文件上传（平台页面点击上传>选择脚本文件进行上传）、2.插件方式（单独开发JMeter插件，GUI模式下编写完脚本后点击上按钮默认直接上传当前脚本及参数化文件，很是的方便，你们可参考bzm开源的插件自行开发）。

脚本标签：这个功能是为了更好的对测试脚本进行快速查找区分，测试人员可根据自定义的标签来实现快速查找脚本。

  

2.3 库文件、插件管理

在使用JMeter测试工具测试，你们确定常常会遇到一个问题那就是常常要上传一些插件（需放lib/ext目录下）和依赖的库文件（需放lib目录下）。若是不作统一管理，很容易出现jar包冲突、覆盖其余人上传的包等现象，进而形成测试失败。

那么怎么规避呢？我们其实能够从用户角度分析，好比：测试用户A在作某个项目时须要上传一个A1插件或A1库文件，可是这个插件或文件对测试用户B根本就用不到。

那就各子维护本身的插件就完事了呗，普通用户本身上传的插件只对本身生效或者可见，那些通用的插件，好比特殊Thread Group、TPS、Shaping Timer等插件则可由组长或者管理员帐户统一来维护。这些插件对特定组员或者普通测试用户可见，且不可编辑（防止乱删）。

场景执行前先对salve机器进行数据同步，好比参数文件、插件和库文件、服务器时间等。

2.4 数据、环境管理

修改数据文件：压测的时候常常会遇到脚本中包含了某些参数文件。特别是消耗性的数据，会让人难受。。。。要反复的搞不少个参数化文件，而后再对每一个slave机进行替换。既然有了性能平台，那性能平台就应该支持在线修改参数据、一键同步文件。记住这种消耗性的数据必定要进行数据分块。否则在压测过程数据库会造成大量锁等待，形成TPS较低。

环境管理：这个应该很好理解，测试人员可提早维护好各个环境。总之一句话说：“脚本不该依赖于环境”。脚本在运行的时候是能够选择环境的，而不是在脚本中固定请求地址。

2.5 压力机管理

智能调度：根据测试脚本中总并发用户，智能分配压力机，进而达到slave机资源利用率最大化。

监控状态：测试人员可查看压测过程当中，所用到slave机的资源消耗状况。若是发现cpu资源消耗较高，可从新配置slave机的并发分配占比，进而达到最优测试结果的目的。

手动启停：在测试过程当中，如遇slave状态异常，测试人员可在平台上对slave机进行人为的启停。

自动熔断：在测试过程当中，若是在某一段连续时间内，出现大量失败请求，此时salve自动触发中止测试场景，以此来保护被测系统。经常使用的开源插件有 AutoStop Listener。这个是一个值得探讨的问题，究竟是应该中止压测场景，仍是中止某些slave机？是maser发起中止所有 仍是salve之间互相通知？关于这块，宝路这边也计划深刻研究一下，毕竟总有更好的办法！

2.6 配置管理

容器配置：为每台容器salve机器配置并发用户上限、cpu数等。

定时任务：测试人员能够配置计划任务，来达到定制执行压测计划的目的。

挡板配置：支持部署单独的挡板模块。配置管理请求地址、接口报文、交易延迟等。

2.7 实时监控

性能数据结果实时展现：常见的方案有两种：一是采用InfluxDB+ Grafana的解决方案（这里也有“坑”，之后宝路会写文章来分析）；二是采用MySQL+Echars +Kafka的解决方案。

被测系统资源监控：解决方案：Collectd+InfluxDB+ Grafana

以上所述的方案，宝路更倾向与采用InfluxDB+ Grafana的解决方案。至于缘由嘛，暂且不谈。固然了想作好这些确定不容易，每一个都须要你去了解，不能光看看网上的帖子就觉得本身会了。。。有好多东西都是值得深挖的。

 2.8 测试报告

邮件发送：这个功能确定是经常使用功能，值得讨论的就是制定一个能知足本身的报告模板。其核心主题就是怎么展现才能让不懂性能的人看明白，也就是所谓的通俗易懂。。。不能总站在本身的角度考虑问题，对吧！

报告共享：邮件的方式算其中一种，测试人员也能够采用共享的方式，给制定人员共享测试报告。该用户经过登陆平台或者制定链接都可查看。

系统测评：当测试人员完成压测需求后，会根据测试结果再结合约定的规则对系统进行评分，再由测试组长复评。这个规则是值得商榷的。。。好比能够根据不一样并发用户下的接口响应时间、系统资源消耗等方面进行规则制定。经过不断的完善，以达成你们均承认的一个评分规则。

2.9 系统管理

  这个就简要说了，经常使用的数据清理功能，能够按时间段清理测试结果，来确保磁盘预留足够的空间，其包含了一些经常使用的用户权限管理、用户的增删改等。

2.10 REST API

做为一个测试平台，不管功能仍是性能，其实都绕不开CI/CD、DevOps。关于这个趋势想必也不须要宝路来过多叙述了。

这就意味着，平台必需要具有这个能力！外部系统能够经过平台API方便的调用平台的服务。图中也仅是举个几个API的例子，为更好的适配，更多的API服务是很是值得开发和研究的。