| 编辑推荐: |
本文来自于个人博客，本文用一个例子简单描述了通过测试分析到最后的总结，如何进行一个完整的性能测试。
|
|
之前有在自己建的测试群直播分享了一些性能测试的基础内容，当时有人说希望有个实战的分享，想了想某些东西属于公司机密不方便直接直播分享，
这里就拿最近我做的一个性能测试实例来举例子说说，理解为主。。。
先看看一个完美的性能测试流程是怎样的，如下图：
当然，实际工作中能实现这种完美的流程很难，下面挑重点的介绍。。。
一、获取测试需求
大概上周三接到这样一个性能测试需求，大概的业务逻辑如下图：
简单概括下业务逻辑，就是：发起一个拼团，其他人点击活动进去，领券，然后领券时要验证拼团的有效性，在买单用券时，先验证是否是会员，如果不是，先注册会员，再将券和会员绑定！
具体的性能指标是：验证上图4个场景中的接口，在响应时间为3S和5S时，服务器的TPS值（这属于系统性能能力验证的应用领域）。
测试的系统，是公司的微信会员系统，系统架构相对熟悉，这里不过多介绍。
二、测试计划和方案
所谓的测试计划，无非就是某人用多久时间用什么资源什么方法完成什么事情。
由于这次性能测试需求工作量不大，且时间足够，所以就我一个人完成测试的大部分工作，当然，一部分需要开发协助。
测试方案，就是测试计划的补充和扩展。
比如这次性能测试，我预计用一周时间完成这些测试工作，设计用例、场景建模、准备测试数据、测试脚本开发、环境搭建等各需要多久时间，在哪一天甚至是上午还是下午完成这些工作。
三、执行前的准备工作
环境搭建：测试环境由于之前会员系统也进行过性能测试，测试环境搭建这一步工作量不大，开发很快就配置完成，所以这里不赘述。
场景建模：个人理解，就是考虑哪些场景下可能存在性能瓶颈，相应的设置对应的测试脚本和测试逻辑，以尽可能模拟生产环境（由于对业务蛮熟悉，这里也不赘述，需要提及的一点是：
一定要理解、熟悉系统业务，因为需求的产生，就是用户+场景）。
测试数据准备：测试数据准备常用的有这两种方式：将生产数据复制一份过来、开发脚本预埋造数据（但无论哪种，一定要注意数据隔离，防止数据污染）。
测试脚本开发：首先，需要从开发那里获取开发接口文档和数据库表设计文档。
然后，通过工具或者写测试脚本调试接口，先保证接口可以成功调用（我用的工具是jmeter+MySQL）。
四、执行测试脚本
在保证接口可以成功调用之后，先进行单接口基准测试，即：对一个接口进行压力测试，不断加压，直到响应时间达到或超过指标，观察当前其并发数和TPS。
个人经验是同样的并发数，多执行几次，得到一个平均值或稳定值（即TPS和TRT曲线相对稳定的值），并记录下来。
如下图：
记录的目的，可以通过直观的数据变化，得到单个接口的最大TPS和不同并发情况下的响应时间变化。
PS：记得前几天从一本书上看到这样一句话：80%的性能瓶颈可以通过分析TPS和TRT的数值变化得到（虽然有点片面，但也不失为一种方法）。
比如按照上图记录的数值变化来看，很明显领券接口性能极差，这时候就可以告知开发，通过查看log、检查代码、SQL语句等方法来查询原因（当然个人能力足够的话，这些可以自己来做）。
五、监控调试
jmeter这个性能测试工具本身就用监听器这个元件提供了一定的监听数值报告元件，但毕竟开源工具，其本身的组件功能不够强大，可以通过下载支持jmeter的增强型功能插件来进行监控。
jmeter插件下载地址：https://jmeter-plugins.org/
下载后可以解压缩，将plugins-manager.jar放入jmeter安装目录lib/exe，然后重启jmeter即可。
可以通过点击下图圈出来的按钮检验是否成功安装：
无论是对服务器资源使用率还是测试数据报表生成，甚至TPS、TRT等的监听，该插件都提供了组件支持，具体的使用方法请自行寻找。。。
所谓的监控调试，就是一个不断调整重复的过程，这个需要根据性能测试的目的，应用领域去判断具体如何执行。。。
六、最终报告
根据上面的几个步骤，得到测试结果，分析系统存在的瓶颈，然后采用各种方法提出解决方案或优化建议，最后对本次性能测试进行一个完整的总结，这样，一次性能测试就完成了。
在整个过程中，费时较长一般是在测试数据准备和测试执行、监控调优阶段。
|
