@classmethod和 @setUpclass(cls) 接口测试token处理用法详解:

@classmethod和 @setUpclass(cls)接口测试 token处理用法详解:

  在我们的daily test中, 一定少不了接口鉴权, 那么大家都是怎么处理的呢? 比较常用的方式就是由开发提供万能token ---- >>绕过服务端的验证, 从而实现对不同接口的输入输出进行校验, 这种方式对普通接口的数据的输入输出校验是没有什么太大影响的,  但在我们的实际工作中,之所以加入鉴权就是希望给不同的人员提供不同的访问权限, 针对不同的访问权限服务端提供不同的响应数据 , 再或者说,我们就是希望验证一下鉴权接口的权限校验,和权限数据的响应是否正常, 那该怎么办呢?  我们用万能token的方式必然无法覆盖。

  这事我们可能会想,要是我们的能保存下账户的token, 并将token传入header中,然后向服务端发送携带token的请求, 而服务端在识别用户token后,给予前端对应权限的响应数据,这样我们即测试了接口间不同输入输出的响应情况, 又覆盖了接口的鉴权校验。

   那么问题又来了, 我们要怎么获取用户的token呢?  ------ >> 大家可能会想到登录时候就获取出用户的token,对,就是这样,我们在用户进行登录的时候就获取用户的token,可是我们只有在用户登录时来获取token, 那假如说我有一个支付类型的接口, 接口中又有很多的服务,每个服务间有很多不同的输入输出校验,好,那可能就这一个类型的接口case就可能有两三百条, 而每个请求都需要携带token访问,那怎么办? 难道我们每执行一个case前都让它先去登录,然后在获取用户token? 如下方式1:

 class UserTest(unittest.Testcase):  

      def  setUp(def):

        res  = rq.post(loginUrl,xxxxx)

        data = res.json()

        token = data["token"]

   def tearDown(self):

        pass

      def test_Xxxx(self):

        pass

     def test_Yxxxx(delf):

      pass

  很显然,采用这种方式我们每执行一个case,就会先去执行setUp中的login方法,否则我们就无法使用token, 那这样做有什么不好呢? 首先,在我们的daily test中,我们有没有遇到过每发一个请求就先跳登录页啊? 这肯定是没有的,不符合人们的日常使用习惯啊,且一般开发都会根据接口特性设置不同的token有效时长,也就是说在时长内token是不会变的。那为什么用户在登录一次以后就可以在一定时间内正常请求访问呢?因为用户登录成功时,服务端会返给前端了一个经过处理的鉴权码,这个加密串的加密和解密的方式呢都有服务端来处理,前端在获取到这个加密串时就把它保存下来然后不做任何处理,以后的每次请求中都原封不动的还给服务端,服务端收到前端的请求时会自己进行解密,  解密通过,就返给前端对应的响应数据, 解密不通过, 那么就有可能是个假token (加密的规则不对)或者失效token 就提示用户重新登录。所以我们的这种获取token的方式需要改进, 那怎么改进呢?  --- >> 利用@classmethod和 @setUpclass(cls) 结合 , 这什么意思啊  ------ >>  在整个测试类之前执行一次,以后再跑多少case都不在执行它修饰的方法, 用这个方法来限定用户只能登录一次, 登录后就直接作为变量保存token的值, 往后执行case时就将变量中保存的token传入henders即可。

  下面就来介绍一下具体用法: setUpclass(cls) 必须和@classmethod 同时使用,限定在整个测试类开始之前执行一次 , setUp() / tearDown() 每个用例开始前 / 结束后执行一次, 这个单元测试框架里的,不管你是unitest框架、nose框架还是pytest框架,这两个方法用法是一样,作用也是一样的,下面展示一个打印当前时间的case来展示 setUpclass(cls)和@classmethod的具体用法:

   

【推广】 免费学中医,健康全家人
原文地址:https://www.cnblogs.com/mixiu26/p/7838718.html