软件测试（一篇就够了！）
目录
软件测试&软件测试分类
什么是软件？
软件测试是什么？
为什么做软件测试？目的是什么？
测试技术划分
按测试阶段划分
笔试面试题整理
软件生命周期&软件测试流程
测试模型
常见笔试面试题
测试需求分析
什么是软件测试需求
软件测试需求的必要性（目的）
发布上线标准
如何对软件测试需求进行分析（重点）
面试题
需求分析评审及测试用例编辑规划
什么是测试用例
测试用例的八大要素（重点）
用例设计方法等价类&用例评审&bug
测试用例方法之场景法&错误推断法&因果图判定表法
笔试面试题
正交试验&用例评审&bug
bug的类型
bug的等级
bug的生命周期（重点）
当发现一个bug，除了尽快报告问题以外，我们还能做哪些事情？
禅道的使用（重点）
测试计划与测试报告编写
常见面试题
作业讲解
DOS命令及网络体系
Dos命令
网络体系
windows环境搭建
面试题
软件测试&软件测试分类
什么是软件？
软件是计算机程序、程序所用的数据以及有关文档资料的集合
软件
- 系统软件：系统软件是生成、准备和执行其他程序所需的一组文件和程序，例如操作系统window，数据库sql-server，驱动程序，java语言系统编译环境等
- 应用软件：应用软件是开发或颜值的各种程序或软件包。如qq
c/s架构：clinet-server 需要安装客户端才能用的软件，比如微信，qq。（缺点：都需要安装客户端，会消耗人力物理）
b/s架构：browser-serve 浏览器即刻访问，优点 只需更新服务端就ok
软件测试是什么？
使用人工和自动手段来运行或测试某个系统的过程，其目的在于验证它是否满足规定的需求或弄清预期结果与实际结果的差别。
为什么做软件测试？目的是什么？
- 发现软件存在的代码或业务逻辑错误
- 检验产品是否符合用户需求
- 提供用户体验
软件测试划分
测试技术划分
- 按测试技术划分：白盒测试、黑盒测试
- 被测试对象是否运行划分：动态测试、静态测试（文档检查、代码走查）
- 按不同的测试手段划分：手工测试，自动化测试
- 测试包含内容划分：功能测试，界面测试，安全测试，兼容性测试，易用性测试，性能测试
- 其他测试：冒泡测试，回归测试，探索性测试/自由测试
按测试阶段划分
- 单元测试：主要测试程序代码，确保各单元模块被正确编译，比如有具体的模块测试，也有具体到类，函数，方法的测试等——一般开发来完成
- 集成测试，单元测试后，将各单元测试合成完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递。——比方说注册和充值这两个功能是否能够联通
- 系统测试：把软件系统搭建起来，按照软件规定说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。（计算机程序结合外设+网络等其他元素进行测试）——根据测试用例，进行完整的系统 将已经确认的软件、
- 系统测试：软件、硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试 和确认测试，系统测试是针对整个产品的测试。
- 验收测试：主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。——用户对软件进行验收
测试分为哪几个阶段?
一般来说分为4个阶段：单元测试、集成测试、系统测试、验收测试
验收测试中的两种测试
- alpha测试：把用户请到开发方对软件进行测试，测试环境受开发方控制，测试人不多，测试时间比较集中 执行人员：用户 公司内部人员
- beta测试：测试环境不受开发方控制，测试人员比较多，测试时间不集中
- 功能测试：验证软件的业务功能是否符合需求，包括对原定功能的检验以及测试软件是否存在冗余功能、遗漏功能。
- 界面测试：被测系统的界面与原型图是否一致，测试用户界面是否友好，系统设计是否合理、界面位置是否正确等问题。
- 安全测试：对被测试系统的安全进行测试，防止非法入侵的能力（多次输入用户名密码，是否允许输入，sql注入）
- 兼容性测试：在不同的平台、不同的工具软件或者相同工具软件不同的版本下的兼容性。
- 易用性测试：是否操作方便、是否容易理解、是否容易上手
- 性能测试：某个特定时间，用户数据剧增，软件是否正常。性能是否满足用户需求，即在特定的运行条件下验证系统的能力状态。主要是通过自动化的测试工具模拟正常、峰值、异常负载状况、对系统的各项性能指标进行测试。（负载测试、压力测试）
- 文档测试：主要检查内部或外部文档的清晰性和准确性。
- 冒烟测试：在进行正式测试前对主要功能核心功能进行测试 一般是开发人员 测试主管来负责
- 回归测试：开发对存在问题的功能进行修改后，再一次进行的测试 bug给开发 开发改bug 测试对Bug再一次验证
- 探索性测试：根据自己的项目经验而进行的随缘测试
为什么要做软测，目的是什么？
- 为了发现程序存在的代码或业务逻辑错误
- 为了检验产品是否符合用户需求
- 为了提高用户体验感
笔试面试题整理
1、什么是软件测试？软件测试的目的是什么？
2、软件测试分类都有哪些？
3、什么是黑盒测试？黑盒测试又称为“功能测试”,是将测试对象看做一个黑盒,在并不考虑软件产品的内部结构和处理过程的基础上，通过输入数据并观察输出结果来判断系统的正确性、完整性和可靠性的测试方法。
软件生命周期&软件测试流程
软件生命周期：软件开始研制到最终被废弃不用所经历的各个阶段
软件生命周期模型
1.大爆炸模型：优点:简单，不用学习就会。缺点：产品质量无法保障，尽量避免使用
2.边做边改模型：优点：快速得到可运行的版本。缺点：计划有些缺乏，导致版本前后变化较大
3.瀑布模型:优点：计划周密，专业，按部就班实现。缺点：相对难于做到快速开发，以抢占市场，可选择的模型之一
自上而下，相互衔接，有顺序性，测试介入比较晚，回溯成本比较高
- 概要设计（总体设计，结构设计，部件设计）——着重解决程序模块的设计问题，它主要是描述软件由哪些部件或模块构成的,以及这些部件或模块之间的关系
- 详细设计（过程设计)——确定每个模块数据结构和内部的具体算法
概要设计的内容可以包含系统构架、模块划分、系统接口、数据设计4个主要方面的内容。
系统架构：系统架构是定义系统的结构、行为及其他视图的概念模型。
4.螺旋模型:优点：计划变化同事考虑。
测试模型
敏捷开发模型
以人为核心，迭代，循序渐进的开发方式。强调以人为本，专注于交付对客户有价值的软件
V模型
测试什么时候介入 需求阶段介入
W模型
开发流程：需求分析、概要设计、详细设计、编码、继承、实施、交付
测试流程：单元测试、集成测试、系统测试、验收测试
软件测试流程
常见笔试面试题
- 生命周期模型包含哪些阶段？你们开发的模型是什么？①问题定义及规划——需求分析——设计——编码——测试——运行维护 ②敏捷开发模型
- 测试流程包含哪些阶段？分析测试需求→制订测试计划→设计测试用例→执行测试→编写测试报告
- 你们公司的开发流程是怎样的？
- 开发环境，测试环境，生产环境是什么？你在测试环境后台添加的数据和信息，能够在生产看到吗？不可以 添加到的是测试环境里面，
- 公司的测试流程是怎样的？各个阶段的输出是什么？
- 需求分析——根据需求规格说明书输出项目测试点列表
- 用例设计——测试用例文档
- 执行测试——bug
- 评估测试——测试报告的输出
测试需求分析
什么是软件测试需求
- 根据需求规格说明书测试的内容，去细分需求（提取测试点）
- 什么是测试点（软件细分的最小单位）
软件测试需求的必要性（目的）
- 编写测试用例的依据
- 有助于保证测试的质量和进度
- 衡量测试覆盖率的指标
发布上线标准
1、测试覆盖率（100%）
- 测试用例覆盖率（100%）
- 测试用例执行率（100%）
- 测试点覆盖率（测试点覆盖率是决定测试覆盖率的重要指标）
2、bug遗留率（0%）
如何对软件测试需求进行分析（重点）
需求分析步骤
查阅需求规格说明书（原型图）
- 熟悉被测软件核心的业务流程
- 再针对某个功能，细化需求，列出测试点
一个页面如何进行测试需求分析
- 进行页面检查（参考原型图，查看界面是否一致）
- 依次分析每个输入项，按照从上到下，从左到右的顺序来进行分析
- 分析哪些内容（约束限制（长度，格式），是否必填，是否重复，隐形需求（例如手机号，需求中没有提及，但是应该需求验证，需求常识，熟悉业务，根据成熟同类产品，从而挖掘需求））
按钮
- 存在（什么条件）操作成功，（什么条件）操作失败，验证结果
- 如何验证操作结果 需要验证按钮操作结果 验证交互功能（关联功能）
面试题
遇到隐形需求怎么办？充分熟悉产品，参考成熟产品，站在用户角度去考虑，从而挖掘需求
给你一个带有logo的水杯，你会如何取测试？
你会如何测试朋友圈，购物车等熟知的软件产品（支付，优惠券，二维码）
需求分析评审及测试用例编辑规划
什么是测试用例
为了项目需求而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序是否满足客户需求（每一个测试点的数据设计和步骤设计）
测试用例的重要性
- 测试用例是软件测试的核心
- 评估测试结果的基准
- 保证测试的时候不遗漏测试功能点。
- 在编写测试用例过程，可以熟悉需求，
- 好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，也是非常重要的。执行性（指导性）
测试用例的八大要素（重点）
1、用例编号；
2、测试项目；
3、测试标题；
4、重要级别；
5、预置条件；
6、测试输入；
7、操作步骤；
8、预期输出
测试文档名：xxx项目 版本号 测试用例 作者名
不同阶段的测试用例的用例编号有不同的规则：
（1）系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
（2）集成测试用例：产品编号-IT-系统测试项名-系统测试子项名-XXX
（3）单元测试用例：产品编号-UT-系统测试项名-系统测试子项名-XXX
1、测试编号：产品名-测试阶段（it -st -uat）-测试项-xxx（英文）或者项目_编号
- it 集成测试--接口测试
- st 系统测试
- uat-验收测试
2、测试项目：对应一个功能模块
模块
- 当前覆盖的测试点所在的模块
- 什么模块（项目分为多个模块，每个模块下存在多个测试点）
3、测试标题：一般的格式（输入+动作）测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，有的公司也取名为测试目的。
测试标题一定要简单、概要；体现测试的出发点和关注点。
4、优先级/重要级别
- 高：主要核心业务功能，冒烟用例
- 中：错误异常测试点
- 低：兼容性，界面错误
5、预置条件：需满足一些前提条件，否则用例无法执行
例如：qq登录成功用例的预支条件 ①网络正常②存在有效的qq账号
例如：测试word打开文件的功能，预置条件就是：需要提前准备被打开的文件；
例如：登录成功的预置条件就是：该用户名已经注册过了。
例如：购买商品成功的预置条件就是：后台已经配置好商品、发货区域、以及支付方式了。
6、测试步骤：
- 点击【用户管理】注册
- 输入用户名和密码
- 点击【注册】
6.1、测试输入：
用户名：x小明
密码：123456
7、预期结果：
- 进入注册页面
- 用户名、密码验证通过
- 注册账号可以登录成功
8、实际结果：
- 通过pass
- 不通过failed
- 阻塞 用例无法执行
10、测试时间
测试用例评审
开发人员
组员
用例设计方法等价类&用例评审&bug
黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测、功能图法、场景法、判定表组成法 、正交实验设计法等，主要用于软件确认测试。
等价类划分法
什么时候用？
- 输入项内容存在无穷尽的情况，一般会通过等价类的方法来实现
- 通过等价类方法把穷尽测试转化为有效测试，捕捉到更多bug
需求：用户长度6-18位长度，必须以字母数字下划线两者或两者以上组合
| 编号 | 有效等价类 | 编号 | 无效等价类 |
| 1 | 长度6-18 | 6 | 长度小于6 |
| 2 | 字母+数字 | 7 | 长度大于18 |
| 3 | 字母+下划线 | 8 | 纯字母 |
| 4 | 字母+下划线+数字 | 9 | 纯数字 |
| 5 | 数字+下划线 | 10 | 纯下划线 |
| 11 | 除字母数字下划线的其他 | ||
| 12 | 空 |
| 测试用例编号 | 输入数据 | 预期输出 | 覆盖等价类 |
| 1 | a12345 | 有效 | 1、2 |
| 2 | abcde_ | 有效 | 1、3 |
| 3 | a_1234 | 有效 | 1、4 |
| 4 | 12345_ | 有效 | 1、5 |
| 5 | 123 | 无效 | 6 |
| 6 | qwertyuiopasdfghjk | 无效 | 7 |
| 7 | uuuuuuuuuuiiiiiiii | 无效 | 8 |
| 8 | 487198619 | 无效 | 9 |
| 9 | ________ | 无效 | 10 |
| 10 | $$8887 | 无效 | 11 |
| 11 | 无效 | 12 |
例子：设置密码长度为1-6个长度，数字小写字母大写字母
例子：长度为6的年月
例三：
某城市的电话号码由三部分组成，分别是：
地区码：空白或三位数字
前缀：非‘0’或'1'开头的三位数字
后缀：4位数字
边界值法
案例一、登录
测试要求：有一个登陆界面，输入账号，账号的要求是6到10位的正整数。
分析：
有效等价类：长度为在6到10之间的整数；
无效等价类：负数，小数，英文字母，中文，空格，特殊字符
测试用例：
边界值分析：
有效等价类：长度等于6、长度等于7、长度等于9、长度等于10
无效等价类：长度等于5、长度等于11
例字：需求：用户长度6-18位长度
有效边界值：长度大于等于6、长度小于等于18、
无效等价值：长度小于6、长度大于18、
| 上点 | 离点 |
| 6位，18位 | 5位，7位，17位，19位 |
测试用例方法之场景法&错误推断法&因果图判定表法
场景法
错误推断法（反推法）
探索性测试
因果图判定表法
判断表
只要是疲倦，就休息，不管其他
只要是不敢兴趣，就跳入下一章，不管其他
不疲倦，感兴趣，糊涂，重读
不疲倦，感兴趣，不糊涂，则继续阅读
简化判定表
例子：
笔试面试题
1、用例需要评审吗？紧急情况用例也需要评审吗？需要，紧急情况用例的话发送邮箱给相关部门
2、如果被测项目很紧急，来不及写用例，怎么办？后期补。checklist检查列表（xmind列出测试点）
3、遇到隐性需求如何写用例（需求不明确）？熟悉功能，参考成熟产品，站用户角度挖掘需求
4、用例有没有优先级？有。如果一定要有，依据什么来确定？测试用例的优先级应该根据测试目标来确定，测试目标应该与质量标准相匹配,测试用例的优先级应该优先考虑测试目标中最重要的部分。
5、如何编写测试用例？测试编号——所属模块——测试标题——优先级——前置条件——测试步骤——预期结果——实际结果
6、编写测试用例会用什么方法？1、正交试验法；2、边界值分析法；3、等价类划分；4、测试大纲法；5、因果图法；6、判定表驱动法；7、场景图法；8、错误推测法。
7、你觉得你在写用例的时候用到了吗？
- 业务流程，用场景法
- 针对某个输入，某个功能。一般用等价类边界值
- 存在多个条件，不同组合，用因果图判定表
作业：
正交试验&用例评审&bug
漏洞缺陷+改进建议+不符合需求
bug的类型
代码功能错误、界面优化、设计缺陷
bug的等级
致命错误：常规操作引起奔溃、死机、死循环、内存泄漏、涉及金钱，阻断性测试，所有测试功能进行不下去
严重错误：重要功能不能实现，影响到其他重要功能，非常规操作导致死机，死循环，闪退，崩溃，密码明文，外观难以接受
一般：不影响运行，次要功能不能实现，查询错误，输入限制未放在前端，删除没有提示
bug的生命周期（重点）
BUG的生命周期就是一个BUG被发现到这个BUG被关闭的过程
对于一名测试人员，bug的生命周期一般分为：发现bug → 提交bug → 验证bug → 关闭bug
- 1、发现BUG，即发现软件程序的漏洞或缺陷；
- 2、提交bug，需要尽量描述这个缺陷的属性、重现环境、类型、等级，优先级以及详细的重现步骤、结果与期望等；
- 3、验证BUG；
- 4、关闭BUG。
当发现一个bug，除了尽快报告问题以外，我们还能做哪些事情？
- (1) 这个bug复现的必要条件是什么？
- (2) 除了发现bug的这条路径，是否还有更多的路径也会导致相同的问题？
- (3) bug是否存在可能影响其它数据或者其它应用的副作用？
- (4) 其它功能模块是否也存在类似问题？
- (5) bug的复现路径是否在用户可达之路上？
- (6) 复现bug的路径是否在测试用例中？有没有可借鉴性？
①复现条件②其他路径是否有同样问题③是否影响到其他数据④其他功能是否同样出现类似问题⑤Bug的复现路径是否在用户可达之路上⑥复现bug是否在测试用例中⑦有无可借鉴性
通过以上分析，我们可能获得以下额外收获：
- (1) 通过bug的定位，确认必现路径、可能的原因，帮助开发快速定位、解决问题
- (2) 通过bug的路径、影响范围等分析，发掘更多的隐藏bug
- 《探索式测试》-恶邻测试法：重灾区往往会有更多的bug
- (3) 通过分析操作路径，补充测试用例，扩展测试用例范围、思路
① 通过bug定位确定bug路径②通过Bug路径分析影响范围挖掘更多隐藏bug，探索性测试③分析操作路径，补充用例，扩展用例范围，思路
禅道的使用（重点）
禅道 (ZenTao) 是第一款国产的开源项目管理软件，她的核心管理思想基于敏捷方法scrum，内置了产品管理和项目管理，同时又根据国内研发现状补充了测试管理、计划管理、发布管理、文档管理、事务管理等功能，在一个软件中就可以将软件研发中的需求、任务、bug、用例、计划、发布等要素有序的跟踪管理起来，完整地覆盖了项目管理的核心流程。
常见面试笔试题
测试计划与测试报告编写
- 初稿
- 修订版本
- 终稿
测试每个阶段输出文件
- 需求分析-项目测试点
- 测试计划-测试计划文档
- 测试设计-测试用例/案例
- 测试评估-测试报告
测试计划内容
编写测试计划时，可以参照IEEE测试计划模板、国标测试计划模板和国军标测试计划模板
GJB 438A-97测试计划模板
时间比例
常见面试题
测试报告包含哪些内容
1、测试范围
2、测试环境
3、数据统计
- bug数据
- bug状态
- bug类型统计
- 测试阶段统计 按功能模块统计
4、测试总结
测试用例数、执行率、成功率、缺陷关闭率、遗留Bug情况（一二级修复情况，遗留bug等级，及情况说明）
bUG-报表-bug状态
作业讲解
DOS命令及网络体系
Dos命令
启动方式1：cmd
切换磁盘: 磁盘名: 如d:
进入目录： cd 目录
返回根目录：cd\
查看目录：dir
常用参数：
/w：宽屏显示，一排显示5个文件名，而不会显示修改时间，文件大小等信息；
/p：分页显示，当屏幕无法将信息完全显示时，可使用其进行分页显示；
/a：显示具有特殊属性的文件；
/s：显示当前目录及其子目录下所有的文件。
例子：dir/s
创建目录：md 目录名
删除目录：rd+目录名
删除文件：del+文件名（文件名要加后缀）例子：del hello.vue
复制文件：copy+被复制的文件名+新文件名（加文件后缀）
重命名文件名：ren+旧文件名+新文件名（加文件后缀）
清屏：cls
网络体系
计算机网络是用通信设备和线路将分散在不同地点的有独立功能的多个计算机系统互相连接起来，并按照网络协议进行数据通信，实现资源共享的计算机集合。
局域网<城域网<广域网
网络协议为计算机网络中进行数据交换而建立的规则、标准或约定的集合，它规定了通信时信息必须采用的格式和这些格式所代表的意义。
TCP：传输控制协议
UDP：用户数据报协议
windows环境搭建
面试题
第一题：
需求分析、需求评审、做计划、编写测试用例 ，测试执行，测试报告编写
第二题：
alpha测试：测试开发人员的环境，由开发方控制，把用户请到开发方的测试，用户数量相对较少，时间集中。
beta测试：测试多个用户的环境，不受开发方控制，用户数量较多，时间不集中。
先a测试再b测试
第三题：
测试计划包括的内容有:1、测试概要;2、测试目标;3、测试范围;4、测试方法;5、时间进度安排;6、人员职责;7、资源;8、风险评估;9、测试交付件。
概要目标范围方法时间职责资源风险交付件
测试报告包含
1、测试概要（）2、测试环境3、测试计划4、测试结果5、测试分析（进度总结 需求覆盖情况）
第四题：
测试用例包含测试编号，测试标题、所属模块、前置条件、优先级、测试步骤，预期结果，实际结果
等价类划分法（密码输入）、场景法（atm取款）
第五题：
- 编号
- 标题（描述bug现象）
- 缺陷类型：判断是需求还是缺陷还是建议级别，若为缺陷，是缺陷中的功能性、浏览器兼容性、界面还是性能。（例子：缺陷-功能）
- 所属模块
- 前置条件
- 复现步骤
- 预期结果
- 实际结果
其他：
- 项目、产品：该缺陷属于哪个项目、产品；
- 发现版本：该缺陷在哪个版本发现，便于与后期的修复版本区别以及版本管理；
- 环境：便于确认是否与环境有关，如浏览器兼容性的问题；
- 状态：刚提交时一般都是未解决状态，待修复后才是fixed状态，回归确认无误后方可关闭；
- 优先级、重要程度：该缺陷所属的优先级、重要性；
- 创建人：谁发现的；
- 指派给：给谁处理。
第六题：
提交新bug入库（new），错误被确认（把bug分配给测试人员，open），开发人员查询bug，若是开发方本身或者测试人员操作错误，设为rejected，bug不在需求中属于升级或者优化，或者不影响客户端的操作顺利进行，可以延迟修复时候，设bug为deferred，开发人员要留下文字说明，测试人员查询fixed的bug，验证是否已解决，解决设为closed，bug每一次状态改变都要邮件周知相关人员，让对方知道bug的当前状态
第七题：
Bug等级，这个划分有分三级或者四级，也有分五级的
1、致命性错误（一级Bug）
2、严重错误（二级Bug）
3、一般错误（三级Bug）：不影响产品的运行，不会成为故障起因，但对产品外观和下一道工序影响交大的缺陷。
4、细微错误（四级Bug）：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误。
第八题：
测试覆盖率 测试执行率，bug遗留率（一二级基本bug全部解决）
第九题：
回归测试：旧代码后，重新测试以确认修改没有引入新的错误或导致其他代码产生错误。
冒烟测试：对该版本最基本的功能进行测试，保证基本的功能和流程能走通
第十题：
在做需求分析时仔细阅读需求文档，了解项目流程 业务逻辑，尽可能的列出所有对应测试点，根据测试点结合对应测试方法，尽可能把用户所有可能要输入的数据场景全部进行覆盖，有效的数据无效的数据，模拟用户正常输入的场景和异常输入的场景尽可能的全部进行覆盖，
去编写用例，提交对应bug，尽量实时跟踪，直到bug关闭，最后填写测试结果报告，是否可以上线
Fiddler抓包
Fiddler是一个蛮好用的抓包工具，可以将网络传输发送与接受的数据包进行截获、重发、编辑、转存等操作。也可以用来检测网络安全。反正好处多多，举之不尽呀！
Filters如何精准抓取项目的包
Fidder如何精准定位前后端Bug
Fidder抓取https协议及app包
Fidder弱网测试和网络挟持
F12抓包实战演示
重定向：当你发送一个请求之后，请求重定向到了别的资源
跳转和重定向的区别：
跳转是会把数据传到新的地址
重定向不会把新的数据传到新的地址
可以导出你的包
过滤器
一般要开启两个地址，一个是项目的ip地址，一个隐藏。这样抓的包就很精准。
抓包后如何快速定位到我们需要的包
用
webForms
压力机：CPU 8核 内存16G 官网：不高于2000 单机压制
3000以上的并发，jmeter很卡，报错
检查
请求四要素：请求方式，请求路径，请求参数，请求头
响应四要素：响应码，响应信息，响应头，响应数据
如何提取https协议的包
允许外部电脑连接到我们
把fiddler关掉 重新打开fiddler和百度 就会抓到
抓取App的包
打开夜神
修改wifi信息，代理，输入本机电脑ip 地址
输入本机电脑+“:8888”
下载证书
命名为：fiddler
网络挟持
想改文件，又不知道改的对还是错
例子：抓百度
再次响应
定位前后端的bug
如何判断是前端的bug还是后端bug
第一步：看返回信息
后端返回的问题不代表后端有问题
第二步：看日志
报错？
第三步：看请求信息
现在的项目也是前后端分离：返回的一般都是json数据
后台返回5条，前端只有3条，前端的渲染有问题
如果和前端的一样，则后端返回的数据有问题
Jmeter
接口架构设计
什么是接口？
api(应用编程接口)、简称接口，程序之间约好的通信方式
接口类型
外部接口：被测系统与外部其他系统之间的接口
承保接口（被测系统）：核算系统
内部接口：被测系统内部各子模块之间的接口
承保系统（A模块，B模块）
测试接口重点：检查接口参数的正确性，接口功能的正确性，输出结果的正确性，以及各种异常场景的容错处理和权限控制
接口测试流程：
1、拿到api接口文档（从开发拿或抓包获取），熟悉接口业务，接口地址，鉴权方式，入参，出参，错误码，其他的特别需求
2、编写接口测试用例及评审
编写思路：
正例：输入正确的入参，接口正常返回
反例：鉴权反例：为空，错误，过期
目前接口架构设计
1、基于SOAP，基于XML规范，基于webserice协议。特点：接口地址？wsd结尾
2、基于RPC架构，基于dubbo协议，thrift协议。SpringCloud微服务
3、基于Restful架构，基于json规范，基于http协议。
restful规则；
接口地址：get(查询用户)，post(新增用户)，delete（删除用户）
json数据格式：只有两种数据类型。
键值对：[key:value]
数组：[arry1,arry2]
简介/安装配置/目录介绍/常用组件
extras:存放第三方的继承构建文件
lib目录：存放jar包
licensce：许可证文件
jmeter常用组件
1、测试计划：是使用 JMeter 进行测试的起点，它是其它 JMeter测试元件的容器
2、线程组：代表一定数量的用户，它可以用来模拟用户并发发送请求。实际的请求内容在Sampler中定义，它被线程组包含。
3、配置元件：维护Sampler需要的配置信息，并根据实际的需要修改请求的内容。
4、前置处理器：负责在请求之前工作，常用来修改请求的设置
5、定时器：负责定义请求之间的延迟间隔。
6、取样器(Sampler)：是性能测试中向服务器发送请求，记录响应信息、响应时间的最小单元，如：HTTP Request Sampler、FTP Request Sample、TCP Request Sample、JDBC Request Sampler等，每一种不同类型的sampler 可以根据设置的参数向服务器发出不同类型的请求。
7、后置处理器：负责在请求之后工作，常用获取返回的值。
8、断言：用来判断请求响应的结果是否如用户所期望的。
9、监听器：负责收集测试结果，同时确定结果显示的方式。（收集结果）
10、逻辑控制器：可以自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
顺序：
测试计划>线程组>配置元件>前置处理器>定时器>取样器>后置处理器>断言>监听器
作用域
必须组件：测试计划、线程组、取样器
辅助组件：除了必须组件外
辅助组件作用于父组件、同级组件、以及同级组件下的所有子组件
执行接口测试
1、拿到api接口文档（Flddler），熟悉 接口业务，接口地址，鉴权方式，入参，出参，错误码。
2、编写接口测试用例以及评审
测试思路：
正例：输入正确的入参，接口正常返回
反例：
- 鉴权：是指验证用户是否拥有访问系统的权利。
- 鉴权反例：为空，错误，过期
- 参数：为空、类型错误、长度错误、错误码的覆盖。
- 其他：黑名单、分页
3、使用接口测试工具执行
4、Jmeter+Ant+Git+Jenkin实现持续继承输出接口测试报告，通过电子邮件
http协议，80端口
https协议，443端口
接口说明：
选用的接口是获取access-token 的接口
access_token是应用调用api的凭证，由 corpid和corpsecret换取。
请求方式：GET（HTTPS）
请求URL：https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=ID&corpsecret=SECRET
把corpid, corpsecret换成实际的值
corpid:
corpsecret:
点击运行,在查看结果树里得到 access_token
请求方式：POST（HTTPS）
请求地址：https://qyapi.weixin.qq.com/cgi-bin/oa/gettemplatedetail?access_token=ACCESS_TOKEN请求示例：“
{ "template_id" : "ZLqk8pcsAoXZ1eYa6vpAgfX28MPdYU3ayMaSPHaaa" }
”
参数说明：
| 参数 | 必须 | 说明 |
|---|---|---|
| access_token | 是 | 调用接口凭证。必须使用审批应用或企业内自建应用的secret获取，获取方式参考：文档-获取access_token |
| template_id | 是 | 模板的唯一标识id。可在“获取审批单据详情”、“审批状态变化回调通知”中获得，也可在审批模板的模板编辑页面浏览器Url链接中获得。 |
Jmeter接口测试关联
1、使用正则表达式实现接口关联
2、
每请求一次 都会取这个值（正则表达式）
把这个值放到第二个接口上，这样就实现了接口关联
2.使用Jsonpath表达式实现接口关联
从根目录开始找(绝对路径) : $. expires_ _in（表示取第一级目录）
从任意目录开始找(相对路径) : $. .expires_ in（任意一级都能取到）
用json提取器使接口关联 ，json用于返回值json格式的，正则表达式可以作用于任意值
实现接口业务闭环
如果碰到增删改查，就要实现接口业务的闭环
乱码怎么处理？
第一种方式
第二种
返回的是id和name
这时候就要用动态参数处理
动态参数处理
随机生成一个六位数的数
文件上传
线程组——添加——取样器——http请求——改名为文件上传
参数名写media，文件名写上传的文件名，MIME写multipart/form-data
输入网址，则输出图片，则上传文件
通过java来发送请求，这样ok
这两种发送没什么区别，只是方式不同
上传图片
上传图片 - 接口文档 - 企业微信开发者中心
请求方式：POST（HTTPS）
请求地址：https://qyapi.weixin.qq.com/cgi-bin/media/uploadimg?access_token=ACCESS_TOKEN
使用multipart/form-data POST上传文件。
| 参数 | 必须 | 说明 |
|---|---|---|
| access_token | 是 | 调用接口凭证 |
POST的请求包中，form-data中媒体文件标识，应包含有filename、content-type等信息.
接口测试断言
接口测试调试方案
fiddler抓到jmeter的包
主要对比请求头headers和请求数据webform，一致的话就ok了
CSV参数化的处理
data.csv
必须带请求头的接口
响应的数据（很少）和网址的代码不一样（因为在这里面必须带请求头）
必须带请求头的接口应该怎么做呢？
打开fiddler，刷新一下，复制所有请求头信息（因为目前不知道需要哪个请求头信息）
添加一个信息头管理器
可以看到结果了
Jmeter的脚本录制功能
1、badbody(淘汰了，还需要用个插件)
2、使用Jmeter自带的http代码服务器实现（Jmeter作为代理）
刷新一下录制了很多请求
那我怎么知道我要哪个呢？答：增加建议排除
OK了，看下图
加上一个登录的包
怎么知道是哪个呢？
很简单，有username和password的
弄完，请还原
不然所有网站访问不了
这是第一个，它所访问的项目
用正则表达式去提取它
这样看是状态码是成功的，登录成功
Jmeter中的BeanShell组件和语言规则
第三句话要在后台才能看到（在控制台打印）
自定义变量
vars表示：JmeterVariables,操作Jmeter变量
- 用户定义的变量
- 正则表达式，JSON提取器
- 定义变量
获取到了这个值
自定义一个
在另一个beanshell获取，获取成功
props用于存取Jmeter的全局静态变量（可以跨线）
Jmeter文件里有个全局静态变量
prev
获取到前面的一个取样器返回的信息
获取到的内容
获取到的字符串（接口所返回的token的值）
上图这个内容太多了报错，我们把它放到控制台
显示上下文全局的所有变量
Jmeter执行数据库操作
方法1：放到lie目录
方法二：测试计划引用
Jmeter的非GUI方式运行
Jenkins
