如何开展性能测试

以前有在本身建的测试群直播分享了一些性能测试的基础内容,当时有人说但愿有个实战的分享,想了想某些东西属于公司机密不方便直接直播分享,html

这里就拿最近我作的一个性能测试实例来举例子说说,理解为主。。。数据库

先看看一个完美的性能测试流程是怎样的,以下图:服务器

固然,实际工做中能实现这种完美的流程很难,下面挑重点的介绍。。。微信

 

1、获取测试需求架构

大概上周三接到这样一个性能测试需求,大概的业务逻辑以下图:并发

简单归纳下业务逻辑,就是:发起一个拼团,其余人点击活动进去,领券,而后领券时要验证拼团的有效性,在买单用券时,先验证是不是会员,若是不是,先注册会员,再将券和会员绑定!工具

具体的性能指标是:验证上图4个场景中的接口,在响应时间为3S和5S时,服务器的TPS值(这属于系统性能能力验证的应用领域)。性能

测试的系统,是公司的微信会员系统,系统架构相对熟悉,这里不过多介绍。测试

 

2、测试计划和方案优化

所谓的测试计划,无非就是某人用多久时间用什么资源什么方法完成什么事情

因为此次性能测试需求工做量不大,且时间足够,因此就我一我的完成测试的大部分工做,固然,一部分须要开发协助。

测试方案,就是测试计划的补充和扩展。

好比此次性能测试,我预计用一周时间完成这些测试工做,设计用例、场景建模、准备测试数据、测试脚本开发、环境搭建等各须要多久时间,在哪一天甚至是上午仍是下午完成这些工做。

 

3、执行前的准备工做

环境搭建:测试环境因为以前会员系统也进行过性能测试,测试环境搭建这一步工做量不大,开发很快就配置完成,因此这里不赘述。

场景建模:我的理解,就是考虑哪些场景下可能存在性能瓶颈,相应的设置对应的测试脚本和测试逻辑,以尽量模拟生产环境(因为对业务蛮熟悉,这里也不赘述,须要说起的一点是:

        必定要理解、熟悉系统业务,由于需求的产生,就是用户+场景)。

测试数据准备:测试数据准备经常使用的有这两种方式:将生产数据复制一份过来、开发脚本预埋造数据(但不管哪一种,必定要注意数据隔离,防止数据污染)。

测试脚本开发:首先,须要从开发那里获取开发接口文档数据库表设计文档

       而后,经过工具或者写测试脚本调试接口,先保证接口能够成功调用(我用的工具是jmeter+MySQL)。

 

4、执行测试脚本

在保证接口能够成功调用以后,先进行单接口基准测试,即:对一个接口进行压力测试,不断加压,直到响应时间达到或超过指标,观察当前其并发数和TPS。

我的经验是一样的并发数,多执行几回,获得一个平均值或稳定值(即TPS和TRT曲线相对稳定的值),并记录下来。

以下图:

记录的目的,能够经过直观的数据变化,获得单个接口的最大TPS和不一样并发状况下的响应时间变化。

PS:记得前几天从一本书上看到这样一句话:80%的性能瓶颈能够经过分析TPS和TRT的数值变化获得(虽然有点片面,但也不失为一种方法)。

好比按照上图记录的数值变化来看,很明显领券接口性能极差,这时候就能够告知开发,经过查看log、检查代码、SQL语句等方法来查询缘由(固然我的能力足够的话,这些能够本身来作)。

 

5、监控调试

jmeter这个性能测试工具自己就用监听器这个元件提供了必定的监听数值报告元件,但毕竟开源工具,其自己的组件功能不够强大,能够经过下载支持jmeter的加强型功能插件来进行监控。

jmeter插件下载地址:https://jmeter-plugins.org/

下载后能够解压缩,将plugins-manager.jar放入jmeter安装目录lib/exe,而后重启jmeter便可。

能够经过点击下图圈出来的按钮检验是否成功安装:

不管是对服务器资源使用率仍是测试数据报表生成,甚至TPS、TRT等的监听,该插件都提供了组件支持,具体的使用方法请自行寻找。。。

所谓的监控调试,就是一个不断调整重复的过程,这个须要根据性能测试的目的,应用领域去判断具体如何执行。。。

 

6、最终报告

根据上面的几个步骤,获得测试结果,分析系统存在的瓶颈,而后采用各类方法提出解决方案或优化建议,最后对本次性能测试进行一个完整的总结,这样,一次性能测试就完成了。

在整个过程当中,费时较长通常是在测试数据准备和测试执行、监控调优阶段。

最后吐槽一句:性能测试水太深,想潜水的作好准备,别稀里糊涂扎进来,太刺激。。。