软件性能测试

1 软件性能定义
性能是一种指标,表明软件系统或构件对于其及时性要求的符合程度;其次,性能是软件产品的一种特性,可以用时间来度量。性能的及时性用响应时间或者吞吐量来衡量。而响应时间是对请求做出响应所需要的时间。
1.1 用户角度
比如一个典型的Web应用:
用户关注的是软件对用户操作的响应时间。此响应时间=呈现时间+系统响应时间。
1.2 管理员角度
关注系统的响应时间。对于系统管理员来说,用户客户端所消耗的时间是不考虑的。重点就考虑系统响应时间,包括网络耗时、各服务器耗时等。
还会关注系统状态,比如资源利用率、系统可扩展性、系统容量、系统稳定性。
1.3 开发角度
关注于如何通过调整设计和代码实现,或是如何通过调整系统设置等方法提高软件的性能表现。和如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷。
会从系统架构、数据库设计、代码质量等方面考虑性能。
2 软件性能的主要术语
d1秒2.1 响应时间
对请求做出响应所需要的时间。响应时间=呈现时间+系统响应时间。
呈现时间:取决于数据在被客户端收到响应数据后呈现页面所消耗的时间。
系统响应时间:应用系统从请求发出开始到客户端接收到数据所消耗的时间。
从设计角度考虑,更好的用户体验是,前端在等待数据结果时,提供进度条或逐步显示数据。
进一步分解响应时间:网络传输时间+应用延迟时间(Web服务器延迟时间+DB延迟时间)。
对于响应时间,其标准不一。一般页面的响应时间,2秒是非常有吸引力,5秒是比较不错的,10秒则是忍受的极限。视具体情况具体设置。
2.2 并发用户数
系统并发用户数:同一时间内访问系统的用户数。针对的是服务器最大承载量。关注的是瞬间最大访问量。
业务并发用户数:从用户角度来说,在相当长的一段时间内,都会有基本固定数量的用户访问系统。
系统用户数:使用该系统的用户总数。
在线用户数:同时在线的用户数。
在做并发测试的时候,一般会采取两种方法:
一是在并发数一定的情况下,按业务不同进行测试(业务一,多少人一起使用,什么时候开始使用,使用多长时间)。这种方式更多的是业务并发测试。
二是在并发数一定的情况下,只做单纯一样的操作(查询、修改、添加、删除)。这种方式更多的是系统并发测试。
ei硅钢片估算并发用户的公式:
    C=nL/T
    其中:C为平均并发用户数;n为login session的数量;L为login session的平均时间长度;T为考察的时间段长度。
峰值并发数:   
m=C+3*
假设login session符合泊松分布。
比如:OA系统,共3000个用户,每天大约有400个用户访问,对一个用户来说,每天在线时间为4小时,而每天工作时间为8小时。则平均的并发用户为C=400*4/8=200,并发用户峰值为242。
实际应用过程中,要考虑时间的细粒度或结合业务峰值和谷值来更精确的估算并发用户。
更一般的公式是:C=n/10,即以每天访问系统用户数的10%作为平均的并发用户数
                Cm=r*C  r为调整因子,取值一般为2~3
对web服务器的日志分析,能得到更为精确的最大并发用户访问数。
2.3 吞吐量
单位时间内系统处理的客户请求的数量。体现软件系统的性能承载能力。
一般描述:请求数/秒或页面数/秒。
业务角度来说,访问人数/天或处理的业务数/小时。
网络角度:字节数/天==网络流量。
作用:
1、用于协助设计性能测试场景,以及衡量性能测试场景是否达到了预期的设计目标;
电热器是利用2、用于协助分析性能瓶颈。比如以字节数/秒主要反映受网络基础设施、服务器架构、应用服务器制约;以单击数/秒表示主要受应用服务器和应用代码的制约。
在未遇到性能瓶颈时,计算公式:
F=Nvu*R/T。
Nvu表示虚拟用户的个数(Virtual Users);R表示每个VU发出的请求(单击)数量;T表示测试时间。
2.4 性能计数器
Counter。描述服务器或操作系统性能的一些数据指标。温湿度控制系统
资源利用率:系统各种资源的使用状况。
2.5 思考时间
Think Time:从业务角度来说,指用户在进行操作时,每个请求之间的间隔时间。
思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。
计算公式:
内孔撑圆涨紧夹具R=T/Tt
R:每个用户发出的请求数;T为测试时间;Tt为思考时间。
计算思考时间的一般步骤:
1、 首先计算出系统的并发用户数;
2、 统计出系统平均的吞吐量
3、 统计出平均每个用户发出的请求数量
4、 根据上面公式计算出思考时间。
三合一打印机如果测试目的是为了验证应用系统具有预期的能力,即能力验证,则尽量模拟用户真实的思考时间;如果是更一般的研究,了解系统在压力下的性能水平或了解系统承受压力的能力,即规划能力,则可考虑0思考时间。
3 软件性能测试方法论
3.1 SEI负载测试计划过程
关注于负责测试计划,目标产生“清晰、易理解、可验证的负载测试计划”。
关注:目标、用户、用例、生产环境、测试环境和测试场景。
3.2 RBI方法
Rapid Bottleneck Idenfity.快速识别系统性能瓶颈的方法。基于:发现80%系统的性能瓶颈都由吞吐量制约;并发数和吞吐量瓶颈之间存在一定的关联;采用吞吐量测试可以更快速定位问题。
首先访问“小页面”或“简单应用”,从应用服务其、网络等基础的层次上了解系统吞吐量表现;其次选择不同的场景,设定不同的并发用户数,使其吞吐量保持基本一致的增长趋势,并通过不断增加并发用户数和吞吐量,观察系统的性能表现。
3.3 性能下降曲线分析法
性能下降曲线分析法:通过性能曲线上的单用户区,性能平坦区,压力区域以及性能拐点几个关键因素来分析性能瓶颈问题。
从上图可以看到,发布博文事务曲线非常平滑,最大响应时间为0.999秒,是属于非常好的现象,其它事务随着负载用户数量的增大,出现相应的波动,从而可以分析性能问题所在。从图中可以看到,一条曲线可以分为以下几个部分:
(1)性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。
(2)压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。
(3)性能拐点——性能开始“急剧下降”的点。
这几个区域实际上明确标识了系统性能最优秀的区间,系统性能开始变坏的区间,以及系统性能出现急剧下降的点。对性能测试来说,到这些区间和拐点,也就可以到性能瓶颈产生的地方。因此,对性能下降曲线分析法来说,主要关注的是性能下降曲线上的各个区间和相应的拐点,通过识别不同的区间和拐点,从而为性能瓶颈识别和性能调优提供依据。

本文发布于:2024-09-23 15:22:27,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/2/223671.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:性能   系统   时间   用户   响应   并发
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议