每个人眼里对性能理解不一样,但是我们如果从一个App的维度来看:
用户眼中的性能:
1、App使用崩溃,卡顿,延迟
2、App反应慢,使用页面无反应
那开发眼中的性能:
1、数据库设计是否合理
2、代码逻辑、算法是否可以优化
运维眼中的性能:
1、服务器资源使用是否合理
2、服务是否需要拓展
那我们测试眼中的性能是什么?
测试的任务是保证质量,所以咱们测试考虑性能应该上述都要考虑
定义:性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。加上性能分析调优
简单来说,自动化的测试工具就是我们用各种工具,比如JMeter 、LoadRunner...
正常、峰值以及异常负载条件就是我们的一系列方法,可以分为性能测试的分类
负载测试 | 通过逐步加压的方法,找到预期性能指标,确定系统所能承载的饱和状态,如90%的用户响应时间不超过5s,cpu使用率不超过70%,是我们常用的一种测试 |
---|---|
压力测试 | 与负载测试一样,压力测试也是同样逐步加压的方法,与负载测试不同的是,压力测试没有具体的性能指标,目的就是看什么条件下可以把系统压崩溃 |
并发测试 | 同一个时间内,多个虚拟用户同时访问同一个模块、同一功能,测试是否有性能问题 |
容量测试 | 是指数据库层面的,目标是获取数据库的最佳容量的能力,具体方式是在一定并发用户,不同的基础数据量下,查看数据库的处理能力,获取数据库的性能指标 |
可靠性测试 | 也叫稳定性测试或疲劳测试。指系统在高压情况下,长时间的运行系统是否稳定,如cpu使用率在70%以上,运行7*24小时,系统是否稳定 |
异常测试 | 也叫失败测试,系统架构方面的测试,如果在负载均衡架构中,要测试宕机、节点挂掉等情况系统的情况 |
出几道测试题,判断下是哪种测试:
1、用户上传10M以内的文件,响应时间不能超过3s
2、双十一期间,购物App是否可以承受大量用户使用功能
3、高并发下,系统运行24小时,系统是否稳定
4、对登录接口进行阶梯型性能压测,看最大的并发量是多少
验证是否达到预期性能指标,找出性能瓶颈
1.需求分析,制定指标
很多人觉得这一步很琐碎,其实很关键的,我们做功能测试的时候都需要知道预期结果,所以在性能测试中不能直接开干,也得需要分析,确认好指标
2.脚本开发,场景设置
这块包括一些准备工作,包括硬件、网络、操作系统,中间件,数据库、测试数据,监控工具等。 然后录制、开发、优化脚本
3.场景设置,监控部署好,执行测试
根据已经设计好的场景执行脚本,记录测试结果,根据监控得出各个性能指标
4.性能分析、性能调优 对性能进行分析,如果性能有问题,进行调优
5.再次执行测试,性能分析。性能报告
调优后再次执行测试,看我们的调优是否符合,是否成功,没啥问题,得出测试报告
小问题:
1、在我们做性能测试前,我们必须先确认什么?
2、我们怎么知道性能是否有问题?
3、性能监控有什么作用?
有三个比较重要的场景:基准场景、单接口负载场景、混合场景负载场景
1、基准场景
指单线程或者少量线程下对单接口进行测试,测试结果作为基准数据
目的:
验证测试脚本及测试参数的正确性,同时也可以验证脚本数据是否能够支持重复性测试等;
通过少量线程访问系统获取结果数据,作为对比参考基准;
根据测试结果,初步判断可能成为系统瓶颈的场景,并决定是否进行后续的测试;
2、单接口负载场景
指通过模拟多线程对单接口进行负载测试
选用线程数,逐步加压,得出相应的指标
3、混合场景负载测试
指的是增加线程数找出多个接口 TPS 的和对应的峰值
比如有人在浏览榜单,有人在抽奖,是最模拟真实环境下用户访问情况,多用户同时访问系统会调用系统各个接口,对各个系统产生并发压力
4、稳定性测试
系统在高压情况下,长时间的运行系统是否稳定,如cpu使用率在70%以上,运行7*24小时,系统是否稳定
5、异常测试
系统架构方面的测试,如果在负载均衡架构中,要测试宕机、节点挂掉等情况系统的情况
小问题:以用户登录、抽奖、奖励查询操作,按照上述测试场景来设计实际场景
序号 | 业务 | 场景 | 场景类型 |
---|---|---|---|
1 | 登录 | 单接口,单用户并发压测 | 基准场景 |
2 | 抽奖 | 单接口,单用户并发压测 | 基准场景 |
3 | 奖励查询 | 单接口,单用户并发压测 | 基准场景 |
4 | 登录 | 单接口,梯度递增线程并发测试 | 单接口负载场景 |
5 | 抽奖 | 单接口,梯度递增线程并发测试 | 单接口负载场景 |
6 | 奖励查询 | 单接口,梯度递增线程并发测试 | 单接口负载场景 |
7 | 登录-抽奖-奖励查询 | 多接口,梯度递增线程并发测试 | 混合场景负载测试 |
8 | 登录-抽奖-奖励查询 | 多接口,性能瓶颈下80%以内的线程下,稳定并发24小时,系统稳定情况 | 混合场景负载测试 |
9 | 登录-抽奖-奖励查询 | CPU占有80%情况下,多接口的响应情况 | 异常测试 |
1、系统性能指标
事务:客户端发起的一个或多个请求(请求组成一个完整的操作),客户端接受从服务端返回的响应
比如:银行转账,银行1给银行2转账发起请求,银行2返回转账成功,银行2账户加钱,银行1收到成功返回,银行1账户扣钱,这一整个过程算一个事务
响应时间:
并发:
吞吐量:
TPS/QPS:
1、tps和吞吐量的区别? tps是网络协议层的指标,指每秒钟处理的事务数。吞吐量是数据层的指标,指单位时间内系统成功传输的数据量,在很多时候,我们把tps当成性能监控数据,因为tps高的则吞吐量就会高
2、tps和qps的区别? tps是每秒处理事务数,qps是每秒查询率。qps基本类似于tps,不同的是每访问一个页面(一个过程),会形成一个TPS,但是一次页面请求,可能会对服务器多次请求(资源、图片),这多次请求可以计入QPS。 比如,对一个接口压测,接口内部不再请求其他接口,那么tps = qps 简单来说,t可以是一个接口,也可以是一个业务的流程
2、系统资源指标
cpu
内存
IO磁盘
系统的架构分层各不相同,但是对于我们来说,只需要关注上述三层即可,我们必须要先了解系统的分层架构,才能分块排查问题,不至于分析调优的时候不知道如何下手
那如果我们不知道如何下手的情况下,可以从底层到最外层的顺序排查。首先进行数据库测试,有问题就sql调优或数据库配置调优。数据库测好了,测api层,以此类推