以軟件開發生命週期來講明不一樣的測試的使用狀況

　　首先來講明一下軟件開發生命週期：

　　軟件開發生命週期又稱爲軟件生存週期或系統開發生命週期，是軟件的產生直到報廢的生命週期，週期內有問題定義、可行性分析、整體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟件工程中的一種思想原則，即循序漸進、逐步推動，每一個階段都要有定義、工做、審查、造成文檔以供交流或備查，以提升軟件的質量。但隨着新的面向對象的設計方法和技術的成熟，軟件生命週期設計方法的指導意義正在逐步減小。 生命週期的每個週期都有肯定的任務，併產生必定規格的文檔（資料），提交給下一個週期做爲繼續工做的依據。按照軟件的生命週期，軟件的開發再也不只單單強調「編碼」，而是歸納了軟件開發的全過程。軟件工程要求每一週期工做的開始只能必須是創建在前一個週期結果「正確」前提上的延續；所以，每一週期都是按「活動 ── 結果 ── 審覈 ── 再活動 ── 直至結果正確」循環往復進展的。

　　軟件開發生命週期彆強調了測試在每個週期中所起到的做用。無論使用了何種生命週期模型對軟件進行開發，軟件都要接受測試。典型的幾種生命週期模型包括瀑布模型、迭代模型、快速原型模型。

　　瀑布模型：

　　在該模型中，首先肯定需求，並接受客戶和SQA小組的驗證。而後擬定規格說明，一樣經過驗證後，進入計劃階段…能夠看出，瀑布模型中相當重要的一點是隻有當一個階段的文檔已經編制好並得到SQA小組的承認才能夠進入下一個階段。這樣，瀑布模型經過強制性的要求提供規約文檔來確保每一個階段都能很好的完成任務。可是實際上每每難以辦到，由於整個的模型幾乎都是以文檔驅動的，這對於非專業的用戶來講是難以閱讀和理解的。

　　迭代模型：

　　迭代式模型是是RUP（Rational Unified Process，統一軟件開發過程，統一軟件過程)推薦的週期模型，也是咱們在這個系列文章討論的基礎。在RUP中，迭代被定義爲：迭代包括產生產品發佈（穩定、可執行的產品版本）的所有開發活動和要使用該發佈必需的全部其餘外圍元素。因此，在某種程度上，開發迭代是一次完整地通過全部工做流程的過程：（至少包括）需求工做流程、分析設計工做流程、實施工做流程和測試工做流程。實質上，它相似小型的瀑布式項目。RUP認爲，全部的階段（需求及其它）均可以細分爲迭代。每一次的迭代都會產生一個能夠發佈的產品，這個產品是最終產品的一個子集。

　　快速原型模式：

　　快速原型（Rapid Prototype）模型在功能上等價於產品的一個子集。注意，這裏說的是功能上。瀑布模型的缺點就在於不夠直觀，快速原型法就解決了這個問題。通常來講，根據客戶的須要在很短的時間內解決用戶最迫切須要，完成一個能夠演示的產品。這個產品只是實現部分的功能（最重要的）。它最重要的目的是爲了肯定用戶的真正需求。在個人經驗中，這種方法很是的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前每每滔滔不絕，有些觀點讓你都以爲很是的吃驚。在獲得用戶的需求以後，原型將被拋棄。由於原型開發的速度很快，設計方面是幾乎沒有考慮的，若是保留原型的話，在隨後的開發中會爲此付出極大的代價。

　　軟件開發生命週期模型的發展其實是體現了軟件工程理論的發展。在最先的時候，軟件的生命週期處於無序、混亂的狀況。一些人爲了可以控制軟件的開發過程，就把軟件開發嚴格的區分爲多個不一樣的階段，並在階段間加上嚴格的審查。這就是瀑布模型的原由以及後面的模型的發展的源由。