性能测试概述、性能测试策略、性能测试指标、性能测试流程

性能测试概述

1. 为什么要进行性能测试

1.1 业务需求

电商双11活动/微信春晚抢红包/12306春运订票
当前服务器配置是否支持20000人同时使用
技术选型，如编程语言选择Java？Python？PHP？

1.2 招聘需求

面试：会性能测试吗
招聘信息：要求会使用性能测试工具Jmeter、LoadRunner

2. 性能测试的概念

2.1 什么是性能？

性能：就是软件质量属性中的“效率”特性
​
效率特性：
    时间特性：指系统处理用户请求的响应时间
    资源特性：指系统在运行过程中，系统资源的消耗情况
        CPU
        内存
        磁盘IO（磁盘的写入Input和读取Output，简称IO)

2.2 什么是性能测试？

概念：使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程就是性能测试。

1. 后台处理程序的性能（代码性能）
2. 中间件(应用服务器)、数据库、架构设计等是否存在瓶颈
3. 服务器资源消耗（CPU、内存、磁盘、网络）
中间件：是提供系统软件和应用软件之间连接的软件。如：Tomcat、Apache...

2.3 性能测试目的

1. 评估当前系统能力
    - 例如：验收第三方提供的软件
    - 例如：获取关键的性能指标，与其他类似产品进行比较（例如：跑分)
2、发现性能问题后，寻找性能瓶颈，优化性能（例如：12306春运时服务故障）
3、评估软件能否满足未来的性能需要（例如：淘宝11在2020年的销售额）

3. 性能测试与功能测试区别

3.1 焦点不一样

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、资源)；

3.2 关系

功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节;
注意：一般新项目中，先功能测试通过后，再进行性能测试。

性能测试策略

1. 性能测试策略

1.基准测试
2.负载测试
3.稳定性测试
4.其他：并发测试、压力测试、容量测试等

1.1 基准测试

    狭义上讲：也是单用户测试，测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。（进行基础的数据采集）
    
    广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。
​
基准测试数据的用途：
1.为多用户并发测试和综合场景测试等性能分析提供参考依据
2.识别系统或环境的配置变更对性能响应带来的影响
3.为系统优化前后的性能提升/下降提供参考指标

 

1.2 负载测试

说明：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。
​
负载：指向服务器发送的请求数量，请求越多，负载越高
​
注意：负载测试关注的重点是逐步增加压力
​
负载测试目的：
通过负载测试，一般能找到系统的最优负载和最大负载。
最大负载一般项目组内部知晓，不会对外公布。
普通用户看到的系统的最大能力，一般都是测试得到的最优负载。

1.3 稳定性测试

说明：稳定性测试是指，在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试，并最终保证服务器能满足线上业务需求。时长一般为1天、一周等。

1.4 其他测试策略

性能测试中，测试策略其实有很多种，但是掌握基础的用法后，其他不同名称的测试策略只是基础用法的一个变形用法。

并发测试：并发测试是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力。如：抢红包、抢购、秒杀活动等。
    
压力测试：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
​
测试系统在强负载的情况下，测试系统在峰值情况下的操作，是否具有良好的容错能力及错误的恢复能力。
​
稳定性压力测试：在系统高负载的情况下（接近C点），长时间运行（24小时），查看系统的处理能力（如下图）
​
破坏性压力测试：在系统极限负载的情况下（C-D点），对系统进行压力测试，查看系统容错能力和错误恢复能力（如下图）
    
容量测试：关注软件的极限压力下的各个极限参数值，例如：最大TPS，最大连接数，最大并发数，最多数据条数等。

性能测试指标

1. 性能测试指标介绍

1.1 什么是指标

指标：在性能测试的过程中，记录的一系列的数据值。用这些实际记录的数据值与需求中的性能要求做对比，达成需求要求则无问题；未达到需求要求则说明是性能bug。

说明：一些经过运算得出的结果，来衡量某种操作性能统称；比如：错误率 0.5%

1.2 性能指标

1.响应时间
2.并发数
3.吞吐量
4.点击数
5.错误率
6.资源利用率
7.PV和UV

2. 常用性能指标

2.1 响应时间

说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。

组成：响应时间 = 网络时间 + 应用程序处理时间

响应时间 = 应用程序处理时间（A1+A2+A3） + 网络传输时间（N1+N2+N3+N4）

 

2.2 并发数

说明：并发测试的用户数
扩展：
    系统用户数：系统注册的总用户数据
    在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
    并发用户数：某一物理时刻同时向系统提交请求的用户数

 

2.3 吞吐量

吞吐量（Throughput）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力
​
1.从业务角度来看，吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量
​
2.从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量
​
3.从技术指标来看，可以用每秒事务数（TPS）和每秒查询数（QPS）来衡量服务器具体性能处理能力

TPS

Transactions Per Second，每秒事务数 (单位时间内系统处理的客户端请求的事务次数)
服务器每秒钟处理的事务请求数量。
一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求。
​
计算：TPS = 并发数/平均响应时间
​
事务：就是业务请求，对应一个或者多个操作。
如支付请求，包括服务器查询用户余额，支付安全校验等多个操作。 
​
一个业务请求发送给服务器后，最终会定位到服务器对应的业务请求的代码，既有可能是一段代码也有可能是多段代码。
​
TPS归属吞吐量

如上图：
对于登录事务而言，当TPS为10时，服务器的QPS也是10 
对于支付事务而言，当TPS为10时，服务器的QPS就是30

QPS

QPS(Query Per Second)每秒查询数
​
应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒60QPS，服务器的性能各项性能指标是否正常）。 （衡量web服务器处理能力一个重要指标）
​
服务器每秒钟处理的接口请求数量。
（一个服务器中有多个接口，QPS指的是所有接口在同一个单位时间内的接口处理数量之和）

 

2.4 点击数

1.点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向Web服务器发出的请求数量。
​
2.通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
    
注意：只有web项目才有此指标。

2.5 错误率

错误率指系统在负载情况下，失败业务的概率。错误率＝(失败业务数/业务总数)*100%。
​
1.不同系统对错误率要求不同，但一般不超过千分之五；
2.稳定性较好的系统，其错误率应该由超时引起，即为超时率

2.6 资源利用率

是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。

提示：通常，没有特殊需求的话
    1).建议CPU不高于80%(±5)
    2).内存不高于80%
    3).磁盘不高于90%
    4).网络不高于80%

 

性能测试流程

1. 性能测试流程

1.性能测试需求分析
2.性能测试计划及方案
3.性能测试用例
4.测试脚本编写/录制
5.建立测试环境
6.执行测试脚本
7.性能测试监控
8.性能分析和调优
9.性能测试报告总结

1.1 性能需求分析

说明：性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。

性能需求分析的目标：

1.熟悉被测系统
    熟悉被测系统的业务功能
    熟悉被测系统的技术架构

2.明确性能测试内容
    从业务角度明确测试内容
        确定关键业务。即：用户使用频率较高的业务功能
    从技术角度明确测试内容
        如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标
        如：通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标

3.明确性能测试策略
    负载测试 
    稳定性测试
    并发测试

4.明确性能测试的指标
    无明确需求指标
        通过查找相关资料，和类似的系统对比，以及对未来流量的预估，确定性能测试需求的指标
    有明确需求指标
        例如，类似如下指标
            下订单业务并发20个用户
            平均响应时间要小于等于3s 
            事务成功率为100%
            CPU使用率小于等于85%
只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在

1.2 性能测试计划及方案

说明：性能测试实施第一份文档，也是最重要的一份文档。

主要内容：
    1、项目背景 —— 简介
    2、测试目的
    3、测试范围 —— 对于需求分析中的性能测试内容
    4、测试策略 —— 对应于需求分析中的测试策略
    5、风险控制 —— 技术风险、人力风险
    6、交付清单 —— 每个阶段的产出物
    7、进度和分工 —— 谁在什么时候做什么事

1.3性能测试用例

要素：用例标题、用例编号、用例预制条件、用例步骤、用例预期结果、用例实际结果（实际结果：需要监控的各项性能指标）

测试脚本的编写/录制

建立测试环境 ——尽可能与用户的环境一致

执行测试脚本

性能测试监控 —— 与测试脚本执行同时进行

性能分析和调优
        测试人员只需要确定是否存在性能bug，有bug则提缺陷报告
        问题分析和调优由开发人员来完成，测试人员配合验证调优结果（可能需要经过多轮验证）

1.4 测试脚本编写/录制

说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。

提示：录制或编写，根据不同的工具要注意代码冗余。

1.5 建立测试环境

说明：在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境

提示：一般情况下可以要求运维和开发工程师协助完成

1.6 执行测试脚本

说明：先保证脚本调试通过之后，才能进入正式压测阶段

执行测试脚本时，要先进行性能运行场景的设置，再运行脚本

1.7 性能测试监控

性能监控就是监控服务器的各项性能指标。例如：监控CPU、内存、网络、TPS、磁盘IO等

1.8 性能分析和调优

说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。

提示：

1. 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整;

2. 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。

注意:
系统调优由易到难的先后顺序如下：
1.硬件问题
2.网络问题
3.应用服务器、数据库等配置问题
4.源代码、数据库脚本问题
5.系统构架问题

1.9 性能测试报告总结

性能测试总结要包含以下内容：

1. 性能测试需求覆盖情况，测试过程回顾，及测试中出现的问题（如何去分析、调优、解决的）---基本要求

2. 性能测试过程中遇到各类风险是如何控制的; 目前是否还有其他的性能风险存在

3. 经过该项目性能测试后，有那些经验和教训等内容

1、性能测试的过程记录，性能测试发现的问题、分析
2、性能测试过程中的风险，当前是否存在风险
3、给出性能测试结论（通过/不通过），经验和教训