基於Python接口自動化測試框架+數據與代碼分離實戰(優化篇)

　　引言

　　以前分享過一篇關於使用unittest框架作接口自動化測試的文章——基於Python接口自動化測試框架+數據與代碼分離(進階篇)，該篇文章主要講設計思路與簡單實踐的過程。可是，小編力求實戰，恰巧遇到項目所需。俗話：光說不練假把式，不少人寫博客，弄幾個小示例後，就感受本身學會了一套框架，甚至以爲本身是測開了。其實否則，實踐使用過程，你會發現不少問題，特別是公司的花式接口和複雜業務邏輯的，你會發現往日搭建的框架不少殘缺，沒法徹底應用全部場景。這個時候，你須要去在實踐中不斷優化與完善，這也是很是可貴的，必須這個過程你在不斷探索與學習，進而提高本身的能力。

 

　　Unittest跳過測試

　　 在版本初期，絕大多數項目接口開發完成後，測試就能夠作接口測試了。而項目後期，維護好的接口測試用例及腳本能夠用於迴歸測試，以便騰出時間用於手工測試及測試用例測試場景的設計。鑑於以前設計模式DDT，都是全量執行測試用例，若是想執行一部分測試用例的話，怎麼辦？基於unittest框架的跳過測試使用方法：

通常狀況下，unittest 會自動測試每個測試用例（以test_開頭的方法），可是若是想臨時跳過某一個測試用例，有兩種實現方法：

方法一：使用 skipXxx 裝飾器來跳過測試用例，unittest 一共提供了 3 個裝飾器：
@unittest.skip(reason) ----- 表明無條件跳過；
@unittest.skiplf(condition, reason) ----- 表明當 condition 爲 True 時跳過；
@unittest.skipUnless(condition, reason) ------ 表明當 condition 爲 False 時跳過。
方法二：使用 TestCase 的 skipTest() 方法來跳過測試用例　　

案例演示：

import unittest


class TestHello(unittest.TestCase):
    # 測試 say_hello() 函數
    def test_001(self):
        self.assertEqual(1+2,3)
        print("test_001:執行了")


    # 測試 add() 函數
    @unittest.skip('臨時跳過 test_002')
    def test_002(self):
        self.assertEqual((3+4), 7)
        self.assertEqual((0+4), 4)
        self.assertEqual((-3+0), -3)
        print("test_002:執行了")

    def test_003(self):
        self.skipTest("臨時跳過 test_003")
        print("test_003:執行了")

if __name__ == '__main__':
    unittest.main()

 

結果以下：

 

 

 

　　DDT跳過測試

　　上面是unittest的跳過測試，而ddt自己使用的也是unittest框架，也是能夠用這種方式來實現。可是，我這裏不介紹了。我使用另外一種方法。咱們的測試數據都存於excel文件中，前面實現了讀取和寫入操做，既然這樣，能夠設置一個開關，用來讀取咱們想要執行的測試用例。

實例：

　　咱們在數據驅動模板中增長一個字段：run，用於控制用例執行。

 

 

　　而後在咱們核心運行程序中，加邏輯判斷：

 

 

 

　　測試結果與日誌優化

　　咱們將結果統計出來，便於咱們調式的時候，能夠追蹤到哪些成功和失敗，而且失敗緣由是什麼。

 

 

 　　運行結果：

 

 

 　　打印日誌：

 

 

 　　在看看全部用例是否執行了？

 

　　總共維護了134-1，而後全部用例執行開關是打開的，因此運行日誌顯示總數是133，執行了133，成功132，失敗1個。因爲詳細日誌數據涉及到保密協議，我這裏不便貼圖，請諒解。

　　動態圖：

 

 

　　測試報告

 

 

 

 

報告和打印的測試結果數據都是一致的，證實是沒問題。

 

　　疑難問題處理

　　上面基本上是顯示上優化的，那麼對於一些接口，你封裝好的是result['message']這種字段，可是你測試的接口，並非全部接口返回的json字符串裏面有message字段，若是公司每一個開發都有本身的風格，沒有統一的話，那這樣就是給測試帶來必定的困擾，好比我遇到的接口，返回的是result['msg']，而有些的是result['message']。而你寫好的斷言方式是 assertEqual，而且是使用其中一個，可是大量接口，有些沒有這個字段，你這樣寫，定會報錯。因此你的改代碼邏輯。最簡單的方式，直接使用條件判斷，分流處理：

接口一的返回數據：

 

 接口二的返回數據：

 

 

 

 　　再舉個例子，好比咱們寫好的代碼獲取的是接口序列化數據——json字符串，可是有些接口返回的並非json格式，有多是其餘格式，甚至在實際項目中，我遇到的接口，返回的數據就是一個動態值或常量值。這個時候你取數據的方式是:res.json()。必然是報錯的。並且對於變量值，你沒法斷言，由於預期結果你都不知道是什麼，它是變化的。可是也不是沒有規律的，至於規律，也就是生成的邏輯，這個須要與開發溝通後，你知道了，而後再去寫這邏輯，最後去斷言。單單這種接口，作起來就沒有那麼簡單了。因此平時作接口測試，多思考。

 

　　總結

　　以上是自動化測試框架用於實際項目中的問題，這些問題可能你從未曾遇到過，也可能遇到過但從未曾思考過，固然，若是你有更好的方式處理這些問題，能夠加入測試開發交流QQ羣來溝通與學習：696400122。本羣以學習交流爲主，全部乾貨以實際項目中實戰案例爲背景，深刻學習與分享。