1、目前金融軟件及產品研發已經認識到測試的重要性，但許多先進的軟件測試方法、技術和標準還處于實踐 和探索階段。軟件測試的實施既要遵循國內外先進的測試理論，也必須根據實際情況量體裁衣，確定適合 于項目的軟件質量目標和測試策略。、項目簡介D 系統（如圖1 所示）建設的總體目標是資金交易管理信息化。用戶可以在統一數據平臺和交易平臺中實現流程自動化、業務處理規范化、交易管理網絡化、輔助決策管理智能化、操作風險控制實時化、報表生成自動化。D系統構建于J2EE平臺，采用分層B/S架構提供服務支持的設計思想，對每一層定義明確的功 能接口，同時在層次內實現組件化接口。二、測試總體計劃D 系統測試工作的首要任務是制

2、訂測試計劃。測試計劃編寫的主要依據是項目組織結構、D 系統需求規格說明書、D 系統開發計劃。通過分析項目組織結構，明確測試人員在項目中承擔的權利和義務，確立測試工作在整個項目開發中所承擔的責任，描述工作流程和溝通方式。需求規格說明書決定測試需求（功能測試、性能測試、安全性測試、容災性測試等）、測試范圍（測試項和測試項特征）、測試優先級等。開發計劃決定測試任務及工作量， 測試資源的投入時間。D 系統測試計劃還描述了測試方法、關鍵原則、通過準則、測試環境要求、缺陷分類級別、遺留問題處理、風險與應急等。根據D 系統測試計劃，將測試工作劃分為5 個階段，見表1 。在各階段測試任務實施過程前，收集和分析

3、上一階段的實施效果，通過建立PDC破進機制，及時對測試計劃進行細化和調整。三、測試策略和方法測試的主要困難是不知如何進行有效測試，也不知何時結束測試。D 系統總體測試策略是將系統劃分為3個業務層（前、中、后臺），按照每個業務層的特點設計測試方案。1. 前臺業務頁面測試D 系統前臺業務的特點是直接和用戶交互頁面展現層。用戶登錄系統，根據權限及角色不同，分別加載相 應的功能頁面；系統運行的結果通過查詢頁面和圖形報表等方式展現給用戶。前臺測試是功能測試的重點，貫穿測試工作的各階段。項目組在單元測試階段制訂 D 系統單元測試規范。規范中既包含頁面功能的驗證，又結合金融行業特點對頁面風格進行統一要求,

4、如數量單位、金額截位、默認值、提示信息、查詢樣式、報表格式等。執行單元測試時使用的最主要測試手段是代碼走查。D 系統前臺編碼基于較成熟的工作流中間件產品，開發平臺為程序員提供各類構件庫，同時提交相應的測試報告和使用說明。封裝后的構件解決了程序健壯性、系統安全性和效率等問題。代碼走查目的是檢查開發人員是否選擇了正確的構件且正確使用構件。前臺業務功能測試用例設計在參考D 系統需求規格說明書和D 系統數據字典的基礎上，遵循GUI 軟件功能測試標準，主要使用邊界值和等價類劃分的測試方法。用例設計原則是不僅要測試程序的正確性，還要測試程序的“魯棒性”（容忍不合法的輸入并檢測出來，避免給出不合理的結果）。

5、輸入數據的設計要求包括小于邊界值、等于邊界值、大于邊界值三種等價類。2. 中臺業務流程測試D 系統中臺業務的特點是風險控制和流程管理。用戶通過前臺頁面設置各類風險指標信息（信用、 限額等） ；前臺交易數據通過中臺業務工作流（授權、授信、審批等）傳到后臺。通過后臺風險分析算法，返回風險級別判斷結果，決定交易流轉方向和審批路徑，實現經風險調整的收益率最大化。中臺測試重點與難點是流程測試。測試任務執行始于集成測試階段。流程的靈活配置是D系統的一大特點, 給中臺測試帶來一定難度。流程測試用例的設計主要使用路徑覆蓋法。流程驗證：確認D 系統中手工配置業務流程圖是否與D 系統需求規格說明書一致，邏輯是否正

6、確。流程劃分：將系統流程劃分為基本流和備選流。基本流是經過用例的最簡單路徑，用直黑線表示。備選流自基本流開始，每個備選流會在某個特定條件下執行。備選流可能會重新加入基本流中（備選流1 和 2），還可能起源于另一個備選流或終止用例而不再重新加入某個流（備選流3 和 4）。場景設計：遍歷所有流程分支。例如基本流-> 備選流2-> 備選流3。一旦所有分支被選擇完畢，場景設計結束。設計用例：分析分支判斷條件，完成測試用例設計。例如測試用例TC004是為驗證當交易“結算金額 >賬戶余額”時，審批流程是否正確。執行測試：用戶、 角色和權限信息是分別在系統中靈活配置的，而流程中的環節參與和

7、用戶權限密切相關。在流程用例設計時只體現角色（權限的載體）；在用例執行時，參考D系統用戶角色信息表。3. 后臺業務深度測試D 系統后臺業務特點是金融算法分析的核心層，完成模擬試算、風險分析、賬務推導、日切批處理等功能。為實現系統兼容性和可擴展性，將復雜計算和金融分析功能進行組件封裝，集成于“金融底層”。底層對外（前、中臺）有Web Service 接口方式和對象接口方式。后臺測試重點是驗證計算精準性。測試任務執行始于集成測試階段。（ 1 ）測試界面后臺業務與用戶無直接交互，本著盡早測試的原則，項目組通過分析應用層對金融底層的調用需求，開發測試頁面，供測試人員進行用例輸入和輸出結果驗證。（ 2）

8、用例設計后臺測試用例設計主要采用模擬數據法和歷史數據分析法。前者是手工編制業務數據，通過第三方軟件匯總計算并生成報表，與D 系統金融底層組件的計算結果比對。后者是向數據庫批量導入歷史業務數據，生成結果和歷史賬務報表進行比對。根據金融業對數據精準性和可靠性的要求，在用例執行時加入“大數據量測試”場景設計。驗證后臺處理 大量業務數據時，批處理效率、容錯能力和事務處理機制等。（ 3）集成測試 前、中、后臺集成測試階段采用“先分再合”的方法，雖然增加了測試頁面開發的工作量，但既保證了測 試和開發工作的并行，又保證了應用層和金融底層測試工作的并行；同時提高測試的準確性，取得事半功 倍的效果。測試初期：測

9、試用例準備完畢，測試人員分兩組。前臺測試人員執行頁面級測試用例，驗證應用層基本功 能是否和需求一致，頁面風格是否一致等。后臺測試人員通過測試頁面，錄入測試用例，比對結果，確認金融底層的正確性。測試中期：中臺開發完成，將前、后臺聯通，開始執行流程測試用例。此時后臺功能很可能未完善，必要時需模擬后臺的接口數據，保證流程測試的進度。測試后期：金融底層正式通過WebServices 發布方式和應用層級聯，業務在系統中實現前、中、 后臺貫通。測試人員重點對系統接口進行測試：通過前臺錄入交易，中臺完成業務流轉，將業務數據送入后臺，最終系統將結果以查詢列表、報表、圖形等方式展現給用戶。集成測試工作結束后，測

10、試轉入系統功能測試階段，測試人員正式執行測試用例，同時以回歸測試驗證測試版本的穩定性。四、測試結果總結D 系統的測試實踐表明，有效的測試方法能提高測試效率，使項目過程可度量，達到質量過程控制目標。1. 測試工具自動化測試和手工測試不能互相取代。D 系統測試的各階段使用了質量管理工具和測試工具，提高效率。2. 測試用例本次測試需求用例419 個，測試用例設計對需求覆蓋率達到100。功能測試用例設計6368個，其中流程用例 364 個 （包括 36 個基本流，328 個備選流）。性能測試用例覆蓋8 個功能模塊，涉及 158種事務類型。共 設 計 21 個 測 試 場 景 ， 數 據 存 儲 設 計 為 1 萬 級 和 10 萬 級 。 vusers 設 計 7 種 并 發 級 別 （1g2g5g8g 10g 12g 150） o3. 測試結果D 系統開發過程中，測試工作歷時10 個月，通過發現缺陷和修復缺陷的過程，有效提高了軟件質量；通過總結測試報告為項目實施提供了有效的度量標準。缺陷率：D 系統測試中累計發現缺陷2605 個，千行代碼缺陷率為0.73 ， 小于包含復用代碼的應用行業缺陷率（一般為2.0 ），小于新開發代碼行業缺陷率（一般為4.1 ）。修復率：除業務驗收階段發現的缺陷