【文章內容簡介】 持 ） 、 軟件四 科（ 主要 負 責 全 行 外 圍業(yè) 務 系統(tǒng) 和 管理 系 統(tǒng)開 發(fā) 及技 術 支持 ） 等 。每 個科 室由一名科室負責人和若干主管及普通技 術 人員 組 成 。 每 個科 室 人員 除了 履 行 日常 科 室 規(guī) 定的 職 責 外 還負 責 對 已完 成 開 發(fā) 的 項目 編制測 試 案例 并 進行 功 能性 測 試和 業(yè) 務邊 界 類及 異 常 處理 流 程的 測 試 ，承 擔 了雙 重職責，在角色扮演上沖突，結果使測試沒有有效地規(guī)劃和執(zhí)行。 測 試團 隊 是 由 監(jiān)督 員 組 成的 虛 擬 團 隊， 缺 乏 實 體測 試 組 織， 缺 乏 明 確的 軟 件質量和軟件測試的管理和執(zhí)行人員角色定義。 目前應用的測試相關技術 目前 信息技術 部主 要 通 過 CA 辦 公 自動 化 系 統(tǒng)與 銀 行 各 相關 職 能 部 門進 行 需求的 流 轉， 無 專業(yè) 需 求管 理 系統(tǒng) ， 各 類測試 階 段 的 實施 仍 停留 在 手工 測 試 方式，沒有 統(tǒng) 一的 測 試管 理 系統(tǒng) 來 進行 有 效的 問 題管 理 及 測試 計 劃的 實 施 ，測 試 過程 中的資 產 被采 用 不同 的 方法 和 技術 記 錄和 管 理 ，導 致 測試 資 產 （ 指 測 試過 程 中生 成或編 寫 的各 類 文檔 、腳 本、 代 碼、 配置 文 件等 ） 的 管 理帶 來 困 難， 使這 些 資產 的價值被忽視，變成被保留的歷史數(shù)據(jù)，而非可促進質量持續(xù)提升的基礎。 業(yè)務部門 跨平臺多樣化技術 架構 傳 統(tǒng) 單一的 技術架構 系統(tǒng)開發(fā)測試環(huán)境 軟件開發(fā)部 運行科 用戶 測試環(huán)境 準生產 環(huán)境 ITSM 管理系統(tǒng) TD 自動化測試 管理 系統(tǒng) CA辦公自動化系統(tǒng) 上海銀行測試中心規(guī)劃建設方案 合康科技 7 / 52 隨著 上 海 銀 行 各類 業(yè) 務 系統(tǒng) 從 單 一 技術 框 架 結 構向 多 樣 化 技 術 框 架 結構 的 轉變，目 前 的測 試 手段 和 技術 已 顯然 無 法滿 足 行內 多 平臺 、多語 言 和 多廠 商 的快 速開發(fā)上線的模式。 綜合評估 綜合 分析 已達到的程度： ? 業(yè)務需求管理過程已經建立 ? 已產生需求過濾及整合機制 ? 對軟件質量有改進意識 ? 部分系統(tǒng)已嘗試使用自動化測試工具 ? 使用 ITSM 進行服 務管 理 尚存問題 ： ? 測試知識無法傳承，容易產生盲區(qū) ? 業(yè)務人員角色沖突，測試無法有效規(guī)劃和實施 ? 缺乏統(tǒng)一的需求管理、測試管理流程和系統(tǒng) ? 手工測試效率低下，無法覆蓋全部測試需求 ? 配置管理缺乏，案例完整性難以保證，存在潛在風險 ? 測試資產難以有效保存，價值易被忽視 Q u a li t y E x p e r tQ u a li t y S a v v yQ u a li t y C o n s c io u sQ u a li t y I n it ia li z in g01234資源共享服務和工作請求需求測試計劃和案例單元測試系統(tǒng)和集成測試用戶驗收測試性能測試缺陷管理報告和度量上海銀行測試中心規(guī)劃建設方案 合康科技 8 / 52 ? 測試 環(huán)境管理缺乏 ， 容易 造 成版 本 錯換 、 漏換 ? 缺乏對外包項目的質量管理，無法對外包廠商的軟件質量進 行 量 化評 估 3 測試中心 簡介 測試中心作用 測試中心定義 ? 軟件 質 量：軟 件質 量 是軟 件 特性 的 總和 ，軟 件 滿足 規(guī) 定或 者 潛在 用戶 需求 的能力 ? 軟件 測 試：軟 件測 試 的經 典 定義 是 在規(guī) 定 條件 下 對程 序 進行 操 作，以 發(fā)現(xiàn) 錯誤 ，對 軟 件質 量 進行 評估。 由 于 軟件 是 由文 檔 ，數(shù)據(jù) 以 及程 序 組成的 ， 因此 目 前軟 件 測試 涵 蓋的 已 經不 僅 僅是 對 程 序進 行 測試 ，還應該包括對軟件行程過程的文檔和數(shù)據(jù)進行的測試。 ? 測試中心： 測試中心是區(qū)別于開發(fā)團隊的相對獨立的，統(tǒng)一的團體或者組織 ，其 人 員具 有 先進 的 測試 理 論和 經 驗 ，能 夠 遵循 測 試管 理 流程 ，通過 手 工或 者 自動 化 測試 工 具 ，對 系 統(tǒng) 或軟 件 開展 有 組織 的 ，有效的測試活動，從而對系統(tǒng)或軟件提供整體的質量評估。 ? 測試中心的特點在于： ? 具有相對獨立性，統(tǒng)一性 ? 可以作用于不同的系統(tǒng)或應用 ? 具有一致的管理流程和軟件質量可見性 ? 提供集中的基礎架構 ? 具有專業(yè)的團隊，實現(xiàn)了技能和測試資產共享 測試中心的意義 相比單純的某個項目內部的測試工具采購和使用而言，建設統(tǒng)一的測試中心的意義在于： 有效性 ：應 用開 發(fā) /實 施產 品 、最佳 實 踐方 法 和人 員 都實 現(xiàn) 了集 成 ，可以 從 一個點上就能便捷地獲取所有項目小組的權限，因此不需要增加昂貴的資源投入。（事實上可能會減少 職員 總 人數(shù) 。） 改進性 ：可以從整個 銀行 中 收 集測 試 流程 、 組織 和 產品 方 面的 最 佳實 踐 ，并且標 準 化及 改 進這 些 實踐 ，然 后重 新 把這 些 改進 過 的實 踐 發(fā)送 到 整個 銀行 中 。這樣，就縮短了新的測試項目的學習曲線，提高了所有測試小組的成功可能性。 統(tǒng)一性 ：測試中心模式能幫助 銀行 統(tǒng) 一業(yè) 務 目標 和 項目 優(yōu) 先級 ， 提供 更 好的最終用戶服務。 上海銀行測試中心規(guī)劃建設方案 合康科技 9 / 52 實用性 ： 建立 一 個測 試 中心 模 型 ，這是 一 個可 以 達到 的 目標 。您 可以 利 用現(xiàn)存的 各 種資 源 從小 范 圍開 始 實施 ，然 后，在 證實 其 價值 后，再 進一 步 擴 展其 能 力。許多公司往往會發(fā)現(xiàn)測試中心模型是自給自足的。 職業(yè)提升 ：測試 中心模型為專 業(yè)人 士 提供 了 一個 具 有吸 引 力的 新 職業(yè) 機 會，幫助銀行重新招募并保留頂級人才。 測試 方法論 軟件 測試 方法論 傳統(tǒng) 的 開發(fā) 方 法屬 于 線型 或 者稱 之 為瀑 布 型 ，每 一 個階 段 的開 始 都 基于 上 一階段 成 果而 展 開 ，因 此 無法 對 整個 系 統(tǒng)質 量 進行 有 效的 控 制，無 法 體現(xiàn) 測 試對 于整個 系 統(tǒng)質 量 控制 的 重要 性 ，一旦 在 后期 測 試中 發(fā) 現(xiàn)問 題 ，很 有 可 能導 致 軟件 發(fā)布延遲，整個項目成本的增加。 我們 所 提 倡 的 測試 方 法 是將 測 試 貫 穿于 項 目 規(guī) 劃、 設 計 、實 施 、 部 署的 整 個過程 中 ，隨 時對 項 目質 量 進行 監(jiān) 控 。一 旦 發(fā)現(xiàn) 問 題 ，及時 提 交 ，使 問 題 能夠 盡 早、盡快地得以解決。 實施 實施 設計 應用部署 測試 傳統(tǒng)方法論 需求驗證 應用部署 優(yōu)化業(yè)務成果 現(xiàn)代 方法論 對業(yè)務功能進行風險和影響度的評估，以縮減 QA的時間，并提高有限時間和成本內的質量水平 業(yè)務影響分析 驗證需求 2 使 IT能更好的迎合業(yè)務需求，在應用交付的 早期就能夠確定可能存在的缺陷 使用業(yè)務度量 3 規(guī)劃 業(yè)務需求 設計 測試 1 時間 業(yè)務需求 規(guī)劃 提供質量流程改進的面向目標的關鍵性能指標，這些指標是面向業(yè)務需求的 上海銀行測試中心規(guī)劃建設方案 合康科技 10 / 52 軟件測試和開發(fā)生命周期 通 過在 軟 件 項 目過 程 中 自始 至 終 地 貫徹 盡 早 測 試、 連 續(xù) 測試 、 自 動 測試 經 驗的實 施 ，能很 大 程度 上 提前 了 軟件 系 統(tǒng)測 試 發(fā)生 的 時間 ，能連 續(xù) 的 及時 的 發(fā)現(xiàn) 軟件錯誤，從而可以在很大程度上降低項目風險和項目開發(fā)成本。 測試中心的功能 測試中心關注的階段 以下是軟件測試 Vamp。V模 型 圖： 如圖所示，測試過程主要分為四個階段：單元測試，集成測試，系統(tǒng)測試，Requirements Functional amp。 Technical Specs Build Test Execution DeployRequirementsVrfcatioTest Strategy amp。Tes PlanTest case UATSystemTstPerformanceTestMercury Quality ProcesesReadinesTestOperationProblemDiagnostic上海銀行測試中心規(guī)劃建設方案 合康科技 11 / 52 驗收測試 。 在模 型 中， 單 元測 試 是基 于 代碼 的 測試 ， 最初 由 開發(fā) 人 員 執(zhí) 行， 以 驗 證其 可執(zhí)行程序代碼的各個部分是否已達到了預期的功能要求； 集成 測 試驗 證 了 2 個 或多 個 單元 之 間的 集 成是 否 正 確，并 有 針對 性 地 對詳 細設計中所定義的各單元之間的接口進行檢查； 在所 有 單元 測 試和 集 成測 試 完成 后， 系 統(tǒng)測 試 開始 以 客戶 環(huán) 境模 擬 系 統(tǒng)的 運行，以驗證系統(tǒng)是否達到了在概要設計中所定義的功能和性能； 最后 ，當 技 術部 門 完成 了 所有 測 試工 作 后，由業(yè) 務 專家 或 用戶 進 行 驗收 測 試，以確保產品能真正符合用戶業(yè)務上的需要。 單元測試和集成測試主要由開發(fā)團隊完成，因此測試中心主要關注的是系統(tǒng)測試 和 驗收 測 試 ，當 系 統(tǒng) 上線 以 后 ，在 版 本更 新 和缺 陷 修復 過