軟件測試人員對 RUP 四個階段的貢獻：另一種觀點(2)

　　系數將被平臺的數量或所需的其他類型的測試工作副本所修改。

　　缺陷管理、構建，發布過程

　　存在與將測試人員插入開發過程中有關的成本。測試人員共享其他項目團隊使用的特定開發工具，如用于缺陷跟蹤的工具，以及構建和發布工具，如用于配置管理的工具。

　　精化(Elaboration)階段：管理技術風險

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

　　在完成極端的非功能目標中可能隱含的權衡。

　　當接近這些極限時各種架構退化的方式。

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

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

　　量度方法的評估

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

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

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

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

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

　　測試設計

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

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

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

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

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

　　構建(Construction)階段：管理進度風險

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

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

　　在盡可能最早的時候給客戶展示系統的功能。

　　團隊可以及早地獲得部署經驗。生成的可執行系統可以轉化為產品化階段的子集(部分部署)。這使我們獲得產品化階段問題的經驗 —— 例如，驗收測試所需要的是什么，如何為部署而打包，以及一百個其他的問題(參見下面的產品化階段)。

　　我們收集量度，這使得在迭代開發中可以立即看到項目進展。在瀑布過程中，不太可能直接比較分析活動量度和設計活動量度或編碼活動量度，因為它們是完全不同的活動。但在迭代過程中，比較迭代 1 的量度與迭代 2 的量度更加容易，因為我們在重復同一組活動。

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

原文轉自：http://www.kjueaiud.com