web性能测试面试核心技术（一）

通用的概念

为什么要做性能测试

主要为了验证以下几点：
带宽够用不
CPU够用不
内存够用不
硬盘速度是否跟的上
数据库的容量、读写速度是否合理
系统稳定不
响应时间快不快

web性能测试的类型

web性能测试主要分为以下四类：

1. 负载测试 Load Testing
2. 压力测试 Stress Testing
3. 容量测试 Volume Testing
4. 疲劳强度测试（稳定性测试）
5. 异常情况测试：在一定压力下，产生异常时的场景

web性能测试的关注点

测试类型	关注点
基准测试	是一种具体的测试方法：验证性能测试脚本的稳定性，为后续的性能测试提供参考指标
负载测试	用户数量，性能指标
压力测试	系统高压力下是怎么崩溃的，提出预案
容量测试	系统最大的支撑数量：并发用户数、数据库最大数据量
疲劳强度测试	系统在长时间运行情况下性能指标的变化：是否出现事物处理失败、响应时间增长、业务吞吐率降低、CPU/内存资源增长

web性能测试的核心概念

1. 响应时间：Response Time
2. 吞吐量、吞吐率：即系统的IO，在性能测试中需要细致明确为硬盘IO、网络IO、CPU内存、请求处理能力、打开页面数量等指标
3. 事物处理能力：TPS、TPM、TPH分别表示系统在每秒、每分、每小时的事物处理能力，事物的概念不是固定的，测试时可以灵活定义。例如：

打开登陆页面
登陆
发帖
淘宝实现一笔网购
以上单个用户行为都可以定义为事物，也可以把几个用户行为统一联合起来定义为一个事物。

性能测试的价值

性能测试的价值和功能测试有所不同，但是也有关联。
web测试中的用户容忍时间有三个参考值：2-5-10

响应时间	用户感受
2s	流畅
5s	比较流畅，期待优化
10s	勉强接受，下次不想用了

为了保证用户的感受是舒坦的，需要关注以下几个方面：

1. 响应时间，服务器端的处理速度–越快用户的体验越好
2. 服务器端的资源使用情况
3. 数据库端的资源使用情况
4. 系统的最大访问用户数量
5. 系统最大业务处理数量
6. 考察系统能否支撑7*24小时运转
7. 内存资源，线程资源能否正常回收
8. 代码：算法、SQL语句
9. 稳定性，恢复性

性能测试核心原理

1. 基于协议：网络分布式架构–网络协议
2. 多线程：模拟用户负载
3. 模拟真实场景

性能测试工具

性能测试工具有很多，千万不要迷恋某一款工具，所有的工具只能帮我们解决1/3的问题，剩下的问题还是需要我们自己活学活用去解决。

特性	LoadRunner	Jmeter	Locust
是否开源	商业收费	开源｜开源
开发语言	C/Java	Java	Python
测试脚本形式	C/Java	GUI	Python
并发机制	进程/线程	线程	协程
单机并发能力	低	低	高
分布式压力	支持	支持	支持
资源监控	支持	不支持	不支持
报告与分析	完善	简单图表	简单图表
支持二次开发	不支持	支持	支持

• Loadrunner| 使用9.5版本最稳定，使用时要允许杀毒软件，付费软件需要破解
• 这里提到了进程、线程、协程，那么这些概念具体是指什么呢？

性能测试的手段

性能测试手段的重点：

加压策略
不同类型的性能测试，本质的区别还是加压的策略，采用哪种加压策略取决于我们测试的目的是什么，即希望通过性能测试发现什么问题。

性能瓶颈定位的核心

性能瓶颈定位的重点在于性能指标的监控和分析。
从维度上性能的指标分为两大类：业务性能指标和资源性能指标

• 业务性能指标
  并发用户数
  事物吞吐率（TPS/RPS）
  事物平均响应时间
  事物成功率
• 系统资源性能指标
  服务器：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况；
  数据库：数据库连接数、数据库读写响应市场、数据库读写吞吐量；
  网络：网络吞吐量、网络带宽、网络缓冲池大小
  缓存（redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
  测试设备（压力发生器）：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况；

性能测试工具的基本组成

市面上有许多性能测试工具，但是不管哪种工具，基本都包含以下几个核心模块：

• 压力生成器 virtual user generator
• 结果采集器 result collector
• 负载控制器 controller
• 系统资源监控器 monitor
• 结果分析器 analysis

压力发生器又是性能测试工具最核心的部分，它主要有两个功能，一是真实模拟用户操作，二是模拟有效并发。

模拟真实用户操作：

如果熟悉浏览器的工作原理，就会知道浏览器在加载网页的时候，是同时并发多个TCP连接去请求页面对应的HTTP资源，包括HTML、JS、图片、CSS，当前流行的浏览器普遍会并发6-10个连接。然而，性能测试工具在模拟单个用户操作的时候，基本上都是单连接串行加载页面资源。产生的差异在于，假如页面有100个资源，每个HTTP请求的响应时间约为100毫秒，那么浏览器采用6个连接并行加载网页时大概会需要1.7秒（100/6100毫秒），而测试工具采用单连接串行加载就需要10秒（100100毫秒），两者结果相差十分巨大。这也解释了为什么有时候我们通过性能测试工具测试得到的响应时间挺长，但是手动用浏览器加载网页时感觉挺快的原因。

有效并发：

什么叫有效并发？有效并发就是我们在测试工具中设置了1000虚拟用户数，实际在服务器端就能产生1000并发压力。然而现实情况是，很多时候由于测试设备自身出现了性能瓶颈，压力发生器产生的并发压力远小于设定值，并且通常测试工具也不会将该问题暴露给测试人员；如果测试人员忽略了这个问题，以为测试得到的结果就是在设定并发压力下的结果，那么最终分析得出的结论也就跟实际情况大相径庭了。不过，我们可以通过保障测试环境不存在瓶颈，使得实际生成的并发压力尽可能地与设定值一致；另一方面，我们也可以通过在测试过程中监控Web层（例如Nginx）的连接数和请求数，查看实际达到服务器端的并发数是否跟我们的设定值一致，以此来反推压力发生器的压力是否有效。

了解这些缺陷的意义在于，我们可以更清楚测试工具的原理，从而更准确地理解测试结果的真实含义。