接口测试相关
为什么要做接口测试？
1、什么是接口测试？
2、为什么要做接口测试，接口测试什么时候做？
3、接口测试怎么做？
JMeter
发送get请求
发送post请求
post请求中参数类型为form格式
post请求参数类型为json格式
断言
参数化
关联等
4、接口文档都有什么内容？
5、接口测试用例怎么写？
6、接口测试发现什么问题？
7、接口调不通了怎么办？
什么是接口？
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点来，通过一些特殊的规则也就是协议，来进行数据之间的交互。
什么是接口测试？
接口测试主要用于检测外部系统与内部系统之间，以及系统内部各个子系统之间的交互点。其测试的重点是：检查数据的交换、传递和控制管理过程，以及系统间的逻辑依赖关系。
接口文档是对前后端开发的强有力约束
接口文档都有什么内容？
1. 接口名字
2. 描述（描述清楚接口的功能）
3. url
4. 请求方式
5. 传入参数：字段、说明、类型、备注、是否必填这5列
6. 返回参数值：字段、类型。
没有接口文档如何做接口测试？
没有接口文档，那还能咋办，瞎测呗！一个公司的开发流程里面，如果接口文档都没有，是无法展开接口测试的，你都不知道这个接口干什么的，也不知道具体每个字段代表什么意思，那还测啥呢？
1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住他，先说自己整理了）
2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通
3.没有需求文档的话，首先会找找资料，看公司之前有没有做过类似的项目，如果有就拿来参考。其次在产品经理介绍项目的时候认真听，做好笔记，有什么疑问就提。
为什么要做接口测试，接口测试什么时候做？
绕过前段传入数据
1.越底层发现bug，它的修复成本是越低的。
2.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
3.检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。
4.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
5. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
6. 现在很多系统前后端架构是分离的，从安全层面来说：
(1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
尽早进行系统集成测试，暴露BUG
解决系统测试复杂度
屏蔽UI层的不稳定性
检查系统安全性，稳定性
接口经过测试稳定了，前端页面随便改，减少BUG的产生
接口功能测试点
接口文档规范性
接口可用性
接口实现功能验证
输入输出参数个数及命名
输入参数的必填项
输入参数的合法性
输出参数内容的正确性
接口传递参数的安全性
接口测试怎么做？
首先是拿到接口文档，然后再进行接口测试。
.通过性验证：首先肯定要保证这个接口功能是好的，也就是正常的通过性测试，
我们的接口文档放在Swagger上，按照接口文档上的参数，正常传入，是否可用返回正确的结果。
也会根据以下这几个维度进行测试。
1、接口的请求参数它的数据类型后台是否做了校验
2、接口的请求参数必填的参数后台是否做了处理
3、接口的请求参数长度是否做了处理
4、提供的接口是否实现了对应的业务场景和业务功能
5、接口关联的
6、密码安全规则，密码的复杂程度校验
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
性能测试：
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别
遇到的bug，自己放几个进去
通常情况下，我们都是用jmeter工具来测的。
你做接口测试，测什么？
首先，明确我们做接口测试质量的标准，以及测试点，这样你就知道我们要从哪方面去测了，测什么
a) 业务功能覆盖是否完整
b) 业务规则覆盖是否完整
c) 参数验证是否达到要求（边界、业务规则）
d) 接口异常场景覆盖是否完整
e) 接口覆盖率是否达到要求
f) 代码覆盖率是否达到要求
g) 性能指标是否满足要求
h) 安全指标是否满足要求
接口测试用例怎么写
三个步骤：
初始化测试数据
调用接口，传入输入数据
对输出断言
接口测试能发现哪些问题？
1.可以发现很多在页面上操作发现不了的bug
2.检查系统的异常处理能力
3.检查系统的安全性、稳定性
4.前端随便变，接口测好了，后端不用变
5.可以测试并发情况，一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
6.可以修改请求参数，突破前端页面输入限制（如金额）
接口调不通了怎么办？（如何排查）
① 接口没有任何响应
1检查接口IP地址是否正确，ping一下接口地址。
2检查被测接口端口号是否正确，可以在本机Telnet接口的IP和端口号，检查端口号能否连通
3检查项目是否启动或部署成功，可以找研发确认，或者自己登录到服务器上，通过ps检查项目的进程是否存在，然后用tail命令查看部署日志
4检查服务器的防火墙是否关闭，如果是以为安全或者权限问题不能关闭，需要找运维进行策略配置，开放对应的IP和端口。
5检查你的客户端（浏览器、测试工具），是否设置了网络代理，网络代理可以造成请求失败。
6检查操作系统的host文件，映射的地址是否正确。
② 接口有相应但是返回了错误状态码。
当一个接口出现异常时候，你是如何分析异常的？
1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了
2.查看后端日志，xhell连上服务器，查看日志
bug出现的原因？
1）需求了解错误，对需求了解不一致
2）代码里面出现了bug（开发里面）
分析bug是前端还是后端的？
平常提bug的时候，前端开发和后端开发总是扯皮，不承认是对方的bug
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯
（页面上的展示问题通常是前端的）
一个Bug出现，最简单易行的判断办法是：通过请求与响应来判断。
如果前端已经把数据发送给了后端，后端接到请求，而后端没有返回数据请求，则是后端出了问题；
如果前端在用户输入数据后，发送的请求没有带数据，则是前端的问题，或者后台已经传回了数据，但在前端显示不出来，这是前端问题。
bug不能重现怎么办？
当时崩溃的时候就要截图，写日志，把记录下来，也可以多次回顾是如何操作的，尝试是否能够重现
一定要提交。
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
开发不认这个bug怎么办？
从自身入手
任何时间检查自己的问题是非常有必要的。
可以通过如下方式，避免测自己提的 bug 本身有问题：
再次验证所提的 bug 确实是 bug，确保自身对需求的理解无误；
检查bug的描述是否会产生歧义；
检查是否是环境或数据的问题，在开发处无法复现。
与开发确认
了解开发为什么不认可，需求不明确？
接收到的需求是否一致？或者理解错误？
与开发讨论，讲清楚你的理由，该问题可能对用户造成的影响。
找权威裁决
如果与开发讨论后依然无法解除争议，这种争议问题一般集中在需求有歧义不明确、或用户体验的地方（数据问题、逻辑问题一般不会有争议）。
可以先找产品经理确认，产品经理对用户的使用和期望是最了解的，也就会清楚 bug 可能对用户造成的影响。
产品经理通过对影响的确认评估是否需要修改。如果你对此依然有疑虑，应该表明你的观点，由产品经理或项目经理决定。
上线的标准？
用例执行完（也不一定执行完，有不能复现的bug，可以给项目经理提出来，然后不能就上线）
bug修改完：是否已经处理完毕，有没有一二级bug
项目验收通过
回归测试：核心流程、核心功能是否完整可用？
时间选择好了么
内容是否已经准备完毕可以正常使用
所有文案是否明确无歧义
什么是需求评审？
统一思想，明确需求，确定实现过程的会议
俗称挑刺大会
为什么非要做需求评审？
电脑上不了网了怎么办？
首先看物理层，检查网线是否松动了，有没有插好
然后在cmd里面ping一下 baidu.com，看看是否正常
然后360断网急救箱
接口测试你是怎么设计的？
接口测试相对稳定一些，绕过前段
