【性能测试入门教程】性能测试正确的打开方式

前言

性能测试一直是测试行业里一个经久不衰的领域，好多测试小伙伴们在做了若干年手动测试后，希望能提升自己技能，做一些更有技术含量的测试工作，然后把目光纷纷转向了性能测试。

随着Loadrunner/Jmeter在国内的普及，越来越多的人加入了性能测试的大军，仿佛掌握了Loadrunner就掌握了振兴中华的核心技术。但是至少80%想学性能测试的小伙伴，一直处于录制&回放的水平。平时在工作中或者网上的性能交流群里，发现即使有些小伙伴工具用的很熟了，但是对于性能的一些基本理论还是一知半解。只是在操作工具，但是没有性能测试的思维。遇到一些问题，不能站在性能的角度去考虑问题，解决问题。究其根源，还是对于性能理论知识、基本概念的理解不深刻。因此，在真正做性能测试之前，一定要在思想上对性能有个清晰的认识，对一些理论知识都彻底理解了，这样在以后学习性能测试或者面对问题时，思路会更加清晰，处理问题会更加得心应手。就好比武侠小说中的武林高手，只要内功深厚，无论学习什么样的功夫，都可以快速掌握，并且发挥出最大的威力。

什么是性能测试

性能是一种特性，任何的产品都有功能性和性能的要求。比如我们买了一辆车，车可以正常开，说明它的基本功能性要求是满足了。但是车辆的百公里加速、车的极限速度、包括长时间的使用后车辆能否可以正常使用，这些都是性能的要求了。

在软件行业里，性能通常是指软件产品在高并发下的表现出来的一些特性。那么什么是性能测试呢，业界也并没有一个统一的定义。我的理解是，性能测试是通过一定的手段，模拟并发的用户请求，去测试系统的最大处理能力和稳定运行能力，找到性能瓶颈，从而提升系统整体处理能力的一个过程。

什么是压力机

从上面的概念定义里，我们可以知道，性能测试需要模拟用户的并发请求。而我们都是借助一些发压工具去产生并发请求，这些工具可能运行在Windows/Linux系统之中。所以我们需要一台或多台Windows/Linux机器来作为压力机。

好多同学在做性能测试时，可能受限于公司成本，都是用自己的办公笔记本/台式机来做压力机。这是一种极其不专业的做法，鲁迅曾说过，任何在办公网络里用笔记本压测的人都是在耍流氓。

为什么说是耍流氓呢？

首先呢，个人电脑的配置一般都比较低（相对于服务器而言），这样的话产生的压力就会小，从而不能压出系统的最大处理能力。

其次，就算个人电脑的配置非常高，但是在公司的办公网络内，通常都会有网速限制，网络带宽首先就成为了一个瓶颈，产生的压力自然也高不到哪去。

那么，正确的做法是怎么样的呢？

土豪公司：高配物理机（cpu>=16核，内存>=32G）N台

屌丝公司：低配物理机/虚拟机（cpu一般是8核或以下）1台或多台

压力机的硬件配置越高，产生的压力自然会很大。但是无论压力机是高配还是低配，切记压力机要和被测服务器没有任何网络瓶颈，最好与被测系统的服务器在局域网或者同机房内。

公司既然想做性能测试，就要有一个正经的态度，提供一定的资源。既想马儿跑，又不想马儿吃草，这样是不行的。否则只能是随便测测玩一玩，测出的数据没有参考价值。

负载测试和压力测试

对于初学者来讲，有两个概念想必都听说过，那就是“负载测试”和“压力测试”，包括出去参加面试的时候，容易有这样的笔试题。或者一些不太懂性能的面试官，也喜欢问这样的问题。

在百度上搜索了一下这两个概念，搜索结果非常多，但是貌似也没有一个统一的概念，描述的都比较含糊、抽象，每个人说的还都不太一样。别说初学者了，我看了都有点蒙了。。。

在实际工作中真的有这些测试类型的区分吗？其实并不是，一般在互联网公司内，普遍把性能测试统一称为“压测”，并不区分要做负载测试啊还是压力测试，每一次压测都有它的目的，比如我想压出系统的最大处理能力，比如我要压到服务器资源出现瓶颈，这其实是对压测场景的一种设计，而并不是说真的存在那么多的测试类型。所以对于初学者的建议是：忘掉这些概念，专注于自己的测试目的。

并发数/用户数

现在市面上所有的性能测试工具，都是通过多线程/进程，循环执行测试脚本，来向服务端发请求。所以每个工具都可以设置并发数。有的工具里也叫虚拟用户（Vuser）。

那么用户数和并发数是一个概念吗？显然不是，用户数分为三种：

注册用户/系统用户数：在系统里有记录的用户数

在线用户数：对服务端来讲，同时在线的用户数

并发用户数：对服务端来讲，同时对服务端发起请求的用户数

很显然，对于一个系统来说，注册用户数>在线用户数>并发用户数

经常有同学问这样的问题，我老板说要测试我们系统支持多少用户，我该怎么办？

很明显，老板们并不一定懂性能测试，他们意识中也没有三种用户数的区分，但是我们作为专业的性能测试人员，要去理解、引导领导们的需求。

领导说的是注册用户数吗？很明显，不是，这个数字只不过是数据库里的一个累积

领导说的是在线用户数吗？可能是，那么我们来分析一下：

在线用户一般指的是在服务端的session（内存）里存在的用户。根据我们的通用习惯，在线用户数里有相当一大部分用户，都是跟服务端没有任何交互的。比如你登录了某电商网站，然后屁股突然想吐，然后你就去解决问题了。这个时候，你就是一个在线用户，那么此时你对服务端有压力吗？有一点儿，那就是你占用了服务器的一丢丢内存，但过了一段时间后，服务器还会把你从session中清理掉。而且http是无状态无连接的（有keep-alive机制，但是时间不长，超时会断开），所以对连接数也基本没啥影响。对于服务端动不动就上百G的内存来讲，多一些或少一些在线用户sessionId之类的信息，基本没有啥影响。所以，测试在线用户数，意义并不是很大。

最后我们可以看到，其实真正影响系统性能的，就是并发用户，它们会对服务端带来压力和资源的消耗。我们通过压测工具测出来的并发数就是系统的绝对并发用户数。

测试出来的并发用户数一般都不会很大，所以老板问你系统支持多少用户数，你告诉他100（并发用户），他绝对会发飙的，什么破系统，就支持这么点用户？这时你要告诉他，我们系统支持100用户同时做某项业务，然后你的饭碗可能就保住了。

事务（Transaction）

好多初学者录制好脚本后，也不管三七二十一就开始压了，压完了就截图发网上问怎么分析这个数据啊。结果一看图，里面连事务都没有。。。

事务是一个比较重要的概念，最早起源于数据库。可以自行百度了解下数据库事务的概念。性能测试里的事务和数据库不一样。在性能测试领域里，事务其实就是一个标记，用户把本次想要测试的业务标记出来。压测工具在执行测试脚本时，它并不知道具体的业务，也不知道每个业务包含多少个步骤，所以它只能通过用户添加的业务标记来统计。

举个例子，大家都去过理发店，理发店业务，基本是分为洗剪吹三个步骤。大一点的叫xx造型，里面有好多Tony老师、阿木老师等。。。还有一堆小弟。老板把洗剪吹业务分给了三个人来做，相当于把整个过程加了三个标记，每个人完成自己的工作后，老板都会在小本本儿上记上对应的数据，统计老师们的工作量。

路边的小理发店，里面只有一个罗师傅，洗剪吹全包了，当他整个流程完成后，理发店老板也会在小本本儿上+1。

所以，对于一个相同的业务，怎么标记完全取决于理发店老板，既可以选择整个流程中一小部分做标记（比如大理发店老板只想统计洗头小弟的业务数据，其他人他就不管了）。同样也可以把整个流程做个标记，如小理发店老板，他就是这么记录的。

回到我们性能测试领域里，事务怎么加，这是由测试人员根据本次重点测试的业务来决定的。我这次想测下单，那么我就把下单添加一个事务标记，尽管我下单前是需要先登录的，由于登录不是测试重点，所以登录就不用加事务了，这样最终统计出来的事务数里就不包含登录业务了。

TPS、QPS和响应时间

知道了事务的概念后，TPS就容易理解了，TPS是Transaction Per Second的简称。它指的是每秒钟通过的事务数，这个事务数是指总的事务数，对应到上面我们讲的例子里，就是每秒钟整个理发店成功洗头或理发的人数。

响应时间一般指的是事务响应时间，也就是说完成某个事务所花费的时间，很显然，如果事务内的业务操作越多，响应时间就越长。

TPS和响应时间是性能测试中最重要的两个指标，相同并发数下，响应时间越长，TPS就越低。当理发店的每个人都笨手笨脚的时候，每天成功理发的人肯定就很少，你很难赚到什么钱。

另外在企业内做性能测试的过程中，时不时的听到一个叫做QPS的指标，尤其是研发人员，动不动就说“你就使劲压吧，我这个接口的QPS要达到1w+”。

什么是QPS？它和TPS有啥区别？

QPS最早也是来源于数据库，它是Query Per Second的简写，指的是每秒的查询量。后来普遍用于的接口的访问量。通过上面事务的概念我们可以知道，如果我们调用接口时添加一个事务标记，那么接口的访问量=TPS（排除极少数请求成功但是业务失败的数量）。所以，TPS和QPS是一回事，不同的职业叫法不相同而已，他们本质上没有区别。

吞吐量

吞吐量就是在测试过程中，网络上的上行流量和下行流量的总和，单位是字节，它反映的是占用网络带宽的情况，以此来判断是否有网络瓶颈。比如一条高速上正向和逆向车道一共有6个车道，如果在同一时刻有超过6辆车在跑，那就就出现排队情况了，这个时候通行效率就会降低。

服务端性能和客户端性能

经常见有人在网上问，APP怎么做性能测试啊，怎么测页面的性能啊。

其实无论APP还是浏览器，它们都是客户端，用户来操作它们的时候，都是从服务器（或者CDN上）下载静态资源到本地，然后调用了对应服务端接口来获取数据，客户端经过一些渲染处理，最后把数据展示给用户。

所以当你在问这些问题的时候，你要先搞清楚，我是要做服务端的性能测试，还是客户端的性能测试。服务端性能测试和客户端性能测试采用的手段是不一样的。服务端注重的是并发，通常我们所说的性能测试，都是指的服务端的性能测试，企业内开展的性能测试，大部分都是后端的性能，基于接口来做。因为服务端环境是统一的，但是客户端的环境却是千差万别，所以优先要保证服务端的性能。

客户端的性能也有自己的一套方案，比如APP的专项测试，采用了一些工具来测试CPU使用率、耗电量、内存使用等，比如腾讯的GT工具。浏览器上也有一些插件，可以测试页面解析加载的一些性能，比如Chrome插件yslow等。

性能测试的流程

把性能相关的一些概念和思路都搞清楚了，你就为开始做性能测试打下了良好的基础。最后我们来看一下，一个完整的性能测试流程：

需求调研-测试方案-环境部署-脚本编写-数据构造-执行测试-结果分析-调优回归-测试报告
大家可以看到，整个性能测试流程，是一个漫长的、复杂的、而且需要极高专业知识的工作。

写在最后

通过上面的一些概念解释，相信或多或少能够减少性能测试初学者的一些疑问。但是因为都是一些个人理解，所以难免会出现偏差，希望能和大家互动交流、共同提高。后续会根据性能测试流程中的每个环节，分享一些个人的理念和见解，希望大家继续关注。