-
设计本套脚本结构方案的原因
Jmeter元件组合过于灵活,需要人为约定一套规则
易维护性
效率(大多数接口自动化项目主要用来回归,回归对效率要求很高)
合作
查看全部 -
基础检查 正常多角度 异常多角度 必录检查项 边界值检查
查看全部 -
整体方案展示
查看全部 -
不错错查看全部
-
jmeter.git
查看全部 -
用例模块实战讲解
模块功能说:该模块见面知意,主要基于用例分类的思想来进行测试用例的维护。
思路查看全部 -
注意
通用模块库中各层级控制元件的名称,后续维护不要轻易改变,以防用例模块调用通用模块失败。
查看全部 -
通用模块库实战讲解
模块功能说明
该模块主要用来归集汇总后面用例模块需要调用的公共模块,包括数据准备相关、接口正反例通用模块等
该模块还没有“历史常用组件/模块设计参考”,下面主要归集以前项目曾经设计的比较好的模块保存下来,以备后面项目参考使用
思路
使用“测试片段”元件作为该模块的顶级层级
使用“简单控制器”元件作为通用模块库的第二层级,用来对通用模块做分类使用,方便维护
第三层级使用“事务控制器”元件作为我们归类汇总的通用模块的最顶层
查看全部 -
全局参数配置模块的元器件应该放在测试计划下面的顶部,其他元器件根据需求可以放在对应的结构下
查看全部 -
全局参数配置模块实战讲解:
模块功能说明:全局参数配置模块主要利用配置元件,配置管理全局的测试数据、运行参数、
数据库配置以及其他测试中需要的全局类的配置。
思路:使用“用户自定义变量”元件配置管理全局测试数据、使用“用户自定义变量”元件配置与脚本运行相关的全局参数、使用“DNS Cache Manager”元件配置测试用的DNS服务地址(看项目情况是否需要用)、使用“计数器”元件配置一个计数变量、用于某些用例的使用、使用“JDBC Connection Configuration”元件配置管理测试数据库连接
查看全部 -
设计本套脚本结构方案的原因:
Jmeter元件组合过于灵活
易维护性
效率
合作
整体方案展示:
全局参数配置:测试数据配置、运行参数、DNS配置、数据库配置
通用模块库:当前脚本通用模块库(数据准备、接口正反通用模块)、历史常用组件/模块设计参考
用例模块:用例分隔符(采用测试片段元件实现)、用例组(采用线程组元件实现)、用例ABCD分类(采用事务控制器元件实现)
测试结果展示:用表格查看结果、查看结果树、聚合报告、断言结果
查看全部 -
目前常用的接口自动化工具:LoadRunner、PostMan、Python+Request+Unittest,Java+HttpClient+testNG、soapUI和soapUI Pro、RobotFramework+HttpLibrary、Jmeter
Jmeter接口自动化优劣:
优点:支持脚本录制、支持多平台部署、支持Jenkins集成,实现CICD、一学二用(即可做接口又能做性能测试),学习产出比高、开源免费、丰富的元件及第三方插件、支持BeanShell脚本,方便二次开发及引入Jar包,满足测试需求
查看全部 -
设计本套脚本结构方案的原因
jmeter原件组合过于灵活
易于维护
效率
合作
脚本结构方案
全局参数配置
测试数据配置:静态测试数据(初始数据)、动态测试数据(动态生成的数据)
运行参数
DNS
数据库配置
通用模块库
当前脚本通用模块库
数据准备
接口正反例通用模块
历史常用组件、模块设计参考
用例模块
用例分隔符(采用测试片段元件实现)
用例组(采用线程组元件实现)
用例ABCD分类(采用事务控制元件实现)
测试结果展示
用表格查看结果
察看结果树
聚合报告
断言结果
查看全部 -
https://github.com/jinganglong123/JinGang-Jmeter/tree/master/demoCase
https://github.com/jinganglong123/JinGang-Jmeter.git
查看全部 -
jmeter接口自动化测试脚本结构
设计原因:
元件组合灵活。
易维护性。自动化测试脚本后期的维护成本,考虑设置可维护的参数变量。
测试效率。例如回归测试。
团队合作。提前制定一套团队合作方案,沟通成本大大降低。
脚本方案
用例模块:针对自动化测试的用例做统一管理。
全局参数配置
测试数据:静态测试数据和动态数据。
静态数据:事先准备的基础数据。(主要配置)
动态数据:接口自动化过程中,动态生成的数据。
运行参数
DNS配置
数据库配置
通用模块库
测试结果
查看全部
举报