1、接口测试的意义（优势）
（1）更早的发现问题：
不少的测试资料中强调，测试应该更早的介入到项目开发中，因为越早的发现bug，修复的成本越低。
然而功能测试必须要等到系统提供可测试的界面才能对系统进行测试。
而接口测试可以在功能界面开发出来之前对系统进行测试。
系统接口是上层功能的基础，接口测试可以更早更低成本的发现和解决问题。
然而，在实际的开发过程中，开发人员并没有充足的时间去编写单元测试，并且他们往往对自己编写的代码有足够的信心，不愿意将“浪费”时间在编写单元测试上面。
这个时候接口测试的作用就会变得更加重要。
如果你想学习接口测试，我这边给你推荐一套视频，这个视频可以说是B站播放全网第一的接口自动化测试教程，同时在线人数到达1000人，并且还有笔记可以领取及各路大神技术交流：798478386
Postman接口测试使用教程和接口自动化测试项目实战你要的都有_哔哩哔哩_bilibiliPostman接口测试使用教程和接口自动化测试项目实战你要的都有共计32条视频，包括：1.精通Postman之课程大纲和效果展示、2.精通Postman之接口测试简介和分类、3.精通Postman之接口测试流程和用例设计等，UP主更多精彩视频，请关注UP账号。
https://www.bilibili.com/video/BV11K4y1J7sh/?spm_id_from=333.337.search-card.all.click
（2）缩短产品研发周期：
对于产品研发周期来说，如果将所有测试工作都集中在功能测试阶段，那么测试的问题和修复周期就会变长。
因为测试可以更早的介入产品开发中，所以可以有效的控制功能测试阶段bug的数量，从而有效的缩短产品开发周期。
（3）发现更底层的问题：
系统的有些底层逻辑是在UI功能测试中不太容易触发的，那么这些逻辑可能会存在问题。接口测试可以更容易更全面的测试到这些底层的逻辑。
（4）检查服务器的异常处理能力：
我们通常把前端的验证称为弱验证，因为它很容易被绕过，这个时候如果只站在功能的层面进行测试，就很难发现一些安全的问题。
而不以功能为入口的接口测试就会很容易的验证这些异常情况。
-
比如订单接口是不允许重复提交的。
-
有些接口还要考虑性能问题。
-
比如购物车里有多个商品，全部勾选后去支付, 会判断商品库存，这时候能提交成功吗，处理逻辑又是什么?
-
安全性测试：
服务端提供API， 接口调用方在客户端，之间的通讯暴露在公网上，如果有不善意的用户抓包获取了支付接口，用1元价格购买到了100元商品，这是非常危险的，这就是安全性测试的一个方面。
SQL注入等也属于这类。
2、UI测试与接口测试对比
（1）UI测试特点:
一般互联网公司，最大的特点就是快，产品需要不停的迭代，迭代时间基本在15天左右。
UI自动化测试的优点是，能够实际模拟真实用户的行为，直接验证软件的商业价值，缺点是用例的维护和执行代价很大。
另外，UI自动化测试的稳定性问题，是长期以来阻碍UI测试发展的重要原因。
在快速迭代的情况下（如不停的更新活动界面），页面的改动可能会很频繁，而UI自动化测试本身基于页面元素，前端小小的改动可能需要测试的非常大的改动。
所以总结如下：
-
web应用和APP迭代速度非常快。
-
页面更新频繁。
-
测试成本高于效益。
-
可交付于第三方进行测试(云测、众测)。
（2）接口测试特点：
针对服务端后台测试，接口规则一旦确定，后期的变化非常的小。
相对于变化频繁的UI来说，接口测试的性价比更高。
这就成为了企业内重点测试的对象，我们都知道服务端中保存着用户数据、业务数据、交易数据等。倘若任何一个接口实现有问题，都会影响所有用户。
正是由于服务端数据和业务逻辑关系着企业的命脉，所以极少会有企业把接口交于第三方测试。
作为测试人员，我们需要验证的是接口间数据传递的正确性和完整性。
1、Requests库
Requests库是用Python语言编写，基于urllib3模块，采用Apache2 Licensed开源协议的 HTTP 库。
虽然Python的标准库中urllib3模块已经包含了平常我们使用的大多数功能，但是它的 API使用起来让人感觉不太友好。而Requests库使用的是urllib3，因此继承了它的所有特性，所以Requests库比urllib3使用更加方便，可以节约我们大量的工作，完全满足 HTTP 测试需求。
Requests库支持HTTP 连接保持和连接池，支持使用cookie 保持会话，支持文件上传，支持自动确定响应内容的编码，支持国际化的URL 和POST 数据自动编码。现代、国际化、人性化。
Requests库自称 “HTTP for Humans”（让HTTP服务于人类），说明使用更简洁方便。
Requests库是以 PEP 20 的箴言为中心开发的
Beautiful is better than ugly.(美丽优于丑陋)
Explicit is better than implicit.(直白优于含蓄)
Simple is better than complex.(简单优于复杂)
Complex is better than complicated.(复杂优于繁琐)
Readability counts.(可读性很重要)
对于 Requests 所有的贡献都应牢记这些重要的准则。
简而言之：Requests库相当于Python中的“浏览器”，可以通过它进行网络请求、获取网页数据，功能强大而且特别好用。
说明PEP20：
PEP20是编写python程序的指导准则，在python shell中输入import this就能看到是编写python程序的指导准则，在python shell中输入import this就能看到，内容如下：
TIM Peters的python之禅
The Zen of Python, by Tim Peters
优美胜于丑陋。
Beautiful is better than ugly.
明确胜于隐晦。
Explicit is better than implicit.
简单胜于复杂。
Simple is better than complex.
复杂胜于难懂。
Complex is better than complicated.
扁平胜于嵌套。
Flat is better than nested.
留白胜于紧凑。
Sparse is better than dense.
可读性很重要。
Readability counts.
特例也并不能特殊到可以违背这些原则。
Special cases aren't special enough to break the rules.
虽然实用性胜于纯粹性。
Although practicality beats purity.
错误不应被默默地忽略。
Errors should never pass silently.
除非你明确地忽视。
Unless explicitly silenced.
面对歧义，不要尝试去猜测。
In the face of ambiguity, refuse the temptation to guess.
应该有一种，最好是仅有一种，明显的处理方式。
There should be one-- and preferably only one --obvious way to do it.
一开始那种方式并非显而易见，除非你是python之父。
Although that way may not be obvious at first unless you're Dutch.
做好过不做。
Now is better than never.
不假思索就动手还不如不做。
Although never is often better than *right* now.
如果实现很难解释，那就不是个好思路。
If the implementation is hard to explain, it's a bad idea.
如果实现易于解释，则可能是个好思路。
If the implementation is easy to explain, it may be a good idea.
命名空间是个绝妙的主意，我们要多多利用它。
Namespaces are one honking great idea -- let's do more of those!2、Requests库文档
-
官方文档：https://requests.readthedocs.io/en/master/
-
中文文档：https://requests.readthedocs.io/zh_CN/latest/
-
GitHub开源地址：https://github.com/psf/requests
3、Requests库安装
安装Requests库前提条件，需要安装python环境，然后在cmd命令行中输入python -m pip install requests(推荐)或者pip install requests即可。
如下图：
执行pip list查看Requests库是否安装成功，和所安装的版本（默认安装最高版本。）
C:Users\ailin-L>pip list
Package Version
------- --------
certifi 2020.12.5
chardet 4.0.0
idna 2.10
pip 19.2.3
requests 2.25.1
selenium 3.141.0
setuptools 41.2.0
ur11ib3 1.25.9
