性能测试方法

上一篇 / 下一篇  2016-12-09 09:35:20 / 个人分类:谈测试

1.性能测试(Performance Testing)

模拟生产运行压力量和使用场景组合,测试系统的性能是否满足生产性能要求。在特定的运行条件下验证系统的能力状况。

确定用户场景、给出需要关注的性能指标、测试执行和测试分析。

性能目标描述:系统在100个并发用户下进行某种业务操作,响应时间不超过5秒。

2负载测试(Load Testing)

通过在被测系统上不断增加压力,直到性能指标。找到系统的处理极限,为系统调优提供数据。亦称为可量性测试(Scalability Testing)。

极限描述:在给定条件下最多允许120个并发用户访问 或 在给定条件下最多在1小时内处理2100笔业务。

预期的性能指标:响应时间不超过10S 或 服务器平均CPU利用率低于65%。

3压力测试(Stress Testing)

测试系统在一定饱和状态下,如CPU、内存等在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。

(1)主要目的是检察系统处于压力情况下时,应用的表现。通过增加访问压力,如增加并发用户,使应用系统的资源使用保持在一定的水平。检测此时的表现,有无错误信息,响应时间等。

(2)通过模拟负载等方法,使系统的资源使用达到较高的水平。比如设定为“CPU 75%,内存70%”情况下,有无错误、系统响应时间。其他,如JVM内存、DB连接数、DB的CPU等。

(3)测试系统的稳定性。如果一个系统能够在压力环境下稳定运行一段时间,那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度

4.配置测试(Configuration Testing)

对被测系统的软/硬件环境的调整,了解各种不同环境对系统性能影响的程度,从而找到系统各项资源的最优分配原则。

(1)了解各种不同因素对系统性能影响的程度,从而判断出最值得进行的调优操作。

(2)规划领域内评估该如何调整才能实现系统的扩展性。

5并发测试(Concurrency Testing)

通过模拟用户的并发访问,测试多用户并发访问同一个应用、模块或者数据记录时是否存在死锁或者其他性能问题。

(1)发现系统中可能隐藏的并发访问时的问题。

(2)关注某些性能指标,如内存泄露、死锁、长事务、线程/进程同步失败等。

并发测试可验证某种架构或设计的合理性,可作代码级别的检查和定位。如Jprofile、JProbe工具。

6可靠性测试(Reliablity Testing)

通过给系统加载一定的业务压力(如资源在70-90%的使用率)的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

(1)验证系统是否能够支持长期稳定的运行

(2)需要在压力下持续一段时间的运行。

(3)关注系统的运行状况。关注内存、CPU、系统响应时间有无明显变化。

7失效恢复测试(Failover Testing)

针对有冗余备份和负载均衡的系统设计的。用来检验如果系统局部发生故障,用户能否继续使用系统;以及如果发生,用户将受到多大程度的影响。还关注问题发生时,能支持多少用户访问和采取何种应急措施。一般说来,只有对系统持续运行指标有明确要求的系统才需要进行此类测试。

性能测试分析方法

性能测试的一般步骤

性能测试的一般步骤如下:

(1)制定目标和分析系统

(2)选择测试度量的方法

(3)学习的相关技术和工具

(4)制定评估标准

(5)设计测试的场景和用例

(6)运行测试用例

(7)分析测试结果

性能测试的估算方法

性能80-20原理方法

用以下例子来说明。

有200个用户使用客户端软件进行业务处理(并发度至少要达到200并发),每年通过软件进行处理的总业务量为:2000万笔业务/年。

测试强度估算时采用如下假设前提:

全年的业务量集中在10个月完成,每个月20个工作日,每个工作日8个小时;

采用80-20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;

测试压力的估算结果:

去年全年处理业务约2000万笔,其中15%的业务处理每笔业务需对应用服务器提交3次请求;70%的业务处理每笔业务需对应用服务器提交2次请求;其余15%的业务每笔业务向应用服务器提交1次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需要,测试需按现有业务量的2倍进行。

每年总的请求数量为:(2000*15%*3+2000*70%*2+2000*15%*1)*2="8000万次/年。

每天的请求数量为:8000/200="40万次/天。

每秒的请求数量为:(400000*80%)/(8*3600*20%)=55.6次/秒。

正常情况下,应用服务器处理请求的能力至少应达到:56次/秒。

性能下降曲线分析法

性能下降曲线实际上描述的是性能随用户数增长而出现下降趋势的曲线。而这里所说的“性能”可以是响应时间,也可以是吞吐量或是单击数/秒的数据。当然,一般来说,“性能”主要是指响应时间。

从图1.1响应时间下降曲线图可以看到,一条曲线可以分为以下几个部分:

(1)单用户区域:对系统的一个单用户的响应时间。这对建立性能的参考值很有作用。

(2)性能平坦区:在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。

(3)压力区域:应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。

(4)性能拐点:性能开始“急剧下降”的点。

这几个区域实际上明确标识了系统性能最优秀的区间,系统性能开始变坏的区间,以及系统性能出现急剧下降的点。对性能测试来说,找到这些区间和拐点,也就可以找到性能瓶颈产生的地方。

因此,对性能下降曲线分析法来说,主要关注的是性能下降曲线上的各个区间和相应的拐点,通过识别不同的区间和拐点,从而为性能瓶颈识别和性能调优提供依据。

性能测试LoadRunner测试过程

LoadRunner将性能测试过程分为计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景和分析结果6个步骤。

从图1.2性能测试步骤

测试过程如下:

(1)计划测试阶段

主要进行测试需求的收集、典型场景的确定;

(2)测试设计阶段

主要进行测试用例的设计;

(3)创建VU脚本阶段

主要根据设计的用例创建脚本;

(4)创建测试场景阶段

主要进行测试场景的设计和设置,包括监控指标的设定;

(5)运行测试场景阶段

对已创建的测试场景进行执行,收集相应数据;

(6)分析结果阶段

主要进行结果分析和报告工作。

性能测试模型PTGM

性能测试模型PTGM(Performance Testing General Model),该性能测试模型将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤,

1.3 PTGM测试模型图

在PTGM模型的描述中,作者为每个步骤设计了相应的活动,囊括了从“测试团队组建”到“测试分析”的全部过程,每个活动都有详细的活动指引和参考模板


TAG: 性能测试方法

 

评分:0

我来说两句

Open Toolbar