作用域: 指作用范围(比如编程语言的变量),指当前组件对哪些范围的取样器生效
分类:
-
取样器自身:
-
无所谓作用域，因为在作用域作为参考物存在的
-
-
以结果树为代表的大多数组件:
-
测试计划下: 对所有取样器生效
-
线程组下: 对当前线程组的取样器生效
-
取样器下: 对当前取样器生效
-
-
以逻辑控制器为代表的部分组件:
-
只对子级取样器生效
-
1.2执行顺序
JMeter 中组件的执行顺序与添加顺序不一定有关系，JMeter 的组件有默认的执行顺序
各元件之间的执行顺
1) 配置元件(config elements) == HTTP信息头管理器、HTTP请求默认值....（执行初始化数据）
2) 前置处理器(Pre-processors) == 用户参数(封装取样器所需数据)
3) 定时器(timers) == synchronizing Timer、Constant Throughput Timer....(控制取样器的执行规则)
4) 取样器(Sampler) == HTTP请求、JDBC请求...(核心:向服务器发送请求)
5) 后置处理程序(Post-processors) == XPath、正则表达式提取器...(提取取样器的执行结果)
6) 断言(Assertions) == 响应断言、大小断言、断言持续时间...(判断响应结果)
7) 监听器(Listeners) == 查看结果树、聚合报告...(查看所有组件的最终运行结果)
口诀: 先两头，再核心，最后中间
1、制定测试计划,分配任务
| 任务名称 | 任务描述 | 责任人 | 工期 | 开始日期 | 结束日期 | 进度 | 备注 |
|---|---|---|---|---|---|---|---|
| 环境搭建 | 安装并运行学生管理系统 | 运维组葫芦娃 | 1 | 01/01 | 01/02 | 进行中 | |
| 学院模块接口测试 | 测试学院增删改查接口 | 测试一组凹凸曼 | 3 | 01/02 | 01/05 | 未开始 | |
| 班级模块接口测试 | 测试班级增删改查接口 | 测试一组穿山甲 | 3 | 01/02 | 01/05 | 未开始 | |
| 学生模块接口测试 | 测试学生增删改查接口 | 测试二组哥斯拉 | 4 | 01/02 | 01/06 | 未开始 | . |
2、从 API 文档中提取接口清单
-
API 文档为了保证易读性，说明性信息较多，导致测试过程中，API 文档内容稍显冗余
-
需要从 API 文档提取测试必须的数据，摒弃冗余数据(提取结果: 接口清单)
3、设计测试用例并参数化覆盖测试用例
4、编写脚本实现，并导入设计的测试数据
核心知识点: 参数化之 CSV 数据文件设置
5、测试结果汇总，BUG提交
3.1 概念
3.项目实现之功能测试
功能测试: 所有接口逐一测试(覆盖率 100%)，测试时需要模拟用户的多样性操作提交各种测试数据
3.2 实现
3.2.1 测试用例设计
1)、设计测试用例
测试用例的设计原则
1. 覆盖所有的必选参数
2. 组合可选参数
3. 参数边界值 = 征兵系统，年龄:[18-24],既要设计 18 又要设计 24，边界值后端算法实现比较容易出问题
4. 越界的数据 = 征兵系统，年龄:[18-24],超出了区间取值的一些数据
5. 如果参数的取值范围是枚举变量，需要覆盖所有枚举值=性别既要测试男也要测试女排序既要测试正序又要测试倒序
枚举值: 程序中的常量,比如性别、排序方式....
6. 空数据 = 字段录入时是一些空格或无录入
7. 包含特殊的字符 = 字段录入时，使用了 #$%@.... 等特殊符号
8. 错误的数据 = 逻辑错误、格式错误...
2)、参数化覆盖测试用例
-
使用 CSV文件存储测试数据
-
测试数据设计时，参考测试用例
3.2.2 测试脚本编写
知识点: 参数化 CSV 数据文件设置
-
编写被复用的脚本
-
设计 CSV 文件存储测试数据,注意:
-
路径选择，建议和脚本平级(保证脚本的可移植性)
-
编码使用 UTF-8
-
-
添加中间件关联脚本与数据
-
R = 读取 CSV 文件
-
W = 将数据导入脚本
-
循环读写
-
3.2.3 测试报告生成
| 功能名称 | 用例描述 | 预期结果 | 实际结果 | 是否BUG | 备注 |
|---|---|---|---|---|---|
| 学院新增 | dep_id有特殊字符 | 添加失败 | 添加成功 | 是 | dep_id 左右两侧有空格，去除属于合理操作 |
| 学院新增 | dep_id超长 | 添加失败 | 添加成功 | 是 | . |
4.项目实现之自动化测试
4.1 概念
自动化测试: 程序驱动代替人工驱动实现的测试
4.2 作用
场景: 程序升级时，会实现自动化测试
举例:
-
今日头条程序升级,从版本 5.0 升级到版本 6.0
-
今日头条添加新的功能实现
-
新增的功能(新接口)可能会影响原有的功能(接口)
上线之前，必须测试原有的接口是否能够正常运行(使用自动化测试完成的)
4.3 实现
自动化测试原则:
1.只需测试重要的或被重复调用的接口(覆盖率不必 100%)? 新增的接口影响有限
2.只需设计正向用例(只是测试接口是否能正常运行，之前已经实现了功能测试)
3.自动化脚本可以重复执行(功能测试脚本不能重复执行,重复执行前需要删除数据库)?怎么实现的重复执行?
4.一个线程组只设计一个取样器(符合封装的思想,解耦合)
....
自动化测试知识点分析:
-
参数化生成测试数据
-
使用断言判断响应结果
-
使用 tearDown 线程组执行最后的数据删除操作,使用 setUp 新增数据
-
HTTP 请求默认值、用户定义的变量
-
跨线程组关联(重点) == setProperty 与 property 和 提取器
-
还可以通过直连数据库获取新增学院的 ID
PS: 自动化测试时建议顺序 = 增改查删,怎保证顺序，保证改查的编写顺序，勾选独立运行每个线程组
5.项目实现之性能测试
5.1 概念
性能测试: 模拟生产环境下的各种场景，向服务器施加负载，测试各项性能指标是否达标
-
场景: 并发、高频率、区间多用户.....
-
指标: 响应时间、错误率、吞吐量 .....
5.2 作用
1.技术选型
2.测试当前程序所能支持的最大负载
3.发现程序中性能瓶颈, 提高资源利用率
4.提升用户体验
.........
5.3 实现
5.3.1 设计原则(了解)
1.线程组：增删改查每一个功能点，都需建立单独线程组，而避免在同一个线程组内添加多个取样器
一个线程组只设计一个取样器(符合封装的思想,解耦合)
2.参数化：参数化尽量避免采用从外部读取参数(CSV 组件)，而是使用 前缀_函数 生成测试数据?
避免资源耗费,性能测试资源开销本身就比较客观，应该尽量杜绝一些无意义的资源占用
3.察看结果树：必须清除单个接口内或线程组内的察看结果树，建议一个测试计划就一个结果树?
同上
4.报告：性能报告可根据实际需求选择，建议保留添加 聚合报告?
可以对所有结果汇总并统计，结果显示更为直观(平均响应时间、错误率、吞吐量....)
5.分布式：如并发数量大，采用分布式测试
6.新增/删除/修改：建议不要采用时间模式(定时器:常量吞吐定时器、同步定时器...)来压测，直接使用线程数和循环
因为实际场景中，用户操作最常用的是查。
5.3.2场景1:模拟半小时之内 1000 个用户访问服务器资源，要求平均响应时间在3000ms内，且错误率为0
区间多用户
5.3.3场景2:模拟 100 个用户同时访问服务器资源，要求平均响应时间在3000ms内，且错误率为千分之五之内 (高并发)
同步定时器
5.3.4场景3:模拟2个用户以20QPS的频率访问服务器资源持续10秒,要求平均响应时间在3000ms内,错误率为0(高频率)
常量吞吐定时器
5.3.5 生成图形化测试报告
在 JMeter 中可以以图形化（饼状图、柱状图...）的方式显示脚本运行结果，较之于聚合报告或查看结果树组件实现更直观，用户体验更友好
前提: 配置 PATH 环境变量
生成图形化测试报告，命令:
Jmeter -n -t 脚本 -l 日志文件 -e -o 目录
-n: 无图形化运行
-t: 被执行的脚本
-l: 日志文件
-e: 生成测试报告
-o: 指定输出目录
PS:
保证日志文件为空或不存在
保证目录为空或不存在