软件测试基础理论
文章目录
- 软件测试基础理论
- 常用DOS命令
- 计算机网络体系
- Jmeter知识点
- 1 接口测试分类
- 2 目前接口架构设计
- 3 接口测试工具
- 4 Jmeter简介
- 5 Jmeter常用组件
- 6 Jmeter接口测试流程
- 7 Jmeter接口测试实战
- 8 Jemeter接口关联
- 9 Jmeter动态参数处理
- 10 Jmeter接口测试断言
- 11 Jmeter接口测试调试方案
- 12 CSV参数化的处理(反例测试)
- 13 Jmeter脚本录制功能(没有接口文档的情况下)
- 14 Jmeter中的Bean Shell组件和语言规则
- 15 BeanSell内置的变量和语法规则
- 16 Jmeter执行数据库操作
- 17 Jmeter的非GUI(界面)方式运行
- 18 使用Jmeter+Ant+Git+Jenkins实现持续集成
- Postman知识点
1 什么是软件
定义:软件是计算机程序、程序所用的数据以及有关文档资料的集合。(软件=程序+数据+文档)
软件分为两大类系统软件(如Windows、Java编译环境)和应用软件(如QQ、微信)
2 什么是软件测试
定义:使用人工和自动化手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
目的:
- 为了发现程序存在的代码或业务逻辑错误
- 为了检验产品是否符合用户需求
- 为了提高用户的体验
3 软件测试的分类
- 按测试阶段划分:单元测试、集成测试、系统测试、验收测试
- 单元测试:主要测试程序代码,确保个单元模块被正常的编译。(对代码进行测试 执行者:开发人员)
- 集成测试:把多个模块/喊出组装到一起进行的测试。(对代码进行测试 执行者:开发人员)
- 系统测试:计算机程序结合外设+网络扽其他元素进行的测试。如QQ(执行者:测试人员)
- 验收测试(Alpha测试、Beta测试):主要是以用户为主进行的测试。主要分为α测试和β测试
- α测试:把用户请到开发方对软件进行的测试,测试环境受开发方控制,测试人不多,测试时间比较集中。(执行者:测试人员、用户、公司内部人员)
- β测试:测试环境不受开发方控制,测试人比较多,测试时间不集中。
- ==两者区别:==1. 测试场所不一样 2. 一般先做α测试再做β测试
- 按测试技术划分(是否查看代码划分):黑盒测试、白盒测试、灰盒测试
- 黑盒测试:只需要关注外部的输入和输入,不需要关注程序内部的逻辑。
- 白盒测试:需要关注内部逻辑具体实现,而不需要关注外部的输入与输入。
- 灰盒测试:需要关注外部的输入和输入,也需要关注程序内部的逻辑。(两者都需要关注)
- 按被测对象是否运行划分:动态测试、静态测试
- 动态测试:运行被测系统、而进行的测试。
- 静态测试:不需要运行被测系统,而进行的测试。(界面检查 文档检查 代码走查)
- **按不同的测试手段划分:**手工测试(点点点)、自动化测试(代替手工、 工具/写代码)
- **按测试包含的内容划分:**功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试
- 功能测试:验证软件的业务功能是否符合需求。
- 界面测试:被测系统的界面与原型图是否一致。
- 安全测试:对被测系统的安全进行的测试。(如 银行卡密码多次输入是否冻结 Sql注入)
- 兼容性测试:被测系统在不同的测试环境下是否正常。(如 淘宝(B/S)使用不同浏览器:ie/chrome/firefow 苹果/安卓)
- 易用性测试:被测系统的各个功能是否操作方便、是否易懂、是否容易上手。
- 性能测试:某个特定的时间,用户数量剧增,软件的功能是否正常。
- 其他测试:冒烟测试、回归测试、探索性测试/自由测试(测试思维)
- 冒烟测试:类比硬件测试,在进行正式测试前对主要核心功能进行的测试。(执行者:开发、测试主管)
- 回归测试:开发对存在问题的功能进行修改后,再一次进行的测试。
- 探索性测试:根据自己项目经验而进行的随意测试(结合测试思维)。
4 软件的生命周期
定义:软件开始研制到最终被废弃不用所经历的各个阶段
一、 问题定义及规划
主要确定软件开发目的及其可行性,指定总体开发计划。
二、 需求分析
确定开发可行的情况下,对软件需要实现的各功能进行分析,明确客户需求,输出需求规格说明书(SRS)(原型图)
三、 设计
把需求分析得到的结果转换为软件结构和数据结构,形成系统架构。包含概要设计和详细设计
概要设计:主要是架构的实现,指搭建架构、表述各模块功能、模块结构链接和数据传递的实现等。
详细设计:对概要设计中表述的各模块进行深入分析,其中需要包含数据库设计说明。
四、 编码
按照详细设计好的模块功能表,开发人员编写出计算机可运行的代码
五、 测试
在软件设计完成后要经过测试,以发现软件在整个设计过程中存在的问题并加以纠正。测试的方法主要有白盒测试和黑盒测试两种,建立详细的测试嘉华并严格按照计划进行。主要分为单元测试、集成测试、系统测试、验收测试
六、 运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的需求。要延续软件的使用寿命,就必须对软件进行维护。主要分为纠错型维护和改进性维护两个方面。
5 软件生命周期模型
-
瀑布模型
- 特点:自上而下、有顺序性和依赖性
- 缺点:测试介入比较晚–>回溯成本比较高、测试周期比较长
- 流程:
- 问题定义及规划:确定软件开发目的及其可行性
- 需求分析:对各功能进行分析,明确客户需求,输出需求规格说明书(原型图)
- 设计:包含概要设计和详细设计
- 编码
- 测试
- 运行维护
-
V模型
- RAD(快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,又称V模型。
- RAD(快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,又称V模型。
-
敏捷开发模型
- 一种以人为核心、迭代、循序渐进的开发方法。是一个用于开发和维持复杂产品的框架。把一个大项目分为多个相互联系,但也可以独立运行的小项目,并分别别完成,在此过程中软件一直处于可使用状态。
- 特点:快速、弱化文档,通过人与人之间的沟通实现需求分析
6 软件测试的工作流程(重点!!)
-
测试计划:测试工作统筹安排(测试内容、哪些人、任务分配、测试环境、工具、时间安排)—测试负责人/主管/组长
-
编写测试用例:具体怎么来进行测试的文档
-
发布上线的标准:Bug遗留率(趋近于0%)+测试覆盖率(趋近于100%)
测试覆盖率:测试用例覆盖率(影响因素:测试点覆盖率)+测试用例执行率
测试点覆盖率(测试需求分析)是决定测试覆盖率的重要指标。
发布流程:开发打包–>运维/开发–>部署到生产环境
开发环境:开发人员写代码的环境
测试环境:测试人员进行测试的环境(1个或1个以上)
预发布环境(UAT环境):验收测试(UAT测试)进行的环境
生产环境:真实的用户使用环境
7 软件测试的基本流程(重点!!)
-
测试需求分析阶段:根据需求规格说明书(原型图)熟悉业务流程、明确测试内容,再针对某个功能去细分需求,提取测试点。
-
测试计划阶段:主要任务是编写测试计划,根据软件需求规格说明书、项目总体计划,内容包括测试范围(来自需求文档)、进度的安排、人力物力分配、整体测试策略指定。(一般由测试负责人编写)
-
测试用例设计阶段:主要任务是编写测试用例文档,根据需求规格说明书(原型图)、概要设计、详细设计等文档。用例编写后会进行评审。
-
测试用例评审阶段:主要评审用例的覆盖率、错写的测试用例。
-
测试执行阶段:产出测试bug。首先搭建测试环境,执行冒烟测试,一判定当前版本可测与否,若通过,正式进入系统测试,遇到bug提交到缺陷管理平台,并对bug进行跟踪,知道被测软件大道测试需求要求,没有重大bug。—(完善测试用例)
-
测试评估阶段:产出测试报告,对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线。
8 如何进行软件测试需求分析?
-
测试需求分析的主要目的:依据需求规格说明书(原型图)提取测试点,根据测试点来编写测试用例。
-
测试点:软件包含多个功能点,每个功能点包含多个子功能(测试点),测试点是软件功能细分的最小单元。测试点不包含测试数据,但必须是可核实可观察的结果。
-
目的:
-
1 测试需求分析是编写测试用例的依据;
-
2 有助于保证测试的质量与进度;
-
3 测试需求是衡量测试覆盖率的重要指标;
-
需求分析的步骤:
-
查阅需求规格说明书(原型图)如果没有说明书,参考同类成熟产品,结合项目经验,站在用户的角度去分析
-
熟悉被测软件的核心业务流程
-
针对某个功能,细化需求,列出测试点
-
-
需求评审
- 评审是否存在漏测和错测的测试点
- 参与人员:测试人员/组内人员/测试主管/产品/开发
-
-
如何进行测试需求分析?(功能测试+非功能测试【界面、兼容、易用、安全、性能】)
- 通过分析需求描述中的输入、输出、处理、限制、约束等,给出对应的验证内容;(功能测试)
- 通过分析各个功能模块之间的业务顺序,和各个功能模块之间传递的信息和数据,对存在功能交互的功能项,给出对应的验证内容;(功能交互测试)**m.**QQ好友发起对话前验证是否是好友,不是好友提示加好友模块
- 考虑到需求的完整性,要充分覆盖软件需求的各种特征,包含隐性需求的验证,比如界面的验证,注册账号的唯一性验证【界面、易用性、兼容性、安全性、性能压力】 (非功能测试)
-
例子(一个页面如何进行测试需求分析?)
-
进行页面检查:参考原型图,查看界面是否一致
-
依次分析每个输入项(字段名),按照从上到下、从左到右的顺序进行分析(约束限制【长度、格式】、是否必填、是否重复、隐性需求【如手机号码必须11位】)
-
按钮,根据业务逻辑的先后顺序来进行依次分析,一般按钮存在(什么条件)操作成功,(什么条件)操作失败,验证操作结果(验证交互功能【验证关联功能】)。m. 比如验证登录成功,进入首页,展示个人信息
-
9 测试用例
测试用例是为项目需求而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序是否满足客户需求。
可以总结为:每一个测试点的数据设计、步骤设计和测试结果。
10 测试用例的重要性
- 测试用例是软件测试的核心。
- 评估测试结果的基准。
- 保证测试的时候不遗漏测试功能点。
- 在编写测试用例的过程,可以熟悉需求,对系统架构或业务流程有一个整体的,深入的了解。
- 好的测试用例不仅方便自己和别人查看,而且能帮助设计的时候考虑的更周全。
11 测试用例的八大要素(重点!!)
- 用例编号:产品名_测试阶段(it/st/uat) 如 某项目_it_注册_001 ZC_001
- it:集成测试–接口测试
- st:系统测试
- uat:验收测试
- 测试项目(模块):对应一个功能模块(细分功能)登录 注册
- 测试标题:直接对测试点进行细化得出,输入内容+结果,同一功能模块标题不能重复 测什么?
- 重要级别(优先级 ):高/中/低(高:主流程/核心流程 中:异常流程/错误流程 低:界面问题/兼容性问题)
- 预置条件:需要满足一些前提条件,否则用例无法执行
- 测试输入(数据):需要加工的输入信息,根据具体情况来设计(跟步骤结合起来一定要具有指导性意义)
- 操作步骤:明确给出每个步骤的描述,执行人员可以根据该步骤完成执行工作
- 预期结果:根据预期输出比对实际结果,来判断被测对象是否符合需求。(预期结果唯一,不能出现”是否或者“)
- 实际结果
例子(博客搜索功能)
12 软件测试用例设计方法(黑盒测试方法)
1. 等价类划分法
定义:等价类划分是一种典型的、黑盒测试方法,是把所有可能的输入划分为N个子集合。在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的。
等价类划分有效等价类(有效的,正确的,有意义的输入)和无效等价类(无效的,错误的,无意义的输入)。
使用场景:输入项内容存在无穷尽的情况,一般就会通过等价类划分方法吧穷尽测试转化为有效测试,捕捉到跟多的bug
- 例子 需求:用户名长度6~18位长度,必须以字母数字下划线两者或两者以上组合
有效等价类 | A | 边界值法 | 无效等价类 | B | 边界值法 | ||
---|---|---|---|---|---|---|---|
组合规则 | 必须以字母数字下划线两者或两者以上组合 | 字母+数字 | A1 | 纯字母 | B1 | ||
字母+下划线 | A2 | 纯数字 | B2 | ||||
数字+下划线 | A3 | 纯下划线 | B3 | ||||
字母+数字+下划线 | A4 | 除字母数字下划线其他字符 | B4 | ||||
空 | B5 | ||||||
长度规则 | 用户名长度6~18位长度 | A5 | (6,18,7,17) | 长度<6 | B6 | 长度=5 | |
长度>18 | B7 | 长度=19 |
有效等价类用例 | 无效等价类用例 |
---|---|
A1+A5(长度=6) | B1 |
A2+A5(长度=18) | B2 |
A3+A5 | B3 |
A4+A5 | B4 |
B5 | |
B6 | |
B7 |
- 等价类划分法用例设计原则
- 划分有效及无效等价类,为没一个等价类规定一个唯一的编号
- 设计一个新的测试用例数据,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;(用最少的用例去覆盖最多的有效等价类)
- 设计一个新的测试用例数据,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止;(用最多的用例去逐一覆盖无效等价类)
- 分析等价类的步骤
- 根据需求分别找出需求的条件,根据条件,分别找出有效等价类和无效等价类
- 对有效等价类和无效等价类进行逐一编号
- 选择测试用例,根据有效等价类选择正例,根据无效等价类选择反例(选取规则根据用例设计选择)
2. 边界值分析法
定义:边界值分析法是对等价类划分法的一个补充,边界值一般都是从等价类的边缘值去寻找。边界值分析的基本思想:正好等于、刚刚大于、刚刚小于边界的值作为测试数据。
注意:0是一个特殊值,考虑边界值同时也要考虑这个特殊值。负数
-
例子:微信红包
-
边界值:0,0.01,0.02,199.99,200,200.01
-
特殊值:负数
-
3. 场景法
定义:通过场景描述的业务流程(业务逻辑),也包括代码实现逻辑,设计用例来遍历场景(图上面所有的路径),验证软件系统功能的正确性。
使用场景:对项目的业务流程功能用例的设计,基于场景法进行设计
业务流程图:基于场景法设计测试用例的依据;由产品提供业务流程图;
正常流程:从起点开始,通过各路径,最后节点结束,对应的流程。
异常流程:从起点开始,然后可能在某个节点结束或者返回上一节点,对应的流程。
- 例子:
画出流程图
矩形:表示步骤(操作、结果)
菱形:判断–是、否
根据上图,设计测试用例:
1. 正常流程(主流程): T-T
2. 异常流程(备用流程):T-F F-T F-F
3. 测试数据:
T-T: A=2,B=5,X=3
T-F: A=2,B=5,X=2
F-T: A=2,B=4,X=3
F-F: A=3,B=4,X=1
4. 错误推测法(反推法)【探索性测试】
定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
用错误的操作,去验证软件及程序的健壮性。即明知不可为而为之
- 例子:某平台登陆页面
- 用户名和密码对应关系验证
- 账号和密码为空
- 用户名和密码,如果太长或太短
- 用户名和密码,中有特殊字符
- 提交登陆时,网络异常
- 单点登录
5. 因果图/判定表法
使用场景:当需求中存在多个条件,不同条件中存在不同的结果;列出需求中的因子(条件)和结果
判定表=条件桩+动作桩
条件桩:需求中的因子(条件)
动作桩:需求中的结果
条件项:不同因子的组合
动作项:不同因子组合的结果
-
因果图/判定表分析步骤:
- 找出需求中的因子及结果
- 确定判定表中条件桩及动作桩
- 列出所有的条件项
- 根据条件项,画出对应的动作项,得到判定表
- 简化判定表
- 根据判定表,针对每种条件项及动作项,编写测试用例
-
例子:
如果感到疲惫则休息;
如果不疲惫且不感兴趣则跳入下一章;
如果不疲惫且感兴趣且糊涂则重读一遍;
如果不疲惫且感兴趣且不感到糊涂则继续阅读;
用判定表描述以上处理逻辑
判定表:
条件桩 | 条件项 | 条件项 | 条件项 | 条件项 | 条件项 | 条件项 | 条件项 | 条件项 |
---|---|---|---|---|---|---|---|---|
疲惫 | Y | Y | Y | Y | N | N | N | N |
感兴趣 | Y | Y | N | N | Y | Y | N | N |
糊涂 | Y | N | Y | N | Y | N | Y | N |
动作桩 | ||||||||
休息 | √ | √ | √ | √ | ||||
跳入下一章 | √ | √ | ||||||
重读一遍 | √ | |||||||
继续阅读 | √ |
简化判定表:
条件桩 | 条件项 | 条件项 | 条件项 | 条件项 |
---|---|---|---|---|
疲惫 | Y | N | N | N |
感兴趣 | - | N | Y | Y |
糊涂 | - | - | Y | N |
动作桩 | ||||
休息 | √ | |||
跳入下一章 | √ | |||
重读一遍 | √ | |||
继续阅读 | √ |
6. 正交实验法
因果关系比较庞大的情况下,不太适合用因果图判定表,在这种情况下,一般采用正交实验法法进行测试(条件很多,组合很多,输出结果很多)
13 测试用例练习
-
(场景法)给出一个登录/购物车/支付页面,直接让你设计尽可能多的用例?
- 测试用例:
- 分模块:登录:正常登录:输入正确的用户名/密码 异常操作:用户名 or 密码错误 为空 输入特殊字符?
- 购物车:最多可以添加多少商品?可以增删改商品?修改选择了的商品属性:颜色?size?异常操作:过期的商品?售罄的商品? 有无优惠券打折?
- 支付:支付的方式?余额不足?代付?
- 测试用例:
-
(场景法/等价类划分法)输入边长A,B,C三个值,判断是否能构成三角形,如果是等腰三角形就输出…?
- 分析思路:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F7u8rBlJ-1690978138716)(image-20230725112544435.png)]
1 画出流程图
- 正常流程:
-
A>0 B>0 C>0 --> A+B>C A+C>B B+C>A --> A=B=C --> 等边三角形
-
A>0 B>0 C>0 --> A+B>C A+C>B B+C>A --> A=B=C不成立 --> A=B!=C A=C!=B B=C!=A --> 等腰三角形
-
A>0 B>0 C>0 --> A+B>C A+C>B B+C>A --> A=B=C不成立 --> A=B!=C A=C!=B B=C!=A不成立 --> A2+B2=C2 --> 直角三角形
-
A>0 B>0 C>0 --> A+B>C A+C>B B+C>A --> A=B=C不成立 --> A=B!=C A=C!=B B=C!=A不成立 --> A2+B2=C2 不成立 --> 普通三角形
- 异常流程:
-
ABC不是所有都大于0
-
ABC>0条件下,A+B<C A+C<B B+C<A
2 等价类划分
按输入的数据类型:
有效:正数 无效:负数 零 特殊字符 空
按是否可以构成三角形:
有效:A>0 B>0 C>0 无效:A>0 B>0 C<0/A>0 B<0 C>0/…
有效:A+B>C A+C>B B+C>A 无效:A+B<C A+C<B B+C<A
14 Bug知识点
定义:软件的Bug,狭义概念是指软件程序的漏洞或缺陷,广义概念还有测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
类型:
1. 代码(功能)错误:功能错误、性能、安全
1. 界面优化:界面、易用性测试
1. 设计缺陷:建议优化的bug
Bug的等级:通常划分为三级或四级。等级越高,可能被修复的等级也会越高。
(1)致命错误:—blocker
a. 常规操作导致的系统崩溃、死机、死循环、闪退
b. 造成数据泄露的安全性问题
c. 涉及金钱计算
d. 阻断性测试、所有测试工作进行不下去(冒烟测试)
(2)严重错误:—critical
a. 重要的功能不能实现
b. 错误的波及面广,影响到其他重要功能的正常实现
c. 非常规操作导致的系统崩溃、死机、死循环、闪退
d.界面非常难以接受
e. 密码明文显示(界面+数据库)
f. 偶现的致命性bug
(3)一般错误:—major
a. 次要功能不能实现
b. 操作界面错误(界面列明定义不一致)
c. 查询错误,数据错误i按时
d. 简单的输入限制未放在前端进行控制
e. 删除操作未给出提示
f. 偶现的严重性bug
Bug的生命周期
发现bug -> 提交bug -> 指派bug -> 研发确认bug -> 研发修复bug -> 回归验证bug -> 是否通过验证 -> 关闭bug
Bug管理的工具
-
禅道
-
testlink
-
Gitlab
15 测试计划包含的内容(5W+1H)
一般包括:测试目的(why)、测试范围(what)、测试进度安排(when)、测试人员(who)、测试环境(where)、测试方法+测试工具(how)、风险评估。
风险评估:需求变更/需求增加,测试时间拉长,人员调配;测试人员变动。人员调配,协调或加班。
16 测试报告包含的内容
**定义:**一份评估软件质量的测试报告
一般包括:测试范围、测试环境、测试方法和工具、测试执行结果、bug统计与汇总、遗留bug情况、测试结论与建议 等
17 兼容性测试
浏览器兼容性问题又称网页或网站兼容性问题,是指因为不同的浏览器对同一段代码有不同的解析,造成页面显示效果不同意的情况。
产生浏览器兼容性问题的原因:
因为不同浏览器使用内核及所支持的HTML等页面语言标准不同;以及用户客户端的环境不同(如分辨率)造成的显示效果不能达到理想效果。最常见的问题就是网页元素位置混乱,错位。
内核:决定了浏览器该如何显示网页的内容以及页面的格式信息。
18 如何进行其他类型测试?
接口测试、性能测试、自动化测试
- 接口测试
- 性能测试
- 自动化测试
常用DOS命令
计算机网络体系
1 网络分层
- OSI七层模型
- 应用层:文件传输、电子邮件、文件服务
- 表示层:数据格式化,代码转换,数据加密
- 会话层:建立或解除与别的端的练习
- 传输层:提供端到端传出,传输协议TCP、UDP
- 网络层:寻址IP,为数据包选择路由
- 数据链路层:二进制的数据转化为数据帧,定义物理地址(MAC)
- 物理层:基于物理媒介(网线/光纤)进行传输,传输二进制数据
- TCP/IP模型
- 应用层
- 传输层
- 网络层
- 物理+数据链路层
2 TCP三次握手(建立连接)
- 第一次握手:有客户端发送SYN包给服务器,询问是否可以连接
- 第二次握手:服务器收到SYN包后,,发送SYN+ACK包给客户端,确认可以连接
- 第三次握手:客户端收到SYN+ACK包后,发送ACK包给服务器,建立连接
3 TCP四次挥手(释放连接)
- 第一次挥手:由客户端发送FIN包给服务器,请求关闭连接
- 第二次挥手:服务器收到FIN包后,发送ACK包给客户端,对请求关闭连接进行确认
- 第三次挥手:服务器主动发送FIN包给客户端,发送关闭连接的请求给客户端
- 第四次挥手:客户端发送ACK包给服务器端,服务器端和客户端连接关闭
4 TCP和UDP的区别
- TCP面向连接的,UDP为无连接的
- TCP是点对点的两点服务,即一条TCP连接只能有两个端点;UDP支持一对一,一对多,多对一,多对多的通信。
- TCP是可靠的;UDP是不可靠的。
- TCP资源占用大,传输速度慢,稳定性好;UDP资源占用少,传输速度快,稳定性差。
- 如果保证数据完整性,选用TCP,如文件传输;如果保证数据传输实时性,选用UDP,如视频通话、实时通信。
- TCP传输是以字节流形式;UDP传输是以数据报文段形式。
5 应用层协议
- 文件传输:FTP、TFTP、NFS
- 电子邮件:SHCP、POP3
- WWW应用:HTTP、HTTPS
- 远程登陆:Telnet、rlogin
- 网络管理:SNMP
- 域名管理:DNS
Jmeter知识点
1 接口测试分类
- **内部接口:**被测系统各个子模块之间的接口,或者被测系统提供给内部系统使用的接口。
- 外部接口:
- 被测系统调用外部的接口
- 系统对外提供的接口
- 接口测试重点:检查接口参数传递的正确性、接口功能的正确性、输出结果的正确性、对各种异常情况的容错处理、权限控制、分页处理、调用次数的限制。
2 目前接口架构设计
-
基于SOAP结构:基于XML规范,基于WebService协议。特点:接口地址?wsdl结尾
-
基于RPC架构:基于dubbo协议,thrift协议。SpringCloud微服务。
-
基于RestFul架构:基于json规范,基于http协议。
RestFul规则:
接口地址:
http://127.0.0.1/user,
get(查),post(增),put(改),delete(删)
Json数据格式:只有两种数据类型。键值对:{key : value} 数组:[arr1,arr2,arr3]
http协议详解:
请求:请求行 + 请求头 + 请求正文
请求行:请求类型+地址,如POST http://127.0.0.1/uer
请求头:Host(请求主机)+ Connection(保存活跃)+ Accept(数据格式)+ X-Requested-With(异步请求)+ User-Agent(客户端类型)+ Content-Type(内容类型)+ Cookie(Cookie信息)
Cookie:客户端发送给服务器的Cookie(从第一次到第n次都会发送)
请求正文:如username=admin&password=admin
响应:响应行 + 响应头 + 响应正文
响应行:响应协议(HTTP/1.1)+响应码(200)+相应信息(OK)
响应头:Server + Date + Content-Type + Connection + Set-Cookie
Set-Cookie:服务器发送给客户端的Cookie(只有在第一次请求时发送)
3 接口测试工具
-
Jmeter + Ant + Git + Jenkins
-
Postman + Newman + Git + Jenkins
4 Jmeter简介
基于Java语言的压力测试工具,可以进行接口测试,也可以进行性能测试。
5 Jmeter常用组件
- 测试计划:起点,所有组件的容器
- 线程组:代表一定数量的用户
- 取样器:向服务器发送请求的最小单元
- 逻辑控制器:结合取样器实现一些复杂的逻辑
- 前置处理器:负责在请求之前的工作
- 后置处理器:负责在请求之后的工作
- 断言:用于判断请求是否成功
- 定时器:负责在请求之间的延迟间隔。【固定/高斯/随机】
- 配置原件:配置信息
- 监听器:负责收集结果
顺序:
测试计划 --> 线程组 --> 配置原件 --> 前置处理器 -->定时器 --> 取样器(请求) --> 后置处理器 --> 断言 --> 监听器
作用域:
必须组件:测试计划、线程组、取样器
辅助组件:出必须组件之外的组件
作用于父组件,同级组件,以及同级组件下的所有子组件。
6 Jmeter接口测试流程
-
拿到api接口文档,熟悉接口业务,接口地址,鉴权方式。入参,出参,错误码。
-
编写接口测试用例。
测试思路:
正例:输入正常入参,查看接口成功返回
反例:
鉴权:空,错误,鉴权过期,鉴权次数限制…
参数:空,类型错误,长度错误,错误码的覆盖
其他:黑名单,分页
-
使用接口测试工具执行
-
Jmeter+Ant+Git+Jenkins实现持续集成输出接口测试报告,通过电子邮件发送
7 Jmeter接口测试实战
http:80 https:443
100,200成功,30X重定向,404页面没找到,500服务器错误
鉴权码:
- 通过接口获取,appid,secret
- 登录之后自动生成,username,password
8 Jemeter接口关联
- 使用正则表达式实现接口关联(可以作用于任意值)
- 使用JSON Path表达式实现接口关联(只能作用于返回值为json的值)
从根目录开始找(绝对路径):如 $.access_token
从任意目录开始找(相对路径):如 $…access_token
9 Jmeter动态参数处理
-
随机数字:${__Random(10000,99999,random_int)}
-
随机字符串:${__RandomString(6,abc123jklz,random_str)}
-
如果不同取样器想要使用相同随机数,可在配置原件【用户定义的变量】中设置
10 Jmeter接口测试断言
-
响应文本:返回的json数据
-
响应代码:200,404等
-
响应信息:OK
-
响应头
-
请求头
-
URL
-
文档(文本):返回的json数据以文本的方式去判断
-
忽略状态:当有多个断言时,如果有一个断言失败了,另一个成功,那么结果成功
-
请求数据
字符串:响应内容包含需要匹配的字符串,大小写敏感,不支持正则
包括:响应内容包含需要匹配的字符串,大小写敏感,支持正则
匹配:响应内容完全等于需要匹配的字符串,大小写敏感,支持正则
相等:响应内容完全等于需要匹配的字符串,大小写敏感,支持正则
11 Jmeter接口测试调试方案
- 通过【查看结果树】里面的请求信息和响应信息。
- 使用【调试取样器】
- Jmeter结合Fiddler实现调试(把fiddler作为代理):在没有接口文档,只能通过抓包去获取接口信息的时候使用。
12 CSV参数化的处理(反例测试)
编写CSV文件,添加配置原件【CSV数据文件配置】
CSV文件如下:
通过配合循环逻辑控制器【循环配置器】调用
13 Jmeter脚本录制功能(没有接口文档的情况下)
- 使用Jmeter自带的http代理服务器**(把Jmeter作为代理)**
-
设置端口和录制位置
-
设置本机的请求通过代理去发送
14 Jmeter中的Bean Shell组件和语言规则
BeanShell是一种完全符合java语法规则的脚本语言,同时还有自己的语法规则。
Jmeter包含的Bean Shell:
- 前置处理器:Beanshell预处理程序
- 定时器:Beanshell定时器
- 取样器:Beanshell取样器
- 后置处理器:Beanshell后置处理程序
- 断言:Beanshell断言
- 监听器:Beanshell监听器
15 BeanSell内置的变量和语法规则
- log打印日志
log.info("lynn");
log.error("lynn出现错误了!");
System.out.println("Java 打印!");
// 获取变量值
log.info(vars.get("name"));
log.info(vars.get("access_token"));
// 设置变量
vars.put("www","zzz");
- vars表示:操作Jemeter变量(只能在当前线程)
- 用户定义的变量
- Json提取器、正则表达式
- 定义变量:从一个取样器中定义变量,从另一个取样器中获取变量
- props用于存取Jmeter的全局静态变量(可以跨线程组)
// 获取全局静态变量
log.info(props.get("jmeter.save.saveservice.output_format"));
// 设置全集静态变量
props.put("aaa","bbbb");
log.info(props.get("aaa"));
- prev获取到前面一个取样器返回的信息
// 获取前面取样器的值
log.info(prev.getResponseCode());
log.info(prev.getResponseDataAsString());
- ctx 上下文
// 获取去上下文所有的变量
System.out.println(ctx.getProperties());
16 Jmeter执行数据库操作
-
准备数据库的驱动jar包
Mysql、Oracle…
方式一:在测试计划里引用
方式二:放到Jmeter的lib目录
-
新建一个JDBC connection configuration
-
新建一个JDBC request取样器
17 Jmeter的非GUI(界面)方式运行
-
执行JMX文件的命令:jmeter
-
命令行参数:
-n -t -n 非界面方式运行 -t指定jmx文件的位置
D:\apache-jmeter-5.6.2\backups>jmeter -n -t Jmeter_test.jmx -l result.jtl
-l - l 指定生成的jtl格式的结果
D:\apache-jmeter-5.6.2\backups>jmeter -n -t Jmeter_test.jmx -l result.jtl
-e -o -e 生成HTML报告 -o指定HTML报告的文件夹(文件夹必须为空)
D:\apache-jmeter-5.6.2\backups>jmeter -n -t Jmeter_test.jmx -l result.jtl -e -o report
18 使用Jmeter+Ant+Git+Jenkins实现持续集成
- 安装Ant
- 需要build.xml文件,将build.xml和test.jmx放到同一目录
- 配置jmeter.properties
- 命令行输入 ant
Postman知识点
1 Token鉴权码
- csrf_token:一般情况下有效期是7~15天
- access_token:一般情况下有效期是10分钟~2小时
2 Postman介绍
请求页签:
Params:get请求传参
Authrization:鉴权
Headers:请求头
Body:请求体
form-data:可以传输键值对,也可以传输文件
x-www-form-urlencoded:只能传输键值对
raw:可以传输Text,JavaScript,JSON,HTML,XML
binary:把文件转化成二进制的方式传输
Pre-request-script:请求之前的脚本
Tests:请求之后的断言
Settings:单个接口的设置
Cookies:Postman管理Cookie信息
响应页签:
Body:返回的信息
Pretty(各种格式查看返回数据)
Raw(文本格式)
Preview(网页格式)
Cookie:响应Cookie
Headers:响应头
Test Results:测试结果
3 Postman接口关联
- Json提取器,在Tests中设置后置断言
// 打印
console.log(responseBody);
// JSON提取器
var jsdata = JSON.parse(responseBody);
// 取值,并且设置为全局变量
pm.globals.set("access_token", jsdata.access_token);
console.log(jsdata.access_token);
- 正则表达式提取器
// 正则表达式提取器,match匹配,新建正则表达式
var data = responseBody.match(new RegExp('"access_token":"(.*?)"'));
// 打印
console.log(data[1]);
// 取值并设置为全局变量
pm.globals.set("access_token", data[1]);
4 全局变量和环境变量
-
全局变量可以在所有的接口请求里面使用。通过{{}}取值
-
环境变量可以在当前环境的所有接口请求使用。通过{{}}取值
- 作用:可以保存多种环境,让接口在多种环境中测试。开发环境、测试环境、生产环境
问题:
- 创建和编辑标签接口参数必须唯一,(动态参数)
- 删除接口,ID不能重复,且ID必须存在
5 Postman内置动态参数以及自定义参数
-
Postman内置动态参数:
{{$timestamp}} 自动生成当前时间的时间戳 (无法断言)
{{$randomint}} 自动生成0-1000的随机数
{{$guid}} 自动生成一个GUID长字符串随机数
- 自定义动态参数
6 Postman常规断言,动态参数断言,全局断言
一般会有两个断言:
状态断言:返回的状态码为200
业务断言:断言其中最核心的业务关键字
Status code:Code is 200 断言返回的状态码为200
Response body:Contains string 断言返回的body中包含有一个字符串
Response body:JSON value check 检查json中的其中一个值
Response body:Is equal to a string 端饭返回的body等于一个字符串
Response headers:端饭响应头包含Content-Type
Response time is less than 200ms:断言请求时间少于200ms
自定义动态参数的断言方式:
在tests页签中是不能使用{{}}方式获取全局变量,只能通过一下方式获取:
-
利用Postman自带的方法Get a global variable
-
globals[“全局变量名”]
-
global.全局变量名
全局断言:一般应用域所有结果都需要做的断言,比如状态断言
7 Postman批量执行测试用例
关于文件上传接口在批量运行时报错的解决方案:
把文件放到该目录下
8 Postman数据驱动方式:CSV或JSON文件
判断只有返回结果中包含access_token才提取
// 判断只有正常返回才提取access_token
if(responseBody.search("access_token")!=-1){
// 正则表达式提取器,match匹配,新建正则表达式
var data = responseBody.match(new RegExp('"access_token":"(.*?)"'));
// 取值并设置为全局变量
pm.globals.set("access_token", data[1]);
console.log(data[1]);
}
**注意:**在断言里面取数据文件CSV文件里面的值,如下:data.变量名
9 必须带请求头的接口
请求包含内容:请求方式,请求参数,请求路径,请求头
10 Postman接口测试之Cookie鉴权
-
什么是Cookie
cookie就是一小段文本信息,客户端第一次请求服务器时生成。
-
Cookie鉴权原理
当客户端第一次请求服务器时生产Cookie,然后再第一个返回时在响应头的Set-Cookie里面吧所有的Cookie传输给客户端;当客户端第2-N次请求服务器时,那么在请求头的Cookie里面就会带上所有的Cookie来实现鉴权。
-
Cookie鉴权实战
Postman会自动保存Cookie,不需要额外的处理。
Jmeter需要增加一个Cookie管理器的组件
11 Postman接口Mock Server服务器
使用场景:前后端分离,后端接口没有完成,前端已经完成了,但是前端的业务流程依赖于后端接口。需要测试自己去Mock接口服务器
如需要的响应信息如下:{”errcode“:0,“message”:“success”,data:[1,2]}
12 Postman接口测试加密和解密
-
对称式加密(私钥加密):DES,AES,BASE64加密算法
如:
AES:lynn --> U2FsdGVkX1/guy6OD40+oV2KQjPth3REK6Asmv+fzCI=
DES:lynn --> U2FsdGVkX19nyjMRByqQ3hYMuCf8tgMS
BASE64:lynn --> bHlubg==
-
非对称加密(双钥加密):RSA加密算法,有公钥和私钥,公钥加密私钥解密或私钥加密公钥解密
通过一个密码生成公钥和私钥:blanche
通过公钥加密后:
lynn --> d3qeWjXZHusg7eDy+12gZLNzAs01g4FM6g9qW5p13M5W4dmA6/oe7eoN3czZkCbUgiLgEXGkO/OxW+A++2ETQ2v+p4KLk65TL6RO5IF652DJtP04q6Uo0GpZa6RgQALguUzJkgvseqmW4qj/oAqs2hy3MW/aILoBfSFUxntJxoJinzyY3oyfOBB3YmbClCQ4GjQe9rC4ESoV8rrrlI94Qp1obDrfaofB0XDtifUcP7z72oZ5LpJH07bZP7k+A4GQWQRdhp8x361n6Ov1bzoXh6VTbhnvx2c4k3h0VJKupKP/y0OYejcXTvGDhb07UrLbwP36X5M4ARWDJ0lrBaan/A==
-
只加密不解密:MD5加密,SHA1,SHA3…
MD5:得到4个值(32位大小写/16位大小写)
-
很多系统会把以上算法进行组合形成自定义算法
网站:http://www.bejson.com
MD5加密实战演示:
前端:对username和password通过按照后端加密方式进行加密,再传值
后端:对username和password所加密的内容进行比较
13 Postman+Newman实现非GUI方式运行
newman run "C:\\Users\\Lynn\\Desktop\\postmans\\testcase.json" -e "C:\\Users\\Lynn\\Desktop\\postmans\\environment.json" -g "C:\\Users\\Lynn\\Desktop\\postmans\\globals.json" -r cli,html,json,junit --reporter-html-export "C:\\Users\\Lynn\\Desktop\\postmans\\report.html"
newman run 固定命令
-e 环境变量
-g 全局变量
-r cli,html,json,junit --reporter-html-export 生成html报告
bHlubg==
-
非对称加密(双钥加密):RSA加密算法,有公钥和私钥,公钥加密私钥解密或私钥加密公钥解密
通过一个密码生成公钥和私钥:blanche
通过公钥加密后:
lynn --> d3qeWjXZHusg7eDy+12gZLNzAs01g4FM6g9qW5p13M5W4dmA6/oe7eoN3czZkCbUgiLgEXGkO/OxW+A++2ETQ2v+p4KLk65TL6RO5IF652DJtP04q6Uo0GpZa6RgQALguUzJkgvseqmW4qj/oAqs2hy3MW/aILoBfSFUxntJxoJinzyY3oyfOBB3YmbClCQ4GjQe9rC4ESoV8rrrlI94Qp1obDrfaofB0XDtifUcP7z72oZ5LpJH07bZP7k+A4GQWQRdhp8x361n6Ov1bzoXh6VTbhnvx2c4k3h0VJKupKP/y0OYejcXTvGDhb07UrLbwP36X5M4ARWDJ0lrBaan/A==
-
只加密不解密:MD5加密,SHA1,SHA3…
MD5:得到4个值(32位大小写/16位大小写)
-
很多系统会把以上算法进行组合形成自定义算法
网站:http://www.bejson.com
MD5加密实战演示:
前端:对username和password通过按照后端加密方式进行加密,再传值
后端:对username和password所加密的内容进行比较
13 Postman+Newman实现非GUI方式运行
newman run "C:\\Users\\Lynn\\Desktop\\postmans\\testcase.json" -e "C:\\Users\\Lynn\\Desktop\\postmans\\environment.json" -g "C:\\Users\\Lynn\\Desktop\\postmans\\globals.json" -r cli,html,json,junit --reporter-html-export "C:\\Users\\Lynn\\Desktop\\postmans\\report.html"
newman run 固定命令
-e 环境变量
-g 全局变量
-r cli,html,json,junit --reporter-html-export 生成html报告