導語

UTP自動化測試平臺是TMQ的一個聯合專案，目的是方便各專案測試人員更好地開展自動化測試建設工作，減少重複平臺建設的成本，提高產品的自動化測試效率。

背景

測試用例，是測試的基礎原料，沒有用例，測試工作無法執行，自動化測試也是一樣。實際的自動化測試開發工作，絕大多數時候都是在進行用例的編寫/除錯。

隨著自動化測試工作的深入，測試用例的數量和型別也大幅度上升。不論從業務的角度，還是技術的角度，我們都需要有一套用例管理系統能夠把自動化用例管理起來，以提升自動化執行的效率。

技術

對於自動化用例, 用例系統需要實現下面3個技術點：

用例的解析：把自動化測試用例轉換為結構化的資料, 才能進行儲存和管理；

用例的展示：讓測試人員可以方便的進行用例管理；

用例的輸出：讓執行系統能夠把用例執行起來。

1 用例的解析

大家有各種各樣的測試用例，有Java的，有Python的，還有Excel等。 並且每個組都有自己的規範和習慣。用例系統不可能去一一適配每個組的規範，那樣的工作量是無法接受的。所以，在考察了各個組現有的用例和規範後，用例系統規定了一套公共的規範。只要用例實現了這套規範，就能被用例系統管理起來。

對於Java語言，用例系統規定了註解規範，如下:

對於Python的用例，用例系統規定了註釋規範，如下：

用例解析時候，形成結構化的資料，用例系統需要把資料儲存到資料庫中。但是，用例是儲存在SVN中，而UTP系統是執行在IDC的伺服器上，IDC的伺服器是無法和SVN互通的。所以，我們需要找一臺能夠訪問SVN，也同時能夠訪問IDC的機器，幫助我們做資料轉發。

圖：節點網路結構

最終，我們將用例解析的程式部署在轉發機上,解析程式定時拉取SVN最新程式碼，如果程式碼有更新，則解析用例程式碼生成結構化資料，然後將資料以json的格式，通過HTTP傳遞到UTP伺服器上。

圖：指令碼程式碼解析流程

2 用例的展示

伺服器收到解析器傳遞過來的用例資料結構以後，將資料儲存在資料庫中，同時將用例檔案儲存在硬盤裡。

資料儲存，是為了向用戶進行展示並使用。平時，用例是在IDE中開發的，使用/除錯的時候，也有可能是在IDE中執行。在IDE中，檔案是以樹狀結構進行展示的，所以考慮到習慣，用例系統仍然以樹狀結構來展示用例。

但是，用例系統和IDE展示，還是會有一些不同。IDE預設是按照檔案為單位進行展示，而用例系統是為了管理“用例”所以會以“用例”為單位進行展示。 一個檔案可能包含多個用例，在這種情況下，對於同一個用例工程,用例系統和IDE展示的結構就會不一樣。

最終，考慮到實際的專案結構，用例系統展示的樹狀結構如下：

圖：用例展示樹狀結構

3 用例的輸出

用例的最終目的是為了進行執行，當用戶選擇了用例以後，用例系統需要將使用者所選擇的用例引數及檔案傳遞出去，讓執行系統可以執行起來。

為了提高執行效率，UTP提供了併發執行的能力。為了滿足併發，用例系統需要將使用者所選擇的用例進行拆分。比如，使用者選擇了10個用例，在5臺機器上進行執行。那麼用例系統需要將10個用例拆分成5份，每份2個用例，然後傳遞到執行系統中。

但是，並不是所有的用例都可以併發，比如用例B的執行，依賴於用例A的輸出結果。這個時候如果將用例A和B拆分到不同的執行機器，會造成用例B無法執行。

同時，一些公共的用例，比如環境準備，檔案清理等，也是不能併發的，它們併發沒有意義。到底一個用例能否併發，用例系統是不知道的，只有指令碼開發人員知道。所以，用例系統提供了一系列註解，用於標示用例的併發屬性。

@SetUp : 標示此用例是前置條件, 併發時必須先執行此用例；

@TearDown: 標示此用例是後置條件, 併發執行完時必須執行此用例；

@Independent: 標示此用例沒有前後依賴關係(SetUp,TearDown除外), 可以被獨立併發執行。

用例被標示以後，用例系統就可以把使用者所選擇的用例進行拆分，目前執行平均拆分原則，也就是儘可能保持每組用例的個數儘可能一致。

具體演算法流程如圖所示：

圖：用例併發拆分流程

舉例，使用者選擇了下面8個測試用例：

TC_Setup1，TC_Setup2，TC_TestCase1，TC_TestCase2，TC_TestCase3，TC_TestCase4，TC_TearDown1，TC_TearDown2。
其中，4個testcase均標記@Independent

圖：用例拆分例子

總結

UTP用例系統到此的流程已經介紹完畢，最後給大家展示一下用例系統的整體架構圖。

圖：用例系統整體架構

掃描下方二維碼，關注微信公眾號：騰訊移動品質中心TMQ，獲取更多測試乾貨！