1. 程式人生 > >乾貨 | 帶有業務邏輯的比對思想在介面測試中的應用

乾貨 | 帶有業務邏輯的比對思想在介面測試中的應用

乾貨 | 帶有業務邏輯的比對思想在介面測試中的應用

原創: 虞斌 攜程技術中心 8月1日

前言

 

在網際網路企業中,開發專案的快速迭代是必不可少的。這就導致了大多數情況下,很多測試人員的迴歸測試速度遠遠跟不上專案開發的迭代速度。

傳統的介面自動化測試是測試人員事先編寫好測試用例,寫好相應的驗證點,然後通過手動執行或者Jenkins自動執行用例,來達到介面迴歸測試的目的。

但是對於一些結構複雜度高、內容大的報文(如機票引擎的報文)來說,通過手動編寫測試用例來做迴歸測試的成本很高,而且很難做到全面覆蓋。

所以我們致力於尋找一種解決方案,使其能夠低成本、高效率地解決上述問題,介面通用比對工具隨之應運而生。

一、傳統的比對思想

大家都會說,報文比對麼,直接用beyondcompare等第三方的工具,把需要比對的文字貼上進去,直接就能出結果了。確實,這麼做也是比對的一種方法,但是這個只適用於結構比較簡單的介面。

在實際的專案中,有一些介面的結構被設計的非常複雜,且自身結構還帶有複雜的業務屬性。這種情況下,傳統的比對思想就變得不那麼適用了。

二、什麼是帶有業務邏輯的比對思想

比對邏輯的本身其實很簡單,就是同一層節點的“一對一”對應,然後分別進行比對,但是如何能找到這“一對一”的對應呢?

首先,我們可以把介面報文的節點分三種情況:

a)節點是葉子節點。(即:節點值的型別是string、int、float等基本型別,已經無法再遍歷進去的節點)這種情況最簡單,只需要通過節點name就可以找到對應關係。

b)節點是一個自定義的型別。這種情況需要對自定義型別的每個屬性進行遍歷,然後通過屬性名找到“一對一”的對應關係。

c)節點是一個數組集合。這種情況下的對應關係是最難確定的。因為集合中的元素通常並不是有序的,所以集合裡面元素的對應關係就不能簡單暴力地通過index的方式來確定了,所以我們需要另尋解決方案。

為了解決陣列集合中“一對一”對應關係的確定,我們提出了一個業務邏輯key的概念。業務邏輯key是指在陣列集合中某個元素的一個或者多個屬性值的組合,並且在這個陣列中可以唯一確定這個元素。

舉一個機票的例子:在一個航班資訊的無序陣列中,航班號(flightNo)和日期能夠唯一確定一個元素,那麼flightNo和date的組合就是這個集合的業務邏輯key。

通過業務邏輯key,我們能夠以更貼近業務的方式來確定集合中元素的對應關係。也能夠很好地解決集合的亂序問題。以達到帶有業務邏輯的比對思想的目的。

三、對於關聯結構的比對思想

 

機票的一些核心報文體量是非常大的。為了能夠進一步壓縮報文,我們設計了一種我稱之為Agg結構的報文結構。即把同一類可能會被重複使用的節點抽出放到另外的節點陣列中進行統一管理並編號,在原來使用的地方引用該編號作為關聯關係。

舉個例子:在查詢國際航班的時候,大多數情況下返回的是航班組合。這種情況下,同一個航班可能會有不同的組合而出現很多次,如果每出現一次就把該航班的所有資訊都放進報文裡,那麼報文中就會出現很多重複冗餘的航班節點,這大大增加了報文的體積。

而Agg結構的出現,則把所有航班節點都放在FlightList的節點中去重複,然後按順序編號,原則上每個航班號只會在陣列中出現一次。而在航班組合節點中只輸出航班號對應的編號的組合,有點類似於關係型資料庫。這麼做的好處就是大大減小了報文的體積。

但是對於我們測試或者比對邏輯來說,這卻是一個巨大的新的挑戰:

a)如何處理編號。編號是在抽出重複節點過程中,為了能夠唯一確定某個節點而順序給的唯一編碼,它本身並沒有並不具備任何業務意義,且在重複請求中,同一個節點的編號可能會不同。所以,在比對過程中,我們不能簡單的將它們直接進行值的比較,那樣沒有任何意義。

b)為了解決這一問題,我們引入了reference的概念。即在介面業務邏輯配置的時候,通過編號設定節點之間的關聯關係,在比對之前通過該關聯關係先計算出所有關聯節點的業務邏輯key,這樣,在之後的比對過程中,通過已經計算出的業務邏輯key準確的找到需要比對的關聯節點。再通過通用比對邏輯,遞迴遍歷所有節點。

基於以上,我們設計開發了一個針對複雜報文介面的通用比對工具。該工具的特點是比對邏輯通用,業務邏輯可配置。通過這種方式,可以有效地降低後續的維護成本。

四、功能介紹

1、介面管理

a)介面資訊配置——獲得介面的請求、響應報文契約結構。

b)測試用例模板管理——該功能可以將測試用例繫結到介面上,方便測試套件新增測試用例。

c)響應報文業務邏輯key配置——可以為每個陣列節點新增業務邏輯key,不設定預設按順序進行比較。

d)響應報文Reference配置——適用於Agg報文的結構。用於巢狀計算業務邏輯key。

2、測試套件管理

a)基礎配置——每個測試套件對應一個介面,裡面可以有若干個測試用例,測試用例可以從介面模板克隆而來,也可以另外建立。

b)例外節點排除——可以排除一些不需要參與比對的節點,如時間戳等。

c)用例執行——併發的執行套件中所有的測試用例。

d)結果展示——展示比對結果,測試人員只需關注並分析執行錯誤的測試用例即可。

3.   比對流程

 

特點:

a)業務邏輯配置——可以理解為把介面的業務屬性翻譯成一條一條的規則,錄入系統,然後讓系統能夠理解報文的結構。

b)比對邏輯通用——針對任意一種報文結構,比對的邏輯是不會變的,即找到一對一的對應關係後,逐一比較對應節點的屬性,直到最後的葉子節點。

c)降低複雜介面的測試門檻——所有介面的邏輯關係只需要在新建的時候配置一次,通常會由最熟悉該介面的開發人員來配置。然後使用方只需要執行用例,然後分析用例中不同點是否符合預期即可。這樣的話,即使是新接手的開發或者不太熟悉介面結構的測試人員也能夠很快上手並完成一輪介面的迴歸測試。

結束語

以上是我對複雜報文比對的一些理解,在這裡和大家分享,希望文章能對大家有所啟發,歡迎大家在學習的過程中一起交流討論。

作者簡介虞斌,攜程機票BU資深測試開發工程師,主要負責攜程機票測試工具以及基礎元件的研發。對自動化測試領域有較深刻的認識,對新技術有著濃厚的興趣。