目录

一、性能测试概述

1.1性能测试的概念

1.1.1性能及性能测试

1.1.2性能测试的目的

1.1.3性能测试与功能测试比较

二、性能测试策略及指标

2.1 性能测试策略（或称分类）

2.2性能测试指标：

三、 性能测试流程

3.1性能测试需求分析

3.2性能测试计划及方案

3.3性能测试用例

3.4性能测试执行

3.5 性能测试报告总结   

---

一、性能测试概述

进行性能测试的原因：

1）业务需求：

        ·大量用户下，系统能否稳定运行；

        ·用于硬件服务器选型

        ·用于软件技术的选型

2）招聘需求

1.1性能测试的概念

1.1.1性能及性能测试

性能：软件质量属性中的“效率”特性，效率特性：时间特性、资源特性。

        ·时间特性：系统处理用户请求的响应时间；

        ·资源特性：系统在运行过程中，系统资源的消耗情况；包括CPU、内存、磁盘IO（磁盘的写入Input和读取Output，简称IO）

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

性能测试软件的范围：后台处理程序（代码）、中间件（应用服务器）、数据库、程序架构等服务器资源的消耗。

1.1.2性能测试的目的

1）评估当前系统的能力：

·如验收第三方提供的软件；

·获取关键的性能指标，与同类型的软件对比（跑分）

2）寻找性能瓶颈：发现性能问题后，寻找性能瓶颈，优化性能（如： 12306春运时服务故障）

3）评估软件是否能满足未来的需要（例如：淘宝双11在2023年的销售额）

1.1.3性能测试与功能测试比较

焦点不一样：

        ·功能：关注系统对用户需求规则的满足程度。关注点（正向、逆向）

        ·性能：关注系统对用户业务场景的满足程度。关注点（时间、资源）

二者关系：在一个项目中，功能测试和性能测试一般都有，功能测试通过后，才进行性能测试。

二、性能测试策略及指标

2.1 性能测试策略（或称分类）

性能测试策略：基准测试、负载测试、稳定性测试、其他：并发测试、压力测试、容量测试 

2.1.1基准测试：

狭义上讲：单个用户进行业务场景测试，并统计性能的各项指标（为后续多用户性能作参考对比）

广义上讲：在某一个时刻进行性能测试建立一个已知的水平，当硬件系统发生变化时再测，观察变化对于性能产生的影响。

2.1.2负载测试：

说明：通过逐步增加系统负载，测试系统性能变化，并最终在满足系统性能指标情况下，系统所能承受的最大负载量的测试。

负载：指向服务器发送的请求数量，请求越多，负载越高。

注意：负载测试关注的重点是逐步增加压力。一般给用户看到的都是最有负载而不是最大负载。

2.1.3稳定性负载：

在服务器稳定（业务正常的负载量）运行的情况下，进行长时间的测试，保证服务器能正常运行。

长时间：一天、一周

2.1.4其他策略：

并发测试：系统在短时间内同时处理大量请求，查看系统的并发处理能力。

压力测试：测试系统在强负载的情况下，测试系统在峰值情况下的操作，是否具有良好的容错能力及错误恢复能力。 

稳定性压力测试：在系统高负载情况（接近C点）下长时间运行（24小时），查看系统处理能力；

破坏性压力测试：在系统极限负载情况下（C-D点），进行压力测试，查看系统容错能力和错误恢复能力。

容量测试：关注系统在极限情况下的各种极限参数值。

2.2性能测试指标：

指标：在性能测试过程中，记录的一系列数据值，用这些实际记录的数据值与需求中的性能要求作对比，达成需求要求则无问题，未达成需求则是性能bug；比如，错误率0.5%。

1）响应时间：客户端发送请求，到服务器收到响应，过程中经历的全部时间，都为响应时间。具体响应时间=应用程序处理时间+网络传输时间；

2）并发数：并发测试的用户数；系统用户数：注册系统的总用户数；在线用户数：某段时间内访问系统的用户数，这些用户并不是同一时间向系统提交要求。并发用户数：某一物理时刻同同时向系统提交请求的用户数。

3）吞吐量（throughput）：吞吐量指的是单位时间内处理客客户端的请求数量，直接体现软件系统的性能承载能力；从一下三方面衡量：

·业务维度：可用“业务数/小时”，“业务数/天数”，“访问人数/天数”，“页面访问量/天数”来衡量。

·网络维度：可以用“字节数/小时”，“字节数/天”衡量网络流量。

·技术维度：可用每秒事务数（TPS）和每秒查询数（QPS）衡量服务器具体性能处理能力。

注：

TPS（Transactions Per Second）：每秒事务数，服务器每秒钟处理事务的请求数量。一个事物通常是界面上的一个操作，一个事务可以包含一个或者多个请求。

QPS（Query Per  Second）：每秒查询数

应用：控制服务器每秒处理指定请求数（如：控制服务器每秒达到60QPS，服务器的性能各项指标是否正常）（衡量web服务器处理能力一个重要指标）

eg：登录操作：发送一个登录请求；登录事务就对应一个接口请求。

支付操作：查询账户余额请求+支付安全校验+支付事务对应了3个接口请求。

对于登录事务而言，当TPS为10时，服务器的QPS也为10；

对于支付事务而言，当TPS为10时，服务器的QPS为30；

4）点击数：衡量Web服务器处理能力的一个重要指标。不是指用户在页面上的一次点击。而是指页面（html代码、图片及js文件等）加载时，向服务器发送请求的数量，可以用每秒的点击数来衡量web服务器的处理能力。

5）错误率：错误率不是指功能有错误或者bug，而是指在系统高负载情况下，业务失败的次数/总业务数*100%，此处的业务指的是同一种业务。稳定性好的系统，其错误率应该由超时引起，即超时率。

6）资源利用率：系统各种资源的使用情况，资源使用总量/总的资源可利用量*100%；

提示：通常没有特殊需求的时：

1）建议CPU不高于80%（±5）；电脑中所有的处理请求（操作系统、软件程序、磁盘拷贝等）都需要经过CPU。

2) 内存不高于80%；所有程序运行时都要消耗空间（存储程序运行的数据）

3）磁盘不高于90%；存储本地数据文件

4）网络不高于80%；影响数据爱网络中的传输速度。

三、 性能测试流程

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

 回顾：功能测试流程

1）需求分析及评审

2）编写测试计划和方案

3）编写测试用例并评审

4）执行测试用例并提交缺陷

5）编写测试报告

3.1性能测试需求分析

1)明确被测系统：熟悉被测系统的业务功能、技术构架

2)明确测试内容：

·从业务角度明确测试内容：确定关键业务，即用户使用频率最高的业务。

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

3)明确性能测试策略：负载测试、稳定性测试、并发测试等；

4)明确性能测试指标：无明确指标时，和类似系统比较，以及未来流量预估；有明确指标时，根据指标与实际结果做比较，不满足时分析改进。

eg：下订单的业务并发20个用户；

平均响应时间要小于等于3s；

事务成功率为100%；

CPU使用率小于等于85%；

3.2性能测试计划及方案

性能测试实施的第一份文档，也是最重要的一份；

主要内容：项目背景、测试目的、测试范围、测试策略、风险控制、交付清单、进度与分工；

3.3性能测试用例

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

用例名称	获取首页数据
用例编号	index001
用例描述	TPS达到100的情况下，进入首页时间不超过5s
前置条件	首页相关的商品数据已经配置完成
用例步骤	动作	期望的性能	...	...
1	进入商城首页	<5s	...	...
2	...	...	...	..
并发用户数与事务响应
并发用户数	事务平均响应时间	事务最大响应时间	TPS	事务成功率
5	...	...	...	...

3.4性能测试执行

·测试脚本编写/录制

性能测试用例编写后需要结合用例，进行脚本编写。

·建立测试环境

进行性能测试之前，要先完成测试环境的搭建工作，测试环境一般包括：软件环境、硬件环境及网络环境。尽可能与用户环境一致。

·执行测试脚本

脚本调试通过后，才能进入正式的压测阶段。

·性能测试监控

监控：CPU、内存、网络、TPS、磁盘IO等；

性能测试监控与测试脚本执行同时进行，而不是脚本运行结束后收集。

·性能分析和调优

测试人员只需要确定性能是否有bug，有责提交报告。问题分析与调优有开发人员来负责。

调优人员（开发、数据库管理员、系统管理员、网络管理员、性能测试分析员）对系统进行调整；

测试人员进行验证，对第二轮、第三轮...的测试，与之前的结果对提从而确定系统是否有提升。

3.5 性能测试报告总结   

性能测试过程记录，发现的问题及分析；

性能测试过程中发现的风险，当前是否存在风险；

给出性能测试的结论（通过/不通过），经验及教训。