性能测试用例编写、脚本开发

性能测试用例编写:

根据测试点逐条进行细化:

· 性能测试数据,有明确要求,需要达到一定的业务量
· 从接口维度来描述测试步骤
· 如果两个接口强绑定(结算、下订单),放在一个用例中间测试

性能测试脚本开发

常用的测试元件

线程组

线程组是任何测试计划的起点,所有的逻辑控制器和采样器都必须放在线程组下。其他的测试元件(例如监听器)可以直接放在测试计划下,这些测试元件对所有的线程组都生效。

每一个JMeter线程都会完成的执行测试计划,而且它们之间都是完全独立运行的。这种多线程机制被用来模拟服务器应用的并发连接

2、控制器

JMeter有两种类型的控制器:采样器和逻辑控制器,二者结合起来驱动了测试进程。采样器用来向服务器发送请求。逻辑控制器用来控制JMeter的测试逻辑,特别是何时发送请求。逻辑控制器可以改变其子测试元件的请求执行顺序

3、监听器

监听器提供了对JMeter在测试期间收集到的信息的访问方法

所有监听器都保存相同的数据,区别是展示方法不同

监听器可以在测试的任何地方添加,它们仅收集测试树中相同或者更低级别测试元件的数据

4、定时器

默认情况下,jmeter线程在发送请求之间没有间隙。可以为线程组添加定时器,设定请求之间应该间隔多长时间。

定时器会让作用域内的每一个采样器都在执行前等待一个固定时长。如果为线程组添加了多个定时器,那么jmeter会将这些定时器的时长叠加起来,共同影响作用域范围内的采样器。

5、断言

断言可以检查从服务器获取的响应内容。判断响应是否正确。

断言会影响作用域内的所有采样器,如果只影响一个采样器,可以将这个断言作为采样器的子项

查看断言结果可以添加断言结果监听器

失败的断言可以在“查看结果树”和“用表格查看结果”两种监听器中显示。在“Summary Report”和“聚合报告”中还回以错误百分率的形式统计

6、配置元件

配置元件与采样器关联很紧密,可以添加或修改请求

配置元件只对其所在测试分支有效

7、前置处理器

前置处理器会在采样器发送请求之前做一些特殊操作

如果前置处理器在某个采样器下,那就只在该采样器运行前执行

一般用于修改采样器的某些设置或更新某些变量的值

8、后置处理器

后置处理器会在采样器发送请求之后做一些操作。

如果后置处理器在某个采样器下,那就只在该采样器运行后执行

一般用于处理服务器的响应数据,特别是服务器响应中提取数据

编写脚本的要点:

JMeter脚本的基本结构:

  1. 创建测试用例结构
  2. 设置HTTP请求默认值
  3. 用户定义的变量
  4. 添加监听器-察看结果树
  5. 添加监听器-聚合报告
    在这里插入图片描述
单接口测试脚本:
(1)登录脚本

· 添加HTTP请求默认值:设置HTTP请求中的默认部分(协议、域名、端口、编码格式)

· 添加HTTP信息头管理,设置HTTP请求的头域

· 添加线程组 - 登录
· 添加HTTP请求 - 登录,填写路径和请求参数
· 在HTTP请求下添加断言:
· 如果做接口测试,必须断言 响应中的业务数据,可以加上 状态码和描述信息
· 如果做性能测试,可以只 添加状态码和描述信息 断言

(2)进入首页、搜索商品、获取商品详情

进入首页:
· 请求:

· 断言:状态码、errmsg

搜索商品:
· 请求:

断言:
· 状态码、errmsg
· 如果是接口测试脚本,必须针对响应中的商品数量进行断言(数据库)

获取商品详情:
· 请求:

在这里插入图片描述

断言:
· 状态码、errmsg
· 如果是接口测试脚本,需要针对响应中的商品的详细数据进行对比(数据库)

(3)加入购物车的脚本

· 添加请求1:登录
· 添加JSON提取器,提取token

在这里插入图片描述

· 将token设置在HTTP信息头管理器中

· 添加请求2:加入购物车

添加断言:
· 状态码、errmsg
· 如果是接口测试脚本, 需要再查询我的购物车,检查我的购物车返回的数据是否与加入购物车返回的数据一致

(4)查看我的购物车、结算下订单、查看我的订单

查看我的购物车:
· 请求:先发送登录请求,提取token信息,添加查看购物车请求,将token信息赋值为X-litemallToken头域,填写请求路径和参数

在这里插入图片描述

响应:
· 状态码、errmsg
· 如果脚本为接口测试脚本,需要断言响应报文中的购物车中的商品总数量或者商品总价值

提交订单:
· 请求:

(1)先发送登录请求,提取token信息,

(2)添加结算请求,将token信息赋值为X- litemall-Token头域,填写请求路径和参数

(3)添加下订单请求,将token信息赋值为X-litemall- Token头域,填写请求路径和参数(注意地址ID必须与用户ID匹配)

· 响应: 状态码、errmsg
· 如果脚本为接口测试脚本,需要断言响应报文中的订单数据,与数据库中订单表中我的订单数 量一致

业务流程的测试脚本:

· 将业务流程中的所有单接口的脚本组装在一起
` 注意所有的脚本组装在一起时,数据是否一致

在这里插入图片描述

某网站性能测试用例 某网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:   ● 产品页面刷新性能   ● 产品上传性能   ● 产品下载性能   目前给出的指标为:   延迟:   测试项 响应时间 抖动 备注   产品页面刷新 <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分钟 取消思考时间
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值