軟件研發模型和軟件測試模型

軟件研發模型和軟件測試模型

筆者：風起怨江南 出處：https://blog.csdn.net/JackMengJin 筆者原創，文章歡迎轉載，如果喜歡請點贊+關注，謝謝支持！

軟件研發模型（Software Development Model）

指軟件開發全過程、活動和任務的結構框架。
意義：使用研發模型可以提高軟件效率，降低研發成本，提高軟件質量。
常見的研發模型包括需求、設計、編碼、測試和維護階段。
軟件開發模型能清晰直觀表達開發全過程，同時也明確規定了要完成的主要活動和任務，故研發模型用來作爲軟件項目工作的基礎。
軟件研發模型有：瀑布模型、快速原型模型、螺旋模型、RUP流程和敏捷模型等。

軟件測試模型（Software Test Model）

意義：軟件測試根據不同的測試對象以及測試項目的背景可採用不同的測試模型實施測試活動。
軟件測試模型有：V模型、W模型、H模型、X模型、敏捷測試模型等。
具體分類如下表所示：

軟件研發模型	軟件測試模型
瀑布模型	V模型
快速原型模型	W模型
螺旋模型	H模型
RUP流程	X模型
敏捷模型	敏捷測試模型

詳細介紹
一.軟件研發模型
1.1 瀑布模型
時間：1970年由溫斯頓.羅伊斯（Winston Royce）提出。
前身：瀑布模型最早根據工業流水線演變過來。
核心思想：按工序將問題化簡，將功能的實現與設計分開，便於分工協作，採用結構化的分析與設計方法將邏輯實現與物理實現分開。

軟件生命週期劃分六個活動，各個活動嚴格按照線性方式進行，當前活動接收上一項活動的工作結果，實施完成所需的工作內容。
當前活動的工作結果需要進行驗證，驗證通過後該結果作爲下一項活動的輸入，繼續進行下一項活動，否則返回修改，直到項目成功。
瀑布模型過於強調文檔的作用，要求每個階段都要仔細驗證，適合一些規模小，需求明確的項目研發。
缺點：
1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加工作量。
2）由於開發模式是線性，用戶只有等到整個過程的末期才能見到開發成果，增加開發風險。
3）而此時活動滯後，導致需要等到開發後期的測試階段才能開始發現問題，不利於項目研發。
4）不能適應用戶需求的變化。
總結：隨着發展，軟件的功能越來越多，瀑布模型已經不再適合現代軟件開發模式，幾乎被業界拋棄。

1.2 快速原型模型（又稱原型模型）
前身：在瀑布模型基礎上演進的一種研發模型，更關注需求的正確性，同時也更加符合開發軟件的習慣。

快速原型模型需要迅速建造一個可以運行的軟件原型，以便使開發人員和用戶儘快確定需求，達成共識，使開發出的軟件能夠真正反應用戶的需求。
原型模型採用逐步求精的方法來完善原型。
總結：從測試角度來看，相比較瀑布模型，測試人員可以在快速原型模型的研發模型期便可以入手，進行測試策略、測試計劃、用例設計等測試工作。

1.3 螺旋模型
時間：1988年由巴利玻姆（Barry Boehm）發表。
特點：將瀑布模型和快速原型模型結合起來，強調了風險分析，適合大型複雜系統。

螺旋模型（Spiral Model）採用週期性方法來進行系統開發。在每一個象限裏使用瀑布模型法（每個週期都包括制定計劃、風險分析、實施工程和客戶評估4個階段，由這4個階段進行迭代），它把軟件項目分解成一個個小項目，每個小項目都標識一個或多個主要風險，直到所有主要風險因素都被確定。
四大象限：
1）制定計劃——確定軟件目標，選定實施方案，弄清項目開發的限制條件。
2）風險分析——分析評估所選方案，由風向專家識別和消除風險。
3）實施工程——實施軟件開發和驗證。
4）客戶評估——評價開發工作，提出修正建議，制定下一步計劃。
缺點：成本過高，商業模式下不採用該模型，但安全係數極高，軍方應用較多。

1.4 RUP流程
RUP（Rational Unified Process），由Rational公司（已被IBM併購）提出的一種統一軟件開發過程。
核心：以用例驅動和體系結構爲核心的增量迭代的軟件過程模式。

關於RUP的2個軸：
橫軸——時間軸，體現了開發過程的動態結構，是過程的生命週期，主要用來描述軟件的週期、階段、迭代和里程碑。
縱軸——工作流，體現開發過程的靜態結構，主要用來描述軟件活動的工作流。
階段：
1）初始化階段——關注整個項目進行中業務和需求方面的主要風險。
2）細化階段——分析問題領域，建立完善的體系結構基礎，編制項目計劃，規避項目中風向較大的元素。爲項目建立支持環境，包括模板、準則和工具。
3）構造階段——開發人員對所有構件和應用程序進行集成，並進行詳細的集成測試。某種意義上說構建階段是一個製造過程，重點放在管理資源及控制運作以優化成本、進度和質量。
4）發佈階段——重點確保軟件對最終用戶是可用的，可以跨越幾次迭代，包括爲發佈作準備的產品測試，基於用戶的反饋進行少量的調整。
工作流：
1）業務建模（Business Modeling）——描述如何爲一個新的目標組織開發一個構想，並給予這個構想在商業用例模型和商業對象模型中定義組織的過程，角色和責任。
2）需求（Requirement）——描述系統應該做什麼，並使開發人員和用戶達成共識。最重要是理解系統所解決問題的定義和範圍。
3）分析和設計（Analysis&Design）——將需求轉化爲系統設計，爲系統開發一個健壯的結構並調整設計使其與實現環境相匹配，並優化其性能。最終生成設計模型和一個可迭代的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。描述主要體現了類的對象如何協同工作實現用例的過程。
4）實現（Implementation）——將層次化的子系統形式定位代碼爲組織結構，以組件的形式（源文件、二進制文件、可執行文件）實現類和對象，將開發出的組件作爲單元進行測試以及集成由單個開發者（或小組）所產生的結構，使其稱爲可執行的系統。
5）測試（Test）——通過可靠性、功能性、系統性能（三維模型）進行測試。在整個項目中進行測試，儘早發現缺陷。
6）部署（Depoyment）——描述了與確保軟件產品對用戶具有可用性相關的活動，包括：軟件打包、安裝軟件、爲用戶提供幫助。也包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。
7）配置和變更管理（Configuration&Chagement）——工作流描述瞭如何管理並行開發、分佈式開發以及自動化創建工程。
8）項目管理（Project Management）——平衡各個部門之間可能產生衝突的目標，客服約束並成功交付用戶滿意的產品。目標包括爲項目管理提供框架，爲計劃、人員配備、執行和監控項目提供實用準則，爲管理風險提供框架。
9）環境管理（Environment Management）——該工作流向軟件開發提供軟件開發環境，集中配置和支持項目過程中需要的活動，提供指導手冊並介紹如何在組織中實現過程管理。

1.5 敏捷模型
時間：2001年，敏捷聯盟成立，提出敏捷開發的概念。
核心：敏捷開發以用戶的需求進化爲核心，採用迭代、循序漸進的方法進行軟件開發。
敏捷開發中一個大項目分爲多個相互聯繫且可以獨自運行的小項目，分別完成。此過程中軟件一直處於可使用狀態。
宣言：儘早的、持續的交付有價值的軟件來使客戶滿意。

原則：
1）快速迭代——敏捷中版本發佈更快，採用小版本，需求、開發和測試更加簡單快速。
2）測試人員和開發者參與需求討論——以研討會的形式定義可測試的需求並確定需求優先級，優點是可以充分利用團隊成員間互補特性，提高效率。
3）編寫可測試的需求文檔——站在用戶的角度編寫需求文檔，不能過早涉及技術實施方案，否則會降低對需求的注意力。
4）多溝通，減少文檔——面對面溝通效率遠遠大於郵件效果。
5）做好產品原型——圖解模型。
6）及早考慮測試——提早設計編寫測試用例，測試在敏捷開發中及其重要。

二.軟件測試模型
2.1V模型
V模型也稱爲RAD（Rap Application Development，快速應用開發，簡稱RAD），模型構圖形似字母V。
V模型通過開發和測試同時進行的方式來縮短開發週期，提高開發效率。
時間：20世紀80年代由PaulRook提出。

V模型中的過程從左到右，描述了基本的開發過程和測試行爲。
核心：V模型的價值在於它強調軟件開發的協作和速度，反映測試活動和分析設計關係，將軟件實現和驗證結合起來。明確了測試過程中存在不同的級別，並清楚描述測試的各個階段與開發過程中的各個階段之間的對應關係。
缺點：測試過程在編碼之後，需求分析前期產生的錯誤要到後期的驗證測試才能發現，忽略了測試活動對需求分析、系統設計等活動的驗證和確認。
總結：V模型適用於項目比較小、週期短的項目，該模式已漸漸被淘汰。

2.2 W模型
前身：V模型，由Evolutif公司提出。
新增：增加軟件開發各階段中同步進行的驗證和確認活動。
W模型由兩個V組成，分別代表開發和測試過程，明確稟明開發和測試的並行關係。

W模型就是V&V模型，即驗證（Verification）和確認（Validation），是在模型實施過程中進行。
定義：W模型就是驗證是否做了正確的事情和確認是否把事情做正確。
1）驗證——保證軟件正確實現特定功能，驗證是否滿足軟件生命週期過程中的標準和約定，判斷每一個軟件生命週期活動是否完成。
2）確認——保證所生產的軟件可追溯到用戶需求，確認過程是否滿足系統需求，解決相應問題。
遵循：要求測試活動從用戶需求介入，測試人員應該參與到對需求文檔的驗證和確定活動中，以儘早找到缺陷所在。
需求：對需求的測試有利於及時瞭解項目難度和測試風險，及早制定應多措施，這將逐漸減少總體測試時間，加快項目進度，有利於儘早地發現問題。
缺點：在W模型中，需求、設計、編碼等活動被視爲串行，同時測試和開發活動也保持着一種線性的前後關係，上一階段完全結束後，纔可正式開始下一個階段工作，無法支持迭代開發模式。
總結：W模型測試伴隨整個軟件開發週期，被測對象不僅僅是程序，需求，設計以及每個階段輸出的文檔同樣需要測試，也就是說測試與開發是同步進行。

2.3 H模型
定義：H模型的軟件測試活動是完全獨立的，將測試準備和測試執行分離。
優點：有利於資源調配，降低成本，提高測試效率。

準備：測試需求分析、測試計劃、測試設計、測試用例、測試驗證。
執行：測試運行、測試報告、缺陷分析、迴歸測試。
總結：H模型貫穿整個產品生命週期，與其他流程併發進行。只要某個測試達到準備就緒點就可以開展測試執行活動，不同的測試活動可按照次序先後，反覆進行。

2.4 X模型
前身：有Marick提出，Robin F.Goldsmith將其思想定義爲X模型。
X模型左邊描述是針對單獨程序片段所進行的相互分離的編碼和測試，通過頻繁交接，最終集成爲可執行的程序，再對這些可執行的程序進行測試。
理念：探索性測試，不進行實現計劃的特殊類型測試，發散性測試。
優點：能發現更多測試計劃之外的錯誤。
缺點：對測試人員要求極高，時間、人力、物力等成本增加。

2.5 敏捷測試模型
敏捷測試（Agile Testing）通過不斷修正質量指標，正確建立測試策略，確認客戶有效需求來保證產品質量。
定義：敏捷測試遵循測試實踐，強調從客戶角度（從使用系統用戶角度）來測試系統。

敏捷測試主旨：測試驅動開發。
對測試人員要求：
1）理解敏捷的核心價值觀：溝通、反饋、尊重、學習、分享。
2）具備測試基本技能，如自動化測試、白盒測試等。

說明：本文由作者參考學習《軟件測試技術指南》等相關資料編寫，供大家學習交流。