肖嵐

（國家衛星氣象中心 北京市 100081）

1 引言

風云三號氣象衛星（FY-3）是我國第二代極軌氣象衛星，搭載了多個遙感儀器，對全球進行全天候觀測。FY-3 地面應用運行控制系統（以下簡稱OCS 系統）實現對地面應用系統的任務調度、運行和設備狀態的監視等。

OCS 系統作為工程軟件項目，從立項至項目驗收, 遵循軟件工程規范開展項目活動，經過需求分析階段、概要設計階段、詳細設計階段、編碼實現階段、測試階段、直至驗收階段。軟件測試活動是OCS 系統項目實施中必不可少的環節。軟件測試目的是為了發現軟件設計和實現過程中所產生的錯誤，驗證軟件是否滿足任務需求和軟件設計所規定的功能和性能要求，更是保證軟件質量的一種手段。測試策劃是軟件測試活動的開始部分。

2 測試過程模型的確定

軟件項目測試過程原則上都應遵循一個測試過程模型，定義過程模型的目的在于將本質上無序的活動有序化，為開發過程中的軟件測試工作提供一個基本的框架，并在此框架上展開測試活動。如圖1 所示。

針對OCS 系統的項目階段，測試過程模型中的V 模型和W 模型都可以與之對應。但傳統的V 模型僅把測試過程作為編碼后的一個階段,忽視了測試對需求的分析，不利于發現設計過程中的錯誤。W 模型可以看作雙V 模型，測試活動與開發活動是同時進行的，體現了“盡早地和不斷地進行軟件測試”的原則，這樣有助于及早發現問題，提高測試效率，故我們選擇W 模型來開展OCS 系統項目測試。

3 測試策劃

按照W 測試過程模型，測試活動是貫穿OCS 系統軟件項目整個生命周期的。我們按照項目進展的順序，對測試策劃活動分別進行說明。

3.1 OCS系統需求分析階段測試策劃

在需求分析階段，開發人員對用戶提供的OCS 系統任務書進行需求分析，編制需求規格說明書和軟件開發計劃等。

我們在需求分析階段，以OCS 系統需求規格說明書為依據，開展OCS 系統的系統測試策劃。

3.1.1 系統測試資源需求

系統測試策劃需明確OCS 系統的系統測試環境，包括軟件項和硬件項：

（1）軟件項：操作系統(Unix/Linux, Windows 系列)、支撐軟件(數據庫、消息通信中間件、網絡管理軟件)、編譯器、測試設計與文檔工具、測試管理工具。

（2）硬件項：計算機硬件（服務器、PC 機）接口設備（以太網卡、通訊卡、語音卡）

測試策劃中需明確測試準備工作：包括建立測試環境和在測試環境中安裝被測試的軟件。

3.1.2 系統測試人員與進度安排

OCS 系統測試是由獨立的測試組來完成的。獨立測試組人員包括：軟件測試組長1 人、軟件測試工程師4 人、軟件質量保證工程師1 人。測試進度安排包括測試用例設計、測試實施、測試總結的預計最早和最晚開始的日期，以及所需的工作日，這些進度日期的設置來源于軟件開發計劃中的活動網絡甘特圖。

圖1

3.1.3 系統測試內容

在對OCS 系統的需求規格說明書進行分析后，確定以下測試內容：

（1）適合性測試：對業務應用服務、客戶端監視、WEB 檢索統計等功能進行測試。

（2）準確性測試：測試預報的時間和位置偏差是否滿足需求規格說明書中的精度要求。

（3）安全性測試：測試系統運行是否具有基于角色的安全控制以及應用軟件安全測試。

（4）容錯性測試：測試出現異常數據輸入或進行異常操作時，系統的容錯處理能力。

（5）可靠性測試：測試系統是否滿足需求規格說明書中的可靠性指標要求。

（6）易維護性測試：測試系統是否滿足需求規格說明書中的易維護性要求，檢查是否具有離線維護環境。

（7）可擴展性測試：測試是否可以通過外部配置予以完成OCS 核心軟件的擴展。

（8）時間特性測試：測試是否滿足需求規格說明書中的時間效率指標。

（9）資源特性測試：測試是否滿足需求規格說明書中的資源效率指標。

（10）易用性測試：測試軟件界面操作易用性，評價用戶手冊和聯機幫助等的易讀、易理解性。

我們建立測試項到測試依據（需求規格說明書）之間的追蹤矩陣，確保測試內容覆蓋需求，如表1 所示。

3.1.4 系統測試準則與文檔標準

OCS 系統的系統測試準則遵循已建立的系統測試工程規范標準。系統測試用例、系統測試記錄、系統測試報告模板在測試策劃中予以提供。

表1

表2

3.2 OCS系統概要設計階段測試策劃

OCS 系統的概要設計階段完成對OCS 系統的軟件結構設計、數據庫設計、接口設計。

我們以概要設計階段輸出的概要設計文檔為依據，進行OCS系統的集成測試的策劃。

3.2.1 集成測試策略

集成測試的基礎策略通常分為兩大類：非增量式集成測試策略和增量式集成測試策略。OCS系統的集成測試采用增量式集成策略。增量式集成的策略有很多種，根據OCS 系統的設計特性，OCS 系統的集成測試采用的是自底向上集成與基于功能集成相結合的集成策略。

3.2.2 集成測試環境部署

由開發人員搭建OCS 系統的集成測試環境：包括C/S 結構和B/S 結構，并部署需集成的軟件部件。

3.2.3 集成測試人員與進度安排

OCS 系統的集成測試人員由開發人員和獨立測試組人員共同組成，在單元測試實施完畢后，進入集成與集成測試階段。OCS 系統的集成測試進度安排參照軟件開發計劃中的活動網絡甘特圖來制定。

3.2.4 集成測試內容

OCS 系統集成測試內容包括對C/S 和B/S 兩種結構的集成功能測試、與其它應用系統仿真接口的測試、關鍵業務流程集成測試。

在集成測試說明中對測試內容細化，設計集成測試用例。

3.2.5 集成測試準則與文檔標準

OCS 系統的集成測試準則遵循已建立的集成測試工程規范標準。集成測試說明、集成測試記錄、集成測試報告模版在集成測試策劃中予以提供。

3.3 OCS系統詳細設計階段測試策劃

詳細設計階段完成模塊的詳細設計，每個模塊的模塊描述、實現算法，流程邏輯，數據結構等都有詳盡的描述。

在詳細設計階段，對應的是單元測試的策劃。單元測試以詳細設計為依據，采用白盒測試法對各模塊進行測試。OCS 系統的單元測試由開發人員在編碼階段同步進行。

3.3.1 單元測試方法和工具

單元測試采用的方法是白盒測試法。白盒測試是按照模塊的內部的結構來測試，測試者可以看到被測模塊的源代碼，并分析其內部結構。因此，白盒測試也叫結構測試或邏輯驅動測試。單元測試的目的在于發現各模塊內部可能存在的各種錯誤?？紤]采用Visual Studio 測試工具開展單元測試。Visual Studio“測試資源管理器”可幫助開發人員創建、管理和運行單元測試。測試框架可以使用 Microsoft 單元測試框架或第三方和開源框架。

3.3.2 單元測試環境

OCS 系統的單元測試環境與開發環境相一致。多數情況下，模塊并不是獨立可運行的程序。因此，在考慮測試模塊時，同時要考慮到它和外界其他模塊的聯系，用一些輔助模塊去模擬與被測模塊關聯的其他模塊。這些模塊分為驅動模塊和樁模塊。驅動模塊相當于所測模塊的主程序，負責接收測試數據，將測試數據傳送給被測模塊，輸出實測結果。 而樁模塊是由被測模塊所調用，用以代替由被測模塊所調用的模塊功能。因此在OCS 系統的單元測試的測試環境中，需要構建驅動模塊和樁模塊，從而達到單元測試的目標。

3.3.3 單元測試人員與進度安排

OCS 系統的單元測試人員安排為開發人員，開發人員有責任編寫功能代碼,同時也就有責任為代碼編寫單元測試代碼，以保證開發出的代碼與設計要求一致。OCS 單元測試進度安排參照軟件開發計劃中的活動網絡甘特圖來制定。

3.3.4 單元測試內容

OCS 系統的單元測試內容包含詳細設計中所有模塊。如表2 所示。

3.3.5 測試準則與文檔標準

OCS 系統的單元測試準則遵循已建立的單元測試工程規范標準。單元測試用例說明、單元測試記錄和和單元測試報告模版在單元測試策劃中予以提供。

3.4 OCS系統驗收階段測試策劃

當項目的生命周期進入驗收階段，意味著開發任務已經完成，通過了系統測試，達到了驗收測試的準入條件。驗收測試是以最終用戶為主導的測試。由最終用戶組織驗收測試組，通過驗收測試活動來確認OCS 系統是否滿足任務書中規劃的功能和性能的要求，并決定是否通過驗收測試。

3.4.1 驗收測試溝通

驗收測試是項目最后一個測試階段，也是啟動項目驗收評審的先決條件，其重要性不言而喻。因此，在著手準備驗收測試之前，應與用戶方進行充分的溝通。根據用戶方的要求，提交技術文檔，準備驗收測試數據；協助用戶方，梳理驗收測試用例與任務書要求之間的追蹤關系，確保驗收測試內容完全覆蓋了任務書功能和性能要求。

3.4.2 驗收測試環境部署

OCS 系統的驗收測試是在真實業務環境下進行的，在驗收測試開始之前，需要將系統安裝到用戶真實業務環境下（用戶業務機房），安裝必要的運行支撐環境，并配置好所有的運行參數。

4 結語

伴隨OCS 系統軟件項目生命周期的進展，我們在需求分析階段進行了系統測試策劃，概要設計階段進行了集成測試策劃，詳細設計階段進行了單元測試策劃。 越早進行測試策劃，越有利于發現需求和設計中存在的問題。而驗收階段的測試策劃,著重與用戶充分溝通, 做好驗收測試準備，保障驗收測試順利進行。軟件項目的測試策劃對后續設計測試用例，實施測試，完成各階段測試總結，直至通過最終驗收測試，都起著重要的作用。正是通過合理的測試策劃，為OCS 系統軟件測試工作的圓滿完成奠定了良好的基礎。