1. 什么是性能测试？
1.1 性能的定义
软件的性能是软件的一种非功能特性，他关注的不是软件是否完成特定的功能，而是在完成功能时展现出来的及时性
1.2 性能测试
通过模拟生产运行的业务压力量和使用情况组合，测试系统各项性能指标是否满足需求，也就是特定运行环境下验证
系统处理能力。
性能测试介入时机是在功能测试完成之后。
2. 性能测试类型
性能测试：
性能测试主要有时间性能和空间性能
时间性能主要指软件的一个具体响应时间
空间性能主要指软件运行时所消耗的系统资源
压力测试：
是指不断给被测系统增加压力，直到被测系统压垮为止，用来测试系统所能承受的最大压力
负载测试：
是指被测系统在其能忍受的压力的极限范围内连续运行，来测试系统的稳定性
并发测试：
并发测试通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时
是否存在死锁或其者他性能问题
可靠性测试：
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定
配置测试:
通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统
各项资源的最优分配原则
基准测试：
在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考
稳定性测试：
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定
。
3. 不同视角中的性能测试
3.1 用户角度的性能
用户视角|-还要让我等多久？ --响应时间
|-为什么总是失败？ --稳定性
3.2 开发眼中的性能
开发视角|-架构设计是否合理？ --架构设计
|数据库设计是否合理？ --数据库设计
|代码是否存在性能问题？ --代码
|是否有不合理的线程同步操作？ --代码
|是否有不合理的线程同步操作？ --代码
|是否有不合理的资源竞争？ --代码
|代码算法是否还能进一步提升？ --代码
3.3 管理员眼中的性能
管理视角|服务器资源使用合理吗？ --资源利用率
|数据使用合理吗？ --资源利用率
|系统是否实现扩展？ --可扩展性
|最多支撑多少用户访问？ --系统容量
|最大业务处理量？ --系统容量
系统有哪些潜在的瓶颈？ --可扩展性
|提升系统性能，需要更换哪些设备？ --可扩展性
|能否支持7*24小时的业务访问？ --系统稳定性
3.4测试眼中的性能
测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，
性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面
1、测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。
2、测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，
比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等言方方面面。
4. 性能测试应用场景
4.1 性能测试应用场景（领域）主要有：
能力验证、规划能力、性能调优、缺陷发现、性能基准比较，
下表简单介绍和对比了这几个场景的各自用途和特点：
| 主要用途 | 典型场景 | 特点 | 常用性能测试方法 | |
|---|---|---|---|---|
| 能力验证 | 关注在给定的软硬件条件下，系统能否具有预期的能力表现 | 在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？ | a)要求在已确定的环境下运行 b)需要根据典型场景设计测试方案和用例，包括操作序列和并发用户量，需要明确的性能目标。 | a)负载测试 b)压力测试 c)稳定性能测试 |
| 规划能力 | 关注如何使系统具有我们要求的性能能力 | 某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？ | a) 它是一种探索性的测试 b) 常用于了解系统性能和获得扩展性能的方法 | a) 负载测试 b) 压力测试 c) 配置测试 |
| 性能调优 | 主要用于对系统性能进行调优 | 某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？ | 每次只改变一个配置，切忌无 休止的调优 | a) 并发测试 b) 压力测试 c) 配置测试 |
| 缺陷发现 | 发现缺陷或问题重现、定位手段 | 某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露。 | 做为系统测试的补充，用来发现并发问题，或是对系统已经出现的问题进行重现和定位 | a) 并发测试 b) 压力测试 |
| 性能基准比较 | 常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁。很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标。 |
5.性能测试的术语
5.1 并发用户数
狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；
广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多
5.2 吞吐量
指在一次性能测试过程中网络上传输的数据量的总和，也可以这样说在单次业务中，客户端与服务器端进行的
数据交互总量
对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中，吞吐量是重点关注的指标，
它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值
吞吐量所呈现数据称为吞吐率
5.3 吞吐率
吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，
它是衡量网络性能的重要指标。
通常情况下，吞吐率用“字节数/秒”来衡量，当然，也可以用“请求数/秒”和“页面数/秒”来衡量；
单位时间内系统处理的客户端请求的数量
计算方法：Throughput吞吐率 = (number of requests) 请求数/ (total time)总时间
5.4 响应时间
从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间
计算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（网络时间 + 应用程序处理时间）
5.5 事务
性能测试中，事务指的是从端到端，一个完整的操作过程，比如一次登录、一次筛选条件查询，一次支付等
5.6 TPS
Transaction Per Second：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量
，一般以request/second为单位
5.7 QPS
Query Per Second：
每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率；
TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
5.8 PV
Page View：
页面浏览量，通常是衡量一个页面甚至网站流量的重要指标；
细分的话，有独立访问者数量、重复访问者数量、单独页面访问数量、用户停留时间等类型。
5.9 RT/ART
Response Time/average Response Time：
响应时间/平均响应时间，指一个事务花费多长时间完成；
一般来说，性能测试中平均响应时间更有代表意义。细分的话，还有最小最大响应时间，50%、90%用户响应时间等
5.10 思考时间（Thinking Time)
用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的
5.11 UV
作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）
5.11 点击数：
每秒钟用户向WEB服务器提交的HTTP请求数。
5.12 超时错误率：
主要指事务由于超时或系统内部其它错误导致失败占总事务的比率
5.13 CPU使用率：
指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%；
5.14 内存利用率：
内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%；
5.15 磁盘I/O:
磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，
存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time
（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能；
5.16 网络带宽：
一般使用计数器Bytes Total/sec来度量，其表示为发送和接收字节的速率，包括帧字符在内；判断网络
连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较；
6.性能测试流程
6.1.性能测试流程
需求分析-》测试准备-》测试执行-》结果分析调优-》报告与总结
6.2 需求分析：
性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行
其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。
6.2.1 性能测试的根本原因
1.新系统能力验证
2.客户有明确要求
3.找出系统性能瓶颈
4.稳定性验证（强度测试）
需要分析的系统信息如下（包括但不仅限于如下这些）：
- 需要分析的业务信息如下（包括但不仅限于如下这些）：
6.3 性能测试准备
6.3.1 测试环境准备：
系统运行环境：这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。
执行机环境：这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前准备好执行机环境。
6.3.2 测试场景设计：
根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。
6.3.3性能工具准备：
负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter或galting等
监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。
6.4 测试脚本准备：
如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试。
6.5 测试数据准备：
负载测试数据：并发测试时需要多少数据？比如登录场景？
DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。
6.6 其它：
如果需要其它其它关联系统或专业人士如DBA配合的，也需要提前进行沟通。
7.测试报告与总结
性能测试报告是性能测试的里程碑，通过报告能展示出性能测试的最终成果，展示系统性能是否符合需求，是否有性能隐患。性能测试报告中需要阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。
性能测试工程师完成该次性能测试后，需要将测试结果进行备案，并做为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优方案等。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀。
我是测试的小学生，欢迎一起讨论。文章内容来源于网络和自己的总结。