測試人員對 RUP 四個階段的貢獻[2] 軟件測試
在完成極端的非功能目標中可能隱含的權衡。
當接近這些極限時各種架構退化的方式。
有了此數據，架構師可以選擇最適當的架構，并且，當涉眾面對他們需求的所有含意時，通常會更愿意調節他們的雄心，并且得到更多的回報。
因此，關鍵的評估需求是其中一個度量，并且這應該是此階段測試人員主要的目標。
量度方法的評估
對于每個技術問題，架構團隊將建立一個或多個具體表現一個解決方案方法的可執行系統�？赡軙腥舾捎懈偁幍慕鉀Q方案(舉例來說，通信中的 UDP 對 TCP)和大量的對于每個解決方案的可配置選擇(舉例來說，進程架構中的 10 線程 對 50 個線程)。測試人員執行對生成架構的度量所必需的步驟。
度量強調的是是否對解決方案有了成熟的考慮而不是功能是否被正確的實現了，因為沒有人會期望生命周期中早期就實現完全正確的功能或者甚至花費大量的精力去雕琢還不成熟的系統的功能。初始階段中指定的許多實驗室環境將在精化階段中被需要。我們將度量性能和可伸縮性，跨過通信鏈接和出自數據庫的數據速率，隨負載變化時的響應時間，并且我們將生成需求所要求的其他度量。根據所有的架構原型執行這些測試，并且測試團隊將與架構師攜手工作，共同設計確認或駁斥每個設計決策的測試。
當傳統測試人員可能會參與整個基于文檔的活動時，測試團隊在此階段的行為與瀑布過程中所做的驚人地不同。當項目從一個危機牽絆到下一個時，許多工作都不相關了。相反，在迭代的項目的精化階段，測試人員在起勁的行動著，被閃光燈和不停的撥號所圍繞。測試人員贊成相關的且實際的測試，使它們與架構師保持一致，并且評估并解釋結果。
當然這是富有挑戰的工作，但同時還是要大量參與的、有價值的，并令人滿意的。如果對于小型的團隊環境及上千行的代碼的情況建立這些測試都是棘手的，那么設想一下對上百萬行的代碼項目的大型團隊來說所受到的阻礙。
雖然這個階段執行測試設計和實現，但是我們應該記住，重要的是測試結果而不是測試文檔。由于將會拋棄許多架構的提議，所以相關的測試也一樣。我們僅需要做足夠的測試設計和實現，用以獲得必需的度量。我們不像細化提議那樣做太多測試，隨著最主要的架構候選的出現，我們可以添加嚴密，如可溯性和其他文檔。
測試設計
作為并行活動，精化階段表現出一次方便的時機來考慮技術架構中的小變更如何能夠更好的幫助測試設計和測試自動化。
通過測試自動化，我的意思是使用記錄鍵盤和鼠標事件的 GUI 記錄或回放工具，可以回放來重復測試。經驗豐富的測試人員知道自動化尤其要求重要的腳本維護工作。值得考慮一下允許腳本構造的“測試架構”，這與設計人員創建“軟件架構”來簡化應用程序構造具有同樣意義。
測試人員應該考慮解決方案，特別是測試可能參數化的方法或映射到需求所暗示的“組合爆炸”的結合方法的復雜性維度。例如，考慮一個指定某個需要支持的平臺組合的非功能需求。根據一個平臺撰寫腳本，在所有平臺上“回放”是有利的。這同樣可以應用到數據庫后端、應用程序服務器、Web 服務器和環境基礎架構的其他元素，并且特別是對于這些的排列組合。手動測試每個組合將是不能忍受的痛苦。測試自動化是唯一經濟的解決方案。
大多數應用程序為測試人員的專長提供許多應用程序專用的機會。設計人員將找到“用參數表示”問題領域的方法，并且這些經常成為類似地用參數表示測試所沿著的維度。例如，在我所工作過的一個應用程序中，有許多看起來一樣的屏幕上的表格，因此設計人員將列參數化為通用的小部件，這給予測試人員類似的能力來用參數表示它們的測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
