0 引言

跨系統的業務場景是指業務需要在2個或者
2個以上系統/平臺進行操作或者數據流轉。聯調測試是針對跨系統的業務場景（即系統間外部接口）進行業務流和數據流的測試,不含系統自身的單元測試、內部集成測試和交付測試（含功能、性能和安全測試）。聯調測試可分為聯調功能測試、聯調非功能測試（含性能和安全測試）。測試內容主要包括：①依據系統需求規格說明書、詳細設計文檔及SOA相關標準,檢查接口是否遵循設計要求、安全規范;②通過自動化工具及人工驗證的測試方法,驗證系統間接口的規范性、數據匹配性、連通性及性能效率、接口系統配置合規性、應用及數據的安全性等,并驗證其抵御惡意攻擊的能力,以達到減少系統試運行調試成本的目的^[1]。

當前,在電力企業大型管理信息系統工程建設中,尚缺乏針對跨系統缺陷定位和調試技術的專門研究,聯調測試基本上依靠的是測試人員的個人經驗和能力,導致了缺陷無法定位、缺陷定位不準確、調試效率低下等問題,無法滿足大規模信息系統工程建設測試的需要。因此,亟需建立一套完整的工作方法和流程,輔以相關的軟件工具,以指導聯調測試工作。

本文基于廣東電網大型管理信息系統建設工程中聯調測試的工作實踐,提出了一整套的跨系統缺陷定位和調試的方法,歸納和定義了常見錯誤類型,規范了測試工作流程,并對具體調試工作所需工具給出了建議。

 1 跨系統缺陷定位和調試的工作流程

跨系統缺陷定位的工作流程包括5個階段,分別是入口、調試準備、調試中、缺陷驗證以及調試總結,各個階段又包含各自的子過程。

1）入口：缺陷單描述缺陷的完整信息,能幫助調試人員復現缺陷。

2）調試準備：包括技術文檔收集、測試環境準備、調試工具安裝部署、報文或場景數據準備等子過程,交付物可以是測試用例（包含測試數據）。

3）調試中：包含復現問題、收集過程記錄（日志、報文、數據庫、界面提示等）、假設原因、驗證假設、波及分析等子過程,交付物是問題指向主體說明文檔。

4）缺陷驗證：包含缺陷驗證、回歸測試等子構成,交付物是缺陷分析和修復報告。

5）調試總結：缺陷分析和修復報告。

 2 跨系統缺陷類型的定義

根據缺陷發生時的特征,將跨系統的缺陷劃分為7個大類、20個小類。

2.1 環境配置問題

環境配置問題主要涉及到網絡、中間件、數據庫、服務器、客戶端、操作系統,這6類設備的問題可能導致接口無法聯通,或者接口性能無法滿足要求。

2.2 應用配置問題

應用配置問題主要有權限賬號配置、流程配置以及接口配置這3類問題。

2.3 接口連通性問題

接口連通性問題主要有兩方連通性、三方連通性、多方連通性問題。

2.4 接口規范性問題

接口規范性測試主要對請求/響應報文的格式、內容是否符合SOA應用技術規范和設計要求進行驗證,不符合接口規范性的問題,通常歸類為接口規范性問題。具體有以下幾類：服務命名問題、服務報文設計問題、服務實現問題、服務異常處理問題、大數據量處理問題以及其他相關約束問題。

2.5 接口一致性問題

接口一致性問題定位在應用系統服務的開發和實現是否嚴格遵守系統設計的規范和要求進行,包括應用系統的服務實現在命名、接口、功能、性能以及異常處理等方面與具體規格的設計描述保持
一致。

2.6 數據問題

各系統間數據交換時需要將基礎數據做好映射,即各系統間的基礎數據信息存在并保持一致。在數據交換時存在數據映射問題引起缺陷,此類問題定位數據映射問題;如在接口連通性測試時,SOA的響應報文返回的異常信息顯示“接口數據映射找不到”,此時的問題主體可能為接口數據映射。

2.7 業務邏輯問題

在實施接口功能性測試時,需要制定業務測試場景并且確保業務場景符合聯調實際測試需求,如果測試操作不符合操作手冊和應用集成設計說明書,將會導致測試失敗,接口不能成功調用或者不能查到接口響應消息,此缺陷則定義為業務邏輯問題。

 3 跨系統缺陷調試的方法和工具

3.1 跨系統缺陷調試的過程

跨系統缺陷調試的過程如圖1所示。

圖1 跨系統缺陷調試的過程Fig.1 Cross system defect debugging process

1）問題重現。當收到一個問題的報告時,應首先在測試環境進行程序的運行,觀察在當前環境下是否可以重現問題,以確認這個問題是一個偶發性現象還是一個真正的缺陷。經此步驟可以排除掉網絡端口不通等偶發性問題,使調試人員可以集中精力關注真正的缺陷。

2）信息收集。聯調環境包括多個應用平臺,牽涉到多個應用的時候,需要調試人員對系統架構了然于胸,清楚每一個應用在整個系統交換中的輸入、輸出、處理過程,以及每一個不同的模塊具體負責的功能。根據復現步驟,通過調試工具,收集并分析缺陷信息,包括問題表象、操作步驟、實際輸出的結果以及預期輸出的結果。除此之外,調試人員也需要收集其他相關專業的信息,如日志/報文信息、數據庫數據信息、界面顯示信息等。

3）提出假設。調試和測試的區別是,調試不僅要測試以發現缺陷,而且還要找出問題原因和問題解決方案。經驗豐富的調試人員可以根據已有的數據資料,大膽提出假設,如果假設有效則可以大大縮短調試所需時間。如果環境涉及多個平臺或有多個應用主體,可能需要多次嘗試才能形成有效的
假設。

4）驗證假設。在測試工具的輔助下,對相關應用運行并察看所涉及的日志、報文、數據庫數據、界面數據的變化,以驗證對于問題的假設是否正確。很多情況下,這個假設和數據流相關,按照數據流方向,對每個主體做正確性判定,找到問題指向主體。

5）對缺陷解決方案做相關性分析。一般而言,開發人員在解決缺陷過程中,關注的是缺陷的一個點,而作為一個軟件產品,需要注意的是整個軟件的全面表現,因此需要對缺陷解決方案做相關性分析,保障回歸測試的充分性。

3.2 跨系統缺陷調試的方法

3.2.1 分解法

當在應用場景中測試問題時,需采用一系列的步驟來重現這個問題,分解法就是把一個要重現的問題分解成幾個最小的解決步驟,以更好定位缺陷。應用分解法可以實現以下目標：①每次只需要重新測試其中一個步驟,從而提高了測試的效率;②有效地隔離問題;③在測試過程的每一個步驟中只需要檢查系統中有限的一些癥狀,就能發現引起問題的原因,例如三方連通性缺陷,將問題分解為提供方-SOA間連通性和SOA-消費方間連通性。

3.2.2 追蹤法

在跨系統調試的過程中,追蹤事件的最精確的辦法是記錄并查看應用運行的報文/日志,通過查看報文/日志可以知道事件發生的時間、地點、操作步驟、環境因素和系統其他假設條件,同時記錄輸入、輸出以及處理過程。如果系統記錄的報文/日志己經有了正確的輸出,就不需要進行重新開發或者調試,同時這些正確的執行記錄也為快速執行回歸測試和問題重定義認證測試提供了有效參考。

數據追蹤法有幾種方式,最常見的是在應用內部嵌入相應的日志或者跟蹤信息,通過相應的記錄對其進行分析;還有一種是應用一些外部工具,截取傳輸報文,然后對相關的內容進行分析,例如SoapUI工具模擬接口報文數據,向SOA發送數據,SOA日志系統中記錄該報文信息及響應信息。

3.2.3 比較法

比較法是通過對比系統正常工作時的狀態和系統異常工作時的狀態,從而發現其中的差異,以便快速定位缺陷。常見的差異情況有：①假定測試數據對問題影響;②假設最近的修改使系統出錯,導致bug突然出現。如果是第一種情況,就需要參考正確的測試數據案例,通過比較法,找到正常數據;如果是第二種情況,則需要對版本進行比較,并進行針對性分析。

3.2.4 系統法

系統法就是從整個系統的功能方面來驗證缺陷,而不是只考慮相關的子系統功能或者單系統功能,只有這樣才能測試出接口的修改對整個系統的影響。系統法要求首先掌握系統的整體業務邏輯,以業務邏輯為基礎可以定位到引起問題的原因;其次了解系統的所有組成部分,理解不同的子系統或者單系統的接口。

在定位缺陷上使用系統法,必須追蹤每個模塊的輸入和輸出、系統運行的過程和接口調用模塊的結果。依據上述條件對系統進行過程測試,發現出現問題的部位,以便盡快以系統法解決問題。對于一個復雜的環境和系統,通常很難對系統的總體架構、各個子系統的各個業務模塊和子系統之間的接口有著充分的理解,所以在進行系統測試時需要把開發系統的相關人員和測試人員集合在一起共同定位缺陷,這也是應用系統法的一個必要條件^[3]。

3.3 跨系統缺陷調試的工具

1）SoapUI。SoapUI是一個開源測試工具,通過Soap/Http來檢查、調用、實現Web Service接口的功能/負載/規范性調試測試^[4]。

2）Eclipse。使用Eclipse模擬發送數據,通過查看busdown日志,來進行JMX接口的功能/規范性調試測試^[5]。

 4 聯調測試案例分析

圖2為某