性能测试基础
性能测试的目的
发现性能瓶颈,应用系统的短板在哪里,若发现性能问题,
能够分析它是哪个点爆发的。
性能测试的分类
1.负载测试
通过逐步加压的方法,达到既定的性能阈值的目标,
阈值的设定应该小于等于某个值,如CPU使用率小于等于80%。
2.压力测试
通过逐步加压的方法,使得系统的某些资源达到饱和,
甚至失效的状态(中间件,数据库,应用程序等)
3.并发测试
同一个时间内,多个虚拟用户同时访问同一个模块,同一个功能,
通常的测试方法是设置集合点。
4.容量测试
通常是指数据库层面的,目标是获取数据库的最佳容量的能力,具体测试方法为
在一定的并发用户,不同的基础数据量下,观察数据库的处理能力,即获取数据库的
各项性能指标。
5.稳定性测试
又称可靠性测试或疲劳测试,指系统在高压情况下,长时间的运行系统是否文档。
如cpu使用率在80%以上,7*24小时运行,系统是否稳定。
内存泄漏的原因,系统长时间运行,底层垃圾回收不彻底。
6.异常测试
又称失败测试,是指系统架构方面的测试,如在负载均衡架构中,要测试
宕机,节点挂掉等情况系统的反映。
性能测试技能树
性能测试流程
需求分析
熟悉项目是做什么的,用户如何在我们的平台上操作的,哪些是重点,有哪些主要流程
性能指标
定义TPS,吞吐量等这些指标
定义我们所满足的指标
什么样的标准满足我们现阶段的业务需求
开发脚本
场景设置
脚本开发完后一般不能直接用于性能测试,调试脚本,设置场景
和需求分析产生关联,设置的场景要符合用户在我们的平台上使用的流程,
比如用户经常做哪些操作等
监控部署
一个应用软件一般包括自己的应用程序,应用的服务器,数据存储部分,
这些都要把它监控起来,才能发现性能瓶颈
测试执行
怎么跑?第一阶段:基本测试,少量用户跑15分钟,
第一轮发现问题,多并发下,应用程序对多线程的逻辑处理问题,
有时,一个用户操作没问题,
但是当多个用户去操作功能点时,就会发生问题,多并发逻辑问题。
解决第一轮的问题时,进入第二阶段时间长的跑一跑,跑几天
性能分析
它基于监控部署,只有把监控部署完善,无死角监控,它才能更轻松。
无论程序运行在哪,发生了什么问题,都可以看到,性能分析才能有理有据
性能调优
只有把监控部署好,性能分析和性能调优才能更顺利
只看测试工具中的那些报告,这些报告是工具用来收集应用程序和服务器的一些运行状态
这些状态并不全,不能完全胜任眼睛这个角色。
开发在做开发时,在对一个变量和类的声明等等生命周期控制的不严格,发生了内存泄漏,溢出等
测试报告
对于敏捷测试来讲,一般多个迭代版本有不同的性能指标
系统应用分层架构
优点
分层利于分析和定位问题
性能的前期准备工作
监控mysql,监控API层,代码处理速度
mysql和api运行在linux,监控linux服务器的运行状态,承载数据库和代码的运行环境
web层面的监控,图片加载和js加载,首先加载js后加图出现停顿
先加载样式后加载js,如何加载图片不失真等
测试思路
(1)可以一块块测试,首先进行数据库测试,把开发的代码拿过来,把其中和数据库交互的sql语句抽离出来,
(2)然后开发成我们的脚本,对mysql进行性能测试,好处没有其他因素影响,
sql语句调优,myql配置调优,服务器配置调优,缩短了分析范围,性能调优变的容易
如果从web开始测试,要经过web>api>myql然后再返回去
(3)然后再做接口API层,做 并发,如果有问题,代码逻辑问题,并发逻辑等
(4)最后再并发前端,自底向上做测试
性能测试指标
事务
从客户端发起的一个或多个请求,到客户端接收到从服务器返回的响应。
TPS
Transaction Per Second
每秒钟系统能够处理的事务数
请求响应时间
从客户端发起的一个请求开始,到客户端接收到服务器返回的响应,整个过程所消耗的时间。
事务响应时间
事务是有一个或多个请求组成,事务响应时间主要是针对于用户的角度而言,如转账。
并发
没有严格意义上的并发,并发总会有先有后,一般讲的并发是在一个时间内,如1秒。
并发的两种情况
多用户在系统上进行同一操作,比如大家对同一种商品进行秒杀;
多用户在系统上进行不同的操作,比如大家浏览不同的商品。
用户并发数
同一单位时间内,对系统发送请求的用户数量。
吞吐量
一次性能测试过程中网络上传输的数据量的总和。
吞吐率
单位时间内网络上传输的数据量的总和。
点击率
每秒钟用户向服务器提交的请求数。
资源使用率
对不同的系统资源的使用情况,如cpu,内存,io
性能测试需求分析
目的
给性能测试画个圈,明确性能测试重点
明确测试指标
把哪些指标作为重点关注指标,和开发人员约定这些指标是什么意思,避免后期不明确而产生分歧
明确测试场景
跟业务挂钩,比如注册相对于登录重要性低,每个功能点要有多少并发