標籤:
首先來說明一下軟體開發生命週期:
軟體開發生命週期又稱為軟體生存周期或系統開發生命週期,是軟體的產生直到報廢的生命週期,周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段,這種按時間分程的思想方法是軟體工程中的一種思想原則,即按部就班、逐步推進,每個階段都要有定義、工作、審查、形成文檔以供交流或備查,以提高軟體的品質。但隨著新的物件導向的設計方法和技術的成熟,軟體生命週期設計方法的指導意義正在逐步減少。 生命週期的每一個周期都有確定的任務,併產生一定規格的文檔(資料),提交給下一個周期作為繼續工作的依據。按照軟體的生命週期,軟體的開發不再只單單強調“編碼”,而是概括了軟體開發的全過程。軟體工程要求每一周期工作的開始只能必須是建立在前一個周期結果“正確”前提上的延續;因此,每一周期都是按“活動 ── 結果 ── 審核 ── 再活動 ── 直至結果正確”迴圈往複進展的。
軟體開發生命週期彆強調了測試在每一個周期中所起到的作用。不管使用了何種生命週期模型對軟體進行開發,軟體都要接受測試。典型的幾種生命週期模型包括瀑布模型、迭代模型、快速原型模型。
瀑布模型:
在該模型中,首先確定需求,並接受客戶和SQA小組的驗證。然後擬定規格說明,同樣通過驗證後,進入計劃階段…可以看出,瀑布模型中至關重要的一點是只有當一個階段的文檔已經編製好並獲得SQA小組的認可才可以進入下一個階段。這樣,瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到,因為整個的模型幾乎都是以文檔驅動的,這對於非專業的使用者來說是難以閱讀和理解的。
迭代模型:
迭代式模型是是RUP(Rational Unified Process,統一軟體開發過程,統一軟體過程)推薦的周期模型,也是我們在這個系列文章討論的基礎。在RUP中,迭代被定義為:迭代包括產生產品發布(穩定、可執行檔產品版本)的全部開發活動和要使用該發布必需的所有其他外圍元素。所以,在某種程度上,開發迭代是一次完整地經過所有工作流程的過程:(至少包括)需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上,它類似小型的瀑布式項目。RUP認為,所有的階段(需求及其它)都可以細分為迭代。每一次的迭代都會產生一個發行就緒的產品,這個產品是最終產品的一個子集。
快速原型模式:
快速原型(Rapid Prototype)模型在功能上等價於產品的一個子集。注意,這裡說的是功能上。瀑布模型的缺點就在於不夠直觀,快速原型法就解決了這個問題。一般來說,根據客戶的需要在很短的時間內解決使用者最迫切需要,完成一個可以示範的產品。這個產品只是實現部分的功能(最重要的)。它最重要的目的是為了確定使用者的真正需求。在我的經驗中,這種方法非常的有效,原先對電腦沒有絲毫概念的使用者在你的原型面前往往口若懸河,有些觀點讓你都覺得非常的吃驚。在得到使用者的需求之後,原型將被拋棄。因為原型開發的速度很快,設計方面是幾乎沒有考慮的,如果保留原型的話,在隨後的開發中會為此付出極大的代價。
軟體開發生命週期模型的發展實際上是體現了軟體工程理論的發展。在最早的時候,軟體的生命週期處於無序、混亂的情況。一些人為了能夠控制軟體的開發過程,就把軟體開發嚴格的區分為多個不同的階段,並在階段間加上嚴格的審查。這就是瀑布模型的起因以及後面的模型的發展的源由。
以軟體開發生命週期來說明不同的測試的使用方式