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