@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的具体用法：
