了解性能测试相关指标
软件用着用着就不能用了,一看热搜,发现该软件的服务器崩崩溃了。
测试人员借助性能测试工具,模拟系统在不同场景下,对应的性能指标是否满足需求。
性能测试是在功能测试之后执行的。
相应时间短,资源利用率高,日活跃用户数多,吞吐量大。
DAU:日活跃用户数。
并发要满足大量用户同时访问。
业务层面的并发用户数:指的是同时向服务器发送请求的用户数量。 后端服务器层面的并发用户数:指的是同时向服务器发送请求的请求数量。
后端服务器层面的并发用户数 >= 业务层面的并发用户数
数量 系统用户数 > 在线用户数 > 并发用户数
用户响应时间:发出请求开始,到客户端接收完所有的字节数据所消耗的时间 N1+A1+N2+A2+N3+A3+N4
请求响应时间:服务器收到请求发出相应这段时间是请求响应时间。A1+N2+A2+N3+A3
影响一个软件的响应时间因素有那些?
用户设备,网络带宽,服务器的配置(CPU,内存),软件算法逻辑,数据库性能
数据库的事务就是把多个操作打包到一起,构成原子操作。
性能测试中,事务指的是指一组密切相关的子操作的组合 ,比如一次登录、一次筛选条件查询,一次支付等;
TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。这个指标衡量了系统在同一时间内处理业务的最大能力。 当压力加大时,TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化,对于同一系统会存在一个最大处理事务能力,它并不随着并发用户的增减而改变。
点击量:用户点击发送的http请求数,并不能衡量软件性能
点击率:点击量/时间
每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大,服务器压力越大。这里的点击并不是鼠标的一次点击,一次点击可能有多次HTTP请求。
吞吐量:用户一次请求和服务器之间的数据交互量。并不能衡量软件性能
吞吐率:吞吐量/时间。吞吐率越高软件性能越好
用户在对软件进行操作的时候,每一个操作中间的时间间隔。
不同系统资源的使用情况。包含CPU,内存,硬盘,网络等。
面试题:了解性能测试,那么你给我说一下你做性能测试的时候,你关注哪些指标?
定义:让系统在正常情况下运行,观察性能指标。建立一个性能基准,作为以后性能测试的参考。
应用场景:软件刚上线需要对性能进行摸底,软件进行升级后,性能测试的参考,衡量软件是变好了还是变坏了。
验证软件在一定的压力情况下运行,观察性能指标是否出现拐点。
系统处于临界饱和的情况下,观察系统性能指标。(往往会把系统搞崩溃)
验证系统在一个持续的时间段内运行,在这个运行时间段内,观察系统各项性能指标是否正常。
持续1day -> 持续运行一周 -> 持续运行1个月 -> 一个季度 -> 一年
如果持续一天没问题就持续一周,如果持续一周没问题就持续一个月……
可靠性就是可用性,正常使用时间的占比。可靠性 = 正常运行时间/(正常运行时间+非正常运行时间)* 100*%*可用性指标一般要求达到4个或5个“9”,即99.99%或者99.999% 。
如果可用性达到99.99%,对于一个全年不间断(7*24的方式)运行的系统,意味着全年(252600min)不能
正常工作的时间只有52min,不到一个小时。
如果可用性达到99.999%,意味着全年不能正常工作的时间只有5min 。
可靠性测试靠人为是达不到要求的,需要借助工具比如(loadrunner)
造成可靠性降低的原因:软件硬件出现问题,网络故障出现问题,自然灾害导致服务器损坏出现问题,停电。
功能测试的执行流程:需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估(发布测试报告)→ 上线
性能测试的执行流程:需求分析→测试计划→选择一款性能测试工具→性能测试脚本编写→执行性能测试脚本→产生性能测试报告
性能测试中出现了不符合预期的情况,我们不叫做BUG,叫做性能瓶颈
在性能测试中,出现了性能瓶颈,开发修复的过程叫做优化