3.1.4　基于RUP的測試過程模型

統一開發過程（Rational Unified Process，RUP）是RATIONAL公司的一款基于網絡平臺，以架構為中心，面向對象，用例驅動的迭代和增量開發過程模型，包括初始、細化、構造、移交四個階段。每個階段都由若干迭代周期構成，每個迭代周期都是一個微型瀑布模型，但隨著項目進展所處階段不同而有所不同。將軟件測試過程活動與RUP模型結合，能夠建立基于RUP的軟件測試模型。

3.1.4.1　初始階段

初始階段旨在通過策劃確定測試過程活動，定義測試需求，制定測試策略，確定測試資源，分析測試風險，編制測試大綱，使相關人員能夠就軟件測試生命周期目標及活動達成一致。該階段的目標如下：

（1）確定軟件范圍及邊界條件，包括關于可操作的概念、可接受的準則。

（2）識別軟件系統的主要任務場景，以驅動系統的功能行為并對重要功能做出權衡。

（3）針對某個主要場景展示或演示其候選架構。

（4）對所需資源、時間等進行估算，對細化階段進行評估。

基于軟件開發過程的宏觀變換模型，如果某次循環的初始階段建立在上一循環的基礎之上，那么整體測試策略、測試過程、測試方法就是上一循環的迭代。RUP初始階段的測試活動如圖3-7所示。

3.1.4.2　細化階段

細化階段旨在分析問題域，建立基礎架構，進行風險分析和評估，確定主要風險因素并進行排序，制定風險防控措施。RUP細化階段的測試活動如圖3-8所示。

細化階段的工作產品包括需求規格、軟件架構描述、可執行架構原型、開發計劃、用例模型等。該階段，測試策劃所需要素已全部具備，測試需求已明確，能夠以此確定測試范圍、測試級別、測試類型、測試項，確定每個測試項的測試方法及充分性條件，構建測試環境，確定質量控制，配置管理要求，編制測試大綱。

針對工作產品生成時間，逐一按序進行測試，檢出錯誤，為后續測試尤其是系統測試和驗收測試奠定基礎。對于需求規格，通常以靜態評審進行需求測試，檢出需求缺陷，同時對修改情況實施跟蹤和回歸。

通常，將細化階段劃分為一至兩次迭代，在迭代的最后，系統測試用例已經明確，以這些用例為基礎，著手進行不同級別、不同類型的測試設計，如果采用自動化測試，尚需依據測試用例生成測試腳本，準備測試數據，到構造階段形成產品后即可開展測試執行。

3.1.4.3　構造階段

在構造階段，通過持續集成構建，開發一個有效版本并確保其質量。構造階段是測試活動最集中的階段。軟件構造是一個持續的過程，通常將構造階段劃分成多次迭代。每次迭代，都要按測試過程模型進行測試策劃、測試設計、準備測試腳本和測試數據、執行測試，對發現的問題進行分析、處理、跟蹤和回歸，直至完成系統構造。所有迭代并非彼此孤立，后一次迭代通常會重用或采信前一次迭代的資產。

一次迭代結束之后的測試評估可以產生大量數據和經驗，如測試用例設計的有效性、容易產生缺陷的模塊及原因、測試領域知識等。在下一次迭代過程中，能夠有的放矢，對測試資源進行合理調整。顯而易見，根據測試重用原則，各次迭代中測試的工作量，尤其是測試用例設計的工作量逐步遞減。RUP構造階段的測試活動如圖3-9所示。

3.1.4.4　移交階段

移交階段是軟件系統的驗收交付階段。RUP移交階段的測試活動如圖3-10所示。

此階段，所有迭代結束，軟件系統運行于實際使用環境，基于實際使用條件和場景，進行系統測試，驗證系統的符合性及交付能力。這個階段的測試可以是上線測試，也可以是鑒定測試，但其本質一樣，都是為系統驗收交付和狀態鑒定提供支撐。

不同開發階段，測試的對象及重點不同，測試活動需要一系列支撐過程，包括測試風險管理、測試環境準備、配置管理、人員管理、質量保證、計劃管理等內容。

每個項目的特點、迭代劃分、測試開銷均不同。當然，RUP并非一成不變，它既是一個過程，也是一個產品，并且是一個可以根據項目特點和用戶需求進行裁剪和定制的過程。迭代測試過程突出了迭代過程所具有的優點，可以更早地、全流程地檢出錯誤，緩解風險，可以更容易地管理變更，可以更加有效地提高測試資產的重用率，可以更加有效地促進項目組在整個過程中不斷學習，持續增強測試過程能力。