JMeter中级篇-9-网站性能测试用例2设计

       这篇,我们继续在前一篇性能测试用例基础之上,添加一点改变(添加断言),同样逐步分析每一个条件,来设计JMeter上的性能测试用例。

 

网站性能测试案例2:

1.用户人数10人,一分钟之后,全部对服务器进行施压。

2.用户分别访问3个页面,而且是所有用户同时进行

3.服务器的URL不能写死,同前面一样。

4.对每一个请求进行断言,响应时间在5秒之内,否则就标记失败。

5.响应内容不能显示Error和Warning

6.生成图表和表格报告。

 

 

设置并发用户数

 

       这里我们在前面的测试计划里,新建一个线程组,名称是TestCase-2, 用户和用户进来的时间都有具体要求,根据第一个条件,JMeter上第二个线程组的线程设置如下。

10个线程数没什么好解释的,第二个60秒就是条件所说的,在一分钟之后,全部用户处于并发状态。

 

访问三个页面

 

三个页面的访问,我们这里不变化,同时带上思考时间,我们可以在TestCase-1这个线程组下复制三个请求过来。

 

服务器地址设置

 

      服务器地址在控制元件里面的HTTP请求默认值设置,依然从前面一个用例里复制过来。

 

对请求进行断言

 

       前面我们设计用例,没有说断言这个需求,只是考虑了给服务器发送请求和测试运行,观察报告,这里我们需要多加一步,就是对请求的结果进行判断,如果不符合条件这个请求就标记失败状态。一般来说,网页访问有258原则,所以我们设置页面响应时间大于5秒就报错。

右键TestCase-2.添加一个断言持续时间,并设置5000毫秒。


 

对响应内容进行过滤和断言

 

有时候我们响应内容如果发生错误或警告,响应体这种包含Error和Warning这样字符串。这里,我们可以通过响应断言这个监听来实现过滤和判断。

 

上面条件表示不包含Error和Warning的断言,如果出现,说明请求失败。

 

生成报告

 

报告和前面一样,选择自己常用的监听类型。我点击运行一下,发现所有请求都是失败状态。

看到错误,不要着急,我们来分析下为什么都请求状态是失败的。这篇我们设计了两个断言,一个是请求时间不能超过5秒,第二个是响应文本不能包含Error和Warning字眼。这全部报错,说明第二个条件引起的可能性更大,比较当前我们10人并发,响应时间肯定不错超过5秒。所以,我们修改以下不包含的关键字来测试下。

 

我们把不包含的关键字替换成,严重错误和崩溃。

保存,测试运行

发现,在Java+Selenium请求这个页面还是出现断言失败,还是存在我们不包含的关键字,猜测这个页面有“崩溃”这个文本出现。

 

      本篇介绍的第二个用例,和第一个相比,主要是增加了断言部分的介绍和使用,作为一个测试人员,设计用例其实不难,难的是如何进行高效的断言。

网站性能测试用例网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:   ● 产品页面刷新性能   ● 产品上传性能   ● 产品下载性能   目前给出的指标为:   延迟:   测试项 响应时间 抖动 备注   产品页面刷新 <5秒 <2秒   产品下载相应时间 <4秒 <2秒   吞吐量:   编号 项 吞吐量   Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次   Perf.T.2 每日页面平均访问量 60000次   Perf.T.3 每日下载量 50000   Perf.T.4 平均每日新增会员数量 500   Perf.T.5 高峰同一模板下载量 100用户并发下载   Perf.T.6 高峰不同模板下载量 150用户并发下载   容量:   编号 项 容量   Perf.C.1 用户数 <=100万   Perf.C.2 活动用户数 10000   Perf.C.3 模板中心总用户数 <=25万   根据如上性能需求及数据我们该如何设计性能测试用例及场景呢?(可以说给出的性能需求很垃圾,没有丝毫价值,但没办法还是点做啊)   首先,我不去在乎它要求的性能是什么,我只需要去做在一定的测试环境下对系统进行压力测试,找到各个性能指标的临界点就好了,至于是否达到性能指标,在和性能需求对照编写测试报告即可。   所以,针对这几个需要进行性能测试的页面,我们做一下分析,如何设计场景才能尽可能准确地体现出系统的性能:   先说一下搜索页面   搜索页面根据对项目的了解,搜索后,将所有符合条件的结果遍历出来,显示在前台,每页的显示数量是一定的,超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面,对于页面显示对性能的消耗我们可以忽略不计,主要的压力来自数据的传输、sql的执行及应用服务器的处理过程,所以我可以从两个方面设计场景:   a、虚拟用户一定,不同数据库数量级的情况下,搜索的性能   如何确定虚拟用户的数量成为一个关键,我们可以让客户提供一个常规情况下每天访问用户数(如果没有实际数据可参考,可以根据产品方案中期望的用户数来代替),我们就用这个用户数来进行测试;再来分析一下不同的数据库数量级,如果系统运营1年的产品数据量是5万条,那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试(具体的分法可以根据实际情况而定),所以对于这个测试目标,我们可以设计5个场景进行:   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   100 10000 搜索页面 随机产生 30分钟 加入思考时间   100 30000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   100 100000 搜索页面 随机产生 30分钟 加入思考时间   100 200000 搜索页面 随机产生 30分钟 加入思考时间   b、一定数据库数量级,不同量虚拟用户的情况下,搜索的性能   我们定下来一个常规的数据库数据量,在数据量不变的情况下逐步增加虚拟用户数,测试一下不同虚拟用户压力下系统的性能   虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间   50 50000 搜索页面 随机产生 30分钟 加入思考时间   80 50000 搜索页面 随机产生 30分钟 加入思考时间   100 50000 搜索页面 随机产生 30分钟 加入思考时间   120 50000 搜索页面 随机产生 30分钟 加入思考时间   150 50000 搜索页面 随机产生 30分钟 加入思考时间   产品上传   影响上传性能的主要因素有上传文件的大小和上传的请求数,所以我们就从这两个方面设计用例。   a、虚拟用户数一定,上传不同大小的文件   虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间   50 100k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   50 500k 上传页面 随机产生 30分钟 取消思考时间   50 800k 上传页面 随机产生 30分钟 取消思考时间   50 1M 上传页面 随机产生 30分钟 取消思考时间   b、上传文件大小一定,不同量的虚拟用户   虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间   20 300k 上传页面 随机产生 30分钟 取消思考时间   50 300k 上传页面 随机产生 30分钟 取消思考时间   80 300k 上传页面 随机产生 30分钟 取消思考时间   100 300k 上传页面 随机产生 30分钟 取消思考时间   产品下载   影响下载性能的主要因素有下载文件的大小和下载的请求数,所以我们就从这两个方面设计用例   a、虚拟用户数一定,下载不同大小的文件   虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间   50 100k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   50 500k 下载页面 随机产生 30分钟 取消思考时间   50 800k 下载页面 随机产生 30分钟 取消思考时间   50 1M 下载页面 随机产生 30分钟 取消思考时间   b、下载文件大小一定,不同量的虚拟用户   虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间   20 300k 下载页面 随机产生 30分钟 取消思考时间   50 300k 下载页面 随机产生 30分钟 取消思考时间   80 300k 下载页面 随机产生 30分钟 取消思考时间   100 300k 下载页面 随机产生 30分钟 取消思考时间
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值