在 RUP 軟體開發生命週期中,軟體會經過反覆而趨於精煉。此流程環境中同等的反覆方法有利於測試生命週期。在每次反覆中,軟體開發團隊會產生一或多個建構版本,每一個建構版本都有可能成為測試的對象。
開發團隊的重點和目標在各反覆活動中各有不同。因此,測試團隊成員必須適當地建構測試工作。建議您儘量減少明確、詳細的測試計劃和設計,且在需要的地方,儘量在接近使用時再產生這項成果。我們也建議您不要提前在一次反覆之前解決明確、詳細的測試開發。
每一個建構版本所實作和執行的測試會有所增加、修正及刪除。其中部分測試會保留和累積成大量測試,在未來每一次測試週期中,再於後續建構版本上進行迴歸測試。這種方式在整個流程中會不斷重做和修訂測試,就像修訂軟體本身一樣。沒有一定的軟體規格,也沒有固定的測試。下圖顯示測試如何隨著時間演進。
此反覆方法(配合使用元件架構)要求您必須考慮在每一個後續的建構版本中進行產品品質的迴歸測試。反覆 X 中開發的任何測試很可能成為反覆 X+1 中迴歸測試的對象,以及在反覆 X+2
中,以此類推。如果同樣的測試很可能不斷重複執行,就值得考慮將測試自動化。自動化測試為使用情境的重複測試找出一種方法,可讓測試人員有更多時間來探索新的功能領域。
請查看測試的生命週期,不要考慮專案的測試。下圖顯示「測試」規範在特定反覆中的工作分解細節。
此生命週期和開發團隊其他人的反覆週期一致。「反覆」一開始由測試團隊展開調查,與專案管理人員和關係人商討,確定在後續反覆中要採取什麼最有用的測試工作。多數測試團隊成員會參與這項工作。
如下圖所示,通常每一個反覆至少會有一個測試週期。最常見的作法是每一次反覆時產生多個建構版本,且每一個建構版本各有一個測試週期。不過,有時不會測試特定的建構版本。
在核心測試工作進行時,也會有一部分團隊成員同時在探索新的測試技術。這是為了證明技術可行,特別是在後續的反覆活動中,讓團隊有所依據。
測試生命週期是軟體生命週期的一部分;最初應該有相同的時間範圍。測試的設計與開發,就像軟體產品本身的開發流程一樣,非常複雜又艱鉅。如果無法在第一個可執行的軟體發行之前測試完畢,測試工作將會造成太多問題累積到開發週期最後才發現。這通常會導致開發時程延誤許多時間來修正錯誤,不僅成為目標絆腳石,也折損反覆式開發的美意。
儘早推動測試計劃和定義作業,雖然可以在規格工作中及早發現重大的錯誤和缺陷,但建議您事先慎選測試工作。除了上述可能導致重做的後果,測試團隊也必須小心秉持中立的態度,扮演一個客觀的品質顧問角色,而非像「品質守衛」一樣打亂早期的需求和設計作業。本質上,專案團隊太早嘗試瞭解問題和解決方案範圍有不良的結果。對這種早期工作過度要求品質,很可能導致測試團隊和整個開發群組之間出現疏離的現象。
一個反覆活動中發現的問題可以在此反覆中就地解決,或擱置到下一次反覆時再解決 -
決策最終會落在「專案管理人員」角色上。測試團隊和專案管理人員有一項重要作業是根據「反覆計劃」,驗證是否達成反覆目標,以衡量反覆的完成率。每次反覆會持續進行「需求探索」。這就是您必須小心和事前妥善規劃的問題。
如何執行測試取決於多項因素:
在測試上投資的多寡,取決於在您的特殊環境中如何評估品質和承受風險。
|