銀行測試探索丨信貸長鏈路業務測試資料快速構造方法，瞭解一下

一、引言

隨著銀行數字化轉型的不斷深入，對信貸領域的測試工作提出了更高的標準和要求，如何在高效完成測試任務的同時確保測試質量就成了一個亟待解決的難題。有實踐研究表明，在具體測試過程中往往大量的時間精力都是耗費在測試資料準備工作上面，能否儘量減少這部分耗費，將更多的時間精力專注於業務邏輯等方面更好地去提升測試質量？本文基於此進行了探索，提出了一種長鏈路業務測試資料快速構造方法，並將該方法應用於信貸領域多個場景，取得了良好成效。

二、背景與挑戰

當前信貸領域長鏈路業務測試主要有三方面特點：一是業務鏈路長，隨著信貸業務不斷迭代，業務場景一般涉及多個業務模組，整體業務流程長；二是信貸業務複雜度高，業務形態的不同會有不同的觸發方式，業務邏輯的不同也會產生不同的組合方式；三是信貸業務依賴性強，業務前後環節間的依賴性強，後一環節的輸入是前一環節的輸出。

一般來講，測試資料準備有“造”數和“找”數兩種方式。“造”數主要是透過某種方式模擬實際業務的執行邏輯生成測試資料，一種方法是透過GUI構造測試資料，這是最常見、最可靠的方式，直接透過客戶端或介面完成資料構造，缺點是成本高、效率低；另一種方法是透過資料庫構造資料，缺點是直接修改資料庫容易產生髒資料，全量匯入資料有評估和操作成本。“找”數是透過某種方式去查詢已經存在的測試資料，一種方法是透過資料庫去查詢可用資料，缺點是資料共用導致資料屬性頻繁變化，會相互影響；另一種方法是透過找專案組或者是相關係統的對應開發人員配合提供，缺點是需要熟悉各自模組，溝通成本高。這兩種方式無疑都能夠滿足基本測試資料準備需要，但往往都伴隨著“造”數難和“找”數難的問題，而對於信貸業務來說，其長鏈路的特點使得“造”數更難和“找”數更難，如何快速構造測試資料就成為了影響測試進度及質效的關鍵。

三、方法探索

在對當前信貸長鏈路業務測試資料準備過程中的相關現狀進行分析梳理並總結歸納後，我們發現主要有以下特點：

信貸長鏈路資料準備一般涉及範圍廣，完成一次流程往往要跨多個系統或者是模組，對上下游系統間的合作需要高度的默契；

資料準備需要熟悉業務流程、熟悉業務介面和實現邏輯，對資料準備人員較高要求；

大部分情況下資料構造流程伴隨著業務狀態的變化，資料狀態是不可逆的，只能按需不斷構造新的資料；

鏈路越長整體成本越高；

資料間依賴性強，往往需要做資料的串聯，例如下一個請求的入參需要上一個請求的返回值；

找誰造數、造什麼樣的數，時間往往都消耗在溝通上。

基於以上痛點和難點，並結合對測試資料實際準備過程中相關問題的探索和研究形成了長鏈路業務測試資料快速構造方法論，主要包括場景梳理、功能編排、資料構造、結果反饋以及維護保鮮等幾部分，總體流程如下圖所示：

1、場景梳理

場景梳理主要是指在熟悉長鏈路業務流程、介面和實現邏輯的基礎上，按照待造數長鏈路業務場景流程梳理出涉及到哪些模組、功能、對應介面以及實現邏輯，大致如下圖所示：

場景梳理的方法總結起來有三種：一是與對應開發人員溝通確認；二是將整個場景涉及到功能、介面等資訊記錄下來再進行篩選，例如Jmeter錄製、抓包等；三是透過F12從前臺介面逐一分析每個功能涉及到的介面相關資訊。在實際操作過程中，一般需要結合三種方法使用會起到較好的作用。

2、功能編排

功能編排是將無序的功能編排成有序的場景，主要採用了JSONPath技術來進行處理。其優點是：語法靈活簡單、使用簡便、無需一層一層往下找，特別是對於比較複雜的JSON結構資料效果更加明顯，在各種主流的程式語言中均有對應的庫支援。其語法大致介紹如下：

簡單來講，功能編排的核心主要是透過JSONpath語法完成引數動態替換，如下圖所示：

3、資料構造及結果反饋

資料構造主要包括明確輸入、輸出格式等資訊，並按照完成組合好的場景完成資料構造，而結果反饋是將構造完成的資料按照格式反饋給使用者。

4、維護保鮮機制

維護保鮮機制是為了解決在建立長鏈路業務資料構造流程後，中間由於某些原因導致長鏈路場景發生了變化（例如功能和介面有改變）而資料構造失效不可用，在透過維護保鮮後能夠及時響應變化，以確保資料構造能夠隨時可用。在檢查反饋資料結果是否符合預期後，如不符合則進入維護保鮮環節及時進行處置，待處置成功後繼續迴圈構造流程。處置措施一般包括以下三方面：

1.若判斷是場景發生變化，需重新評估；

2.若判斷是場景中功能發生變化，需定位到具體功能，重新梳理更新場景；

3.其他問題：例如環境不可用等，需進一步排查解決。

……

由於作者版權要求，僅展示文章的一部分