測試人員對 RUP 四個階段的貢獻[4]

　　測試人員對 RUP 四個階段的貢獻[4]  軟件測試

　　構建迭代測試優先級

　　用例驅動的迭代方法生成了新的機會和新的負擔。因為我們將已經限制阻礙完全測試的資源，所以我們應該根據以下優先級順序執行測試：

　　運行“冒煙測試”。如果冒煙測試通過了，那么：

　　測試那些在此迭代中分辨出的缺陷。

　　測試那些在此迭代中實現的新場景。

　　上面的三項應看作是絕對極小值，并且不能實現它們的應該看作是測試過程的主要失敗。我們應該繼續三個步驟：

　　維護和執行的自動化測試

　　維護和執行的手動測試

　　人造量度集合

　　當然，應該優先選擇不需要維護當前連編的自動化測試。隨著時間的推移，我們應該能夠收集從中可以預計測試工作的量度，例如，維護自動化測試要多少工作，運行手動測試要多少工作，等等。

　　每個項目團隊必須分辨的一個問題是測試活動與開發活動并行的方式。從某種意義上講，一旦對開發人員來說迭代結束了，對于測試人員迭代就開始了。

　　測試優先的方法

　　測試優先的方法在最近五年內受到了相當大的推動。簡單地說，開發人員在撰寫代碼之前要撰寫一個測試。每個分支、循環，或其他邏輯在加入源代碼之前都要寫出將要執行結果的自動化測試。

　　測試優先主要在構建階段，主要由開發人員執行，而不是測試人員?？梢詫⑵浔M早地引入精化階段，但如您所見到的，強調的不是功能的完整性。

　　產品化(Transition)階段：管理可接受的風險

　　驗收測試應該已經是所有測試人員都熟悉的，因此此討論將只涵蓋驗收的重點。

　　總體上我將定義驗收活動包含部署，以及因此發現的所有問題和缺陷。這是 RUP 在產品化階段所描述的內容，并且測試人員將其理解為驗收的評估。

　　測試人員在支持項目經理達到項目階段目標上起著關鍵作用。無疑會有大量增加的請求以及低優先級的缺陷，無論哪里，只要可能，這些都應當延遲到新的維護項目中。

　　評估可接受性

　　產品化階段中強調的是分辨缺陷并停止項目。不允許新的功能。開發人員有時候稱項目中這一點為“代碼爛泥” —— 換句話說，還沒有“代碼凍結”，因為某些類型的變更還允許出現。

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