01.性能测试的理论
1、性能测试的概念
为什么要做性能测试?
进行性能测试:满足真实业务场景、支持大量的用户。满足商用要求
1. 概念
性能:就是软件质量属性中的
效率
特性- 效率特性:
- 时间特性:表示系统处理用户请求的响应时间
- 资源特性:指系统在运行过程中,系统资源的消耗情况(CPU、内存、磁盘IO)
- 效率特性:
什么是性能测试?
概念:使用自动化工具,模拟不同的场景,对软件各项性能指标进行测试和评估的过程就是性能测试。
包含:1. 后台处理程序的性能(代码性能)
2. 中间件、数据库、架构设计等是否存在瓶颈
3. 服务器资源消耗(CPU、内存、磁盘、网络)
- 性能测试的目的
- 评估当前系统能力
- 例如:验收第三方提供的软件
- 例如:获取关键的性能指标,与其他类似产品进行比较
- 寻找性能瓶颈,优化性能
- 评估软件是否能够满足未来的需要
- 评估当前系统能力
2. 性能测试与功能测试
2.1 焦点不一样
功能测试:验证软件系统操作功能是否符合产品功能需求规格,主要焦点在功能(正向、逆向);
性能测试:验证软件系统是否满足业务需求场景,主要焦点是业务场景的满足(时间、资源、正向);
2.2 关系
- 功能测试和性能测试是相辅相成的,对于一款优秀的软件产品来讲,它们是不可减少的2个重要测试环节;
- 注意:一般新项目中,先功能测试通过后,再进行性能测试。
2、性能测试的策略
- 基准测试
- 负载测试
- 稳定性测试
- 其他:并发测试、压力测试、容量测试等
1. 基准测试
狭义上讲:也是单用户测试,测试环境确定以后,对业务模型中的重要业务做单独的测试,获取单用户运行时的各项性能指标。(进行基础的数据采集),单用户测多次
广义上讲:是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平(称为基准线),当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。
基准测试数据的用途:
为多用户并发测试和综合场景测试等性能分析提供参考依据
识别系统或环境的配置变更对性能响应带来的影响
为系统优化前后的性能提升/下降提供参考指标
2. 负载测试
- 说明:通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量的测试。
- 负载:指向服务器发送的请求数量,请求越多,负载越高
- 负载测试关注的重点是逐步增加压力
3. 稳定性测试
稳定性测试是指,在服务器稳定运行(用户正常的业务负载下)的情况下进行长时间测试,并最终保证服务器能满足线上业务需求。时长一般为1天、一周等。
稳定运行时的负载量设置为多少?
例如:前面电梯案例中,实际测试的最大负载为:13人
- 场景1:如果甲方要求用户正常的负载人数为15人,稳定运行的负载量为多少?
- 答:实际性能达不到要求,这时候就要提BUG,进行修复以达到要求性能后再测试
- 场景2:如果甲方要求用户正常的负载人数为10人,稳定运行的负载量为多少?
- 答:稳定运行的负载量为10就可以了
4. 压力测试
为什么要进行压力测试?
- 软件实际使用时,用户量超过预期(系统最大负载量),改如何反应?
- 软件由于意外情况出现问题,多久能恢复
在强负载下的测试,查看系统在峰值情况下是否功能隐患、系统是否具有良好的容错能力和可恢复能力。
两个场景:1、极限负载情况下导致系统崩溃的破坏性压力测试【C-D区间】;2、高负载下的长时间的稳定性压力测试【B-C区间】
5. 并发测试
为什么要进行并发测试?
- 电商系统能抗住双11的考验,能保证在秒杀活动时不出问题吗?
并发测试(绝对并发):是指在极短的时间内,发送多个请求,来验证服务器对并发的处理能力。
如:抢红包、抢购、秒杀活动等。
3、性能测试指标
- 响应时间
- 并发数
- 吞吐量
- 点击数
- 错误率
- 资源利用率
- PV和UV
1. 响应时间
说明:响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的结果,整个过程所耗费的时间。
- 注意:不包括 发送消息时前端页面的处理时间 和 收到消息后前端页面的渲染显示时间
总结:响应时间 = 网络传输时间 + 服务器处理时间
2. 并发数
并发(用户)数:某一时刻同时向服务器发送请求的用户数。
3. 吞吐量
吞吐量:指的是单位时间内处理的客户端请求数量,直接体现软件系统的性能承载能力。
- 从业务角度来看,吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量
- 从网络角度来看,还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量
- 从技术指标来看,可以用每秒事务数(TPS)和每秒查询数(QPS)来衡量服务器具体性能处理能力
- QPS每秒查询数:控制服务器每秒处理的指定请求的数量,不同请求不一样
- TPS每秒事务数:控制服务器每秒处理的事务请求的数量
- 事务:即业务,页面上的一次操作,可能对应一个请求/多个请求
- QPS和TPS有什么关系?
- 一个事务对应一个请求时: TPS = QPS
- 一个事务对应n个请求时: QPS = n * TPS
4. 点击数
指客户端向服务端发送请求时,所有的页面资源元素(如:图片、链接、框架css、js等)的请求总数量。
- 只有web项目才有此指标
- 点击数不是页面上的一次点击
5. 错误率
错误率:指系统在负载情况下,失败业务的概率。错误率=(失败业务数/业务总数)*100%。
- 大多系统都会要求错误率无限接近于0
- 错误率是一个性能指标,不是功能上的随机bug
6. 资源利用率
是指系统各种资源的使用情况,一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
根据经验,资源指标通常要求:
(1)CPU不高于75%-85%
(2)内存不高于80%
(3)磁盘IO(速率)不高于90%
(4)网络(速率)不高于80%
4、性能测试的流程
- 性能测试需求分析:熟悉需求,获取性能需求指标
- 性能测试计划及方案:测什么,谁来测、怎么测
- 性能测试用例:用来验证系统是否符合需求
- 测试脚本编写/录制:建立测试环境、编写测试脚本、性能测试监控、执行测试脚本
- 性能分析和调优:分析性能结果,针对性能bug调优
- 性能测试报告总结
1. 性能测试需求分析
2. 性能测试计划和方案
测什么
项目背景
测试目的
测试范围
谁来测
- 进度与分工
- 交付清单
怎么测
- 测试策略
3. 性能测试用例
4. 性能测试执行
5. 性能分析和调优
说明:性能测试分析人员经过对结果的分析以后,如果不符合性能需求,则会提出性能bug,然后由开发人员进行后续的调优。
提示:
- 调优 – 开发人员为主导,数据库管理员、系统管理员、网络管理员、性能测试分析人员配合进行
- 验证 - 性能测试人员继续进行第二轮、第三轮……的测试,与以前的测试结果进行对比,从而确定经过调整以后系统的性能是否有提升
6. 性能测试报告
测试报告的主要内容:
- 测试工作的经过回顾
- 缺陷分析和调优
- 风险评估
- 性能测试结果
- 测试工作总结与改进