在完成極端的非功能目標(biāo)中可能隱含的權(quán)衡。
當(dāng)接近這些極各種架構(gòu)退化的方式。
有了此數(shù)據(jù)，架構(gòu)師可以選擇最適當(dāng)?shù)募軜?gòu)，并且，當(dāng)涉眾面對他們需求的所有含意時，通常會更愿意調(diào)節(jié)他們的雄心，并且得到更多的回報。
因此，關(guān)鍵的評估需求是其中一個度量，并且這應(yīng)該是此階段測試人員主要的目標(biāo)。
量度方法的評估
對于每個技術(shù)問題，架構(gòu)團(tuán)隊將建立一個或多個具體表現(xiàn)一個解決方案方法的可執(zhí)行系統(tǒng)。可能會有若干有競爭的解決方案（舉例來說，通信中的 UDP 對 TCP）和大量的對于每個解決方案的可配置選擇（舉例來說，進(jìn)程架構(gòu)中的 10 線程 對 50 個線程）。測試人員執(zhí)行對生成架構(gòu)的度量所必需的步驟。
度量強(qiáng)調(diào)的是是否對解決方案有了成熟的考慮而不是功能是否被正確的實現(xiàn)了，因為沒有人會期望生命周期中早期就實現(xiàn)完全正確的功能或者甚至花費大量的精力去雕琢還不成熟的系統(tǒng)的功能。初始階段中指定的許多實驗室環(huán)境將在精化階段中被需要。我們將度量性能和可伸縮性，跨過通信鏈接和出自數(shù)據(jù)庫的數(shù)據(jù)速率，隨負(fù)載變化時的響應(yīng)時間，并且我們將生成需求所要求的其他度量。根據(jù)所有的架構(gòu)原型執(zhí)行這些測試，并且測試團(tuán)隊將與架構(gòu)師攜手工作，共同設(shè)計確認(rèn)或駁斥每個設(shè)計決策的測試。
當(dāng)傳統(tǒng)測試人員可能會參與整個基于文檔的活動時，測試團(tuán)隊在此階段的行為與瀑布過程中所做的驚人地不同。當(dāng)項目從一個危機(jī)牽絆到下一個時，許多工作都不相關(guān)了。相反，在迭代的項目的精化階段，測試人員在起勁的行動著，被閃光燈和不停的撥號所圍繞。測試人員贊成相關(guān)的且實際的測試，使它們與架構(gòu)師保持一致，并且評估并解釋結(jié)果。
當(dāng)然這是富有挑戰(zhàn)的工作，但同時還是要大量參與的、有價值的，并令人滿意的。如果對于小型的團(tuán)隊環(huán)境及上千行的代碼的情況建立這些測試都是棘手的，那么設(shè)想一下對上百萬行的代碼項目的大型團(tuán)隊來說所受到的阻礙。
雖然這個階段執(zhí)行測試設(shè)計和實現(xiàn)，但是我們應(yīng)該記住，重要的是測試結(jié)果而不是測試文檔。由于將會拋棄許多架構(gòu)的提議，所以相關(guān)的測試也一樣。我們僅需要做足夠的測試設(shè)計和實現(xiàn)，用以獲得必需的度量。我們不像細(xì)化提議那樣做太多測試，隨著最主要的架構(gòu)候選的出現(xiàn)，我們可以添加嚴(yán)密，如可溯性和其他文檔。
測試設(shè)計
作為并行活動，精化階段表現(xiàn)出一次方便的時機(jī)來考慮技術(shù)架構(gòu)中的小變更如何能夠更好的幫助測試設(shè)計和測試自動化。
通過測試自動化，我的意思是使用記錄鍵盤和鼠標(biāo)事件的 GUI 記錄或回放工具，可以回放來重復(fù)測試。經(jīng)驗豐富的測試人員知道自動化尤其要求重要的腳本維護(hù)工作。值得考慮一下允許腳本構(gòu)造的“測試架構(gòu)”，這與設(shè)計人員創(chuàng)建“軟件架構(gòu)”來簡化應(yīng)用程序構(gòu)造具有同樣意義。
測試人員應(yīng)該考慮解決方案，特別是測試可能參數(shù)化的方法或映射到需求所暗示的“組合爆炸”的結(jié)合方法的復(fù)雜性維度。例如，考慮一個指定某個需要支持的平臺組合的非功能需求。根據(jù)一個平臺撰寫腳本，在所有平臺上“回放”是有利的。這同樣可以應(yīng)用到數(shù)據(jù)庫后端、應(yīng)用程序服務(wù)器、Web 服務(wù)器和環(huán)境基礎(chǔ)架構(gòu)的其他元素，并且特別是對于這些的排列組合。手動測試每個組合將是不能忍受的痛苦。測試自動化是經(jīng)濟(jì)的解決方案。
大多數(shù)應(yīng)用程序為測試人員的專長提供許多應(yīng)用程序?qū)Ｓ玫臋C(jī)會。設(shè)計人員將找到“用參數(shù)表示”問題領(lǐng)域的方法，并且這些經(jīng)常成為類似地用參數(shù)表示測試所沿著的維度。例如，在我所工作過的一個應(yīng)用程序中，有許多看起來一樣的屏幕上的表格，因此設(shè)計人員將列參數(shù)化為通用的小部件，這給予測試人員類似的能力來用參數(shù)表示它們的測試。
針對測試的設(shè)計在精化階段如此重要的一個原因是在構(gòu)建階段很難找出時間來適當(dāng)處理這一活動。但是有一個甚至更好的理由：通過測試人員和設(shè)計人員之間的良好對話，架構(gòu)中的小讓步可以給測試設(shè)計添加一個大好處。總而言之，精化階段是針對測試而設(shè)計的適當(dāng)時機(jī)。
構(gòu)建（Construction）階段：管理進(jìn)度風(fēng)險
RUP 的構(gòu)建階段瞄準(zhǔn)進(jìn)度風(fēng)險的管理。如果應(yīng)用了 RUP 首選的基于用例的方法，就可以比利用傳統(tǒng)的（瀑布）方法更快地集中于可用的（盡管不完全）系統(tǒng)。當(dāng)達(dá)到這一可用地不完全層次，剩下的路也就不遠(yuǎn)了。
該方法生成了一系列客觀的改進(jìn)的可執(zhí)行系統(tǒng)，并且擁有重要的優(yōu)勢：
在盡可能最早的時候給客戶展示系統(tǒng)的功能。
團(tuán)隊可以及早地獲得部署經(jīng)驗。生成的可執(zhí)行系統(tǒng)可以轉(zhuǎn)化為產(chǎn)品化階段的子集（部分部署）。這使我們獲得產(chǎn)品化階段問題的經(jīng)驗 —— 例如，驗收測試所需要的是什么，如何為部署而打包，以及一百個其他的問題（參見下面的產(chǎn)品化階段）。
我們收集量度，這使得在迭代開發(fā)中可以立即看到項目進(jìn)展。在瀑布過程中，不太可能直接比較分析活動量度和設(shè)計活動量度或編碼活動量度，因為它們是完全不同的活動。但在迭代過程中，比較迭代 1 的量度與迭代 2 的量度更加容易，因為我們在重復(fù)同一組活動。
在幾個星期內(nèi)，我們就會完成一個分析——設(shè)計——編碼——測試的周期，這個給我們一種明顯進(jìn)展的感覺。這就是構(gòu)建階段的迭代的獨特之處。測試活動評估進(jìn)展并驗證確實有了進(jìn)展。
評估進(jìn)展
RUP 提到的迭代節(jié)奏到構(gòu)建階段還是活躍著的，并且該頻率與測試人員有特別的關(guān)系。測試人員的主要目標(biāo)是能夠客觀地描述系統(tǒng)的當(dāng)前狀態(tài)，并且能夠?qū)⒃摖顟B(tài)與以前的狀態(tài)進(jìn)行比較。這兩個狀態(tài)之間的區(qū)別，簡單地說，就是進(jìn)展。
測試人員的“節(jié)奏”源于以下活動。
當(dāng)接近這些極各種架構(gòu)退化的方式。
有了此數(shù)據(jù)，架構(gòu)師可以選擇最適當(dāng)?shù)募軜?gòu)，并且，當(dāng)涉眾面對他們需求的所有含意時，通常會更愿意調(diào)節(jié)他們的雄心，并且得到更多的回報。
因此，關(guān)鍵的評估需求是其中一個度量，并且這應(yīng)該是此階段測試人員主要的目標(biāo)。
量度方法的評估
對于每個技術(shù)問題，架構(gòu)團(tuán)隊將建立一個或多個具體表現(xiàn)一個解決方案方法的可執(zhí)行系統(tǒng)。可能會有若干有競爭的解決方案（舉例來說，通信中的 UDP 對 TCP）和大量的對于每個解決方案的可配置選擇（舉例來說，進(jìn)程架構(gòu)中的 10 線程 對 50 個線程）。測試人員執(zhí)行對生成架構(gòu)的度量所必需的步驟。
度量強(qiáng)調(diào)的是是否對解決方案有了成熟的考慮而不是功能是否被正確的實現(xiàn)了，因為沒有人會期望生命周期中早期就實現(xiàn)完全正確的功能或者甚至花費大量的精力去雕琢還不成熟的系統(tǒng)的功能。初始階段中指定的許多實驗室環(huán)境將在精化階段中被需要。我們將度量性能和可伸縮性，跨過通信鏈接和出自數(shù)據(jù)庫的數(shù)據(jù)速率，隨負(fù)載變化時的響應(yīng)時間，并且我們將生成需求所要求的其他度量。根據(jù)所有的架構(gòu)原型執(zhí)行這些測試，并且測試團(tuán)隊將與架構(gòu)師攜手工作，共同設(shè)計確認(rèn)或駁斥每個設(shè)計決策的測試。
當(dāng)傳統(tǒng)測試人員可能會參與整個基于文檔的活動時，測試團(tuán)隊在此階段的行為與瀑布過程中所做的驚人地不同。當(dāng)項目從一個危機(jī)牽絆到下一個時，許多工作都不相關(guān)了。相反，在迭代的項目的精化階段，測試人員在起勁的行動著，被閃光燈和不停的撥號所圍繞。測試人員贊成相關(guān)的且實際的測試，使它們與架構(gòu)師保持一致，并且評估并解釋結(jié)果。
當(dāng)然這是富有挑戰(zhàn)的工作，但同時還是要大量參與的、有價值的，并令人滿意的。如果對于小型的團(tuán)隊環(huán)境及上千行的代碼的情況建立這些測試都是棘手的，那么設(shè)想一下對上百萬行的代碼項目的大型團(tuán)隊來說所受到的阻礙。
雖然這個階段執(zhí)行測試設(shè)計和實現(xiàn)，但是我們應(yīng)該記住，重要的是測試結(jié)果而不是測試文檔。由于將會拋棄許多架構(gòu)的提議，所以相關(guān)的測試也一樣。我們僅需要做足夠的測試設(shè)計和實現(xiàn)，用以獲得必需的度量。我們不像細(xì)化提議那樣做太多測試，隨著最主要的架構(gòu)候選的出現(xiàn)，我們可以添加嚴(yán)密，如可溯性和其他文檔。
測試設(shè)計
作為并行活動，精化階段表現(xiàn)出一次方便的時機(jī)來考慮技術(shù)架構(gòu)中的小變更如何能夠更好的幫助測試設(shè)計和測試自動化。
通過測試自動化，我的意思是使用記錄鍵盤和鼠標(biāo)事件的 GUI 記錄或回放工具，可以回放來重復(fù)測試。經(jīng)驗豐富的測試人員知道自動化尤其要求重要的腳本維護(hù)工作。值得考慮一下允許腳本構(gòu)造的“測試架構(gòu)”，這與設(shè)計人員創(chuàng)建“軟件架構(gòu)”來簡化應(yīng)用程序構(gòu)造具有同樣意義。
測試人員應(yīng)該考慮解決方案，特別是測試可能參數(shù)化的方法或映射到需求所暗示的“組合爆炸”的結(jié)合方法的復(fù)雜性維度。例如，考慮一個指定某個需要支持的平臺組合的非功能需求。根據(jù)一個平臺撰寫腳本，在所有平臺上“回放”是有利的。這同樣可以應(yīng)用到數(shù)據(jù)庫后端、應(yīng)用程序服務(wù)器、Web 服務(wù)器和環(huán)境基礎(chǔ)架構(gòu)的其他元素，并且特別是對于這些的排列組合。手動測試每個組合將是不能忍受的痛苦。測試自動化是經(jīng)濟(jì)的解決方案。
大多數(shù)應(yīng)用程序為測試人員的專長提供許多應(yīng)用程序?qū)Ｓ玫臋C(jī)會。設(shè)計人員將找到“用參數(shù)表示”問題領(lǐng)域的方法，并且這些經(jīng)常成為類似地用參數(shù)表示測試所沿著的維度。例如，在我所工作過的一個應(yīng)用程序中，有許多看起來一樣的屏幕上的表格，因此設(shè)計人員將列參數(shù)化為通用的小部件，這給予測試人員類似的能力來用參數(shù)表示它們的測試。
針對測試的設(shè)計在精化階段如此重要的一個原因是在構(gòu)建階段很難找出時間來適當(dāng)處理這一活動。但是有一個甚至更好的理由：通過測試人員和設(shè)計人員之間的良好對話，架構(gòu)中的小讓步可以給測試設(shè)計添加一個大好處。總而言之，精化階段是針對測試而設(shè)計的適當(dāng)時機(jī)。
構(gòu)建（Construction）階段：管理進(jìn)度風(fēng)險
RUP 的構(gòu)建階段瞄準(zhǔn)進(jìn)度風(fēng)險的管理。如果應(yīng)用了 RUP 首選的基于用例的方法，就可以比利用傳統(tǒng)的（瀑布）方法更快地集中于可用的（盡管不完全）系統(tǒng)。當(dāng)達(dá)到這一可用地不完全層次，剩下的路也就不遠(yuǎn)了。
該方法生成了一系列客觀的改進(jìn)的可執(zhí)行系統(tǒng)，并且擁有重要的優(yōu)勢：
在盡可能最早的時候給客戶展示系統(tǒng)的功能。
團(tuán)隊可以及早地獲得部署經(jīng)驗。生成的可執(zhí)行系統(tǒng)可以轉(zhuǎn)化為產(chǎn)品化階段的子集（部分部署）。這使我們獲得產(chǎn)品化階段問題的經(jīng)驗 —— 例如，驗收測試所需要的是什么，如何為部署而打包，以及一百個其他的問題（參見下面的產(chǎn)品化階段）。
我們收集量度，這使得在迭代開發(fā)中可以立即看到項目進(jìn)展。在瀑布過程中，不太可能直接比較分析活動量度和設(shè)計活動量度或編碼活動量度，因為它們是完全不同的活動。但在迭代過程中，比較迭代 1 的量度與迭代 2 的量度更加容易，因為我們在重復(fù)同一組活動。
在幾個星期內(nèi)，我們就會完成一個分析——設(shè)計——編碼——測試的周期，這個給我們一種明顯進(jìn)展的感覺。這就是構(gòu)建階段的迭代的獨特之處。測試活動評估進(jìn)展并驗證確實有了進(jìn)展。
評估進(jìn)展
RUP 提到的迭代節(jié)奏到構(gòu)建階段還是活躍著的，并且該頻率與測試人員有特別的關(guān)系。測試人員的主要目標(biāo)是能夠客觀地描述系統(tǒng)的當(dāng)前狀態(tài)，并且能夠?qū)⒃摖顟B(tài)與以前的狀態(tài)進(jìn)行比較。這兩個狀態(tài)之間的區(qū)別，簡單地說，就是進(jìn)展。
測試人員的“節(jié)奏”源于以下活動。