接口測試自動化生成框架(2)

　　那么針對所有的接口測試用例寫接口測試代碼，可以看到的是，我們的接口測試代碼主要是入參的不同，校驗結果的不同，其他區域的測試代碼都是一樣的。我們要做的是不斷的copy前一個測試用例代碼，然后修改某個參數、修改某個驗證點就搞定了。

　　接口測試自動化生成框架

　　對于這些比較重復的測試代碼編寫工作，大家肯定想到是否可以自動生成這些腳本，還會想到自動生成的腳本是否可以和測試數據一起自動運行測試代碼呢。這里可沒想象那么簡單，需要考慮業務邏輯、接口環境、測試數據、接口測試框架等一系列的組合。

　　我們來簡單點吧，我們的目的，在一定的測試范圍內，充分利用工具來自動化生成測試用例，保證測試用例的覆蓋率。 兩種程度的復用該測試套件，一種是測試用例的生成和復用，一種是測試代碼的生成和復用。 請看下面的自動化生成框架的架構圖：

　　模板引擎架構圖如下：

　　相關術語解釋：

　　1.All Pairs：利用參數來定制化生成測試用例的工具，入口是Excel準備的參數文件;出口是txt文件的測試用例。這個工具是開源的，可以自己定制化開發

　　2.業務API庫：由于需要生成測試代碼，需要知道業務邏輯所涉及到的接口和類，比如IC中的發布寶貝的發布接口。

　　3.模板：根據業務邏輯規則制定的邏輯描述，可以利用因果圖分析法中的“或 與 非”來描述接口業務功能邏輯(需要抽象出相應的關鍵因子，也就是部分的接口入參)

　　4.測試用例分析器：將txt文件格式的測試用例進行分析，分析每個用例的參數和參數值和業務邏輯。

　　5.測試數據分析器：將xml文件格式的測試數據進行分析，與生成的每個測試用例代碼進行組合和處理，生成帶數據的測試代碼。

　　那么接下來我們需要做什么呢。迭代去開發我們需要的組件就行，第一步考慮自動生成接口測試框架代碼，定制化的選擇接口來自動生成框架代碼(包括集成了現成的接口測試框架);接下來考慮如何讓我們的用戶(測試人員)來輸入我們的測試數據，并考慮與框架代碼生成進行集成融合;另外一塊就是測試環境的API的調用了，如何能自動運行自動生成的測試代碼并反饋結果給測試人員等一系列的問題需要進一步深入挖掘。

　　這里還需要說明的是，我們不期望這個框架能解決所有接口功能接口測試代碼的自動生成(有些接口實現業務邏輯較復雜)，我們能解決掉一部分重復工作(某個接口的60%的測試代碼)，且能告訴大家我們可以做一些事情更智能化和簡單化。

原文轉自：http://www.uml.org.cn/Test/201303123.asp