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