目录
八、今日学习思维导图
一、为什么要进行性能测试
业务需求
1).具体业务性能需求指标
2).用于技术选型
3).用于硬件服务器选型
二、什么是性能测试
2.1.概念
测试软件的性能
2.2.测试哪几个方面
1).后端处理性能-响应时间
2).服务器硬件资源（cpu、内存、磁盘）
3).中间件。网络、数据库、架构设计等是否存在瓶颈
三、性能测试目的
3.1.评估当前系统能力---发布时（简而言之，就是跑分）
3.2.寻找性能瓶颈，优化性能---线上出问题，定位问题时使用
3.3.预估未来的性能
四、性能测试与功能测试区别
4.1.关注点
1).功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要关注点在功能（正向、逆向）
2).性能测试：验证软件系统是否满足业务需求场景，主要关注点是业务场景的满足（时间、空间）
2.1).时间：软件的响应时间..
2.2).空间：服务器的磁盘使用率、CPU使用率、内存空闲率..
4.2.关系
1).功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节
2).功能测试的后期（功能稳定后）才会进行性能测试
五、性能测试分类
5.1.常用分类
1).负载测试
1.1).说明：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。(负载：向服务器发送请求)
1.2).目的：找到系统能承受的最优负载量
2).压力测试
2.1).说明：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于【失效】状态。
2.2).目的：找到系统所能承受的极限负载量
3).并发测试
说明：通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在问题。
4).稳定性测试
4.1).说明：通过给系统加载一定的业务压力（如CPU资源在70%~90%的使用率）的情况下，运行一段时间，检查系统是否稳定。
4.2).提示：通常稳定性测试，我们测试一段时间即可：（如：24小时、3x24小时或7×24小时来模拟长时间运行)
5.2.提示
以上负载测试、压力测试、并发测试执执行前都要采取策略(性能基准指标测试)
5.3.策略-性能基准指标测试
说明：评估系统一个基准性能指标，作为后续性能测试的参照。
六、性能测试指标
6.1.概念
一些经过运算得出的结果，来衡量某种操作性能统称：比如：错误率0.5%
6.2.常用指标
1).吞吐量
1.1).说明
1.吞吐量（Throughput）：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。
2.通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。
1.2).常见的吞吐量衡量方式
1.从业务角度来看，吞吐量也可以用"业务数/小时”、“业务数/天”、“访间人数/天”、“页面访间量/天”来衡量。
2.从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量
3.每秒事务数（TPS）和每秒查询数（QPS）归属吞吐量，区别在于TPS\QPS描述服务器具体性能处理能力
2).并发数
2.1).说明：并发测试的用户数
2.2).扩展
1.并发用户数：某一物理时刻同时向服务器发送请求的用户数
2.在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
3.系统用户数：系统注册的总用户数据
2.3).并发补充
1.相对并发：同一时刻同时访问同一个应用
2.绝对并发：同一时刻同时访问同一个操作
3).响应时间
3.1).说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程所耗费的时间
3.2).组成：响应时间=（N1+N2+N3+N4）+（A1+A2+A3)，即：（网络时间+应用程序处理时间)
4).点击数
4.1).说明：点击数是衡量Web服务器处理能力的一个重要指标
4.2).提示
1.点击数不是通常一般人认为的访问一个页面就是1次点击数
2.点击数是该页面包含的元素（如：图片、链接、框架等）向Web服务器发出的请求数数量
3.通常我们也用每秒点击次数（HitsperSecond）指标来衡量Web服务器的处理能力
5).资源利用率
5.1).说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量x100%”形成资源利用率的数据
5.2).提示：通常，没有特殊需求的话
1.建议CPU不高于80%：(±5)
2.内存不高于80%；
3.磁盘不高于90%；
6).错误率
6.1).说明：错误率指系统在负载情况下，失败交易的概率。错误率=(失败交易数/交易总数）*100%
6.2).提示
1.不同系统对错误率要求不同，但一般不超过千分之五；
2.稳定性较好的系统，其错误率应该由超时引起，即为超时率。
7).TPS
7.1).说明：TransactionsPerSecond，每秒事务数（单位时间内系统处理的客户端请求的事务次数)
7.2).计算：tps=并发数/平均响应时间
7.3).事务
1.用户角度，指的是业务，可以包括完成业务功能的一个或者多个操作
2.业务站在代码角度的统称，可以理解为一段或多段代码。
7.4).提示：TPS归属吞吐量
8).QPS
8.1).说明：QPS：QueryPerSecond每秒查询数（衡量web服务器处理能力一个重要指标）
8.2).应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒60QPS，服务器的性能各项性能指标是否正常）。
七、性能测试流程
7.1.性能测试需求分析
1).说明：性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。
2).性能需求分析的目标
3).要求
3.1).熟悉被测系统
1.熟悉被测系统的业务功能
2.熟悉被测系统的技术架构
3.2).明确性能测试内容
1.业务角度明确测试内容
(1)确定关键业务。即：用户使用频率较高的业务功能
2.从技术角度明确测试内容
(1).如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标
(2).如：通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标
3.3).明确性能测试策略
1.负载测试
2.压力测试
3.稳定性测试
4.并发测试
3.4).明确性能测试的指标
1.无明确需求指标
(1).通过查找相关资料
(2).和类似的系统对比
(3).以及对未来流量的预估，确定性能测试需求的指标
2.有明确需求指标
(1).例如，类似如下指标
1).下订单业务并发20个用户
2).平均响应时间要小于等于35
3).事务成功率为100%
4).CPU使用率小于等于85%
(2).只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在
7.2.性能测试计划
1).说明：性能测试实施第一份文档，也是最重要的一份文档。
2).主要内容
2.1).项目背景
2.2).测试目标
确定此次性能测试的目标
2.3).人员安排
明确性能测试的时间，计划需要多少人来进行测试
2.4).时间进度
2.5).性能测试环境
1.系统架构
2.软硬件配置
3.测试数据
4.原则：尽量与生产环境保持一致
2.6).测试工具
性能测试工具、监控工具等
2.7).测试策略
1.确定性能测试类型
(1).负载测试
(2).压力测试
(3).稳定性测试
(4).并发测试
2.确定性能测试场景
(1).单一场景
服务器同一时刻只进行同一业务操作。如抢红包
(2).混合场景
服务器同一时刻处理多个不同业务操作。如网上商城搜索商品、加入购物车、下订单、支付等
2.8).风险控制
7.3.性能测试用例
1).说明：用例应能覆盖到测试需求
2).主要包括
2.1).测试步骤
2.2).并发数
2.3).目标值
2.4).场景策略
7.4.测试脚本编写/录制
1).说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
2).提示：录制或编写，根据不同的工具要注意代码余。
7.5.搭建场景
1).说明：测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来。
2).提示
2.1).虚拟用户数量及启动虚拟用户方式
2.2).场景的相关设置 (如：集合点)
2.3).脚本是否存在依赖关系 (登录与注册)
7.6.运行脚本
1).说明：运行脚本就是运行场景
2).注意
2.1).负载的测试机不能够运行设定的虚拟用户数；
2.2).没有“预热”过程；
2.3).没有模拟用户的真实环境：
2.4).性能用例运行次数过少
7.7.系统性能调优
1).说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
2).提示
2.1).调优人员（开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员）相关人员对系统进行调整；
2.2).验证-性能测试人员继续进行第二轮、第三轮.的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。
3).注意
系统调优由易到难的先后顺序如下：
1.硬件问题
2.网络问题
3.应用服务器，数据库等配置问题
4.源代码、数据库脚本问题
5.系统架构问题
7.8.性能测试报告总结
说明：性能测试总结要包含以下内容
1).性能测试需求覆盖情况，性能测试过程中出现的问题，如何去分析、调优、解决的
2).测试人员、进度控制与实际执行偏差和性能测试过程中遇到各类风险是如何控制的
3).经过该项目性能测试后，有那些经验和教训等内容
7.9.提示
据不同的性能测试工具以上流程会有稍微差别，但主要流程是不变的。
八、今日学习思维导图
1159
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
