測試人員對 RUP 四個階段的貢獻：另一種觀點

從測試工程師那里聽到的最普遍的抱怨是直到過程中很晚的時候才能有效地參與到軟件開發項目中。此外，測試通常是在開發人員在抗爭損壞一個接一個版本候選的很晚出現的缺陷時所逼出的行為。到一個合適的候選版本出現的時候，測試人員已經成為瓶頸，顯然，要對進一步的延遲負責。

Rational Unified Process®，或 RUP®，廣泛地概括了測試規程（Test Discipline），并介紹了測試角色如何及早地參與項目生命周期。

我希望在本文中介紹另一種觀點。代替由測試規程開始，我將依次考慮每個 RUP 階段的風險管理原則，并詢問經驗豐富的測試人員，為了促進那些目標他們可能會做些什么。雖然測試工程師不能估算總的項目成本，但是他們的確可以評估對成本的測試貢獻，并且提出測試風險和可行性。雖然他們不應該計劃解決方案架構，但是他們可以幫忙度量。雖然測試人員不構建一系列可執行程序，但是他們可以評估每個可執行程序如何表示一個從前一個而來的進展。雖然測試人員不構建最終的候選版本，但是他們可以確保具有可接受的質量。

我相信在 RUP 的每個階段，測試人員都有機會對項目做出大量貢獻。該貢獻遠遠地擴展了，例如，要求更早地測試交付內容 —— 或者更早地執行一組標準的測試 —— 比傳統的瀑布驅動過程中。本文應作為面向開發團隊中的測試人員的 RUP 原則的激勵說明來閱讀。它不應該作為 RUP 測試規程的概要或初級讀物。雖然我相信許多測試人員會覺得該信息很有用，但是我還相信管理人員將會對看到測試人員的能力和經驗如何在 RUP 項目的所有階段中更有效地應用感興趣。

初始（Inception）階段：管理業務風險

RUP 的初始階段是對準業務風險的管理。為了制定出自該階段的可行或不可行的決策，我們需要了解

• 待解決問題的性質。
• 解決方案的價值，不論是就節約或收益而言，還是以一些其他的業務價值，如質量或時間性而言。
• 潛在的解決方案，因此我們至少知道問題是可解決的。
• 對解決方案的粗略成本估算。
• 危害解決方案的風險。

帶著此信息，涉眾被聚集到生命周期目標（Lifecycle Objectives，LCO）會議上。如果項目被視為是可行且值得做的，那么項目會繼續進入精化階段。

評估成本

可行性和成本是 LCO 會議上的重要因素，并且測試人員無疑可以為該決策貢獻重要的數據。測試人員可以估算對成本的測試貢獻，甚至有時候可以有助于可行性問題。記住，在初始階段中，盡管我們只對球場的數字感興趣。過高的精確度將給我們帶來不真實精確度的不適當安全感。

也許有或也許沒有實際的可執行程序作為 LCO 簡報的一部分。這些可能由技術示范者、現有產品的快速出租，或者也許是更實質的東西組成。我的意見是在如此初步的階段執行如此正式的操作是不適當的。

因為測試成本對總的開發成本做出貢獻，所以我已經列出許多對測試成本做出貢獻的行為。

• 測試風險
  風險需要減輕計劃，減輕風險需要花費金錢。測試風險是各種各樣的。例如，需求可能迅速地變更，這可能會破壞可測試性或測試成本設想。后繼的精化階段可能會利用新的測試難點的解決方案來解決技術風險?？赡苄枰袷?MC/DC（Modified Condition/Decision Coverage）測試、ISO 標準、SEI 標準，IEEE 標準，等等這樣的標準。 ¹ 這些標準可以減少整個業務成本，但是順應成本在某種程度上落在測試人員上，并且應該更加明顯?？赡艽嬖谂c數據安全相關的政府規章，如保密性規章，使對“真實”數據的測試變得困難或昂貴。
  
  
• 可測試性
  可測試性與可行性直接相關，并且很可能找到很難測試的高層次需求。一些需求是非可測試的，因為他們是主觀的，或者不是有助于度量或量度的。一些是不可測試的，因為從技術上很難安排一個合適的測試。例如，一些戰略防御計劃（Strategic Defense Initiative，SDI）的批評家提到在美國執行其導彈防御的可接受性測試時，讓蘇聯啟動非武裝的洲際彈道導彈（Intercontinental Ballistic Missile，ICBM）的困難。在軟件開發項目中，這種情況發生于格外昂貴的硬件不能為了測試很容易地重新執行任務的時候，或者當獨特的環境因素使測試的安排變得困難時。
  
  
• 準備測試實驗室
  通過“實驗室”，我的意思是一個環境，在其中有我們測試每個需求所需要的東西，一個被提供但與產品環境有很難區分的不同。即使我們在早期的需求發現階段，仍有可能估算您很可能需要的資源。
  
  資源可能包括 1) 硬件、計算機、網絡，以及由慢速管道或很長的往返傳遞，及防火墻所引起的瓶頸，2) 軟件，包括測軟件及其他必需或采用的軟件，所有的都處于已知版本層（或根據所有版本進行測試?。?，3) 測試軟件，如測試經理，測試自動化軟件，如記錄或回放 GUI 測試人員，以及用于可伸縮測試的用戶虛擬化，4) 數據，包括用于冒煙測試和功能測試的小型數據集，以及用于可伸縮性測試的大型數據集。
  
  注意到盡管潛在的實驗室特性的列表很長，我們還必須在存在相應的實際需求的地方指定實驗室需求。例如，不是所有的系統都有可伸縮性需求，所以不是所有的實驗室都將需要用戶虛擬化工具。
  
  
• 估算需求或場景的整體測試成本
  大多數需求將作為普通的功能需求出現。與測試相關的成本通常與編碼或設計的成本大致成比例，因此測試工作一般來說將是編碼和設計成本的某個比例（比方說 25％）。此系數將具體到每個組織，并且可以通過收集一兩個項目量度按經驗尋找。
  
  系數將被平臺的數量或所需的其他類型的測試工作副本所修改。 ²
  
  
• 缺陷管理、構建，發布過程
  存在與將測試人員插入開發過程中有關的成本。測試人員共享其他項目團隊使用的特定開發工具，如用于缺陷跟蹤的工具，以及構建和發布工具，如用于配置管理的工具。

精化（Elaboration）階段：管理技術風險

RUP 的精化階段是對準技術風險的管理的。為了制定出自該階段的可行或不可行的決策，我們需要論證一個對每個鑒別出的技術風險的滿意解決方案。通常，最糟的技術問題由非功能需求導致。非功能需求可以造成這樣的有趣斷言“系統將擁有 99.999％ 的可用性，”或者“系統將支持 10,000 個同時發生的用戶會話。”這些需求寫起來便宜，但滿足和測試起來昂貴。為了進行適當的評估，我們需要了解：

• 在完成極端的非功能目標中可能隱含的權衡。
• 當接近這些極限時各種架構退化的方式。

有了此數據，架構師可以選擇最適當的架構，并且，當涉眾面對他們需求的所有含意時，通常會更愿意調節他們的雄心，并且得到更多的回報。

因此，關鍵的評估需求是其中一個度量，并且這應該是此階段測試人員主要的目標。

量度方法的評估

對于每個技術問題，架構團隊將建立一個或多個具體表現一個解決方案方法的可執行系統?？赡軙腥舾捎懈偁幍慕鉀Q方案（舉例來說，通信中的 UDP 對 TCP）和大量的對于每個解決方案的可配置選擇（舉例來說，進程架構中的 10 線程 對 50 個線程）。測試人員執行對生成架構的度量所必需的步驟。

度量強調的是是否對解決方案有了成熟的考慮而不是功能是否被正確的實現了，因為沒有人會期望生命周期中早期就實現完全正確的功能或者甚至花費大量的精力去雕琢還不成熟的系統的功能。初始階段中指定的許多實驗室環境將在精化階段中被需要。我們將度量性能和可伸縮性，跨過通信鏈接和出自數據庫的數據速率，隨負載變化時的響應時間，并且我們將生成需求所要求的其他度量。根據所有的架構原型執行這些測試，并且測試團隊將與架構師攜手工作，共同設計確認或駁斥每個設計決策的測試。

當傳統測試人員可能會參與整個基于文檔的活動時，測試團隊在此階段的行為與瀑布過程中所做的驚人地不同。當項目從一個危機牽絆到下一個時，許多工作都不相關了。相反，在迭代的項目的精化階段，測試人員在起勁的行動著，被閃光燈和不停的撥號所圍繞。測試人員贊成相關的且實際的測試，使它們與架構師保持一致，并且評估并解釋結果。

當然這是富有挑戰的工作，但同時還是要大量參與的、有價值的，并令人滿意的。如果對于小型的團隊環境及上千行的代碼的情況建立這些測試都是棘手的，那么設想一下對上百萬行的代碼項目的大型團隊來說所受到的阻礙。

雖然這個階段執行測試設計和實現，但是我們應該記住，重要的是測試結果而不是測試文檔。由于將會拋棄許多架構的提議，所以相關的測試也一樣。我們僅需要做足夠的測試設計和實現，用以獲得必需的度量。我們不像細化提議那樣做太多測試，隨著最主要的架構候選的出現，我們可以添加嚴密，如可溯性和其他文檔。

測試設計

作為并行活動，精化階段表現出一次方便的時機來考慮技術架構中的小變更如何能夠更好的幫助測試設計和測試自動化。

通過測試自動化，我的意思是使用記錄鍵盤和鼠標事件的 GUI 記錄或回放工具，可以回放來重復測試。經驗豐富的測試人員知道自動化尤其要求重要的腳本維護工作。值得考慮一下允許腳本構造的“測試架構”，這與設計人員創建“軟件架構”來簡化應用程序構造具有同樣意義。

測試人員應該考慮解決方案，特別是測試可能參數化的方法或映射到需求所暗示的“組合爆炸”的結合方法的復雜性維度。例如，考慮一個指定某個需要支持的平臺組合的非功能需求。根據一個平臺撰寫腳本，在所有平臺上“回放”是有利的。這同樣可以應用到數據庫后端、應用程序服務器、Web 服務器和環境基礎架構的其他元素，并且特別是對于這些的排列組合。手動測試每個組合將是不能忍受的痛苦。測試自動化是唯一經濟的解決方案。

大多數應用程序為測試人員的專長提供許多應用程序專用的機會。設計人員將找到“用參數表示”問題領域的方法，并且這些經常成為類似地用參數表示測試所沿著的維度。例如，在我所工作過的一個應用程序中，有許多看起來一樣的屏幕上的表格，因此設計人員將列參數化為通用的小部件，這給予測試人員類似的能力來用參數表示它們的測試。

針對測試的設計在精化階段如此重要的一個原因是在構建階段很難找出時間來適當處理這一活動。但是有一個甚至更好的理由：通過測試人員和設計人員之間的良好對話，架構中的小讓步可以給測試設計添加一個大好處?？偠灾?，精化階段是針對測試而設計的適當時機。

構建（Construction）階段：管理進度風險

RUP 的構建階段瞄準進度風險的管理。如果應用了 RUP 首選的基于用例的方法，就可以比利用傳統的（瀑布）方法更快地集中于可用的（盡管不完全）系統。當達到這一可用地不完全層次，剩下的路也就不遠了。

該方法生成了一系列客觀的改進的可執行系統，并且擁有重要的優勢：

• 在盡可能最早的時候給客戶展示系統的功能。
• 團隊可以及早地獲得部署經驗。生成的可執行系統可以轉化為產品化階段的子集（部分部署）。這使我們獲得產品化階段問題的經驗 —— 例如，驗收測試所需要的是什么，如何為部署而打包，以及一百個其他的問題（參見下面的產品化階段）。
• 我們收集量度，這使得在迭代開發中可以立即看到項目進展。在瀑布過程中，不太可能直接比較分析活動量度和設計活動量度或編碼活動量度，因為它們是完全不同的活動。但在迭代過程中，比較迭代 1 的量度與迭代 2 的量度更加容易，因為我們在重復同一組活動。

在幾個星期內，我們就會完成一個分析——設計——編碼——測試的周期，這個給我們一種明顯進展的感覺。這就是構建階段的迭代的獨特之處。測試活動評估進展并驗證確實有了進展。

評估進展

RUP 提到的迭代節奏到構建階段還是活躍著的，并且該頻率與測試人員有特別的關系。測試人員的主要目標是能夠客觀地描述系統的當前狀態，并且能夠將該狀態與以前的狀態進行比較。這兩個狀態之間的區別，簡單地說，就是進展。

測試人員的“節奏”源于以下活動。

• 測試設計和實現
  測試人員的一項主要任務是測試腳本的設計和實現。在迭代開發中，這是由為當前迭代安排的場景所驅動的。測試腳本必須開發成能夠將應用程序推到正確的“屏幕”或其他應用程序模式。測試數據必須開發成可以在此處執行應用程序，并且驗證必須設計成可以核對應用程序的行為。
  
  如果使用了自動化的測試工具，那么此時會提出某種考慮，關于該測試用例是否是好的自動化候選或者是否應該手動執行。
  
  
• 測試執行
  執行測試來確定每個驗證點的通過或失敗狀態。執行手動測試意味著有方法地遵守測試實現提示并適當地觀察和注意結果。
  
  執行自動化的測試意味著安排正確的系統初始條件，然后調用腳本回放工具。在控制初始條件時，我們希望管理測試過程中什么數據處于什么狀態。該需求也適用于手動測試，區別在于測試人員可以“照顧”交互并且經常讓測試不工作來工作于未初始化的開始條件周圍。
  
  
• 回歸和測試腳本維護
  迭代開發的一個明確的任務是需要為每個新的迭代再次運行舊的測試。這種對現有測試集的重復執行稱為回歸測試，是一個顯露出自動化測試的好處和負擔的活動。好處：因為另一種是手動測試，很明顯的耗費時間的活動。負擔：因為自動化的腳本經常需要仔細的修改來服務于下一個構建。測試腳本維護，和腳本回放調試器，對測試人員來說將會是非常熟悉的。測試人員將會及早并且使用減少腳本退化的測試工具，了解如何減少維護工作。
  
  
• 缺陷跟蹤和分辨
  缺陷跟蹤和分辨活動是測試人員都知道的。測試行為總是揭示缺陷或問題，并且必須勤奮地跟蹤每個事故來進行分辨。首先，分辨通常需要在實驗室中復制的錯誤，但至少是處于這個原因，即 SEI Capability Maturity Model Integration (CMMI) 要求項目團隊實現配置管理以達到有威信的“可重復級別, 級別 2”。只有通過將所有開發文件置于該控制下，并且用材料清單描述每個構建，開發人員才可能有許多機會重復所有已知的事件并因此能夠滿足該標準。
  
  為了提高項目角色之間缺陷信息的共享，用開發人員使用的同樣的配置管理和缺陷跟蹤環境來裝備測試人員是合理的。

針對進展的量度

我們已經回顧了測試人員在構建階段所做的事情。我們如何將其轉化為進展的量度呢？有多種描述恰當的技術， ³ 以下的處理是可以借鑒的。

• 完成百分比
  度量進展的一個過分簡單但特別實際的方法是利用“完成百分比”作為量度。如果有人考慮通過測試的場景的流程，我們可以考慮構造一組檢查點，表 1 中所顯示的一個實例。

我們確定表 1 中每個場景和測試中所描述的每個檢查點。不論完成或是沒完成，它們的值都嚴格地報告為是或不是的值。我們合計每一層并將其表示為前一個層的某個百分比。目標是達到每一層的 100％ 覆蓋?？偟慕Y果相當粗略，但針對達到最高百分比的工作帶來了提前測試工作的非常有意義的副加作用。

• 缺陷趨勢
  每個迭代將擁有一個開發包，一些新的特性或場景加入其中并且根據現有場景的缺陷也得到修復。當然有一個趨勢，即實現新的而不修復老的，但是明智的項目經理將注意缺陷趨勢并強調，至多一兩個以缺陷形式的未解決的迭代工作的價值將保留。
  
  無論如何，分辨缺陷無疑可以看作進展。與缺陷相關的量度也能夠以有趣的方式得來，包括：
  
  
  • 每個缺陷的工作、每行源代碼的缺陷、每個模塊或組件的缺陷、按照注入點的缺陷、按照時間的缺陷、按照狀態的缺陷。
  • 使用時間圖表 —— 根據時間所有這些量度都可以畫為圖表趨勢，例如，應該積極地調查表示修復缺陷工作穩定增長的趨勢。

我們還能夠通過余下的迭代的數量和平均的缺陷分辨工作來增加每個迭代的預期缺陷。這指示了顯著的缺陷負擔，包括在還沒撰寫的代碼中沒有發現的缺陷！這些是粗略的數字，但是是要求全部的完成百分比的重要基礎。

• 對于測試人員的缺陷趨勢
  雖然上面的缺陷趨勢不是具體到測試規程的，但是存在重要的缺陷量度來指導測試人員，包括每個找到的缺陷的測試工作、每個測試用例的缺陷、每個場景的缺陷，及每個迭代的缺陷。
  
  這樣的量度是有效的，不僅從歷史的觀察，還從預言能力上講。例如，如果我們的測試揭示了一個突然的且出乎意料的缺陷密度，我們可能宣稱該構建是不健全的，放棄測試，并讓架構團隊檢查此構建。測試一個糟糕的構建以致精疲力盡，從中得不到一點好處。
  
  
• MTBF
  平均故障時間（mean time between failure，MTBF）是重要的“人造”量度 —— 也就是，我們不得不捏造定義，為了能夠生成受控條件下的客觀度量。MTBF 通常作為非功能需求出現。為了驗證我們的系統，我們必須在實驗室設置在測的應用程序，利用事件進行干擾，并且當不能適當處理事件時進行監測。我們將其記錄為一個失敗，并且繼續測試或者（如果不幸的話）重新啟動應用程序。我們能夠以快于真實情況的節奏來生成事件流。這些手段的凈效應是能夠在幾個星期內生成幾年中才能度量出的 MTBF 數字。 因為明顯的理由，可以將其認為是人造的量度。

這些量度證明測試人員應該看作是項目經理重要的數據來源。

構建迭代測試優先級

用例驅動的迭代方法生成了新的機會和新的負擔。因為我們將已經限制阻礙完全測試的資源，所以我們應該根據以下優先級順序執行測試：

1. 運行“冒煙測試”。如果冒煙測試通過了，那么：
2. 測試那些在此迭代中分辨出的缺陷。
3. 測試那些在此迭代中實現的新場景。

上面的三項應看作是絕對極小值，并且不能實現它們的應該看作是測試過程的主要失敗。我們應該繼續三個步驟：

4. 維護和執行的自動化測試
5. 維護和執行的手動測試
6. 人造量度集合

當然，應該優先選擇不需要維護當前連編的自動化測試。隨著時間的推移，我們應該能夠收集從中可以預計測試工作的量度，例如，維護自動化測試要多少工作，運行手動測試要多少工作，等等。

每個項目團隊必須分辨的一個問題是測試活動與開發活動并行的方式。從某種意義上講，一旦對開發人員來說迭代結束了，對于測試人員迭代就開始了。

測試優先的方法

測試優先的方法在最近五年內受到了相當大的推動。簡單地說，開發人員在撰寫代碼之前要撰寫一個測試。每個分支、循環，或其他邏輯在加入源代碼之前都要寫出將要執行結果的自動化測試。

測試優先主要在構建階段，主要由開發人員執行，而不是測試人員?？梢詫⑵浔M早地引入精化階段，但如您所見到的，強調的不是功能的完整性。

產品化（Transition）階段：管理可接受的風險

驗收測試應該已經是所有測試人員都熟悉的，因此此討論將只涵蓋驗收的重點。

總體上我將定義驗收活動包含部署，以及因此發現的所有問題和缺陷。這是 RUP 在產品化階段所描述的內容，并且測試人員將其理解為驗收的評估。

測試人員在支持項目經理達到項目階段目標上起著關鍵作用。無疑會有大量增加的請求以及低優先級的缺陷，無論哪里，只要可能，這些都應當延遲到新的維護項目中。

評估可接受性

產品化階段中強調的是分辨缺陷并停止項目。不允許新的功能。開發人員有時候稱項目中這一點為“代碼爛泥” —— 換句話說，還沒有“代碼凍結”，因為某些類型的變更還允許出現。

測試人員在發布計劃中起很大作用。這包括測試工作和進度（應該源于最近的構建迭代中獲得的測試工作量度）。預先應該已經確定了，構成缺陷級別和其他量度的可接收的門限是什么。這可能意味著（例如），零關鍵缺陷，只有一個工作區至多一個“高優先級”缺陷，五個“中等”，及許多“低級”的。因此，測試人員可以指定并跟蹤版本候選是否具有適當的質量。

產品化階段將構建階段“開發的”缺陷跟蹤與外部的面對客戶的及服務臺的缺陷跟蹤連結起來。測試版程序的許多優勢之一是該支持及跟蹤機制可以實行。

從理論上講，如果對可交付內容做出了任何變更，都應該執行完整的測試集合。在安全至上的系統中，這很可能成為一個需求，甚至是一個規章。在一般的商業環境中，測試人員可以幫助項目經理決定運行哪個測試子集。這可能包含所有自動化測試、一些手動測試，再加上，比方說，在“實驗室”中的五天時間（也就是，在 MTBF 環境中）。測試人員將使用在其上測試最可能產生失敗的量度。當創建軟件“補丁”時，測試人員履行類似的職責。

數據格式支持、數據轉換，及數據遷移是產品化階段和客戶部署中的重要活動。這些都在測試人員的職責范圍內。有時候，測試人員回顧用戶指導和其他文檔。技術作者執行此任務。

測試、編碼、迭代，和量度

量度已經在我們的討論中表現顯著。測試是量度重要的來源和用戶。當測試進展量度結合開發進展量度時，我們獲得項目狀態及其可能道路的引人注目的全面指示。這些客觀的預測是管理用戶期望，及能夠精確地估算、請求，并防御額外的進度或資源所必要的。

像這些量度在傳統的瀑布過程中是很難收集的。它是迭代生命周期與使收集和應用成為可能的適當測試過程的交匯點。

總結：搖尾巴的狗是好狗

在傳統的開發模型中，直到預定的交付之前的最后“失敗”時刻，測試人員經常作為二等公民。然后，他們成為關鍵的瓶頸，在其中會出現無休止的挑挑揀揀。

RUP 為測試人員提供了另一種觀點。您在其中可以在整個項目中立即做作出貢獻，并且減輕每個人的負擔。

注釋

¹ ISO 是國際標準組織（International Organization for Standardization）的名稱，SEI 是卡內基梅隆大學的軟件工程學院，IEEE 是電子及電氣工程師協會，它為計算行業頒布了多種標準。

² 參看 COCOMO II，了解在估算中應用系數的技術。

³參見 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。