軟件測試人員對 RUP 四個階段的貢獻：另一種觀點(4)

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

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

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

　　維護和執行的自動化測試

　　維護和執行的手動測試

　　人造量度集合

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

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

　　測試優先的方法

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

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

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

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

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

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

　　評估可接受性

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

　　測試人員在發布計劃中起很大作用。這包括測試工作和進度(應該源于最近的構建迭代中獲得的測試工作量度)。預先應該已經確定了，構成缺陷級別和其他量度的可接收的門限是什么。這可能意味著(例如)，零關鍵缺陷，只有一個工作區至多一個“高優先級”缺陷，五個“中等”，及許多“低級”的。因此，測試人員可以指定并跟蹤版本候選是否具有適當的質量。

　　產品化階段將構建階段“開發的”缺陷跟蹤與外部的面對客戶的及服務臺的缺陷跟蹤連結起來。測試版程序的許多優勢之一是該支持及跟蹤機制可以實行。

　　從理論上講，如果對可交付內容做出了任何變更，都應該執行完整的測試集合。在安全至上的系統中，這很可能成為一個需求，甚至是一個規章。在一般的商業環境中，測試人員可以幫助項目經理決定運行哪個測試子集。這可能包含所有自動化測試、一些手動測試，再加上，比方說，在“實驗室”中的五天時間(也就是，在 MTBF 環境中)。測試人員將使用在其上測試最可能產生失敗的量度。當創建軟件“補丁”時，測試人員履行類似的職責。

　　數據格式支持、數據轉換，及數據遷移是產品化階段和客戶部署中的重要活動。這些都在測試人員的職責范圍內。有時候，測試人員回顧用戶指導和其他文檔。技術作者執行此任務。

　　測試、編碼、迭代，和量度

　　量度已經在我們的討論中表現顯著。測試是量度重要的來源和用戶。當測試進展量度結合開發進展量度時，我們獲得項目狀態及其可能道路的引人注目的全面指示。這些客觀的預測是管理用戶期望，及能夠精確地估算、請求，并防御額外的進度或資源所必要的。

　　像這些量度在傳統的瀑布過程中是很難收集的。它是迭代生命周期與使收集和應用成為可能的適當測試過程的交匯點。

　　總結：搖尾巴的狗是好狗

　　在傳統的開發模型中，直到預定的交付之前的最后“失敗”時刻，測試人員經常作為二等公民。然后，他們成為關鍵的瓶頸，在其中會出現無休止的挑挑揀揀。

　　RUP 為測試人員提供了另一種觀點。您在其中可以在整個項目中立即做作出貢獻，并且減輕每個人的負擔。

　　注釋

　　1 ISO 是國際標準組織(International Organization for Standardization)的名稱，SEI 是卡內基梅隆大學的軟件工程學院，IEEE 是電子及電氣工程師協會，它為計算行業頒布了多種標準。

　　2 參看 COCOMO II，了解在估算中應用系數的技術。

　　3參見 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。

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