但是,我还是想说说RequestsLibrary

发表于:2021-11-16 09:08

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:刘晓佳Rachel    来源:51Testing软件测试网原创

  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不是很了解,那么希望这篇文章能为你扫清迷惑。

  版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号