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版本的功能，并更进一步优化。主要改变在以下方面：

　　1)新的关键字结构：?所有请求关键字都已被重写，并在不久的将来允许在没有会话的情况下请求关键字。旧关键字* Request现已弃用，并将在 1.0.0 版本中删除。例如Get Request已经弃用，在0.8版本中用GET On Session替代；而在0.9版本中可以只用GET?不需要一个会话时。

　　2)状态码上的隐式断言：?* 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.创建会话关键字

表1 创建会话关键字

　　RequestsLibrary提供了5个创建会话的关键字，乍一看也许你和此刻的我一样二脸懵逼，实在不太搞得清楚他们之间的区别。其实，他们之间没有太大的区别……，仅有的小区别就存在于传入的参数有略微不同，如上表1所示，已经用红色字体给大家标注出不同关键字之间参数差异。

　　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类型的请求。

　　2）Create Custom Session

　　其他相同参数不再赘述，单独说说不一样的参数auth。

　　auth：要传递到请求库的自定义身份验证对象。例如：有一个web服务，该服务只在headers中X-Pizza设置为密码值时才会响应，则可以定义一个方法为PizzaAuth，传参为headers的X-Pizza值。然后使用Create Custom Session关键字，设auth=PizzaAuth(‘xxxx’)即可。

　　3）Create Digest Session

　　其他相同参数不再赘述，单独说说不一样的参数auth。

　　auth：['DOMAIN', 'username', 'password'] 用于 DIGEST （一种验证方式）身份验证。

　　4）Create Ntlm Session

　　其他相同参数不再赘述，单独说说不一样的参数auth。

　　auth：['DOMAIN', 'username', 'password'] 用于 NTLM （一种验证方式）身份验证。

　　5）Create Session

　　auth：HTTP 基本身份验证的用户名和密码列表。

　　2.http请求关键字

表2 http请求关键字

　　1）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，结果失败报错，返回提示信息即为设置的“状态码输入错误”。

　　2）Delete和Delete On Session

　　默认参数与Get关键字一致，不再赘述。

　　3）Head和Head On Session

　　默认参数与Get关键字一致，不再赘述。

　　4）Patch和Patch On Session

　　url：与Get中所述一致；

　　data：可以时键值对字典、元组列表、字节或文件类数据。将被作为urlencoded类型数据或二进制数据发送；

　　json：如果你想要传入的数据为json格式，则可以使用这个参数；

　　expected_status，msg， **kwargs：同Get中所述一致。

　　5）Post和Post On Session

　　同Patch参数一致，不再赘述。

　　6）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编码

　　3.更新会话关键字

　　更新指定会话alias的headers和cookies。

　　4.关闭会话关键字

　　删除所有存在的会话链接，若请求结束后不删除会话则会占用链接资源，对比大并发测试而言，使用完成的链接不及时清理则可能引起后续会话建链失败。

　　5.断言关键字

　　1)Session Exists

　　判断名为alias的会话是否存在，若如存在则失败报错；

　　2)Status Should Be

　　判断响应码是否与expected_status一致，如图1中样例所示，若response不传入则默认对比最后一次请求的响应码；若传入response，则与对应的response响应码对比。

　　三、还是来个小结吧

　　虽然RequestsLibrary大家都在用，熟悉程度非常高。但新版发布后有的细节还是和原来有点差别，也许也有人和我一样对于一些不常用的关键字如Create Digest Session不是很了解，那么希望这篇文章能为你扫清迷惑。

作者：刘晓佳Rachel   

来源：http://www.51testing.com/html/49/n-4479949.html