vlambda博客
学习文章列表

陆思远 • 百信银行测试负责人

        最近在项目中一直忙着做自动化平台后端的接口开发工作，本来想陆续总结篇SpringMVC 及 Mabyties 框架方面的心得与遇到的坑。但是没想到上篇随手写的Jmeter与Grafana的集成被认可度这么高，阅读量近4万并且增加了很多订阅读者。其实最开始写专栏的目的是为了我们接口自动化框架以及开源项目Teamcat的推广，没想到得到了很多同行的认可。并且写着写着发现在每个阶段学到不同知识后及时写篇总结后，于己是对知识进行一遍系统的梳理与凝练，于他人也能感受到分享的快乐。希望大家也可以多多尝试总结，知识千千万，真的只有不断复盘总结才能真正掌握。

        鉴于上篇工具使用类文章这么受欢迎，今天就继续性能测试这个话题，聊聊对性能测试的理解，包括概念、流程以及常用测试工具对比几个方面。说实话我对性能测试了解并不深，我最擅长的是自动化、持续集成、工程效率方向。说到这，简要说下我对测试人员的理解：相比开发，测试开发的知识广度要求更广，从前端到后端、从安全到运维、从产品到设计、从测试流程到项目管理等等，哪个点不涉及？广度就决定了我们肯定没办法做到在每个方向都专精，那怎么办呢？我觉得测试人员对自己的定位应该是一专多能，所谓一专就是一定要明确的清楚自己最擅长什么方向，这可能由自己内在兴趣决定，也可能由公司外部条件决定。但不管什么原因，当有人问到这个问题时，一定要能立马、准确、坚定的说出来。试问如果出去找工作时，如果自己都对自己的定位不清楚，那让别人怎么来评估你，难道说您看着办？哈哈，所以一专一定是你需要下苦工，下时间研究最多的地方。至于多能，就需要平时有时间时广泛的学习了解，在项目需要的时候能及时顶上。总不能当有个环境部署或者接口压测的任务交过来，我说我擅长自动化，干不了这个～那估计第二天就废了，哈哈。所以我们平时需要多积累，遇到事情不但能够做到及时顶上，还要顶的尽量专业～貌似写跑题了，就不过多延展了。。。另外最近好多人私信时称我大佬、大神，我想说我真的不是大佬，只是一个在测试路上摸索前进的小菜鸟，或许会很艰难，但绝不敢懈怠。

1、什么是性能&性能测试？

2、性能测试能够解决什么问题？

       a）评估当前系统

系统未做过任何性能测试，对系统的当前性能情况不了解，就好像没有体检过就不知道自己的身体状况一样。而一系列性能引发的严重问题也正是由于缺少了必要的性能评估而导致。包括峰值的承载能力、稳定性、吞吐量等等。

       b）寻找瓶颈，优化性能

常见的现象为，某业务操作响应时间很长、某系统上线一段时间后运行越来越慢，这些都需要逐步分析定位并调优。

       c）预测未来性能

当用户数和业务量增加时能否及时应对?如何调整?是增加应用服务器，还是数据库服务器?还是要优化代码逻辑?这一系列问题都值得我们深思，这也是性能测试的目的所在。

3、性能测试等同于压力测试？

       首先明确性能测试肯定不是等同于压力测试这么简单，压力测试是性能测试的一种，主要的目的大概有4类：

       a）得到业务服务处理能力的指标，tps，响应时间。

       b）根据压测过程分析系统的瓶颈在什么地方（数据库连接限制，IO密集，业务逻辑）

       c）基于现状和线上的流量来决策线上扩容部署和优化点。（加机器，加几台，扩容那些业务）

       d）在压力测过程中，发现一些潜在的隐患（内存泄漏，高并发用户线业务逻辑问题，数据出错，日志太大导致的磁盘问题等等。）

       压测中的各种概念与指标诸如负载、并发、压力、事务、吞吐量、TPS、QPS、PV、RT、ART等等就不过多介绍了，随便百度都有很多介绍非常清晰的文章，这里只提一点，TPS到底是不是QPS？很多人认为QPS和TPS是一样的，其实还是有些不同点，QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS算起来可以是TPS的子集。

4、性能测试流程？

        a）性能需求分析

       性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。

        b）性能测试准备

          测试环境准备：系统运行环境，这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。执行机环境 ，这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前准备好执行机环境。

          测试场景设计：根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。

          测试工具准备：负载工具，根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter或galting等。监控工具，准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。

          测试脚本准备：如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试。

          测试数据准备：负载测试数据：并发测试时需要多少数据？比如登录场景？DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。

          其它：如果需要其它其它关联系统或专业人士如DBA配合的，也需要提前进行沟通。

        c）性能测试执行

当用户数和业务量增加时能否及 时应对?如何调整?是增加应用服务器，还是数据库服务器?还是要优化代码逻辑?这一系列问题都值得我们深思，这也是性能测试的目的所在。

        d）结果分析调优

没办法简要概括，后面有机会深入学习后单独总结。

        e)   测试报告与总结

制式模版要好看，数据指标要全且准确，结论要简单明了、直切要点等等总之要显得专业就好啦。

5、常用测试工具对比？

       压测离不开测试业务场景和压测目标，没有一个工具可以适合所有的业务压测场景。并且我觉得性能测试不应该依赖某一工具，它应该是一个不依赖任何工具的独立的体系，而不是建立在某一工具上的体系，这样不免就本末倒置了。下面还是简要介绍一下目前常用的压测工具，只介绍下特点及适用场景，至于工具的具体使用都很简单，有需要时去找资料学习下就好了。轻量级web服务压测工具有Apache Bench，http_load等，使用环境在linux下，用简单的命令行操作的工具。稍微重一点的压测工具有jmeter，特点是功能强大，jmeter设计之初只是一个简单的web性能测试工具，但经过不段的更新扩展，现在可以完成数据库、FTP、LDAP、WebService等方面的测试。因为它的开源性，当然你也可以根据自己的需求扩展它的功能。还有就是loadrunner，安装包3G左右，负载机需要安装到linux机器。

附：

性能测试工具列表

来源：

https://maimai.cn/article/detail?fid=1094698875&efid=5Yee0veX4xaLsOgI_AvfZg