通常来说,性能首先是一种指标,表明软件系统或构件对其即时性要求的符合程度;其次是软件产品的的一种特性,可以用时间来进行衡量。性能的及时性用响应时间或吞吐量来衡量。响应时间是对请求做出的响应所需要的时间。
通常,对软件的关注是多个层面的。如果按使用者划分为:用户、管理员和产品的开发人员。于此还有一个重要的是Web的前端性能。
从用户的角度来说,软件性能就是软件对用户操作的响应时间。
从管理员的角度来看,软件系统的性能首先表现在系统的响应时间上,其次管理员还想要知道系统具有多大的可扩展性、处理并发的能力如何、系统可能的最大容量是什么、系统可能的性能瓶颈在哪里、通过更换设备或进行哪些扩展能够提高系统性能、系统在长时间的运行中是否足够稳定、是否能够不间断地提供业务服务等。管理员关注的部分性能如表1-1所示:
表1-1管理员关注的部分性能相关问题
从开发人员的角度来说,主要关心用户感受----响应时间;其次,系统的扩展性等管理员关系的内容。图表1-2开发人员关注的部分性能问题:
表1-2开发人员关注的部分性能问题
Web前端性能考察的主要是浏览器的展现和脚本执行时间,通常对前端性能的关注主要在浏览器展现页面的方式、浏览器各种执行机制的合理应用及脚本的合理性。如何提高浏览器下载和执行资源的并发性,如何让浏览器尽快渲染页面,如何让浏览器尽可能充分利用缓存等问题是前端性能关注的重点。
响应时间是“对请求做出响应所需要的时间”,而且,通常把响应时间作为用户时间软件性能的主要体现。
在实际的性能测试过程中,测试人员一般比较关心业务并发用户数,也就是从业务的角度关注究竟应该设置多少并发用户数比较合理,因此性能测试中直接将业务并发用户数称为并发用户数。下面给出一些用于估算并发用户数的公式:
在公式(1)中,C是指平均的并发用户数;n是登录 session的数量;L是登录 session的平均时间长度;T指考察的时间段长度。例如,对一个典型的OA应用,考察的时间段长度应该为8h的工作时间。
在公式(2)则给出了并发用户数峰值的计算方式,其中,Ĉ指并发用户数的峰值;C是公式(1)中得到的平均并发用户数。
实例:假设一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一只只在8h内使用该系统,且登录到退出该系统的平均时间为4h。根据公式(1)和公式(2):可以得到:
C=400X4/8=200; Ĉ≈200+3X=242
指单位时间内系统处理用户的请求数
从业务角度看,吞吐量可以用:请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量;从网络角度看,吞吐量可以用:字节/秒来衡量;对于交互式应用来说,吞吐量指标反映的是服务器承受的压力,他能够说明系统的负载能力,以不同方式表达的吞吐量可以说明不同层次的问题,例如,以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈;已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候,吞吐量与虚拟用户数之间存在一定的联系,可以采用以下公式计算:F=VU * R / T
其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间
是描述服务器或操作系统性能的一些数据指标,如使用内存数、进程时间,在性能测试中发挥着“监控和分析”的作用,尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
资源利用率:指系统各种资源的使用情况,如cpu占用率为68%,内存占用率为55%,一般使用“资源实际使用/总的资源可用量”形成资源利用率。
Think Time,从业务角度来看,这个时间指用户进行操作时每个请求之间的时间间隔,而在做新能测试时,为了模拟这样的时间间隔,引入了思考时间这个概念,来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数,而其中的R又可以用时间T和用户思考时间TS来计算:R = T / TS
下面给出一个计算思考时间的一般步骤:
A、首先计算出系统的并发用户数
C=nL / T F=R×C
B、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R
该性能测试流程,以loadrunner性能测试设计与实现的。
选定测试业务场景
根据用户需求中所描述的系统架构来分析,性能测试的重点表现在哪几个方面,如:并发访问的性能、数据交换的性能、批处理业务执行效率、系统处理的稳定性等,同时结合系统架构分析可能存在的性能瓶颈,这个也是选择测试业务场景的基础。
根据用户需求并结合实际,不要做到全部业务覆盖,但尽量做到对不同业务类型和操作类型的覆盖,操作类型的覆盖,如;对数据库的读操作(简单查询、复杂查询)、数据库的写操作(如:插入、删除和更新),选取一些典型的业务操作作为测试业务场景。
分析性能测试指标
1)根据用户需求和所选取的典型业务场景,首先选取性能指标项,如:并发用户数、交易响应时间、每秒交易数(TPS)、服务器资源占用率、网络吞吐量等;
2)在选取性能指标项后,根据用户需求或总体设计文档对性能指标进行分析,获得各个性能指标项值,如:用户需求中说明了某个业务使用的用户数为N,但没有说明并发用户数,可以按照10%N~20%N来谁都能够并发用户数;有的文档中会提到一年会处理多少业务量,那么可以按照28原则计算出每秒交易数(TPS)。
测试环境搭建
测试环境要尽量与系统运行的真实环境大致一致,也有一些要求:
1)测试环境时尽可能的模拟系统上线运行环境
搭建测试环境时应充分考虑用户的使用环境,尽可能模拟用户实际使用的软硬件环境,这对性能测试来讲尤为重要,如果生产环境和测试环境相差过大,则测试结果没有参考价值。要求被测系统的硬件配置应与生产部署一致,所安装的软件版本与预期测试的版本号一致。
2)营造独立的测试环境
被测系统在预期性能测试执行期间应保证其资源独占性,即测试过程中要确保我们的测试环境独立,避免测试环境被占用,影响测试进度及测试结果,比如设备连网后,如果其他开发组或测试组也在共用,这样就可能影响我们的测试结果。有时开发人员为确定问题会使用我们的测试环境,这样会打乱我们的测试活动,更严重的是影响测试进度。因此需要为本次测试搭建独立的测试环境。
3)构建可复用的测试环境
项目实际执行过程中,测试环境是经常变化,比如测试软件版本更新、测试人员流失等等,需要随时跟踪和改进,尽量将可控的资源进行分类整理。可控资源包括:测试环境配置手册、测试硬件信息、环境变更记录等等,目的是尽量将测试环境进行备份,方便出现未知问题时快速的还原。当刚搭建好测试环境,安装测试软件之前及测试过程中,对操作系统及测试环境进行备份是必要的,这样一来可以为我们下轮测试时直接恢复测试环境,避免重新搭建测试环境花费时间,二来在当测试环境遭到破坏时,可以恢复测试环境,避免测试数据丢失,重现问题。
测试数据准备
在实施性能测试时,需要运行系统相关业务,这时需要一些数据支持才可运行业务,这部分数据即为初始测试数据,数据准备和清理的工作量是非常大的,需要在测试前提前考虑。
为更加真实的模拟现实运行环境,我们在测试过程中,应尽可能准备与真实业务执行相一致的初始数据,如系统用户数据、业务数据、辅助数据等。
系统用户数据:登陆系统使用的帐户名-口令等,数量与虚拟用户数一致;
业务数据:每个虚拟用户模拟真实用户进行操作时使用到的数据;
辅助数据:为保证业务操作的正常进行而设置的基本信息资料。
此外,测试数据可分可重用和不可重用数据:
可重用数据:如客户信息等查询类的数据,此类数据只需一次准备即可;
不可重用数据:此类数据为一次性消耗数据,不可重用,一般应用在数据增加或修改类业务交易,此类数据如增加客户标识、帐户标识等。
测试环境配置
1)RPC服务。监控服务器资源利用率需要打开系统RPC服务,RPC打开步骤参考详见《监控配置文档》。
2)Agent process。该服务是loadrunner的服务,它的作用是实现控制多台机器同时进行并发,安装了loadrunner的每台机器都会有该服务,只要打开该服务,然后在loadrunner的控制台的Loadgenerator中加入打开该服务的机器的IP地址即可。
3)监控服务器资源利用率。在Loadrunnercontroller中加入所要监控服务器,选择监控的性能指标。
录制和调试脚本可以具体参见其他的资料,不过要注意静态关联和动态关联的问题。
将所录制和调试好的加入到Loadrunner controller控制台中,设置好测试场景,如:并发用户数、调度和运行模式(真实运行模式还是经典模式、虚拟用户加载方式、运行周期)等。
执行完脚本后,可以点开LoadrunnerAnalysis获得执行脚本过程中,所收集的性能指标值的分析报告,可以通过分析报告中数据,写测试报告,同时也可以分析性能瓶颈,得出建议优化措施。
本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。