構(gòu)建迭代測試優(yōu)先級
用例驅(qū)動的迭代方法生成了新的機會和新的負擔(dān)。因為我們將已經(jīng)限制阻礙完全測試的資源，所以我們應(yīng)該根據(jù)以下優(yōu)先級順序執(zhí)行測試：
運行“冒煙測試”。如果冒煙測試通過了，那么：
測試那些在此迭代中分辨出的缺陷。
測試那些在此迭代中實現(xiàn)的新場景。
上面的三項應(yīng)看作是絕對極小值，并且不能實現(xiàn)它們的應(yīng)該看作是測試過程的主要失敗。我們應(yīng)該繼續(xù)三個步驟：
維護和執(zhí)行的自動化測試
維護和執(zhí)行的手動測試
人造量度集合
當(dāng)然，應(yīng)該優(yōu)先選擇不需要維護當(dāng)前連編的自動化測試。隨著時間的推移，我們應(yīng)該能夠收集從中可以預(yù)計測試工作的量度，例如，維護自動化測試要多少工作，運行手動測試要多少工作，等等。
每個項目團隊必須分辨的一個問題是測試活動與開發(fā)活動并行的方式。從某種意義上講，一旦對開發(fā)人員來說迭代結(jié)束了，對于測試人員迭代就開始了。
測試優(yōu)先的方法
測試優(yōu)先的方法在最近五年內(nèi)受到了相當(dāng)大的推動。簡單地說，開發(fā)人員在撰寫代碼之前要撰寫一個測試。每個分支、循環(huán)，或其他邏輯在加入源代碼之前都要寫出將要執(zhí)行結(jié)果的自動化測試。
測試優(yōu)先主要在構(gòu)建階段，主要由開發(fā)人員執(zhí)行，而不是測試人員。可以將其盡早地引入精化階段，但如您所見到的，強調(diào)的不是功能的完整性。
產(chǎn)品化（Transition）階段：管理可接受的風(fēng)險
驗收測試應(yīng)該已經(jīng)是所有測試人員都熟悉的，因此此討論將只涵蓋驗收的重點。
總體上我將定義驗收活動包含部署，以及因此發(fā)現(xiàn)的所有問題和缺陷。這是 RUP 在產(chǎn)品化階段所描述的內(nèi)容，并且測試人員將其理解為驗收的評估。
測試人員在支持項目經(jīng)理達到項目階段目標(biāo)上起著關(guān)鍵作用。無疑會有大量增加的請求以及低優(yōu)先級的缺陷，無論哪里，只要可能，這些都應(yīng)當(dāng)延遲到新的維護項目中。
評估可接受性
產(chǎn)品化階段中強調(diào)的是分辨缺陷并停止項目。不允許新的功能。開發(fā)人員有時候稱項目中這一點為“代碼爛泥” —— 換句話說，還沒有“代碼凍結(jié)”，因為某些類型的變更還允許出現(xiàn)。
測試人員在發(fā)布計劃中起很大作用。這包括測試工作和進度（應(yīng)該源于最近的構(gòu)建迭代中獲得的測試工作量度）。預(yù)先應(yīng)該已經(jīng)確定了，構(gòu)成缺陷級別和其他量度的可接收的門限是什么。這可能意味著（例如），零關(guān)鍵缺陷，只有一個工作區(qū)至多一個“高優(yōu)先級”缺陷，五個“中等”，及許多“低級”的。因此，測試人員可以指定并跟蹤版本候選是否具有適當(dāng)?shù)馁|(zhì)量。
產(chǎn)品化階段將構(gòu)建階段“開發(fā)的”缺陷跟蹤與外部的面對客戶的及服務(wù)臺的缺陷跟蹤連結(jié)起來。測試版程序的許多優(yōu)勢之一是該支持及跟蹤機制可以實行。
從理論上講，如果對可交付內(nèi)容做出了任何變更，都應(yīng)該執(zhí)行完整的測試集合。在安全至上的系統(tǒng)中，這很可能成為一個需求，甚至是一個規(guī)章。在一般的商業(yè)環(huán)境中，測試人員可以幫助項目經(jīng)理決定運行哪個測試子集。這可能包含所有自動化測試、一些手動測試，再加上，比方說，在“實驗室”中的五天時間（也就是，在 MTBF 環(huán)境中）。測試人員將使用在其上測試最可能產(chǎn)生失敗的量度。當(dāng)創(chuàng)建軟件“補丁”時，測試人員履行類似的職責(zé)。
數(shù)據(jù)格式支持、數(shù)據(jù)轉(zhuǎn)換，及數(shù)據(jù)遷移是產(chǎn)品化階段和客戶部署中的重要活動。這些都在測試人員的職責(zé)范圍內(nèi)。有時候，測試人員回顧用戶指導(dǎo)和其他文檔。技術(shù)作者執(zhí)行此任務(wù)。
測試、編碼、迭代，和量度
量度已經(jīng)在我們的討論中表現(xiàn)顯著。測試是量度重要的來源和用戶。當(dāng)測試進展量度結(jié)合開發(fā)進展量度時，我們獲得項目狀態(tài)及其可能道路的引人注目的全面指示。這些客觀的預(yù)測是管理用戶期望，及能夠精確地估算、請求，并防御額外的進度或資源所必要的。
像這些量度在傳統(tǒng)的瀑布過程中是很難收集的。它是迭代生命周期與使收集和應(yīng)用成為可能的適當(dāng)測試過程的交匯點。
總結(jié)：搖尾巴的狗是好狗
在傳統(tǒng)的開發(fā)模型中，直到預(yù)定的交付之前的最后“失敗”時刻，測試人員經(jīng)常作為二等公民。然后，他們成為關(guān)鍵的瓶頸，在其中會出現(xiàn)無休止的挑挑揀揀。
RUP 為測試人員提供了另一種觀點。您在其中可以在整個項目中立即做作出貢獻，并且減輕每個人的負擔(dān)。
注釋
1 ISO 是國際標(biāo)準(zhǔn)組織（International Organization for Standardization）的名稱，SEI 是卡內(nèi)基梅隆大學(xué)的軟件工程學(xué)院，IEEE 是電子及電氣工程師協(xié)會，它為計算行業(yè)頒布了多種標(biāo)準(zhǔn)。
2 參看 COCOMO II，了解在估算中應(yīng)用系數(shù)的技術(shù)。
3參見 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。
用例驅(qū)動的迭代方法生成了新的機會和新的負擔(dān)。因為我們將已經(jīng)限制阻礙完全測試的資源，所以我們應(yīng)該根據(jù)以下優(yōu)先級順序執(zhí)行測試：
運行“冒煙測試”。如果冒煙測試通過了，那么：
測試那些在此迭代中分辨出的缺陷。
測試那些在此迭代中實現(xiàn)的新場景。
上面的三項應(yīng)看作是絕對極小值，并且不能實現(xiàn)它們的應(yīng)該看作是測試過程的主要失敗。我們應(yīng)該繼續(xù)三個步驟：
維護和執(zhí)行的自動化測試
維護和執(zhí)行的手動測試
人造量度集合
當(dāng)然，應(yīng)該優(yōu)先選擇不需要維護當(dāng)前連編的自動化測試。隨著時間的推移，我們應(yīng)該能夠收集從中可以預(yù)計測試工作的量度，例如，維護自動化測試要多少工作，運行手動測試要多少工作，等等。
每個項目團隊必須分辨的一個問題是測試活動與開發(fā)活動并行的方式。從某種意義上講，一旦對開發(fā)人員來說迭代結(jié)束了，對于測試人員迭代就開始了。
測試優(yōu)先的方法
測試優(yōu)先的方法在最近五年內(nèi)受到了相當(dāng)大的推動。簡單地說，開發(fā)人員在撰寫代碼之前要撰寫一個測試。每個分支、循環(huán)，或其他邏輯在加入源代碼之前都要寫出將要執(zhí)行結(jié)果的自動化測試。
測試優(yōu)先主要在構(gòu)建階段，主要由開發(fā)人員執(zhí)行，而不是測試人員。可以將其盡早地引入精化階段，但如您所見到的，強調(diào)的不是功能的完整性。
產(chǎn)品化（Transition）階段：管理可接受的風(fēng)險
驗收測試應(yīng)該已經(jīng)是所有測試人員都熟悉的，因此此討論將只涵蓋驗收的重點。
總體上我將定義驗收活動包含部署，以及因此發(fā)現(xiàn)的所有問題和缺陷。這是 RUP 在產(chǎn)品化階段所描述的內(nèi)容，并且測試人員將其理解為驗收的評估。
測試人員在支持項目經(jīng)理達到項目階段目標(biāo)上起著關(guān)鍵作用。無疑會有大量增加的請求以及低優(yōu)先級的缺陷，無論哪里，只要可能，這些都應(yīng)當(dāng)延遲到新的維護項目中。
評估可接受性
產(chǎn)品化階段中強調(diào)的是分辨缺陷并停止項目。不允許新的功能。開發(fā)人員有時候稱項目中這一點為“代碼爛泥” —— 換句話說，還沒有“代碼凍結(jié)”，因為某些類型的變更還允許出現(xiàn)。
測試人員在發(fā)布計劃中起很大作用。這包括測試工作和進度（應(yīng)該源于最近的構(gòu)建迭代中獲得的測試工作量度）。預(yù)先應(yīng)該已經(jīng)確定了，構(gòu)成缺陷級別和其他量度的可接收的門限是什么。這可能意味著（例如），零關(guān)鍵缺陷，只有一個工作區(qū)至多一個“高優(yōu)先級”缺陷，五個“中等”，及許多“低級”的。因此，測試人員可以指定并跟蹤版本候選是否具有適當(dāng)?shù)馁|(zhì)量。
產(chǎn)品化階段將構(gòu)建階段“開發(fā)的”缺陷跟蹤與外部的面對客戶的及服務(wù)臺的缺陷跟蹤連結(jié)起來。測試版程序的許多優(yōu)勢之一是該支持及跟蹤機制可以實行。
從理論上講，如果對可交付內(nèi)容做出了任何變更，都應(yīng)該執(zhí)行完整的測試集合。在安全至上的系統(tǒng)中，這很可能成為一個需求，甚至是一個規(guī)章。在一般的商業(yè)環(huán)境中，測試人員可以幫助項目經(jīng)理決定運行哪個測試子集。這可能包含所有自動化測試、一些手動測試，再加上，比方說，在“實驗室”中的五天時間（也就是，在 MTBF 環(huán)境中）。測試人員將使用在其上測試最可能產(chǎn)生失敗的量度。當(dāng)創(chuàng)建軟件“補丁”時，測試人員履行類似的職責(zé)。
數(shù)據(jù)格式支持、數(shù)據(jù)轉(zhuǎn)換，及數(shù)據(jù)遷移是產(chǎn)品化階段和客戶部署中的重要活動。這些都在測試人員的職責(zé)范圍內(nèi)。有時候，測試人員回顧用戶指導(dǎo)和其他文檔。技術(shù)作者執(zhí)行此任務(wù)。
測試、編碼、迭代，和量度
量度已經(jīng)在我們的討論中表現(xiàn)顯著。測試是量度重要的來源和用戶。當(dāng)測試進展量度結(jié)合開發(fā)進展量度時，我們獲得項目狀態(tài)及其可能道路的引人注目的全面指示。這些客觀的預(yù)測是管理用戶期望，及能夠精確地估算、請求，并防御額外的進度或資源所必要的。
像這些量度在傳統(tǒng)的瀑布過程中是很難收集的。它是迭代生命周期與使收集和應(yīng)用成為可能的適當(dāng)測試過程的交匯點。
總結(jié)：搖尾巴的狗是好狗
在傳統(tǒng)的開發(fā)模型中，直到預(yù)定的交付之前的最后“失敗”時刻，測試人員經(jīng)常作為二等公民。然后，他們成為關(guān)鍵的瓶頸，在其中會出現(xiàn)無休止的挑挑揀揀。
RUP 為測試人員提供了另一種觀點。您在其中可以在整個項目中立即做作出貢獻，并且減輕每個人的負擔(dān)。
注釋
1 ISO 是國際標(biāo)準(zhǔn)組織（International Organization for Standardization）的名稱，SEI 是卡內(nèi)基梅隆大學(xué)的軟件工程學(xué)院，IEEE 是電子及電氣工程師協(xié)會，它為計算行業(yè)頒布了多種標(biāo)準(zhǔn)。
2 參看 COCOMO II，了解在估算中應(yīng)用系數(shù)的技術(shù)。
3參見 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。