接口测试概览
接口
外部系统与其它系统之间或内部各子系统之间的交互点.
接口有两种，一种是程序内部的接口，一种是系统对外的接口。接口类型
web接口：http协议的接口，web service接口（如soup、rmi、rpc协议）。
webservice接口：走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都要通过工具才能进行调用，测试。
http api 接口：走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法。
http请求方式包括：get（查）、post（增），put（改）、delete（删）等.
GET：发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
POST：向服务器提交数据。，几乎目前所有的提交操作都是靠这个完成。它用来向指定资源提交数据进行处理请求（例如：提交表单和上传文件），数据包被包含在请求体中，post请求可能导致新的资源的建立或者已有的资源的修改。
PUT：HTML表单也不支持这个。本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。客户端向服务器传送的数据取代指定文档的内容。
DELETE：删除某一个资源。get型接口:格式：请求数参数写在网址后面，用"?"连接，多个参数之间用"&"连接。
https://api.douban.com/v2/music/search?q=因你而在&start=1
场景:用于获取信息，多用于查询数据，如列表查询功能，点击查询按钮就调用一个get接口，然后把信息返回出来
post型接口:向指定资源位置提交数据（如提交表单、上传文件）来进行请求，post请求可能会导致新资源的建立
https://api.douban.com/v2/book/reviews
场景：如注册、上传、发帖等功能，如用户在豆瓣网站对某本书进行收藏、写笔记、发表评论,请求数据量大，安全性高
put型接口:put请求用于向指定资源位置上传最新内容
场景：如用户在豆瓣网站修改对某本书的收藏、修改某篇笔记或修改评论.
delete型接口:
请求服务器删除请求里url所标识的资源
场景：如用户在豆瓣网站取消对某本书的收藏、删除某篇笔记或删除评论
接口测试：
测试系统组件间接口，通过脚本或者工具，模拟客户端对服务端接口进行调用。要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程， 以及系统间的相互逻辑依赖关系等。从接口层测试能更早的发现问题，从而提高测试效率，降低修复成本。接口测试的优点：
项目的影响来说，接口测试直接测试后端服务，更加接近服务器上运行的代码程序，也更能发现影响范围广泛的 Bug。
通过接口自动化完成接口回归测试，让自己的工作更轻松、更高效；
通过持续集成平台调用接口自动化测试，为流水线提供质量保障方法和手段，赋能研发。接口测试的工具：
Fiddler,Postman、SoupUI
Python代码做接口测试
jmeter(java+Jmeter+ant+jenkins做接口性能监听测试)、
robotframework+httplibrary,LoadeRunner等。接口测试的流程：
1.开发人员提供测试接口文档（需求文档）
2.根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）
3.接口测试用例编写调试完成后,部署到持续集成的测试环境中,设定脚本运行频率,告警方式等基本参数,进行接口的日常监控,每日进行接口脚本的维护更新,接口异常处理.
4.执行测试，查看不同的参数请求，接口的返回的数据是否达到预期,输出接口测试报告。接口测试的测试用例
完整http的请求过程:
浏览器(客户端)发起TCP连接请求,TCP三次握手建立连接,客户端将HTTP请求数据包发送给服务端,服务器端响应http请求,浏览器得到html代码,浏览器解析html代码,并请求html代码中的资源,渲染后呈现给用户.http中存在如下问题：请求信息明文传输，容易被窃听截取。数据的完整性未校验，容易被篡改,没有验证对方身份，存在冒充危险.
HTTPS 协议： HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。
SSL：安全套接字层1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
TLS：传输层安全其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名.
REST:表现层状态转移是HTTP协议（1.0版和1.1版）的主要设计者Roy Fielding提出的的一种架构风格。REST 规范中有如下几个核心：REST中一切实体都被抽象成资源，资源通过URI来指定。使用HTTP1.1协议定义的通用动词GET/POST/PUT/DELETE，来实现资源的增删改查操作。服务端和客户端之间用JSON，XML传输文本，或者用JPG，WebP传输图片。RESTful API:
RESTful是一种接口设计的架构风格，它不是需要严格执行的标准，而只是提供了一组可用设计原则，通过约定的规范，便于开发、测试理解沟通。越来越多的互联网公司，已经要求接口设计必须按照这种规范执行。
这样的API格式，可以达到如下目标：通过URI，就知道需要操作什么资源,通过http请求方法，就可以知道对资源进行何种操作。通过http 返回状态码，就知道操作的结果。RESTful API格式:
http://服务器地址:端口号[/项目名称/版本]/资源集合[/单个资源]HTTPS的缺点:
HTTPS协议多次握手，导致页面的加载时间延长近50%；HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗；申请SSL证书需要钱，功能越强大的证书费用越高。SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大。
HTTPS和HTTP的区别：https协议需要到CA申请证书，一般免费证书较少，使用需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用连接方式不同，默认端口也不一样，http是80，https是443。
HTTPS协议是SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。Cookie的原理:
W3C组织提出的保存在客户端本地，方便下次访问服务端时直接放到请求报文头中，如登录的cookie，下次访问同一网站时，用户不必再次输入用户名和密码就已经直接登录，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。
session原理Session保存在服务器上用来记录用户状态的机制。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。Session在用户第一次访问服务器的时候自动创建。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。一般客户端和服务端通过一个SessionID来进行沟通，为了防止不同的用户之间出现冲突和重复，SessionID一般是一个32或者48个字节的随机字符串。cookie 和session 的区别：
存放位置不同：cookie数据存放在客户端（浏览器）；session数据放在服务器端，一般存储在内存中，但是SessionID存储在客户端cookie中。cookie由浏览器存储在本地，安全有风险，不宜存储敏感信息，如密码等。session会在一定时间内保存在服务器上，访问较多时，影响服务器性能。接口的常见类型：
webService接口：它是简单对象访问协议（soap）通过http传输，SOAP=RPC+HTTP+XML，即采用HTTP作为通信协议，RPC（Remote Procedure Call Protocol 远程过程调用协议）作为一致性的调用途径，XML作为数据传送的格式，从而允许服务提供者和服务客户经过防火墙在Internet上进行通信交互，请求报文和返回报文都是xml格式，常使用测试调用工具有SoapUI、jmeter、loadrunner等。
http api接口：基于http协议，一般通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，请求方法最常见的为get和post方法，常见的测试调用工具有postman、RESTClient、jmeter、loadrunner等。
性。测试三环节:单元测试,接口测试,界面测试.
单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹.但开发很少做单元测试,故采用智能化框架补充单元测试工作或是加大接口测试,增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由 UI 层保障的业务逻辑测试.
接口测试更容易和其他自动化系统相结合；相对于界面测试，接口测试可以更早开始，也可测试一些界面测试无法测试的范围，使“测试更早的投入”这句话变成现实；接口测试还可以保障系统的健壮性，使得被测系统更健壮。
接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。理想的提测项目:
包含前期参与的产品需求、原型设计，由产品经理来提供的；产品需求。它描述系统的业务逻辑，通过这个文档，你才能知道怎么来设计测试用例；原型设计。它会更加直观地告诉你系统的使用逻辑，这对测试用例的设计、对系统的前期认知都是有辅助作用的。
包含后端接口文档、代码单元测试脚本，由开发工程师提来供的。接口文档。它详细地描述了后端接口的访问方式和参数说明，使用这个输入项才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建。单元测试脚本。它是保障提测质量的必要环节，是研发工程师自测的一个有效手段，可以保障提测项目的提测质量。现实的提测项目:一个项目没有接口文档.
拿到一个 SUT 环境的时候，首先就要进行接口测试，因为单元测试不是由测试工程师来完成的，而是由开发工程师编写、并由持续集成系统自动完成执行的。但开发没有给有价值的文档,要开始接口测试,
从工具辅助,分析问题,询问解惑三个步骤完成.
具体的工作模式：
借助一些工具的辅助来完成接口分析；通过工具截获一些接口信息；
通过分析接口的访问方式、参数等信息整理出一些问题，
和研发工程师沟通这些问题，将一些不知道的参数含义、参数取值范围等问题问清楚。Python接口测试
配置环境
pip install requests基本模板(以带参数的get请求为例)
import requests
#设置参数
param = {"q":"西游记"}
#多个参数格式：{"key1": "value1", "key2": "value2", "key3": "value3"}
#请求网站豆瓣首页
r = requests.get("https://www.douban.com/search",params=param)
#打印状态码
print(r.status_code)
#conten 字节方式的响应体，会自动为你解码 gzip 和deflate 压缩
print(r.content)
#headers 以字典对象存储服务器响应头，但是这个字典比较特殊，字典键不区分大小写，若键不存在则返回 None
print(r.headers)
# Requests 中内置的 JSON 解码器，requests的方便之处还在于，对于特定类型的响应，例如JSON，可以直接获取
#print(r.json())
# 获取 url
print(r.url )
# 编码格式，requests自动检测编码
print(r.encoding)
# 获取 cookie
print(r.cookies)
# 返回原始响应体-- r.text #字符串方式的响应体，会自动根据响应头部的字符编码进行解码
print(r.raw)
# 失败请求(非 200 响应)抛出异常
#print(r.raise_for_status())
#打印文本
print(r.text)
Post请求的接口
Post请求模板
#发送post请求的接口（dict参数）
import requests
url = 'http:bin.org/bin'
payload = {"username":'3210682950@qq.com',"passowrd":'mcaddd'}#值以字典的形式传入
response = requests.post(url=url,data=payload)
print(response.text)
#或是发送post请求的接口（json参数）
#post 的 body 是 json 类型，也可以用 json 参数传入。2、先导入 json 模块，用 dumps 方法转化成 json 格式。3、返回结果，传到 data 里
import requests
import json
url = 'https://www.baidy.com'
payload = {"username":'213123123',"password":'231312213'}#值以字典形式传入
data_json = json.dumps(payload) #转换成json格式
response = requests.post(url=url,json=data_json)
print(response.text)
#现在的网站安全性很高,一般上面的都不行.举一个header的例子
import requests
import json
url = 'http:bin.org/bin'
headers = {
"Connection": 'xxx',"Host":"xx.org","User-Agent":"xx"
}
response = requests.post(url=url,headers=headers,verify=False)
print(response.text)
print(response.json())
Post请求的四种传送正文方式
HTTP 协议规定 POST 提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。
常见的四种编码方式如下：
1、application/x-www-form-urlencoded
2、multipart/form-data
3、application/json
4、text/xmlpost请求四种传送正文方式：
（1）请求正文是application/x-www-form-urlencoded
（2）请求正文是multipart/form-data
（3）请求正文是raw
（4）请求正文是binarypost请求传data 参数，
1 # coding:utf-8
2 import requests
3 # 先打开登录首页，获取部分session
4 url = "http://localhost:8080/jenkins/j_acegi_security_check"
5 headers = {
6 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
7 } # get方法其它加个ser-Agent就可以了
8 d = {"j_username": "admin",
9 "j_password": "111111",
10 "from": "",
11 "Submit": u"登录",
12 "remember_me": "on"
13 }
14 s = requests.session()
15 r = s.post(url, headers=headers, data=d)
16 #print (r.content.decode('utf-8'))
17 # 正则表达式提取账号和登录按钮
18 import re
19 t = re.findall(r'<b>(.+?)</b>', r.content.decode('utf-8')) # 用python3的这里r.content需要解码
20 print (t[0])
21 print (t[1])https请求的SSL问题
在你不启用fiddler时，python代码直接发送https请求，不会有SSL问题（也就是说不想看到SSL问题，关掉fiddler就行）
启动fiddler抓包，会出现这个错误：
requests.exceptions.SSLError: HTTPSConnectionPool(host='passport.cnblogs.com', port=443): Max retries exceeded with url: /user/signin (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')])")))verify参数设置:
1、Requests的请求默认verify=True
2、如果你将 verify设置为 False，Requests 也能忽略对 SSL 证书的验证
3、但是依然会出现两行Warning,可以不用管
忽略Warning,添加:
requests.packages.urllib3.disable_warnings()cookie绕过验证码登录
有些登录的接口会有验证码：短信验证码，图形验证码等，这种登录的话验证码参数可以从后台获取的（或者查数据库最直接）。获取不到也没关系，可以通过添加cookie的方式绕过验证码。（注意：并不是所有的登录都是用cookie来保持登录的，有些是用token登录）
(1)先手动登录一次，然后使用Fiddler抓取这个cookie,先打开博客园登录界面，手动输入账号和密码（勾选下次自动登录）.打开fiddler抓包工具，刷新下登录首页，就是登录前的cookie了,如图.
(2)登录成功后，再查看cookie变化，发现多了两组参数，多的这两组参数就是我们想要的，copy出来，一会有用,如图
(3)添加cookie:1、往session里面添加cookie,在set里面参数按括号里面的参数格式.
c = requests.cookies.RequestsCookieJar()
c.set('.CNBlogsCookie', 'xxx')
c.set('.Cnblogs.AspNetCore.Cookies','xxx')
s.cookies.update(c)
print(s.cookies) 1 # coding:utf-8
2 import requests
3 # 先打开登录首页，获取部分cookie
4 url = "https://passport.cnblogs.com/user/signin"
5 headers = {
6 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
7 } # get方法其它加个ser-Agent就可以了
8 s = requests.session()
9 r = s.get(url, headers=headers,verify=False)
10 print s.cookies
11 # 添加登录需要的两个cookie
12 c = requests.cookies.RequestsCookieJar()
13 c.set('.CNBlogsCookie', 'xxx') # 填上面抓包内容
14 c.set('.Cnblogs.AspNetCore.Cookies','xxx') # 填上面抓包内容
15 s.cookies.update(c)
16 print s.cookies
17 # 登录成功后保存编辑内容
18 url2= "https://i.cnblogs.com/EditPosts.aspx?opt=1"
19 body = {"__VIEWSTATE": "",
20 "__VIEWSTATEGENERATOR":"FE27D343",
21 "Editor$Edit$txbTitle":"这是绕过登录的标题：北京-宏哥",
22 "Editor$Edit$EditorBody":"<p>这里是中文内容：http://www.cnblogs.com/duhong/</p>",
23 "Editor$Edit$Advanced$ckbPublished":"on",
24 "Editor$Edit$Advanced$chkDisplayHomePage":"on",
25 "Editor$Edit$Advanced$chkComments":"on",
26 "Editor$Edit$Advanced$chkMainSyndication":"on",
27 "Editor$Edit$lkbDraft":"存为草稿",
28 }
29 r2 = s.post(url2, data=body, verify=False)
30 print r.contentcookie组成结构
用抓包工具fidller只能看到cookie的name和value两个参数，实际上cookie还有其它参数
cookie ={u'domain': u'.cnblogs.com', u'name': u'.CNBlogsCookie', u'value': u'xxxx', u'expiry': 1491887887, u'path': u'/', u'httpOnly': True, u'secure': False}
name：cookie的名称
value：cookie对应的值，动态生成的
domain：服务器域名
expiry：Cookie有效终止日期
path：Path属性定义了Web服务器上哪些路径下的页面可获取服务器设置的Cookie
httpOnly：防脚本攻击
secure:在Cookie中标记该变量，表明只有当浏览器和Web Server之间的通信协议为加密认证协议时，浏览器才向服务器提交相应的Cookie。当前这种协议只有一种，即为HTTPS。
session关联接口
新建会话,然后fiddler抓包,把body的参数内容写成字典格式,用上面登录保存的session继续发送post请求，来新建任务.执行后，查看所有任务就多了一条新增的.
# coding:utf-8
import requests
# 先打开登录首页，获取部分session
url = "http://localhost:8080/jenkins/j_acegi_security_check"
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
} # get方法其它加个ser-Agent就可以了
d = {"j_username": "admin",
"j_password": "111111",
"from": "",
"Submit": u"登录",
"remember_me": "on"
}
s = requests.session()
r = s.post(url, headers=headers, data=d)
#print (r.content.decode('utf-8')) 1 # coding:utf-8
2 import requests
3 # 先打开登录首页，获取部分session
4 url = "http://localhost:8080/jenkins/j_acegi_security_check"
5 headers = {
6 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
7 } # get方法其它加个ser-Agent就可以了
8 d = {"j_username": "admin",
9 "j_password": "111111",
10 "from": "",
11 "Submit": u"登录",
12 "remember_me": "on"
13 }
14
15 s = requests.session()
16 r = s.post(url, headers=headers, data=d)
17 #print (r.content.decode('utf-8'))
18 # 正则表达式提取账号和登录按钮
19 import re
20 t = re.findall(r'<b>(.+?)</b>', r.content.decode('utf-8')) # 用python3的这里r.content需要解码
21 print (t[0])
22 print (t[1])
23 #新建任务
24 url1 = "http://localhost:8080/jenkins/createItem"
25 body = {"name":"北京-宏哥1",
26 "mode": "hudson.model.FreeStyleProject",
27 "Jenkins-Crumb":"51a97fc7fbf3792823230d9bdd7ec906",
28 "json":{"name":"北京-宏哥1",
29 "mode": "hudson.model.FreeStyleProject",
30 "Jenkins-Crumb":"51a97fc7fbf3792823230d9bdd7ec906"
31
32 }
33 }
34
35 r2 = s.post(url1, data=body, verify=False)
36 print (r2.content.decode('utf-8'))参数关联接口
1 # coding:utf-8
2 import requests
3 # 先打开登录首页，获取部分session
4 url = "http://localhost:8080/jenkins/j_acegi_security_check"
5 headers = {
6 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
7 } # get方法其它加个ser-Agent就可以了
8 d = {"j_username": "admin",
9 "j_password": "111111",
10 "from": "",
11 "Submit": u"登录",
12 "remember_me": "on"
13 }
14
15 s = requests.session()
16 r = s.post(url, headers=headers, data=d)
17 #print (r.content.decode('utf-8'))
18 # 正则表达式提取账号和登录按钮
19 import re
20 t = re.findall(r'<b>(.+?)</b>', r.content.decode('utf-8')) # 用python3的这里r.content需要解码
21 print (t[0])
22 print (t[1])
23 #新建任务
24 url1 = "http://localhost:8080/jenkins/createItem"
25 body = {"name":"6666",
26 "mode": "hudson.model.FreeStyleProject",
27 "Jenkins-Crumb":"51a97fc7fbf3792823230d9bdd7ec906",
28 "json":{"name":"6666",
29 "mode": "hudson.model.FreeStyleProject",
30 "Jenkins-Crumb":"51a97fc7fbf3792823230d9bdd7ec906"
31
32 }
33 }
34 print(type (body))
35 import urllib
36 import sys
37 #获取name的值
38 name = body['name']
39 print('name:'+name)
40 #获取body的值
41 Jenkins_Crumb = body['Jenkins-Crumb']
42 print('body的值是：',body['Jenkins-Crumb'])
43 r2 = s.post(url1, data=body, verify=False)
44 #print (r2.content.decode('utf-8'))
45 #删除新建任务
46 url2 = "http://localhost:8080/jenkins/job/"+name+"/doDelete"
47 body1 = {
48 "Jenkins-Crumb": Jenkins_Crumb
49 }
50
51 r3 = s.post(url2, data=body1, verify=False)
52 print (r3.content.decode('utf-8'))
53 #删除成功重定向到主界面（由于抓包没有看到response的结果，只知道重定向主界面）
54 print(r3.url)Json 数据处理
在python里面写的代码，传到json里，不用说肯定识别不了，所以需要把python的代码经过encode后成为 json 可识别的数据类型，反之json数据就需要decode后成为python代码可识别的数据类型。
1 # coding:utf-8
2 import requests
3 # 先打开登录首页，获取部分cookie
4 url = "https://passport.cnblogs.com/user/signin"
5 headers = {
6 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0"
7 } # get方法其它加个ser-Agent就可以了
8 s = requests.session()
9 r = s.get(url, headers=headers,verify=False)
10 print (s.cookies)
11 # 添加登录需要的两个cookie
12 c = requests.cookies.RequestsCookieJar()
13 c.set('.CNBlogsCookie', 'XXX') # 填上面抓包内容
14 c.set('.Cnblogs.AspNetCore.Cookies','XXX') # 填上面抓包内容
15 c.set('AlwaysCreateItemsAsActive',"True")
16 c.set('AdminCookieAlwaysExpandAdvanced',"True")
17 s.cookies.update(c)
18 print (s.cookies)
19 result = r.content
20 print(result.decode('utf-8'))
21 # 登录成功后保存编辑内容
22 url2= "https://i.cnblogs.com/EditPosts.aspx?opt=1"
23 body = {"__VIEWSTATE": "",
24 "__VIEWSTATEGENERATOR":"FE27D343",
25 "Editor$Edit$txbTitle":"这是绕过登录的标题：北京-宏哥",
26 "Editor$Edit$EditorBody":"<p>这里是中文内容：http://www.cnblogs.com/duhong/</p>",
27 "Editor$Edit$Advanced$ckbPublished":"on",
28 "Editor$Edit$Advanced$chkDisplayHomePage":"on",
29 "Editor$Edit$Advanced$chkComments":"on",
30 "Editor$Edit$Advanced$chkMainSyndication":"on",
31 "Editor$Edit$lkbDraft":"存为草稿",
32 }
33 r2 = s.post(url2, data=body, verify=False)
34 print (r.content.decode('utf-8'))
35
36 # 第三步：正则提取需要的参数值
37 import re
38 postid = re.findall(r"postid=(.+?)&", r2.url)
39 print(type(postid))
40 print (postid) # 这里是 list
41 # 提取为字符串
42 print (postid[0])
43 # 第四步：删除草稿箱
44 url3 = "https://i.cnblogs.com/post/delete"
45 json3 = {"postId": postid[0]}
46 r3 = s.post(url3, json=json3, verify=False)
47 result = r3.content #content数据是字节输出
48 print(type(result))
49 print(result)
50 #json是经过加码encode成对应python的数据类型
51 result1 = r3.json()
52 print (type(result1))
53 print(result1['isSuccess'])以快递100为案例
1.在浏览器中打开快递100,link输入单号.
2.抓包看参数和url
代码如下:
import requests
import json
url ="https://www.kuaidi100.com/query?type=zhongtong&postid=73124853607476&temp=0.9490992175423745&phone= "
headers = {
"User-Agent" : "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36"
} # get 方法加个 User-Agent 就可以了
s = requests.session()
r = s.get(url, headers=headers,verify=False)
result = r.json()
#以上是代码模拟接口请求
data = result['data'] # 获取 data 里面内容
print (data)
print (data[0]) # 获取 data 里最上面有个
get_result = data[0]['context'] # 获取已签收状态
print (get_result)
#以上取到接口返回结果
#下面是进行断言
if u"已签收" in get_result:
print ("快递单已签收成功")
else:
print ("未签收")获取重定向后地址
1 # coding:utf-8
2 import requests
3 # 请求头
4 headers = {
5 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
6 }
7 s = requests.session()
8 # 打开我的随笔
9 r = s.get('https://i.cnblogs.com/EditPosts.aspx?opt=1',
10 headers=headers,
11 allow_redirects=False,
12 verify=False)
13 # 打印状态码，自动处理重定向请求
14 print (r.status_code)
15 new_url = r.headers["Location"]
16 print (new_url)token登录
为了验证用户登录情况以及减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。有些登录不是用 cookie 来验证的，是用 token 参数来判断是否登录。token 传参有两种一种是放在请求头里，本质上是跟 cookie 是一样的，只是换个单词而已；另外一种是在 url 请求参数里，这种更直观.
如图,登录返回带token:
请求头带token:登录成功后继续操作其它页面，发现post请求的请求头，都会带有token参数
token关联
1、用脚本实现登录，获取token参数，获取后传参到请求头就可以了
2、如果登录有验证码，前面的脚本登录步骤就省略了，自己手动登录后获取token
1 # coding:utf-8
2 import requests
3 header = { # 登录抓包获取的头部
4 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0",
5 "Accept": "*/*",
6 "Accept-Language": "zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3",
7 "Accept-Encoding": "gzip, deflate",
8 "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
9 "X-Requested-With": "XMLHttpRequest",
10 "Content-Length": "423",
11 "Connection": "keep-alive"
12 }
13 body = {"key1": "value1",
14 "key2": "value2"} # 这里账号密码就是抓包的数据
15 s = requests.session()
16 login_url = "http://xxx.login" # 自己找带token网址
17 login_ret = s.post(login_url, headers=header, data=body)
18 # 这里token在返回的json里，可以直接提取
19 token = login_ret.json()["token"]
20 # 这是登录后发的一个post请求
21 post_url = "http://xxx"
22 # 添加token到请求头
23 header["token"] = token
24 # 如果这个post请求的头部其它参数变了，也可以直接更新
25 header["Content-Length"]="9"
26 body1 = {
27 "key": "value"
28 }
29 post_ret = s.post(post_url, headers=header, data=body1)
30 print post_ret.contentToken的来源：
当客户端多次向服务端请求数据时，服务端就需要多次从数据库中查询用户名和密码并进行对比，判断用户名和密码是否正确，并作出相应提示。但这样无疑会增加服务器端的运行压力，是否可以有一种方式只需要验证用户就是之前的用户而不需要每次在客户端请求数据时都需要查询数据库判断用户名和密码是否正确。在这种请求下，引入了token来解决服务器端多次访问数据库问题。什么是token
Token是服务端端生成的一串字符串，作为客户端进行请求时辨别客户身份的的一个令牌。当用户第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。使用Token的目的：
Token的目的是为了验证用户登录情况以及减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。Token的运用流程：
1、当用户首次登录成功之后, 服务器端就会生成一个 token 值，这个值，会在服务器保存token值(保存在数据库中)，再将这个token值返回给客户端；
2、客户端拿到 token 值之后，进行保存 （保存位置由服务器端设置）；
3、以后客户端再次发送网络请求(一般不是登录请求)的时候,就会将这个 token 值附带到参数中发送给服务器.；
4、服务器接收到客户端的请求之后,会取出token值与保存在本地(数据库)中的token值进行比较；
5、如果两个 token 值相同， 说明用户登录成功过!当前用户处于登录状态；
6、如果没有这个 token 值, 没有登录成功；
7、如果 token 值不同: 说明原来的登录信息已经失效,让用户重新登录；
8、Django Rest framework中JWT的使用稍有差异，这里不做详细说明。状态码表
简略状态码表
| 已定义范围 | 分类 | |
|---|---|---|
| 1XX | 100-199 | 信息提示，用于指定客户端相应的某些动作 |
| 2XX | 200-299 | 成功，用于表示请求成功 |
| 3XX | 300-399 | 重定向，用于移动的文件并且常被包含在定位头信息中制定新的地址信息 |
| 4XX | 400-499 | 客户端错误，用于指出客户端的错误 |
| 5XX | 500-599 | 服务器错误，用于指出服务器的错误 |
常见状态码
200 OK 服务器成功处理了请求（这个是我们见到最多的）
301/302 Moved Permanently（重定向）请求的URL已移走。Response中应该包含一个Location URL, 说明资源现在所处的位置
304 Not Modified（未修改）客户的缓存资源是最新的， 要客户端使用缓存
404 Not Found 未找到资源
501 Internal Server Error服务器遇到一个错误，使其无法对请求提供服务状态码详解对照表
| 状态码 | 含义 |
|---|---|
| 100 | 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。 |
| 101 | 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 |
| 102 | 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 |
| 200 | 请求已成功，请求所希望的响应头或数据体将随此响应返回。 |
| 201 | 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。 |
| 202 | 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。 返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。 |
| 203 | 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。 |
| 204 | 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。 如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。 由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。 |
| 205 | 服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。 与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。 |
| 206 | 服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。 该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。 响应必须包含如下的头部域： Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。 Date ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。 Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了 If-Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。 假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。 任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。 |
| 207 | 由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。 |
| 300 | 被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。 除非这是一个 HEAD 请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。 如果服务器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。 |
| 301 | 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。 新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个301响应的话，接下来的重定向请求将会变成 GET 方式。 |
| 302 | 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。 |
| 303 | 对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。 新的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 注意：许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。 |
| 304 | 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。 该响应必须包含以下的头信息： Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。 ETag 和/或 Content-Location，假如同样的请求本应返回200响应。 Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使用了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。 假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。 假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。 |
| 305 | 被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。 注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。 |
| 306 | 在最新版的规范中，306状态码已经不再被使用。 |
| 307 | 请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求，否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。 如果这不是一个GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 |
| 400 | 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。 |
| 401 | 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 |
| 402 | 该状态码是为了将来可能的需求而预留的。 |
| 403 | 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。 |
| 404 | 请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。 |
| 405 | 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。 |
| 406 | 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。 |
| 407 | 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。 |
| 408 | 头用以验证。参见RFC 2617。408 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 |
| 409 | 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。 |
| 410 | 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。 |
| 411 | 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。 |
| 412 | 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。 |
| 413 | 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。 |
| 414 | 请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括： 本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。 重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。 |
| 415 | 对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。 |
| 416 | 如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。 |
| 417 | 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。 |
| 421 | 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 |
| 422 | 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 |
| 423 | 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）423 Locked 当前资源被锁定。（RFC 4918 WebDAV） |
| 424 | 由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV） |
| 425 | 在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。 |
| 426 | 客户端应当切换到TLS/1.0。（RFC 2817） |
| 449 | 由微软扩展，代表请求应当在执行完适当的操作后进行重试。 |
| 500 | 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。 |
| 501 | 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。 |
| 502 | 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。 |
| 503 | 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。 注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。 |
| 504 | 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 注意：某些代理服务器在DNS查询超时时会返回400或者500错误 |
| 505 | 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。 |
| 506 | 由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。 |
| 507 | 服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918) |
| 509 | 服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。 |
| 510 | 获取资源所需要的策略并没有没满足。（RFC 2774） |
Fiddler接口测试
一个 HTTP 的调试代理， HTTP 协议的抓包工具，运行时会在本地建立一个代理服务，默认地址为 127.0.0.1:8888。
当浏览器和被访问的服务之间发生交互，Request（请求）和 Response（响应）都会经由 Fiddler 代理，可截获全部的访问信息流。先打开Fiddler(需配置抓取HTTPS的网址),然后启动浏览器访问被测项目地址,如XX
点击Fiddler的Inspectors的标签页,查看Request请求的内容和Response请求的内容.注意一下几个参数:
HOST，它表示指定访问的服务器域名；
Connection 的值为 keep-alive，这表示需要持久连接；
Accept，它表示客户端可以接受的内容类型为 application/json, text/plain, User-Agent，它说明请求是从什么浏览器发出去的；
Sec-Fetch-Site 和 Sec-Fetch-Mode，它们是 JS 中对跨域的一些设置；
Accept-Encoding 设置为 gzip、deflate、br，这表示可以支持的 Web 服务器返回内容压缩编码类型；
Accept-Language，它表示接受的语言。其中的 Cookie 的内容，特别重要，因为 Cookie 中传递的参数很多都是用来确认用户身份、鉴定角色权限等需要的参数。通过上面的分析绘制如下的表格.
在表格中，被标注为白色背景的部分，是这次访问的基本信息；被标注为黄色背景的部分，是访问的头信息，同时也是我们已知的内容；被标注为红色背景的部分，就是 Cookie 信息，是我们未知的内容。同时你可以看到，本次消息访问的 body 是空的，是没有内容的。
再看请求的Response信息，这些返回值包含了很多参数，也需要关注这些参数，很多时候，一个接口的返回值会是另外一个接口的入参，也就是我常说的串联业务逻辑上下文的参数。
拿着这张接口信息表，进入了第三步，询问解惑。去搞懂这些参数是干什么，起什么作用，怎样算搞懂，判断如下：
（1） 你要搞清楚每一个参数的含义，也就是这个参数对应的实际自然语言的名字，通过记录每一个参数的中文语义，也会让更你容易记住这个函数是干什么的。同时，你也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到的？还是 JS 生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个字段？这样，当你开始做接口测试的时候，你就知道去哪里拿到这个参数的赋值了。如果是另一个接口的返回字段，那么，你还需要维护一份返回该参数接口的接口信息文档，以便于自己下一次创建对应的参数，如果不可以创建，那么你就要知道这个参数的生成规则，也要知道如何手动构造它。
（2） 参数的作用域：参数的作用域指的是这个参数在这个接口中是做什么用的，它在哪一个访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验证用户权限吗？它的验证算法是什么？之所以要搞清楚这些内容，是为了你在做接口测试的时候，可以设计更小的参数组合来覆盖更多的业务逻辑，这是测试用例去除冗余的一个很好的方法。
（3） 返回值的含义：针对上面一大串的返回 JSON，你要搞清楚在返回值中，每一个 JSON 的 Key 所对应的含义，这样，当你需要和这个接口产生交互的时候，就可以快速地拿到对应参数的含义，完成业务逻辑上下文的参数串联了。以上借助工具、通过分析问题明确未知参数，也通过询问解决未知参数的中文含义、作用域，以及对应返回参数的中文含义，现在，即使面对没有接口文档的提测项目，也能收集明确的、足够的信息。接下来进行业务逻辑的接口测试。
多个接口之间并不是随意组合的，而是按照业务逻辑、通过数据传递来完成的。要想使用接口测试完成业务逻辑，要制作一个流程中所有接口的接口信息表，同时理清每一个流程的数据流程，数据流程驱动业务流处理，才能开始业务逻辑的接口测试。
开发自己的测试框架：
在win10环境配好python,先pip install requests,然后敲代码设计用例，见相关文件。再新建文件夹,新建一个common.py(见下图),然后一个个设计测试用例,模板使用unittest.
测试框架支持RESTful风格接口：
RESTful风格接口使用JSON格式进行数据交换.使框架支持可以借助python的相关支持库或自己封装.
测试平台：用工具和框架结合搭建平台.
使用post工具设计脚本(在code里面,可读性差要改写),放到自己的框架中,使用github保存. 测试未知协议：
接口测试最快速的方法不是去看协议的说明文档，而是直接去看开发实现的客户端代码.API 测试的基本步骤:
准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）, 通过 API 测试工具，发起对被测 API 的 request, 证返回结果的 response。
API 测试工具，比如常见的命令行工具 cURL、图形界面工具 Postman 或者 SoapUI、API 性能测试的 JMeter 等.杂症
公司项目的单接口、串联接口都已经在做 但是好多时候接口已经测试完 然后开发改了部分接口，导致接口再次自动化回归的时候就又有问题了 这样很被动，请问下如何解决此类问题？
变更频繁这个问题目前只能在项目内部解决，服务端工程师应该设计接口，所有相关人评审后就不能变更，要变更需要有人承担成本。这个可以通过引入敏捷模式来进行规避，可以关注一下对应内容。get和post的区别
从三个方面去回到这个区别:方式、大小、安全.
方式:方式指的是参数的传入方式，GET方法一般是指获取服务器上的数据，参数直接跟着URL后边，直接可以放到浏览器地址栏里，例如登录就是采用GET方法。而POST方法是指客户端给服务器上提交表单数据，所以POST是通过表单提交的，例如你网页上的新用户的注册、调查问卷和答题就是采用POST方法。
大小:GET是直接在浏览器地址栏输入，由于浏览器有限制，一般整个URL的长度可以很长，但是不能超过2049KB的大小限制，而这个POST就没有大小限制。
安全性:GET的参数是在浏览器地址栏直接拼接，暴露在互联网中，肯定不安全。POST是通过表单数据提交，相对比GET方法更安全。接口测试与自动化测试的区别？
自动化测试如app自动化测试、web自动化测试：都是模拟人类的行为去测试，底层都是通过接口去和服务器进行交互,接口测试可以在底层模拟人类的行为去进行测试。python中字典和json的区别
json：是一种数据格式，是纯字符串。可以被解析成Python的dict或者其他形式。
dict：是一个完整的数据结构，是对Hash Table这一数据结构的一种实现，是一套从存储到提取都封装好了的方案。它使用内置的哈希函数来规划key对应value的存储位置，从而获得O（1）的数据读取速度。
实际上JSON就是Python字典的字符串表示，但是字典作为一个复杂对象是无法直接转换成定义它的代码的字符串，字典是一个数据的结构，而json只是一个具有一定规则的字符串，方便在不同平台上处理其中包含的数据。
但本质上来讲，字典是一种数据结构，json是一种格式；字典有很多内置函数，有多种调用方法，而json是数据打包的一种格式，并不像字典具备操作性，并且是格式就会有一些形式上的限制，
比如json的格式要求必须且只能使用双引号作为key或者值的边界符号，不能使用单引号，而且“key”必须使用边界符（双引号），但字典就无所谓了。形式上的相近也让python提供了json.loads()转换函数，方便json数据的调用。
。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。