一.瀑布模型
- 瀑布模型在軟件工程中佔有重要地位，是所有其他模型的基礎框架。
- 瀑布模型的每一個階段都只執行一次，因此是線性順序進行的軟件開發模式。
（1）優點：
- 強調開發的階段性；
- 強調需求分析和早起計劃；
- 強調產品測試。
（2）缺點：
- 依賴於早期進行的唯一一次需求分析，不能適應需求的變化；
- 由於是單一流程，開發中的經驗教訓不能的及時反饋給應用於本產品的過程；
- 風險往往遲至後期的測試階段才顯露，因而失去較早的糾正機會。
瀑布模型的一個大缺陷在於，如果在需求引入的一個缺陷要到測試階段甚至更後的階段才發現，通常會導致前面階段的工作大面積返工。
二.螺旋模型
- 一般在軟件開發初期階段需求不是很明確時，採用漸進式的開發模式。螺旋模型是漸進式開發模型的代表之一。
- 這對於那些規模龐大、複雜度高、風險大的項目尤其適合。這種迭代開發的模式給軟件測試帶來了新的要求，它不允許有一段獨立的測試時間和階段，測試必須跟隨開發的迭代而迭代。因此，迴歸測試就顯得尤爲重要。
（1）優點：
- 強調嚴格的全過程風險分析
- 強調各開發階段的質量
- 提供機會檢討項目是否有價值繼續下去
（2）缺點：
引入非常嚴格的風險識別、風險分析和風險控制，這對風險管理的技能水平提出了很高的要求。這需要人員、資金和時間的投入
三.增量和迭代
- 增量開發能顯著降低項目的風險，結合軟件持續構建機制，構成了當今流行的軟件工程最佳實踐之一。
- 增量開發模型，鼓勵用戶反饋，在每個迭代過程中，促使開發小組以一種循環的、可預測的方式驅動產品的開發。因此，在這種開發模式下，每一次的迭代都意味着可能有需求的更改、構建出新的可執行軟件版本，意味着測試需要頻繁進行，測試人員需要與開發人員更加緊密地協作。
- 增量通常和迭代混爲一談，但是其實兩者是有區別的。增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……而迭代是反覆求精的概念，同樣是畫人物畫，我們可以採用先畫整體輪廓，再勾勒出基本雛形，再細化、着色
四.敏捷開發
- 面對面的溝通（認爲比書面的文檔更有效）
- 頻繁交付新的軟件版本
- 緊湊而自我組織型的團隊
- 能夠很好地適應需求變化的代碼編寫和團隊組織方法
- 更注重軟件開發中人的作用
- 強調程序員團隊與業務專家之間的緊密協作
敏捷的主要貢獻在於他更多地思考了如何去激發開發人員的工作熱情。
敏捷開發的價值觀總括：
個體與交互 重於過程和工具（面對面溝通）
可用的軟件 重於完備的文檔
客戶協作 重於合同談判（強調程序員與業務專家之間的緊密協作）
響應變化 重於遵循計劃（頻繁交付新的軟件版本）
敏捷開發的原則：
1、凝聚人的力量，緊密協（合）作。
2、聚焦客戶價值，消除浪費
3、持續地學習與改進
（1）scrum裏面的角色：
scrum由product owner(產品經理)、scrum master(項目經理)和team(研發團隊)組成。 其中：
- product owner負責整理user story(用戶故事)，定義其商業價值，對其進行排序，制定發佈計劃，對產品負責。
- scrum master 負責召開各種會議，協調項目，爲研發團隊服務。
- 研發團隊則由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品
迭代開發
與瀑布不同，scrum將產品的開發分解爲若干個小sprint(迭代)，其週期從1周到4周不等，但一般不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產生一定的交付。
敏捷中的測試
1.測試工作的核心內客是沒有變的，就是不斷地找Bug，只是要調整好自己的心態，一切以敏捷的原則爲主。
2.測試人員不能依賴文檔，測試用例作用減弱，更多的採用思維導圖、探索性測試（強調自由度，設計和執行同時執行，根據測試結果不斷調整測試計劃）、自動化測試
3.敏捷講求合作，在敏捷項目組中，測試人員應該更主動點，多向開發人員瞭解需求、討論設計、一起研究Bug出現的原因