SoftwareTest8 - 怎样测试一个系统的性能 ?

Hello , 大家好 , 又给大家带来新的专栏喽 ~

这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .

这篇文章是带着大家先了解一些性能测试的概念 , 然后通过 LoadRunner 工具对自带的 WebTours 工具进行性能测试

那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html

希望大家都能够拿到好的 Offer

一 . 性能测试概述

性能测试是什么 ? 他跟我们的功能测试仅仅有一字之差 , 那他们俩到底有什么区别呢 ?
举个例子 : 我们访问百度
但是假如在信号不好的时候 , 页面在很久之后也会渲染出来 , 所以功能测试方面是没问题的 , 但是在性能方面就产生了很大的问题

假如我们某一天自研了两款软件 , 那怎么样评估这两个软件是好是坏的呢 ?
这就需要一定的标准来去进行评估
那性能测试的好坏最终都需要通过数据来展示 , 那就是通过性能指标对应的数据来判定性能的好坏

二 . 常见的性能指标

2.1 并发

我们可以类似乌鸦喝水的故事来理解

那大家要注意的是 : 并不是只要发出请求 , 服务器一定会造成压力

比如 : 乌鸦大家一起虎视眈眈的盯着这瓶水 , 并不会造成压力

只有当并发数达到一定程度的时候 , 才对服务器有可能造成压力

这里的并发强调的是大量用户和同时性的发送请求 , 这种情况才会对服务器造成压力

1. 大量用户
2. 同时
3. 发送请求

2.2 响应时间

在我们的整个 Web 模块中 , 基本是这样的架构

其中 , 里面包括了客户端与服务器之间的交互 , 服务器与数据库之间的交互
那响应时间就分为了前端展示时间和系统响应时间两个部分
前端展示时间指的是客户端收到服务器返回的数据后渲染前端页面 , 所耗费的时间 .
系统的响应时间 , 还分为 web 服务器、应用服务器、数据库服务器等各种服务器之间通信和处理请求的时间
那我们只需要知道响应时间大概是个啥即可

2.3 事务

事务指的是一整个流程操作中的其中一个操作
比如 : 我们做菜 , 需要洗菜、切菜、烹饪、刷碗洗锅
那中间的每个部分都是一个事务 , 事务是衡量系统处理能力的重要指标
每秒通过的事务数越高 , 那么性能就越好

比如 : 登录功能 , 每秒有越多的事物登陆成功 , 那么性能就越好

那么这句话 , 是相对来说的 , 并不是绝对的

比如 : 我们的提交订单事务

1. 增加一个订单数据 : 要添加数据库
2. 用户账户扣除余额 : 要修改数据库
3. 商品的库存要减减 : 要修改数据库

那这个事务 , 他的复杂度就比较复杂 , 因为大家都知道数据库往往是一个系统中最容易出问题的阶段 , 所以每个问题都是要各自分析的

拓展 : 在工作中 , 会有一个词 , 叫做 “技术事务”
其中 , 有可能会进行自动化、性能测试、混沌工程、数据监测 等等
混沌工程指的就是模拟一些突发情况或者故障情况 , 来推动提高系统的鲁棒性

每秒事务通过数 (Transaction Reponse Time)

每秒事务通过数 , 简称 TPS
衡量不同事务处理能力 , 是通过每秒事务通过数来衡量的

2.4 点击率

点击率与性能有关 , 当我们点击某个按钮之后 , 肯定会向服务器发送请求
但是有可能只发送一个请求吗 ?
比如我们随便点击一个页面 , 不可能只有一个请求

点击率就代表每秒向服务器提交的请求数

注意 : 点击率不是鼠标的一次点击 , 一次点击可能有多个请求

点击率越大 , 对服务器的压力越大

2.5 吞吐量

吞吐量指的是单位时间内系统处理的请求数量 , 体现的是软件系统的性能承受能力
吞吐量是受服务器性能和网络性能的影响的
吞吐量的单位是 : bytes/s

2.6 资源利用率

比如说我们的服务器会部署到一台机器上
那这台机器上就会有许多设备 , 比如 : CPU、硬盘、内存等资源
资源利用率指的就是不同系统资源的使用情况

三 . 性能测试的分类

分为一般性能测试、负载测试、压力测试、稳定性测试

3.1 一般性能测试

指的是在正常情况下和系统条件下是否满足性能指标
一般不会有太多的并发 , 主要是进行软件在安全的范围内进行测试

3.2 负载测试

验证系统在一定的压力下延长系统的运行时间 , 直到系统出现拐点

3.3 压力测试

验证系统在已经处于极限负载下或者某个性能指标已经处于饱和状态下性能的表现

一定要把系统搞崩溃 , 了解系统在什么时候才能崩溃 , 方便做好准备

3.4 稳定测试

验证系统在连续运行情况下 , 查看系统的各项性能指标

我们可以类比水瓶来理解这几种测试

但是实际上我们在执行性能测试的时候 , 步骤都是一样的

四 . LoadRunner 的使用

安装完 LoadRunner (LR) 之后 , 就会出现这三个图标

那这三个工具是用来干什么的呢 , 为什么是三个工具呢 ?
我们之前也介绍了 , 性能测试的指标才能评估性能的好与坏
那性能测试的指标对应的数据如何计算 ? 这就需要使用到我们的性能测试工具

1. Virtual User Generator : 虚拟用户发生器 , 简称 VUG , 在这里我们去编写性能测试的脚本
2. Controller : 创建和设计测试场景 , 运行测试脚本 , 监控场景运行 , 收集测试过程的数据

在性能测试中，“Controller” 是指用于创建、运行和监控测试场景的组件。它是性能测试工具（如LoadRunner）中的一个重要模块或组件。Controller 允许您定义和配置测试场景，包括虚拟用户数量、测试持续时间、并发用户数量等。一旦测试场景被设置好，您可以使用 Controller 来启动整个测试过程，并实时监控测试的执行情况，以便进行性能分析和评估。

3. Analysis : 分析性能测试结果 , 生成测试报告

4.1 VUG

打开 Virtual User Generator 工具 , 就会来到这个页面

接下来 , 先创建性能测试脚本的工程

接下来 , 就会有一个弹窗

我们测试的是 Web 页面 , 所以选择 Web 协议

接下来来看一下我们的项目组成

那我们现在要打开一个 Web 系统进行测试 , 我们可以先打开 LoadRunner 自带的 Web 系统来模拟
找到 LoadRunner 的安装路径 , 打开 WebTours 目录 , 双击 StartServer.bat

我这里是这个路径 : C:\Program Files (x86)\HP\LoadRunner\WebTours\StartServer.bat

就会弹出一个黑框框

注意 : 性能测试结束之前 , 不能关闭这个窗口

然后在浏览器中访问 127.0.0.1:1080/WebTours

我们可以在左侧部分登录
那账号密码是什么 , 我们可以去安装路径下面的 WebTours 下面的 cgi-bin 下面的 users 中

我这里面的路径是这个 : C:\Program Files (x86)\HP\LoadRunner\WebTours\cgi-bin\users

我们就可以看到账号信息

我们可以打开这个文件 , 查看一下账号密码

使用记事本打开

我们可以修改一下账号密码
修改账号 : 修改第二行的 Jojo
修改密码 : 修改第一行的 bean 修改成你想要的密码即可
那我们要想创建多个用户的话 , 拷贝出多个 jojo 文件 , 然后重命名 , 比如 one two …
然后就可以修改 one two 里面的账号密码即可

那接下来 , 我们就可以去编写我们的性能测试脚本了
那 LoadRunner 很贴心 , 他会帮我们给出一些常用的性能测试的函数框架


首先 , 我们要访问 http://127.0.0.1:1080/WebTours/ 的首页 , 那我们就要搜索 url 相关的函数


我们的访问主页的函数就实现好了

接下来去实现输入登录的账号和密码功能

模拟账号 : jojo
模拟密码 : bean

那我们就需要抓一下包看看数据传输使用的是哪种格式
我们抓包之后 , 发现数据传输使用的是 form 表单的形式

所以我们选择 web_submit_form



对照我们谷歌浏览器抓到的包 , 我们来添加要传输的数据
我们只需要传输账号密码 , 所以我们只需要添加账号和密码的键值对即可

接下来点击 Add 添加键值对

注意 : 这里提交的是 key-value 形式的
我们要添加两组键值对 , 分别是 username-jojo , password-bean
而不是添加 jojo-bean 这样的一组键值对

我们就可以发现 , 提交函数也顺利完成了

那脚本已经写完了 , 我们怎么知道对不对呢

这就相当于我们申请了一个虚拟用户来执行脚本代码
那我们就打印成功了

刚才的按钮是运行 , 还有一个按钮 , 叫编译

那我们来看一下打印出的日志

当我们点击某个日志 , 页面还会有光标闪烁一下提醒对应的位置

以上是最简单的性能测试脚本的写法 , 但是这种写法不足以让我们进行性能测试数据的收集
举个例子 :
那么我们要是只想观察到提交功能的性能指标 , 目前还实现不了
或者我们目前只是实现了一个 jojo 用户的测试 , 那么我们还需要让用户参数化 , 能够使用更多虚拟用户来进行测试
或者我们的虚拟用户设置成很大的数字 , 那么我们想要对登录功能进行性能测试 , 那我们需要让所有的虚拟用户在登录功能之前停一下 , 等到所有的虚拟用户都执行到登录这里 , 大家再一起进行登录操作

并发 : 大量用户 同时 进行操作

那所以我们需要进行性能测试脚本的增强

4.1.1 添加事务

添加事务 : 在想要测试的函数前后添加事务 , 通过前后标注事务 , 就可以统计出要测试的函数的测试指标
搜索 lr_start_translation




那这样 , 开启事务和结束事务我们都创建成功了
运行一下

事物之间是可以嵌套的 , 但是插入了开启事务 , 我们就一定要插入结束事务
我们可以再统计一下整个流程的事务




那 index 的事务也生成完成

那有个问题 , index 事务能不能放到 login 事务中间

这是可以的 , 但是不推荐 , 我们指事物的嵌套是大套嵌小套 , 而不是两个嵌套交叉重叠

运行一下

4.1.2 添加集合点

假如我们后续创建 10W 个虚拟用户去执行编写好的性能测试脚本 , 不能保证所有的虚拟用户都同时的去执行每一步

意思就是有的虚拟用户才走到主页 , 有的用户已经登录了

集合点的作用就是让虚拟用户执行到集合点的时候进行短暂的整队 , 在满足条件后一起执行下一个步骤

举个例子 : 红灯的时候 , 所有行人就都需要在路口等待 , 这就是集合点

集合点是真正意义上的模拟了并发
添加集合点的关键词是 lr_rendezvous


这样的话集合点就创建成功 , 代表所有的虚拟用户都会在登陆之前整队 , 然后一起进行登录操作

接下来运行一下 , 看一看集合点打印出来的相关信息

集合点的其他信息我们只能在 controller 中看到
那就让我们拭目以待吧

4.1.3 设置检查点

假如现在是这种情况 : 我们登录的是 one 的账号 , 那欢迎界面就应该是 Welcome One

但是万一系统发生错乱了 , 我们登录的是 one 这个账号 , 但是打印的确是 jojo 账号 , 所以我们需要设置检查点来检查这个错误
我们的思路就是在登陆之前先检查页面是否有 jojo 这个元素 , 正常情况下登录页面是不会有 jojo 的信息的
等登录 jojo 账号之后 , 欢迎页面就会有 jojo 关键字出现
根据关键词去匹配 , 我们的关键字是 web_reg_find


我们的代码就插入成功了

运行一下

我们需要注意的是 , 检查点应该放在登录操作之前
我们可以模拟一下放在登录操作之后


我们把错误信息复制 , 翻译一下

他的意思就是检查点必须要放在请求之前 , 之前的任意位置都可以
这是因为我们在登陆之后去检查是否存在 jojo , 那肯定存在 , 因为我们已经输入了 jojo 元素

4.1.4 参数化

用户不可能只登陆 jojo 这一个账号 , 所以我们不能只使用一个账号来进行测试 , 我们就需要利用参数化模拟出许多账号
比如我们先对用户名进行参数化


接下来 , 会弹出一个弹窗 , 意思是你想要去替换所有的参数吗 ? 我们选择 No , 我们只想替换 jojo

这样的话 , 原本 jojo 的位置就被替换成了 {username}
那我们参数化的文件来源放到哪里呢 ?

我们双击 Parameters

接下来 , 是 File Path , 指的是数据源的来源 , 我们可以点击右边的 Browses



我们发现 , 第一行就是变量名 , 第二行就是我们变量对应的取值了

那我们可以在后面添加上其他的账号

保存之后 , 回到刚才的页面

我们需要退出重进 , 就可以看到新的账号的信息了
在底下 , 还有一些其他的按钮

下面还有一个 Select column


右面还有一个 File format , 无需关注

下面还有一些其它参数

我们再整体叙述一下每样功能

那我们设置完这些参数之后 , {username} 就会从我们设置的数据源从第一列顺序的去取数据
但是每一次我们运行性能测试脚本 , 他只会运行一遍
那这一遍使用的是哪个参数呢 ?

那我设置的这么多参数 , 怎么设置成让他们都各自执行一遍呢

修改上面的 3 , 并不会影响 init 和 end 脚本

这次再次运行

这个位置如果报错 , 是因为我们 one 的账号之前密码设置的是 one , 而代码中密码目前设置的是 bean , 所以我们需要修改一下 one 账号的密码和添加 two 账号相关信息
来到这个目录下 : C:\Program Files (x86)\HP\LoadRunner\WebTours\cgi-bin\users
修改 one 文件内容

选中其中一个文件 , 复制一份 , 将文件名改成 two

接下来 , 运行代码

那每一次迭代是否真的使用了不同的参数呢
我们以第三次迭代为例 , 来看一眼

那我们设置遍历 5 次呢 , 我们设置了 3 个参数

再次执行
先来看第三次执行的时候 , 我们使用的是 two 这个参数

再来看第四次 第五次的时候

这就代表当我们的迭代次数 > 参数个数的时候 , 会循环执行我们已有的参数

目前的代码

Action()
{
	// 事务: 在最刚开始添加一个开始事务
	lr_start_transaction("index_trans");

	// 1. 访问 webTours 主页:http://127.0.0.1:1080/WebTours/
	// 注意:需要带上协议名,推荐从浏览器中复制
	web_url("index",
		"URL=http://127.0.0.1:1080/WebTours/",
		"TargetFrame=",
		"Resource=0",
		"Referer=",
		LAST);

	// 集合点: 所有的虚拟用户来到这里都会整队,直到所有虚拟用户都来到了这里
	lr_rendezvous("login_rendezvous");

	// 事务: 在登陆之前添加开始事务
	lr_start_transaction("login_trans");

	// 2. 在登陆之前先检查页面是否有 jojo 元素
	web_reg_find("Text=to the Web Tours reservation pages.",
		LAST);

	// 3. 输入账号密码
	web_submit_form("login",
		ITEMDATA,
		"Name=username", "Value={username}", ENDITEM,
		"Name=password", "Value=bean", ENDITEM,
		LAST);

	// 事务: 在登陆之后添加结束事务
	lr_end_transaction("login_trans", LR_AUTO);

	// 事务: 在最后面添加结束事务
	lr_end_transaction("index_trans", LR_AUTO);

	return 0;
}

4.1.5 脚本录制

我们新创建一个项目来模拟录制场景


在状态栏的这个位置就有录制按钮

使用录制功能 , 我们只需要在页面上操作操作 , 代码就会自动生成

我们点击 Start Recording 之后 , 就会自动跳转到 IE 浏览器

前提 : 你需要有 IE 浏览器

这样 , 就会自动弹出 IE 浏览器

输入账号密码 , 点击 Login


我们就可以看到 , LoadRunner 自动帮我们把代码生成了

那脚本录制的时候 , 右侧还出现了一个小悬浮窗 , 里面也有很多按钮 , 里面就可以添加事务、结束事务、添加集合点等操作

如果 IE 浏览器自动跳转到 Edge 浏览器 , 可以这样做
打开 IE 浏览器 , 右上角有三个齿轮 , 也就是设置 , 选择高级 , 找到启用第三方浏览器扩展 , 关闭掉

第一步 : 先添加事务

第二步 : 输入账号密码 , 点击登录

第三步 : 添加结束事务

第四步 : 点击结束

我们可以看到 , 代码也就被生成了

那这里面还有一个添加集合点的按钮 , 大家可以自己去尝试

4.2 controller

controller 的作用是运行 VUG 里面的测试脚本 , 创建和设计测试场景
我们可以直接在桌面上打开 controller , 也可以在状态栏中打开

虚拟用户数可以设置成 3 个 , 一般电脑都能承受得住

点击 OK , 然后稍等片刻

4.2.1 Design 页面

我们来分析一下页面构成


接下来分析 Global Schedule , 他有好几个选项 , 我们分别来看

第一个 : 初始化虚拟用户 Initialize , 在脚本运行之前初始化虚拟用户的策略
我们双击一下 Initialize

选项一指的是当我们一开始的场景 , 所有的虚拟用户都会迅速地初始化
选项三指的是当虚拟用户要执行对应的操作之前 , 才去初始化

那我们选择第二个 , 设置成 10 s 初始化一个

第二个 : 开始我们的虚拟用户
在 Initalize 阶段 , 就相当于每个用户先学跳舞 , 为后续的舞台表演做准备
那开始执行虚拟用户阶段 , 指的是现在要上台了 , 每个同学都需要化好妆并且为下一步的上台演出做准备

第三个 : 指的是每个虚拟用户运行多久

我们设置成第二个选项 , 循环执行 1min

第四个 : 退场

点击 OK 之后 , 右侧就生成了一个图形

那图形的变化 , 就是根据我们左侧大概的设置 , 推测出虚拟用户大概的状态图

在底下的状态栏中 , 有两个重要的按钮 : Design、Run

Design 就是我们刚才设置参数的界面
那我们来看一下 Run 页面

4.2.2 Run 页面

页面构成

Run 页面就长这个样子

我们逐步拆分一下
左上角 : Scenario Groups

右上角 :

再来看中间部分

我们可以转化成图表来看

那中间部分就会展现出我们目前的一些指标对应的图表等等

如果只展示两个的话 , 查看一下这里的设置

这样就可以展示四个 , 我们还可以设置展示成 8 个等等
但是有的同学可能设置成 4 个之后页面还是显示两个 , 我们点一下缩小屏幕 , 再点一下扩展全屏应该就可以了

接下来我们就执行一下性能测试脚本

我们发现性能测试脚本已经跑起来了 , 风扇也开始呜呜的转了

等到像图片中这样 , 就代表三个虚拟用户都已经执行完毕 , 就会自动打开性能测试报告 Analysis
我们还是分析当前页面 , 右上角就会展示出本次性能测试的一些信息

那我们就看一下失败的事务都有哪些

下面还有 Errors , 点击 Errors 会加载我们有哪些错误

截图待复制

那页面中部也展示出了一系列的图表
我们点击第一个

图表分析

虚拟用户运行状态

那这四个内容 , 就代表四条线
那从 Error 来看 , 他一直在最下面 , 那就代表稳定执行

那 Running 这条线 , 就是刚开始虚拟用户逐步创建 , 然后一直运行 , 最后逐个销毁的过程

每秒事物的响应时间

注意 : 我们只是在脚本里面写了两个事物 , 但是这里面怎么出现了五个事务 ?

那再来看我们下方具体的每秒事务的响应时间
vuser_init_Transaction : 在最刚开始的时候会创建虚拟用户 , 而且只会执行一次 , 所以就在刚开始那一段

与之对应的 , 就是 vuser_end_Transaction , 只有当 Action 执行完之后 , 再去执行一次 vuser_end_Transaction

再来看 Action , 刚开始比较高 , 在 40s 的时候慢慢就趋于平滑

我们再来看我们自己创建的两个事务
index_transaction : 貌似跟 Action 重叠了

因为 index_transaction 是创建在 Action 的刚开始和结束位置的 , 就可以替代一下

但是登录的事务 , 也就是 login_trans 就不会重叠

我们来观察这个图表

每秒点击数

来搭配运行过程一起分析

吞吐量

选中一个图 , 双击便可以放大

基本的走向是这样的

那我们来分析一种特殊情况

---

小结 :

其他 : 系统资源图表

我们再回到这个下拉框页面

有一个选项叫做 System Resource Graphs , 系统资源图表
比如 : 我们在自己的机器上 , 运行性能测试脚本 , 这个脚本可能会请求一些服务 , 那请求服务是在我们的本地发送请求 , 就相当于主动打开了浏览器 , 进行了一些请求的对应服务 , 就有可能对我们的机器造成一定压力
其中 , 他有三个属性 :

那我们想测试性能测试脚本在我们的机器上能否承受得住 , 那就可以添加这个图表
我们需要先开启 Windows 系统的一些设置

直接跳到第四点

番外 4 : LoadRunner 的安装
那我们就来看看我们选择的两个参数是什么意思

那我们运行脚本之后就可以看到系统资源的消耗了

那接下来 , 就会自动打开 Analysis 分析报告了

没有自动打开的 , 需要设置这里 , 就会分析性能测试结果 , 生成性能测试报告

这两个我们都需要选中

4.3 Analysis

接下来 , 我们就来到了性能分析报告的页面

先来看左上角 :

我们点击性能测试报告

4.3.1 性能测试报告

4.3.2 性能测试图表

Running Vusers 运行的用户虚拟图

根据显示的运行虚拟用户数量可以判断出在哪个时间段内给定服务器的负载
当虚拟用户最大的时候 , 服务器也就是负载最大的时候

Hits per Second 每秒点击数(点击率)

我们每秒的点击数越多 , 这也就代表每秒发送过去的服务越多

通过点击率也可以判断出某段时间内服务器的负载

Throughput 吞吐量图

我们将每秒点击数和吞吐量图放在一起 , 他们的形状是有一些相似的 , 但是吞吐量曲线稍微滞后一点

那这是为什么呢 ?
点击数图形指的是我们需要在页面上点击一下 , 之后才会给服务器发送请求
而吞吐量指的是服务器已经接收了请求 , 在请求处理之后把请求返回回去
那吞吐量就肯定是要在点击数之后了
这样说比较官方 : 因为吞吐量表示的是响应返回的资源数量 , 肯定是先有请求再有返回

那假如请求变多 , 但是吞吐量没什么变化或者降低 , 可能的原因是什么 ?

1. 服务器响应慢了 , 来不及响应
2. 压力没有到服务器

比如 : 上传速率很低 , 用户发送请求之后好久还没发送到服务器 , 那如果所有用户是在同一时刻点击的 , 那点击数就会暴增 , 但是发送的请求到服务器需要的时间变的特别长 , 压力就还没来到服务器 , 没办法处理吞吐量就没办法变高 . 那服务器在收到请求之前这段时间 , 吞吐量肯定会降低

3. 服务器设计一定的阈值 , 超过多少个请求之后就不返回响应了

Transaction Summary 事务总结图

Average Transaction Response Time 平均事务响应时间

通过这个图 , 我们可以得到虚拟用户在性能测试过程中 , 每秒在服务器上命中的次数

如果出现了事务的响应时间 (纵坐标有值了) , 而响应又是在发起请求之后 , 所以我们就可以推出该响应命中了

通过命中次数 , 可以帮助我们评估当虚拟用户增多 , 根据响应时间的变化 , 从而评估服务器的负载

Windows Resources 系统资源图表

我们在 Controller 中还开启了系统资源图表的检测 , 但是这个页面上没有 , 我们怎样将系统资源图表调出来呢 ?

---

那接下来来看我们生成的图表

至此 , 性能测试基础讲解结束~