性能测试总结（概念&流程&工具）

vlambda
2020-07-29

性能测试总结（概念&流程&工具）

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

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

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

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

定义：软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。

性能测试定义：指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

由上面定义我们起码可以看出来，对于性能测试，我们关注的是软件的非功能特性。所以说性能测试介入的时机一定是在功能测试完成之后的，另外所谓及时性是一个比较宽泛的指标，这可能包括时间或其它很多子指标来综合衡量。通常我们会使用某些工具或手段来检测软件的某些指标是否达到了要求，这就是性能测试。

当然这个性能在不同角色不同视角中是不同的，或者说关注点侧重方向完全不一样。用户眼中最直观的感觉可能是这还要我等多久（响应时间）、为什么总是失败（稳定性）；开发眼中可能会关注架构是否合理（架构设计）、数据库设计是否合理（数据库设计）、运行时会不会存在内存、线程同步、资源竞争方面的问题（代码质量）；运维眼中可能会关注服务资源、数据库资源等利用合理吗（资源利用率）、系统能支持多少用户，支持多大业务处理量（系统容量）、有哪些瓶颈、是否能够扩展（可扩展性）；说了这么多，那在测试眼中的性能是什么样的？虽然不想说，但不得不说，测试人员需要考虑全面的性能，包括上述用户、开发、运维等各个视角的性能。前几篇文章一直在讲质量意识，在讲QA是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，总不能光说不练吧。写到这，可能我一会测试一会QA会引起误解，但麻烦各位大大不要再提醒我QA和测试角色是不一样的，这个我知道也很清楚，如果你们公司既有测试又有QA作为分开的两个部门，那就当我说错啦～

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机器。

常用软件	应用场景	安装包大小	优点	缺点	其他
ab	模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的	依赖于apcache，安装完apache自带ab测试工具	多进程压测，对施压机资源消耗少，操作简单，启动快，	只能对接口进行简单测试，无法进行场景模拟。	java开发
http_load	http接口测试	100k，下载安装编译操作简单	c操作简单，上手快，可与其他测试场景一起用，比如在一定压测情况下，做某些操作。	简单的接口测试，不支持post形式，单进程操作。压力不会太大。	可以二次开发，也有现成的库文件
jmeter	m模拟复杂场景，支持参数序列化，支持断言，也可用作回归的测试	只有几M，依赖java环境	可界面化操作，输出的分析报告不如loadrunner丰富	相比上面两个工具，可界面，但是分析报告简单。
loadrunner	复杂和高并发，需要持续大压力的业务场景	4G左右，软件安装比上面都复杂，一般需在agent代理机	丰富的数据收集和测试报告产出，支持三成协议开发交互，支持录制。支持被压机服务的性能指标的收集展示。	压测脚本需要自己开发，需要有一定的编程基础。	商业不免费