1. 測試體系方案
1.1. 概述
本節旨在論述如何在XX用戶建立測試體系以促進和加強測試管理和測試流程，提高測試質量，保證銀行IT產品品質，終達到更好地為金融客戶服務的目標。

測試體系是圍繞測試活動開展制定的一系列規程、指南、標準、模板，用于管理和規范測試過程，通過引入測試體系可以引入更好地測試方法來優化測試細節；可以通過規定和規范加強流程化管理；可以通過定義指標、標準更準確地反映測試、評估測試。

1.2. 總體思路
詳細描述以解決現有不足為目標并結合銀行測試管理的現狀而設計的測試管理總體解決方案的理念、思路、實現的方式方法。

根據上一節對XX商行測試工作的現狀和現實環境的分析，我們了解到在行里建立符合現狀和現需求的測試體系，并在該測試體系的指導下建立一批技術過硬的IT測試團隊的必要性。本節將著重描述測試體系建設的整體規劃和發展路線圖。

1.2.1. 測試內容補充
為了進一步提高測試的覆蓋度，保證系統質量，需要不斷豐富測試的內容，使用“自底向上”的方式檢驗系統各個層面上的正確性和可靠性。在已有的UAT測試的基礎上增加FT測試、SIT測試以及非功能性測試，非功能性測試包含的內容有：性能測試、兼容性測試等等。

1.2.2. 初步模型選型
建立測試體系的第一步是選擇適應于目前情況的測試模型。與當前情況相符合主要是指研究目前開發項目和系統的特點，其中包括：項目需求的規模，對測試周期的要求，以及項目所選擇的開發模型。

測試模型的選型目標主要是當前比較常用和成熟的測試模型：

瀑布模型

V模型

W模型

迭代模型

進化模型

RUP模型（增量迭代）

在選型過程中，需要選擇多種不同的模型以滿足現實中不同的開發需求，選型的方法可以參考選擇一個主模型以適應IT項目、一個子模型以適應新特性開發、需求變更或緊急情況應急處理。

，選型完成后，可根據自身的需要對模型定義的測試階段進行刪減和補充。

1.2.3. 引進有效的測試方法
1.2.4. 建立規程與標準
在選擇適合的測試模型后，測試活動被劃分為多個測試階段和多種針對不同測試目的的測試。例如：

單元測試

集成測試

功能測試（FT）

系統測試（SIT）

用戶驗收測試（UAT）

1.3. 體系建立
1.3.1. 建設目標
建立測試體系的目的是為測試工作制定周密的管理計劃，為測試工作建立標準化流程和標準化文檔，為測試單位提供運行的流程和規范�？紤]到本項目的特點，我們知道該項目的測試工作需要橫跨不同的業務系統，不同系統之間存在著網狀的數據流。這種系統的復雜性為測試管理工作提出了嚴峻的挑戰，據此我們需要通過建立測試體系的方法規范化測試流程，使得復雜的聯調測試變得易于跟蹤和控制，從而達到降低項目風險的目的。

建立測試體系的第一步是要確定一個生命周期模型從整體的角度描述整個項目。

1.3.2. 項目管理過程
將項目的測試管理分為五個階段和一個日常事務檢查表，對每個階段的工作任務進行說明，包括時間點、任務、提交物等。提供該體系給項目管理人員作為測試項目管理手冊，對整個項目的測試工作進行系統的管理、監督。

1.3.3. 流程與控制
該體系是針對項目具體實施過程的，對大運會項目的測試過程實施，在各個里程碑階段，我們將使用以下體系進行項目測試過程的執行，包括：里程碑接口、里程碑輸入信息、參與角色、工作過程、工作內容、輸出信息等。

1) 初始階段

初始階段主要是給客戶做測試過程和測試標準的介紹，加強客戶對測試過程和測試標準的了解。

面向對象：對象為項目參與人員（包括管理人員和技術人員）。

介紹內容：

介紹測試過程

介紹測試策略

介紹測試方法和特點

介紹測試結果評估、分析方法

2) 需求分析階段

前期接口：

初始階段完成，項目組認可所使用的測試過程、方法等；

基本的測試范圍（功能測試、性能測試、自動化測試等）和使用何種測試工具等基本達成一致。

輸入：

被測系統的開發文檔

被測系統的客戶文檔

參與角色：

在測試項目中，開發廠商，CSC專家，和測試組都有眾多人員的參與，這里闡述了各方在項目中需要的角色和各自的職責。

階段過程：

測試計劃階段的基本過程如下：

測試需求制定過程：

略

輸出：

項目測試計劃

項目相關標準

項目測試需求

3) 案例設計階段

前期接口：

測試設計人員都參與了系統的詳細培訓

測試設計人員參與了測試工具的培訓，掌握了測試工具的試用

輸入：

項目測試計劃

項目相關標準

項目測試需求

階段過程：

略

定義測試策略：考察應用程序、系統環境和測試資源等以決定測試目標。

分解測試對象：將AUT（被測應用程序）分解成具體的測試單元（可被測試的模塊和功能）。

定義測試案例：確定每個模塊所需的測試類型，添加基本的定義描述。

建立需求覆蓋：將具體的測試案例和需求建立覆蓋關系。

設計測試步驟：為每個測試案例添加測試步驟。測試步驟描述測試的操作、檢查點和預期輸出。

分析測試案例：評審所有測試案例以確保符合測試目標。

輸出：

測試案例

4) 執行階段

前期接口：

測試案例設計并審核完畢

輸入：

測試案例

階段過程：

輸出：

測試執行記錄

缺陷記錄單

缺陷跟蹤匯總表

缺陷跟蹤：

匯報缺陷記錄

跟蹤缺陷修改情況

回歸測試直到缺陷得到恰當處理（是否進行缺陷跟蹤要根據客戶要求不同而定）

5) 總結分析階段

前期接口：

測試執行工作完成

輸入：

測試執行記錄

缺陷記錄

缺陷跟蹤匯總表

階段過程：

本階段包含四個步驟：

整理數據：整理測試過程數據和缺陷數據，以備分析之需。

分析數據：根據收集整理的測試過程數據和缺陷數據對測試過程和系統情況進行分析。

編制總結分析報告：對項目進行總結，在整理數據和分析數據的同時即可進行該項工作，待數據分析完成后，將分析結果增加到報告中，并將總結分析報告提交給開發部，業務部，以便開展項目評估工作。

調查客戶滿意度：總結完成后，由開發部，業務部人填寫滿意度調查表，調查結果供測試過程改進和項目評估參考。

項目評估：由項目雙方（開發部，業務部和測試組）相關人員一起，根據評估項及其統計數據對項目完成情況進行評估。

略

輸出：

測試總結分析報告

項目評估報告

1.3.4. 項目測試標準
1) 缺陷相關標準

嚴重級別：

5 緊急

導致操作系統崩潰（如Win NT/2000 的籃屏、Win 98 的系統致命錯誤等）

導致操作系統不響應

程序退出沒有釋放資源

導致其它應用程序出現異常（如無法啟動、不響應、異常退出）

卸載時不提示客戶確認即刪除公用程序（DLL 等）

其它導致操作系統或其它應用程序異常的情況

造成重大安全隱患情況（如機密性數據的泄密）

4 很高

程序掛起

程序異常退出

系統無法正常安裝、卸載或升級

其它導致被測系統本身出現無法正常運行的錯誤

3 高

導致輸出的數據錯誤（數據內容出錯、格式錯誤、無法打開等）

導致其它功能模塊無法正常執行，如：

功能不完整或功能實現不正確；

導致數據終操作結果錯誤

文件或數據傳輸不完整或不正確

對數據格式不進行檢測

提示語句易誤導用戶，造成數據丟失等重大問題

其它導致被測應用系統其它模塊無法正常運行或出現錯誤結果的情況

2 中等

影響當前操作結果

數據修改后沒有保存提示

系統出錯提示不正確或沒有捕獲系統出錯信息

數據的重要操作（如刪除、添加等）沒有提示

其它影響被測模塊/功能正常執行的情況

1 低

頁面布局不合理

字體不一

錯別字

語言不一致（如：中英文混合）

頁面提示不明確

系統易用性不好

其它對被測模塊功能實現沒有影響的情況

缺陷導入階段：

1. 需求階段

未能真正了解客戶需求，功能描述不正確

需求定義有二義性

需求中遺漏客戶功能需求

2. 概要設計階段

架構設計不正確

業務流程設計錯誤

3. 詳細設計階段

功能模塊間數據格式定義不一致

開發規范

4. 編碼階段

5. 其它

缺陷優先級：

3 必須修改

2 將要修改

1 有時間則改

0 未分配

缺陷類型：

程序錯誤

環境設置

重復記錄

需要完善

不可重現

并非問題

1.4. 測試體系涵蓋的其它內容
1.4.1. 規范和強化測試子流程
略

1.4.2. 規范和強化測試流程
測試流程可分為兩支：

自動化測試流程；

手工測試流程。

1.4.3. 標準化、規范化測試對象
在測試活動中通過標準化、規范化測試資源使測試資源可以被共享和重用。

如果測試對象缺乏必要的標準化、規范化，會導致測試案例等測試對象無法共享。例如，很多測試團隊的測試案例編寫缺乏規范，導致：

測試案例“個性化”、“個人化”，只有自己才能夠“看懂”自己的測試案例來進行測試執行，其他的測試工程師無法使用其他人的測試案例來進行測試；

測試設計人員和測試執行人員無法分離，高成本的測試設計人員必須自己來執行測試案例，而不能使用低成本的測試執行人員來執行測試案例，導致無法達到很好的勞動組合，提高工作效率，也大大占用了經驗豐富的測試設計人員的時間。

對于測試過程也需要進行控制，只有進行測試對象的標準化、規范化，才能夠進行測試案例評審，進一步提升測試案例的質量。

1.4.4. 測試對象復用，降低測試成本
測試對象復用，主要指測試案例復用、測試腳本復用、測試計劃復用。

1.4.5. 建基于模型驅動的自動化測試架構
一般情況下，如果一個測試需要執行3次以上，那么自動測試的成本能夠和手工測試持平。隨著執行測試的不斷增加（特別是后期的回歸測試），測試成本大大小于手工測試執行。

隨著測試技術的發展，很多測試腳本能夠通過灰盒測試方法，通過自動轉換程序技術來自動生成，能夠把測試工作大大提前，并且測試腳本的編寫成本大幅度下降。

1.4.6. 定制流程管理缺陷，定制查詢
實現缺陷流程定制化。根據項目特點，定制有針對性的缺陷管理流程。為每一個測試角色分配缺陷處理的權限。使得每個測試人員的分工更明確，人員配置更合理。

在缺陷跟蹤之前定制查詢。通過定制常用的查詢規則，例如：當日提交給我待解決的缺陷、所有解決的缺陷等等，測試員和開發人員將有針對性地關注缺陷，測試經理也可以即時了解問題解決情況。

基于Test Center的測試體系可以劃分為8個子模塊，見下圖。

缺陷管理模塊：

支持缺陷管理流程，可以定制缺陷管理流程，支持缺陷流程的是一個工作流；

可定制的缺陷過濾器。用戶根據自身的需要定義過濾器。通過輸入查找條件，將查詢規則定義為過濾器。通過這種方式，用戶可以更快地找到自己所關心的缺陷，例如“剩余的沒解決的缺陷”之類；

支持缺陷報告，缺陷報告以圖表和圖的方式展示處于各個狀態的缺陷，以及各個緊急程度分類上的缺陷。缺陷報告還提供了缺陷關閉、打開曲線圖，用以了解每日缺陷的關閉和打開趨勢。

1.4.7. 生成測試報告
生成詳盡的測試報告，包括執行情況、缺陷情況、需求達成情況使得項目重要干系人即使了解項目進程，了解問題的分布情況，即時分析和規避開發風險。

1.4.8. 測試環境管理
管理開發和測試資源，使用預約的方式將資源分配給人員和組，為資源分配提供管理和監控的解決方案。