测试用例之性能测试用例

合集下载

如何编写性能测试场景用例(如何编写性能测试用例)

如何编写性能测试场景用例(如何编写性能测试用例)

如何编写性能测试场景⽤例(如何编写性能测试⽤例)单场景前⾔写测试⽤例,是测试绕不开的⼯作内容,不管是功能、⾃动化,还是性能。

先来回顾⼀下功能测试⽤例主要包含的要素:测试⽤例编号、测试标题、所属模块、测试需求项编号、案例状态、预置条件、优先级、测试输⼊、操作步骤、预期输出、实际结果、案例设计者、设计⽇期、案例性质等。

性能测试⽤例(有的称为场景⽤例)的设计,有别于功能测试⽤例、⾃动化测试⽤例的设计,毕竟,考虑的点不⼀样。

对于性能测试来说,⼀般要考虑这4种场景:单场景、混合场景、稳定性场景、异常场景。

下⾯,结合笔者实际⼯作,分享下单场景的⽤例是如何设计的。

单场景的定义 有的称为接⼝基准(Benchmark)、或者单交易的容量,总之,这个不是真实的业务原型(可以简单理解为不同业务的使⽤情况)。

单场景压测的⽬的 既然单场景不是真实的业务原型,为什么不直接做混合场景的压测呢?其实,做单场景压测的⽬的是测试出这个单业务的最⼤tps,⽅便判断瓶颈,⽐如,业务部门给的混合场景的tps(假设这个tps值是合理有效的),根据业务原型⽐例计算后,业务A的⽬标tps都⽐你单场景的最⼤tps还要⼤,那是不是应该让开发提前优化了?如果在混合场景压测中,发现业务A的tps已经到达或者接近其单场景最⼤tps,但是混合场景还没有达标,那说明瓶颈在业务A。

单场景的来源 有⼈可能要问,单场景从哪⾥来?如果你们业务部门或者其它部门能给,那最好,如果不能给,你作为性能测试⼈员,要引导相关⼈员给,总之,我觉得这个不能性能测试单独定,否则后期出问题可能你独⾃背锅哦,要尽最⼤努⼒保证不出问题,哪怕出问题,也要⼀起背锅。

单场景是来⾃于业务原型,但是不是每个业务接⼝都需要做压测,所以,我们这⾥说的业务原型,是混合场景的业务原型,混合场景⾥⾯,每个业务接⼝都需要做单场景压测。

⾄于业务原型如何获取,这是⼀个⼤话题,本次分享暂不讨论,如果想交流,欢迎微信留⾔。

性能测试用例

性能测试用例

性能测试用例
性能测试用例是指在软件开发过程中,通过各种预先定义的测试条件,对软件系统或服务进行测试,以确定其能够满足特定性能要求的一系列测试。

性能测试用例主要包括以下内容:
1. 测试目标和范围:明确测试的目标和范围,如性能测试的类型、平台、测试时间、测试范围等;
2. 计划:明确测试步骤和测试环境,如测试数据准备、测试工具、测试环境等;
3. 执行:执行测试,记录测试结果;
4. 结果分析:分析测试结果,如测试报告、数据分析、性能报告等;
5. 验收:验证测试结果,确保其满足要求。

性能测试用例(转载)

性能测试用例(转载)

性能测试⽤例(转载) ⼀、WEB 全⾯模型 Web 性能测试模型提出的主要依据是:⼀种类型的性能测试可以在某些条件下转化成为另外⼀种类型的性能测试,这些类型的性能测试的实施是有着相似之处的; 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出⼀些性能指标,完成这些指标的相关的测试是性能测试的⾸要之⼀,这些指标主要诸于“系统可以⽀持并发⽤户200个;”系统响应时间不得超过20秒等,对这种预先承诺的性能要求,需要⾸先进⾏测试验证; 2. 独⽴业务性能测试 独⽴业务实际是指⼀些核⼼业务模块对应的业务,这些模块通常具有功能⽐较复杂,使⽤⽐较频繁,属于核⼼业务等特点。

⽤户并发测试是核⼼业务模块的重点测试内容,并发的主要内容是指模拟⼀定数量的⽤户同时使⽤某⼀核⼼的相同或者不同的功能,并且持续⼀段时间。

对相同的功能进⾏并发测试分为两种类型,⼀类是在同⼀时刻进⾏完全⼀样的操作。

另外⼀类是在同⼀时刻使⽤完全⼀样的功能。

3. 组合业务性能测试 通常不会所有的⽤户只使⽤⼀个或者⼏个核⼼业务模块,⼀个应⽤系统的每个功能模块都可能被使⽤到;所以WEB性能测试既要模拟多⽤户的相同操作,⼜要模拟多⽤户的不同操作;组合业务性能测试是最接近⽤户实际使⽤情况的测试,也是性能测试的核⼼内容。

通常按照⽤户的实际使⽤⼈数⽐例来模拟各个模版的组合并发情况;组合性能测试是最能反映⽤户使⽤情况的测试往往和服务器性能测试结合起来,在通过⼯具模拟⽤户操作的同时,还通过测试⼯具的监控功能采集服务器的计数器信息进⽽全⾯分析系统瓶颈。

⽤户并发测试是组合业务性能测试的核⼼内容。

组合并发的突出特点是根据⽤户使⽤系统的情况分成不同的⽤户组进⾏并发,每组的⽤户⽐例要根据实际情况来匹配; 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运⾏的情况下,以⼀定的负载压⼒来长时间运⾏系统的测试,其主要⽬的是确定系统长时间处理较⼤业务量时的性能,通过疲劳强度测试基本可以判定系统运⾏⼀段时间后是否稳定; 5. ⼤数据量性能测试 ⼀种是针对某些系统存储,传输,统计查询等业务进⾏⼤数据量时的性能测试,主要针对某些特殊的核⼼业务或者⽇常⽐较常⽤的组合业务的测试; 第⼆种是极限状态下的数据测试,主要是指系统数据量达到⼀定程度时,通过性能测试来评估系统的响应情况,测试的对象也是某些核⼼业务或者常⽤的组合业务。

性能测试用例

性能测试用例

同预期
备注
样品编号 测试用例总数 序号 用例标识
模块名称
功能点
1
WW1
统一登录模 用户100并

发登录
2
WW2 ***平台 单用户3源自WW3****平台
用户100并 发
性能测试
性能测试用例
操作步骤
1.编写接口测试脚本; 2.对脚本进行调优(关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点); 3.设置脚本执行场景,模拟100并发用户数执行“统一登录”业务操作,并根据测试结果 数据分析系统的性能状况 41..查编看写接接口口成测功试率脚、本响;应时间、吞吐量和系统资源消耗情况; 2.对脚本进行调优(关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点); 3.设置脚本执行场景,模拟单用户执行“大数据分析平台”业务操作,并根据测试结果数 据分析系统的性能状况 4.查看接口成功率、响应时间、吞吐量和系统资源消耗情况; 1.编写接口测试脚本; 2.对脚本进行调优(关联接口、请求参数参数化、设置思考时间1S、设置响应文本检查 点); 3.设置脚本执行场景,模拟100并发用户数执行“大数据分析平台”业务操作,并根据测 试结果数据分析系统的性能状况 4.查看接口成功率、响应时间、吞吐量和系统资源消耗情况;
能测试用例
期望结果
实际结果 设计者
检查人
执行人
100用户并发进行“统一登录”操作,系统响应时间≤5S,峰值≤ 15S、接口失败率<5%。
同预期
单用户并发进行“大数据分析平台”业务操作,系统响应时间控制在 平均值≤2S、峰值≤15S、接口失败率<5%。
同预期
100用户并发进行“大数据分析平台”业务操作,系统响应时间控制 在平均值≤2S、峰值≤15S、接口失败率<5%。

性能测试之测试用例(方案篇)

性能测试之测试用例(方案篇)

性能测试之测试用例(方案篇)性能测试在软件测试中占有重要的地位,而性能测试又关联很多内容。

例如压力和强度测试就与性能测试密切相关:针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试,如果同时对系统进行大量的数据查询操作,就包含了强度测试。

为了便于性能测试工作的实施,这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容,主要包含的内容有:预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求,编写方法要根据实际要求进行编写,本文提出一个常见的参考方案,在实际工作中,可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容:1.1预期性能指标测试用例通常系统在设计前都会提出一些性能指标,这些指标是性能测试要完成的首要工作之一。

针对每个指标都要编写多个测试用例来验证是否达到要求,并根据测试结果来改进系统的性能。

这类通常以单用户为主,如果遇到并发用户的情况,可以归到并发用户测试用例中。

这类用例通常都是可以通过手工来执行的用例,例如示例中的上传一份文件,期望的性能为2M/S,完全可以手动上传文件,同时用秒表计时。

这些内容通常在需求说明书中可以显而易见的查到。

不过当看到如支持并发用户300人,就应该放到后面进行。

测试结果也是直接记录是否达到要求,如果系统没有达到要求则进行改善。

1.2用户并发性能测试用例用户并发测试是性能测试的最主要部分,包含了负载测试和压力测试的过程。

主要是逐渐增加用户数量来加重系统负担,直到出现不能接收的性能点或者瓶颈。

一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试,要以真实的业务数据作为输入,选择有代表性和关键的业务操作来设计测试用例。

主要编写以下两个方面的用例:核心模块的测试(可以理解为“单元性能测试”):对核心功能模块进行并发用户测试,测试系统是否能够稳定运行。

性能测试用例demo

性能测试用例demo

参数设置 运行时设置 事物设置 集合点设置 检查点设置 Scenario Type
Manual Scenario Scenario 非百分比模式
场景编号 1 系统登录
业务名称
场景编号 1 系统登录
业务名称
业务名称
录制步骤
系统登录 1、启动VuGen,按照录制设置设置录制前提条件; 2、切换至Action,在被测系统操作系统登录流程,按照事物设置插入事物; 3、切换至vuser_end,操作退出系统流程
脚本设置 参数策略 迭代次数 Sequential+Each iteration 参数值个数 Same line as username 参数值个数 Pacing迭代间隔 Log是否启动日志 5秒 启动标准日志 起始位置 结束位置 初始化页面前 跳转至欢迎页面后 起始位置 单击登录按钮前 检索内容 检索范围 Text=Welcome, <b>jojo</b>,Search=Body 场景设置 Run Mode Basic schedule Action Initialize Start Vusers Duration 预期结果 并发数 1 事物平均响应时间 <=3s001 应用类型:Internet Applications URL地址:http://127.0.0.1:1080/WebTours/ 录制起始存放函数:Action 录制协议:Web(HTTP/HTML) 录制模式:URL-based script 参数名 username password Run Logic迭代次数 参数值个数 事物名称 transaction_login 集合点名称 rendezvous_login 检查点类型 文本 Schedule by

性能测试用例设计

性能测试用例设计

性能测试⽤例设计性能测试⽤例的设计,有别于功能测试⽤例的设计,毕竟,考虑的点不⼀样。

在有了性能测试⽅案后,我们就可以设计我们的性能测试⽤例了,⼀般考虑:单场景、混合场景、稳定性场景下⾯给出笔者在实际⼯作中,单场景的⽤例(之前⽤loadrunner做压测的⽤例),供⼤家参考:⽤例编号:PT001场景描述:模拟⽤户进⾏登录操作并发量:分别模拟并发⽤户数为1000、1500、2000等多种情况进⾏测试(除了压测能否达到⽬标,还要压测出最⼤的并发和tps,参考:)压测时间:每次600s数据量:oracle数据库user表有100万存量账户脚本设置关键点:参数化⽤户名、封装登录事务、添加思考时间集合点:不使⽤加压减压⽅式:全部初始化爬坡加压、全部退出场景运⾏时设置:think time=1s、continue when error、log选择Send messages only when an error occurs重点关注指标:响应时间、tps,事务成功率,各个服务器资源使⽤情况(CPU、内存、磁盘I/O、磁盘容量)、⽹络、是否频繁fgc、是否线程阻塞、线程死锁、连接池未释放、数据库死锁、慢sql等等预期指标:并发>=1000,响应时间<=1s,tps>=600,事务成功率为99.5%(涉及资⾦的,要求100%),应⽤服务器、数据库服务器CPU和内存使⽤率<=90%,没有内存泄漏现象、没有死锁等各种性能问题。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21⽤例编号:PT001场景描述:模拟⽤户进⾏登录操作并发量:分别模拟并发⽤户数为1000、1500、2000等多种情况进⾏测试(除了压测能否达到⽬标,还要压测出最⼤的并发和tps,参考:https:///uncleyong/p/11543488.html)压测时间:每次600s数据量:oracle数据库user表有100万存量账户脚本设置关键点:参数化⽤户名、封装登录事务、添加思考时间集合点:不使⽤加压减压⽅式:全部初始化爬坡加压、全部退出场景运⾏时设置:think time=1s、continue when error、log选择Send messages only when an error occurs重点关注指标:响应时间、tps,事务成功率,各个服务器资源使⽤情况(CPU、内存、磁盘I/O、磁盘容量)、⽹络、是否频繁fgc、是否线程阻塞、线程死锁、连接池未释放、数据库死锁、慢sql等等预期指标:并发>=1000,响应时间<=1s,tps>=600,事务成功率为99.5%(涉及资⾦的,要求100%),应⽤服务器、数据库服务器CPU和内存使⽤率<=90%,没有内存泄漏现象、没有死锁等各种性能问题。

软件测试测试用例实例(功能测试用例、性能测试用例、兼容性测试用例)资料

软件测试测试用例实例(功能测试用例、性能测试用例、兼容性测试用例)资料

测试用例实例含:功能测试用例、性能测试用例、兼容性测试用例)一、功能测试用例-2-二、性能测试-11-2.1预期性能测试用例-11-2.2用户并发测试用例-12-2.3大数据量测试用例-12-2.4疲劳强度测试用例-13-2.5负载测试测试用例-13-三、兼容性测试-.14-用例编号TestCase_LinkWorks_WorkEvaluate项目名称LinkWorks模块名称WorkEvaluate模块项目承担部门研发中心-质量管理部用例作者完成日期2005-5-27本文档使用部门质量管理部评审负责人审核日期批准日期注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。

历史版本:版本/状态作者参与者起止日期备注一、功能测试用例此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。

主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

二、性能测试性能测试是一种对响应时间、事务处理速率和其他与时间相关的需求进行测试和评估。

性能测试的目标是核实性能需求是否都已满足。

可以分为以下几种进方式来组织进行测试。

2.1预期性能测试用例通常系统在设计前会提出一些性能指标,这些指标是性能测试要完成的首要工作,针对每个指标都要统写多个测试用例来验证是否达到要求,根据测试结果来改进系统的性能。

预期性能指标通成以单用户为主。

2.2 用户并发测试用例用户并发测试是性能测试最主要的部分,主要是通过增加用户数量来加重系统负担,以检验测试对象能接收的最大用户数来确定功能是否达到要求。

2.3 大数据量测试用例大数据量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。

大数据量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

测试用例之性能测试用例注:本文摘自作者正在编写的《Web性能测试实战》一书,曾经在程序员杂志2004年第10期上发表过。

性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于对应的测试用例如何编写和执行,就更不用说了。

如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。

目前国内,测试工程师却时常要面对“已经延期几倍计划时间的项目”,测试用例如何发挥更大的作用,是一个迫切需要解决的问题。

事实上,完全可以把测试用例看成是测试工程师编写的程序:这个“程序”是为了辅助测试工作的进行而开发的,目的是为了发现软件问题,同时“顺便”证明软件功能是否符合要求。

本文针对上面的问题,以设计性能测试用例为示范,讲解在企业实际工作中,如何有效划分测试种类和编写对应的测试用例,使测试工作更加合理、高效率的开展。

1测试种类和阶段1.1 测试种类对于测试种类的说法多种多样,最多的能达到30多种测试类型。

而实际工作中很多测试是互相包含的。

按照企业中实际工作需要,通常主要进行下面几种类型的测试:功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

下面介绍几种重要的测试种类及其测试的内容:功能测试:功能测试主要针对产品需求说明书的测试,是验证功能是否否合需求,包括原定功能的检验、是否有冗余功能、遗漏功能。

这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作,他们也需要进行基本功能的测试。

接口测试:程序员对各个模块进行系统联调的测试,包含程序内接口和程序外接口测试。

这个测试,在单元测试阶段进行了一部分工作,而大部分都是在集成测试阶段完成的。

由开发人员进行。

性能测试:在交替进行负荷和强迫测试时常用的术语。

性能测试关注的是系统的整体。

它和通常所说的强度、压力/负载测试测试有密切关系。

所以压力和强度测试应该与性能测试一同进行。

用户界面测试:对系统的界面进行测试,测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题安装/反安装测试:安装测试主要检验软件是否可以正确安装,安装文件的各项设置是否有效,安装后能否影响原系统;反安装是逆过程,测试是否删除干净,是否给影响原系统等。

文档测试:主要测试开发过程中针对用户的文档,以需求、用户手册、安装手册等为主,检验文档是否和实际应用存在差别。

文档测试不需要编写测试用例。

测试种类的划分不要拘泥于上面的形式,总体来说应该服从于测试策略,可以根据具体工作的特点进行安排,为了工作更容易开展,完全可以把一些测试合在一起进行。

在后面的性能测试用例的编写上,充分体现了这一思想。

1.2 测试阶段和开发过程相对应,测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要图1 开发与测试的“V”型关系单元测试:单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作,通常由开发人员进行。

集成测试:集成测试是将模块按照设计要求组装起来进行测试,主要目的是发现与接口有关的问题。

由于在产品提交到测试部门前,产品开发小组都要进行联合调试,因此在大部分企业中集成测试是由开发人员来完成的。

系统测试:系统测试是在集成测试通过后进行的,目的是充分运行系统,验证各子系统是否都能正常工作并完成设计的要求。

它主要由测试部门进行,是测试部门最大最重要的一个测试,对产品的质量有重大的影响。

验收测试:验收测试以需求阶段的《需求规格说明书》为验收标准,测试时要求模拟实际用户的运行环境。

对于实际项目可以和客户共同进行,对于产品来说就是最后一次的系统测试。

测试内容为对功能模块的全面测试,尤其要进行文档测试。

尽管测试阶段的划分十分明确,但是在具体的项目和产品的测试中,尤其在执行测试时,会根据实际需要来开展。

1.3 测试种类、阶段和用例的关系为了便于在实际工作中提高效率,同时方便测试用例的编写和执行,可以把上面提到的各个测试类型与对应的测试用例合并。

合并后的测试用例主要有以下几种:1.功能测试用例:包含功能测试、健壮性测试、可靠性测试2.性能测试用例:包含性能测试、压力测试、强度测试3.集成测试用例:包含接口测试、健壮性测试、可靠性测试4.安全测试用例:安全测试用例5.用户界面测试用例:包含用户界面测试用例、少量功能测试用例6.安装/反安装测试用例:安装/反安装测试用例表1 测试的种类、阶段和执行人员的关系总之,测试的种类应该尽量的少,这样每次都可以执行更多的测试内容。

例如在进行功能测试的同时,完全可以进行健壮性的测试。

(当然如果产品健壮性方面要求较高,就可以把健壮性测试作为独立的测试。

)2性能用例编写方案性能测试在软件测试中占有重要的地位,而性能测试又关联很多内容。

例如压力和强度测试就与性能测试密切相关:针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试,如果同时对系统进行大量的数据查询操作,就包含了强度测试。

为了便于性能测试工作的实施,这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容,主要包含的内容有:预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求,编写方法要根据实际要求进行编写,本文提出一个常见的参考方案,在实际工作中,可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容:2.1预期性能指标测试用例通常系统在设计前都会提出一些性能指标,这些指标是性能测试要完成的首要工作之一。

针对每个指标都要编写多个测试用例来验证是否达到要求,并根据测试结果来改进系统的性能。

这类通常以单用户为主,如果遇到并发用户的情况,可以归到并发用户测试用例中。

这类用例通常都是可以通过手工来执行的用例,例如示例中的上传一份文件,期望的性能为2M/S,完全可以手动上传文件,同时用秒表计时。

这些内容通常在需求说明书中可以显而易见的查到。

不过当看到如支持并发用户300人,就应该放到后面进行。

测试结果也是直接记录是否达到要求,如果系统没有达到要求则进行改善。

2.2用户并发性能测试用例用户并发测试是性能测试的最主要部分,包含了负载测试和压力测试的过程。

主要是逐渐增加用户数量来加重系统负担,直到出现不能接收的性能点或者瓶颈。

一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试,要以真实的业务数据作为输入,选择有代表性和关键的业务操作来设计测试用例。

主要编写以下两个方面的用例:核心模块的测试(可以理解为“单元性能测试”):对核心功能模块进行并发用户测试,测试系统是否能够稳定运行。

例如对于互联网的公用邮件系统,每天早上9点左右可能是收发邮件的高峰,这时候上千的用户都要在上班后进入邮件系统,系统这个时候需要接收和发送大量的邮件。

所以邮件系统这一功能模块要进行并发测试。

通过测试可以知道数据库服务器、操作系统、网络设备等是否能够承受住考验,同时可以对瓶颈进行分析。

表2列出来一些常见的参数(表格中的数据为示例的测试用例和测试结果),可以根据实际需要进行增加和删除,其中磁盘I/O、数据库相关测试参数要根据实际情况进行选择,因此没有列表2 核心模块的性能测试用例在编写这类用例时,要进行综合分析,选出系统中的各个核心模块,分别设计每个模块的测试用例:把模块划分成小的“事务”进行测试,这样在测试分析中便于定位问题究竟出现在哪里。

例如邮件系统可以划分成:接收邮件、发送邮件、打开邮件等小的事务进行测试用例的编写,每个操作做为一个用例来执行。

业务组合性能测试(可以理解为“集成性能测试”):所有的用户不会只使用核心模块,通常每个功能都可能被使用到,所有既要模拟多用户的“相同”操作,又要模拟多用户的不同操作,对多个业务进行组合性能测试。

业务组合测试是更接近用户实际操作系统的测试,因此用例编写要充分考虑实际情况,选择最接近实际的场景进行设计。

这里的业务组成单位以不同模块中的“子操作事务”为单位,进行各个模块的不同业务的组合。

例如在办公自动化系统中就可以选择“公文模块中的发送公文、电子公告模块中的查看公告信息、网上论坛模块中的上传文件”等事务作为一组组合业务进行测试,用例设计信息如下:功能:在线用户达到高峰时,用户可以正常使用系统,保证500个以内用户可以同时在线使用系统。

目的:测试系统500个以内的用户同时在线能否使用比较常见的模块:公文系统、电子公告、网上论坛。

方法:采用LoadRunner的录制工具录制三个业务:业务1––在公文系统内,进行打开、修改等操作;业务2––在电子公告系统内,查看、发布公告;业务3––在网上论坛系统内发布帖子,查看文章。

每个业务分配一定数目的用户,利用LoadRunner来完成相关参数的测试。

其它部分设计可以参考表2。

执行时要分别记录各个事务的执行情况。

多用户并发性能测试是性能测试的核心内容,包含了全部与多用户相关的测试。

因此设计时要全面考虑,不要有遗漏。

在测试执行时,本部分通常是采用性能测试工具例如LoadRunner来进行测试的,因此更容易执行和提高效率。

2.3疲劳强度与大数据量测试疲劳强度测试是在系统稳定运行下模拟最大用户数量、并长时间运行系统,通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能。

疲劳强度测试的目的就是检验系统长时间运行后的性能,因此设计用例时,需要编写不同参数或者负载条件下的多个测试用例,对服务器、软件、网络进行不同条件下的综合测试分析,测试时要记录系统发生故障的信息作为测试结果。

疲劳强度测试也是采用测试工具进行的。

大数据量测试分为两种:一个是针对某些系统存储、传输、统计查询等业务进行大数据量的测试;另一个是与前面并发测试相结合的综合数据测试。

编写用例时主要编写前一部分,后一部分尽量放在并发测试中。

大数据量测试一般是针对那些对数据库有特殊要求的系统进行测试,例如电信业务系统的手机短信息表,由于有的用户关机或者不在服务区,每秒钟需要有大量的短信息保存,同时在用户联机后还要及时发送,因此对数据库性能有极高的要求,需要专门测试。

本部分用例设计表格可以参考用户并发性能测试部分。

2.4网络性能测试网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。

在实际的软件项目中,主要是测试用户数目与网络带宽的关系。

相关文档
最新文档