目录

• 一、回顾

  • 1.性能测试

  • 2.负载测试

  • 3.压力测试

• 二、性能指标

  • 1.tps

  • 2.吞吐量

  • 3.rps

  • 4.qps

  • 5.hps

• 三、可靠性测试和容量测试

  • 1.可靠性测试

  • 2.容量测试

• 四、性能测试

  • 1.自己搭建

  • 2.独立环境

  • 3.云服务器使用无线网吗？

一、回顾

1.性能测试： 通过工具模拟一定数量的并发用户，请求服务器获取性能指标。

不知道被测系统需要多少并发用户，所以猜一个并发用户数，然后去做，这样也可以得到性能指标。

例如，猜测50个并发用户的数量，做性能测试也会得到性能指标。猜测80个并发用户的数量，做性能测试也会得到性能指标。性能指标：响应时间，tps，资源利用等。

哪个并发用户获得了真正的服务器性能指标进行性能测试？我们不知道。因此，在猜测并发用户数之前，我们将进行负载测试。

2.负载试验： 并发用户数量逐步增加，请求服务器获得最大并发用户数量的拐点。

并发用户数量每次增加都会有一个区间，比如从0，每次增加10人，逐渐增加，不断增加。

2.1如何判断拐点区间？

1)看有没有报错。 例如，将用户数量增加到80个并发用户是正常的。当用户数量增加到90个并发用户时，发现响应结果中的一些请求是连续错误的。

当90并发用户数量超过服务器最大可接受的并发用户数量时。那么这个拐点区间就是80-90之间应该有最大的并发用户。

然后再做一次负载测试，缩小范围。从80开始，每次增加一个。每次增加的范围是并发用户数。

如果83个并发用户数正常，84个并发用户数连续报错，最大并发用户数为83。

接下来，将83个并发用户数放入性能测试中，然后连续运行一段时间获得性能指标值，然后写入报告，完成性能测试。

有时会出现一种情况是不会连续报错，那就看平均响应时间是否超过1.5s，判断拐点区间。

2)平均响应时间是否超过1.5s。 从0开始，每次增加10个，一直增加到100个。发现70个并发用户的平均响应时间为1.5s以下。

如果80个并发用户的平均响应时间超过1.5s，此时可以说，70-80之间已经出现了最大的并发用户数量。

应该在70-80之间有一定的值，其平均响应时间接近1.5s。

然后从70开始逐渐增加，每次增加1个或2个并发用户，直到80个。通过这种方式，再次进行负载测试，以找出特定值。该值的平均响应时间为1.5s。

在这1.5s以前的时间是我们可以接受的最大并发用户数量。然后拿这个并发用户数进行性能测试，得到相关的性能指标。

3）tps下降。

随着并发用户数量的增加和并发用户数量的增加，如果服务器可以处理，请求频率会很高，总请求量会更高，每秒处理的总请求量会更多。

并发用户数量的增加，tps如果超过服务器的最大处理能力，值就会上升。但超过了服务器可以处理的最大要求，tps值会下降，此时也是拐点区间。

此时，服务器的性能指标可以获得最大并发用户数，并带到性能测试中。

3.压力试验： 使用一定量的并发用户数，长期持续请求服务器检查服务器稳定性。

也就是说，压力测试的目的是测试稳定性，而不是获得性能指标。性能指标是性能测试。

负载测试是获得拐点范围和最大并发用户数。

3.如何理解一定量？

范围必须小于最大并发用户数，而不是最大并发用户数。一般使用最大并发用户数的20%或80%。

1)为什么会有这样的说法？

例如，服务器最大的处理能力是83个并发用户，20%是16个左右。然后使用大约16个并发用户来查看稳定性。

或者83的80%，大概是60多个并发用户，总是要求服务器看稳定性。

2)为什么先用20%再用80%？

我可以用83的80%，也就是65个人继续向服务器提出请求。此时，我收到的总请求和相应的日志将超过83的20%并发用户的日志和请求。

通过日志和数据量的分析，最大并发用户数的20%更容易分析。因此，首先使用最大并发用户数的20%，然后使用最大并发用户数的80%。

最大并发用户数的20%，请求速度可能较慢，每秒总请求量可能较少，慢慢积累的时间可能稍长。我也有足够的时间观察资源的使用。

一般来说，为了测试这种稳定性，我们将首先使用相对较低的并发用户持续运行更长的时间，然后使用相对较大的并发用户运行更长的时间。

相对而言，最大并发用户80%的时间会比最大并发用户20%的时间短一点。

3)时间长:几个小时，几天。

负载测试和性能测试通常持续几分钟、十分钟或半小时。

运行时间相对较长。如果一些资源没有及时释放，它们就会积累。如果长时间没有得到足够的释放，最终资源可能不足，因为积累的资源越来越多。

如果资源不足，服务可能会停机。不一定是操作系统停机，只是服务挂断，这也是服务的不稳定性。

服务部署在这台机器上，使用这台机器的所有资源，导致这台机器的资源耗尽，你的机器可能会停机。

服务停机更多。

二、性能指标

1.tps: 服务器每秒处理的事务数量反映了服务器的综合处理能力。

服务器会有cpu、构成服务器的内存、磁盘、网络、应用等。cpu内存是资源，磁盘也是资源，io也是资源，得到这些资源，综合处理一个请求。

例如，当服务器处理时，它需要启动登录请求cpu计算需要内存资源的交换。

登录必须有帐户密码。数据应首先通过网络进入内存。登录的帐户密码应在内存中计算。

计算用户是否存在，是否注册，账户密码是否正确。因此，简单的登录需要消耗内存空间cpu计算，数据库查询数据，磁盘读写。

登录需要通过网络传输到我的网卡，网卡的数据转换为操作系统的数据。操作系统的数据应该存储在内存中。

检查时进入cpu，cpu检查时，从磁盘中获取数据，通过内存与其进行比较。

所以需要网络io，磁盘的io，内存，cup因此，资源是整体资源能力的体现。

2.吞吐量： 网络每秒通过的事务数。

它只是一个通道，相当于一个水管，水管越粗，在这个时间能通过的水流量就越大些。水管越细，在这个时间能通过的水流量就小些。

管道越厚，水流就能通过，服务器的处理能力就越强。如果服务器处理能力很强，但水管很薄，那么水流就不会流出，这也会阻碍服务器处理能力的体现。

当网络没有瓶颈时，服务器的所有处理都可以通过网络流出。此时，服务器每秒处理的事务数将相当于网络的事务数值，但它们从不同的角度测量，一个是服务器，另一个是网络。

3.rps： 请求，每秒用户请求率，是发起人(无论用户如何发起)。

比如现在用的是jmeter工具，模拟jmeter调用此请求，每秒要求多少次。

如果用手点击，就是模拟真人在页面上点击的事件，每秒要求多少次。这是从用户的角度来衡量的。

服务器没有瓶颈，每秒发出100个请求，服务器可以处理。服务器每秒可以处理300个请求，现在你每秒给服务器100个，服务器每秒处理。在这种情况下，rps会和tps等值。

rps是发起人每秒的请求数。rps太低没有反映服务器tps的能力。

4.qps： 每秒查询率， 服务器的查询。

有些接口需要查询数据库，有些接口不需要查询数据库。一个事务可能需要调用多个查询。

因此，一个事务可能需要多次查询，一个事务可能会出现tps对应多个qps。

比如登录，首先要查询用户是否存在于数据库中，果不存在就不需要校验用户名和密码了。

发现这个用户是存在的，那么我再查询用户加密码的组合是不是一致的。组合一致，我才认为你能登陆成功。

组合不一致，就登陆失败。你登陆成功了，需要告诉用户登陆成功的结果。那还要查询用户相关信息。

所以，这个只是查询数据库，有可能要查询三次。

在企业中，如果没有严格区分，是把1个事务，当做只查询1次，但，实际请求可能是 1事务: n个查询。

5.hps： hitpers。每秒用户的点击率。（页面点击的时候才会有这样一个概念）

lr里面有hps这个概念，但是jmeter里面基本上就没有hps这个概念了。jmeter用的是接口向服务器发起请求，再也不是通过html的页面发起请求了。

并发： 每秒同一时间点发起请求。

rps是用户每秒发起请求率。现在有10个人一起向服务器发起请求，并发用户数就是10。

如果用户每秒能请求30次，那么这1秒里10个人总共会发起300次请求。那么1秒钟就会有300个并发。

如果增加到20个人来发起请求，那它的频率如果还是30，那么1秒钟就发起了600个请求，那1秒钟的并发就是600。

三、可靠性测试和容量测试

1.可靠性测试： 在给定的一定的业务压力下，持续运行一段时间，查看系统是否稳定。

关键词：是否稳定，一定业务压力。

最大并发用户数的20%做可靠性的测试。

2.容量测试：  在一定的软、硬件条件下，在数据库不同数量级数据量的情况时，对系统中读\写比较多的业务进行测试，从而获得不同数据量级下的性能指标值。

在性能测试时，如果数据库的数据量级是不一致的，性能指标值也可能存在差异。在做性能测试时，数据库的数据量级一定要保证一致。

比如生产的数据库数据量级是百万级，但是做测试用的环境是我自己搭建的，自己搭建的时候是个空的数据库开始进行性能测试造数据的，结果数据量级可能是几十条，几百条几千条，不超过一万条。

这种情况下会不会存在很大的性能差异？这是可能的。例如打开一个只有一两行数据的excel表格，很快就打开了。打开一个有一万行数据的excel表格，打开的速度按就是很慢。

打开的表的数据量越少，打开的速度越快，这个是单独从数据量的角度上来说。

日常放在手边的一个小的笔记本用来写写画画的，是不会在前面列目录的。但是一本字典，如果要在字典里面查一个字，那么字典前面的目录就非常有用了。

数据量很大的时候，通过目录来查找就会快很多。整个字典相当于数据库的一张表里面的数据，这个目录就相当于数据库里面的索引。

如果你的生产是百万级别的，那你的性能测试的环境里面的数据库里的这张表的数据量级也要保证百万级别。

如果现在公司的数据是百万级，随着使用的时间越来越长，数据量级会增加，某天达到千万级，亿级级别，那性能会是如何呢？

性能测试就是要提前预估在千万级，上亿级别的时候，性能指标值会有什么变化。

不同的数据量级情况下的性能指标值会有些差异。

在没有特别说明让做容量测试的时候，就保证性能测试环境里的数据库的数据量级和生产的数据库的数据量级保持一致。

四、性能测试

1.自己搭建： 也就是说性能测试需要自己搭建性能测试环境，而且是独立环境。

性能测试，不能使用功能测试环境、自动化测试环境、验收、生产环境都不能用，需要自己搭建独立环境。

所以，你要清楚公司产品的架构，要有自己独立搭建环境的能力。

2.独立环境： 真正的性能测试环境，机器的资源配置和生产完全一样（硬件配置一样、数量一样、网络一样、架构参数一样）。

公司生产环境有20-30台服务器，让我搭建独立环境，难道我也要20-30台机器吗？

金融、电信类的公司，这些公司确实能够给你足够的机器做性能测试。一般的公司，给不了那么多的机器，但是也不能一台服务器都不要啊。

2.1)千万不能使用生产环境进行性能测试，如果你用高并发的用户向服务器发起请求，响应时间很长。正好有用户也在用，响应时间很长，用户体验性就很差。

现在你把服务器搞挂了，用户突然发现服务器挂掉了，就要打电话投诉了：“服务器挂掉了，我的数据怎么办？”。这是个很严重的客户投诉。

假如你半夜的时候在生产环境做性能测试，凌晨三四点的时候是很少人在用，但是你注册下单的数据也写在生产环境的数据库里面。

这些数据在生产的数据库里就成为了脏数据。一个生产环境的数据库里出现了脏数据，这个脏数据不能被清干净。

万一因为这个不干净的数据导致生产环境出问题，追究责任就麻烦了。

当然也有人在生产数据库里建立了一个影子数据库，做性能测试的时候把数据写到影子数据库里面去，但是日志里面还是有脏数据。所以也是不合理的，尽可能不要使用生产环境。

功能测试环境、自动化测试环境、验收环境也不能用，是因为做性能测试会有大量的并发，这个导致服务器不稳定。

假如他正在做功能测试，在页面上点的正嗨的时候，服务器挂掉了，一点就报错了。还以为出bug了，相关人员一起来定位问题，结果是因为服务器挂掉了。

原因是你在做性能测试，这个事情就不好解释了。

2.2)硬件配置要一样：

假设生产的服务器是8核cpu，16g的配置之上，结果给的服务器配置达不到这么高，cpu能给到8核，但是内存只能给到8g，这样可以吗？

不可以！内存由16g变成8g，资源利用率一定会减半吗？不能这样简单计算。理论脱离了实际。

2.3)数量（是可以少给点机器）： 生产环境有30台服务器，硬件配置都是8核16g，给这么多机器要花太多钱了，能不能减配几台啊？

这个是可以的。比如生产环境有30台服务器，性能测试给3-5台是可以的。能给我30台是最好，给不了30台，至少也得给几台啊。

但是只给一台不行。因为要构成一个集群，最少需要2台服务器。

2.4)网络： 网络架构，网络基础，性能测试不能使用无线网络，也不要去使用vpn等桥连，尽可能使用局域网。

比如a和b两个局域网之间不能直接数据交换，需要架一个桥，从一个网络进入另外一个网络。

方式很多，例如vpn。公司的内网连接到公司的生产环境服务器网络中去。

因为无线网络不稳定，带宽不够的时候会导致阻塞和丢包。 除非你要做的是电信网络的测试项目，那就没办法。

不能使用vpn等桥连，是因为在你做性能测试的时候，肯定会通过网络传输大量的数据。因为这些桥连网络目的是保证数据的安全。

在保证数据安全的前提下，可能会牺牲一些速度和稳定性的问题。就很容易随时断网。

性能测试：首先要能搭建测试环境。

防火墙：我们的服务对外能访问的时候，必须在防火墙里面开一个端口出来，我才能通过这个端口来访问这个服务。得会配置这个防火墙。

3.云服务器用的是无线网吗？

绝大多数的企业里用到的服务器都会是云服务器，但云服务器并不是用的无线网络。

你的电脑插上公司的有限网络---连接到园区的交换机---进入电信的交换机---国家的组干网络---云服务器服务提供商对应地区的交换机---再进入地区它所在的网络里面去。

也是通过有限网络，不是通过无线网络。

---

欢迎关注 “清菡软件测试”，进群加v：qhtester，感谢点赞与分享！