引言
之前分享過一篇關於使用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。本群以學習交流為主，所有干貨以實際項目中實戰案例為背景，深入學習與分享。