但是，我还是想说说RequestLibrary
转自公众号投稿：https://mp.weixin.qq.com/s/FUs5wjU1gn89u1CODUCV2A
RequestsLibrary大家都不陌生，作为robotframework接口请求常用关键字被频繁使用。
但是，笔者最近在写自动化接口用例时，发现RequestsLibrary库和N年前的老版本相比，还是有了不少改（优）变（化），在用法上来说还是有一点区别。
那么，今天就让我们老生常谈，再聊聊这个RequestsLibrary库吧~
版本对比
RequestsLibrary最新版本为2021.4.22号发布的0.91版本，适配python2.x和python3.x，只需一句pip install robotframework-requests命令即可在线安装。
与历史<0.8版本相比，0.9的版本兼容了0.8版本的功能，并更进一步优化，主要改变在以下方面。
新的关键字结构
所有请求关键字都已被重写，并在不久的将来允许在没有会话的情况下请求关键字。
旧关键字* Request现已弃用，并将在 1.0.0 版本中删除。例如Get Request已经弃用，在0.8版本中用GET On Session替代，而在0.9版本中可以只用GET不需要一个会话时。
状态码上的隐式断言
- On Session如果返回错误状态码，关键字会自动失败。
expect_status=可用于指定状态代码 ( 201, OK, Bad request) 或者为any当你想自己判断响应码时。
还是举个例子吧！
图片
图1 RequestsLibrary新版http接口请求样例
关键字详解
大家是否发现了，图1中的Status Should Be关键字在get请求后，使用Status Should Be判断请求响应码是否与预期一致。
但与以往不同的时，该关键字不需要传入待判断的请求返回响应码，默认时判断最后一个http请求的响应码。
对比起来，是不是简单、清晰多了？所以，我们还是一起再来看看0.91版本的RequestsLibrary关键字吧。
该版本一共提供了33个关键字，列表如下：
图片
除开被替代的7个关键字，来说一说剩下的26个关键字的用法吧。
创建会话关键字
图片
表1 创建会话关键字
RequestsLibrary提供了5个创建会话的关键字，乍一看也许你和此刻的我一样二脸懵逼，实在不太搞得清楚他们之间的区别。
其实，他们之间没有太大的区别，仅有的小区别就存在于传入的参数有略微不同，如上表1所示，已经用红色字体给大家标注出不同关键字之间参数差异。
Create Client Cert Session
alias
会话名，给一个建立的连接会话起一个名字以供rf区分，具有唯一性格。
url
需要连接服务器的基础地址。比如图1所示样例中，最终要访问的是http://bbs.51testing.com/images/54646789.jpg，但建立会话的url为基础地址http://bbs.51testing.com。
headers
http请求头部，是一些字典kv组合，如Accept: text/plain。
client_certs
'client certificate', 'client key'] 包含客户端密钥和证书的 PEM 文件。
timeout
连接超时时间，默认单位为s。
proxies
包含http和https请求时的代理url。
verify
是否验证SSL证书，主要在https请求时使用，设置为True时，需要提供CA_BUNDLE路径，默认为False。
debug
设置debug等级，默认为0，表示无debug详细信息输出。
max_retries
每个连接最大重试次数，默认为3。
backoff_factor
每次重试后引入更长的重试之间的延迟时间。
ReqestsLibrary底层引用urllib3的backoff_factor计算方法，计算公式为{backoff factor} * (2 ** ({number of total retries} - 1))。
例如：如果 backoff_factor 设置为 0.1，则尝试之间的等待时间将为：0.0, 0.2, 0.4。
disable_warning
禁用告警，当测试用例多时，该参数很有用。
retry_status_list
整数 HTTP 状态代码列表，如果响应码在该列表内，则尝试重试。
例如设置为 [502, 503] 以在返回这些状态时重试请求，请注意，max_retries必须大于0。
retry_method_list
允许重试的大写 HTTP 方法列表。默认情况下，仅允许对被认为是幂等的 HTTP 请求方法进行重试（具有相同参数的多个请求以相同状态结束）。
例如，设置为 ['POST', 'GET'] 以仅重试POST和GET类型的请求。
Create Custom Session
其他相同参数不再赘述，单独说说不一样的参数auth。
auth
要传递到请求库的自定义身份验证对象。
例如有一个web服务，该服务只在headers中X-Pizza设置为密码值时才会响应，则可以定义一个方法为PizzaAuth，传参为headers的X-Pizza值。然后使用Create Custom Session关键字，设auth=PizzaAuth(‘xxxx’)即可。
Create Digest Session
其他相同参数不再赘述，单独说说不一样的参数auth。
auth
['DOMAIN', 'username', 'password'] 用于 DIGEST （一种验证方式）身份验证。
Create Ntlm Session
其他相同参数不再赘述，单独说说不一样的参数auth。
auth
['DOMAIN', 'username', 'password'] 用于 NTLM （一种验证方式）身份验证。
Create Session
auth
HTTP 基本身份验证的用户名和密码列表。
http请求关键字
图片
表2 http请求关键字
Get和Get On Session
在第一节已经提到，* On Session在不久的将来1.0版本中将会被替代， On Session和的区别只在于 On Session需要在请求前创建会话，然后通过alias参数引用该会话，而*（如GET，POST等）关键字则无需单独创建会话。
url
用于接受http请求的网址，例如图1所示样例中，最终要访问的是http://bbs.51testing.com/images/54646789.jpg，使用Get关键字则需要填写完整链接http://bbs.51testing.com/images/54646789.jpg，使用Get On Session则只需填写/images/54646789.jpg。
expected_status
可用于指定状态代码 ( 201, OK, Bad request) 或者为any当你想自己判断响应码时。
msg
当返回响应码与expected_status，自定义输出的信息。
****kwargs**
传入其他该关键字未定义参数，例如proxy、verify等等。
我们举个例子，来看看expected_status与响应码不一致时的情况。以第一节样例稍作改动：
图片
图2
expected_status与响应码不一致样例
在图2例种，请求真实响应码为200，但我们预期为500，结果失败报错，返回提示信息即为设置的“状态码输入错误”。
Delete和Delete On Session
默认参数与Get关键字一致，不再赘述。
Head和Head On Session
默认参数与Get关键字一致，不再赘述。
Patch和Patch On Session
url
与Get中所述一致。
data
可以时键值对字典、元组列表、字节或文件类数据，将被作为urlencoded类型数据或二进制数据发送。
json
如果你想要传入的数据为json格式，则可以使用这个参数。
**expected_status，msg， kwargs
同Get中所述一致。
Post和Post On Session
同Patch参数一致，不再赘述。
Put和Put On Session
同Patch参数一致，不再赘述。
还是来举个例子吧~在http://www.51testing.com/batch.search.php地址中传入body=’刘晓佳’进行查询。
图3
post请求样例1，数据非json编码
再举一个例子，加入存在url为http://xxxx/xxx/xx，接受Post请求，数据需要json编码，则可以使用Post的json参数传入，例举如下：
图片
图4
post请求样例2，数据为json编码
更新会话关键字
图片
更新指定会话alias的headers和cookies。
关闭会话关键字
图片
删除所有存在的会话链接，若请求结束后不删除会话则会占用链接资源，对比大并发测试而言，使用完成的链接不及时清理则可能引起后续会话建链失败。
断言关键字
图片
图片
Session Exists
判断名为alias的会话是否存在，若如存在则失败报错。
图片
Status Should Be
判断响应码是否与expected_status一致，如图1中样例所示，若response不传入则默认对比最后一次请求的响应码。
若传入response，则与对应的response响应码对比。
小结
虽然RequestsLibrary大家都在用，熟悉程度非常高。但新版发布后有的细节还是和原来有点差别，也许也有人和我一样对于一些不常用的关键字如Create Digest Session不是很了解，那么希望这篇文章能为你扫清迷惑。
