軟體的生命周期
軟體生命周期是指從軟體産品的設想開始到軟體不再使用而結束的時間。
如果把軟體看成是有生命的事物，那麼軟體的生命周期可以分成6個階段，即：需求分析、計劃、設計、編碼、測試、運作維護。
瀑布模型
- 瀑布模型在軟體工程中占有重要地位，是所有其他模型的基礎架構。
- 瀑布模型的每一個階段都隻執行一次，是以是線性順序進行的軟體開發模式。
優點：
1. 強調開發的階段性；
2. 強調早期計劃及需求調查；
3. 強調産品測試。
缺點：
1. 依賴于早期進行的唯一一次需求調查，不能适應需求的變化
2. 由于是單一流程，開發中的經驗教訓不能回報應用于本産品的過程；
3. 風險往往遲至後期的測試階段才顯露，因而失去及早糾正的機會。
瀑布模型的一個大缺陷在于，如果在需求引入的一個缺陷要到測試階段甚至更後的階段才發現，通常會導緻前面階段的工作大面積返工。
盡管瀑布模型存在很大的缺陷，例如，在前期階段未發現的錯誤會傳遞并擴散到後面的階段，而在後面階段發現這些錯誤時，可能已經很難回頭再修正，進而導緻項目的失敗。 但是目前很多軟體企業還是沿用了瀑布模型的線性思想，在這個基礎上做出自己的修改。例如細化了各個階段，在某些重點關注的階段之間摻入疊代的思想。
在瀑布模型中，測試階段處于軟體實作後，這意味着必須在代碼完成後有足夠的時間預留給測試活動，否則将導緻測試不充分，進而把缺陷直接遺留給使用者。
螺旋模型（Spiral Model）
一般在軟體開發初期階段需求不是很明确時，采用漸進式的開發模式。螺旋模型是漸進式開發模型的代表之一。
這對于那些規模龐大、複雜度高、風險大的項目尤其适合。這種疊代開發的模式給軟體測試帶來了新的要求，它不允許有一段獨立的測試時間和階段，測試必須跟随開發的疊代而疊代。是以，回歸測試就顯得尤為重要。
優點：
1. 強調嚴格的全過程風險管理
2. 強調各開發階段的品質
3. 提供機會檢讨項目是否有價值繼續下去
缺點：
引入非常嚴格的風險識别、風險分析和風險控制，這對風險管理的技能水準提出了很高的要求。這需要人員、資金和時間的投入
增量、疊代
- 增量開發能顯著降低項目風險，結合軟體持續建構機制，構成了當今流行的軟體工程佳實踐之一
- 增量開發模型，鼓勵使用者回報，在每個疊代過程中，促使開發小組以一種循環的、可預測的方式驅動産品的開發。是以，在這種開發模式下，每一次的疊代都意味着可能有需求的更改、建構出新的可執行軟體版本，意味着測試需要頻繁進行，測試人員需要與開發人員更加緊密地協作。
- 增量通常和疊代混為一談，但是其實兩者是有差別的。增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……而疊代是反複求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再勾勒出基本雛形，再細化、着色
靈活
靈活其實是有關軟體開發的社會工程(Social Engineering)的。靈活的主要貢獻在于他更多地 思考了如何去激發開發人員的工作熱情。
靈活開發有很多種方式，其中scrum是比較流行的一種。
scrum
scrum裡面的角色
scrum由product owner(産品經理)、scrum master(項目經理)和team(研發團隊)組成。 其中：
- product owner負責整理user story(使用者故事)，定義其商業價值，對其進行排序，制定釋出計劃，對産品負責。
- scrum master 負責召開各種會議，協調項目，為研發團隊服務。
- 研發團隊則由不同技能的成員組成，通過緊密協同，完成每一次疊代的目标，傳遞産品
疊代開發
與瀑布不同，scrum将産品的開發分解為若幹個小sprint(疊代)，其周期從1周到4周不等，但一般不會超過4周。參與的團隊成員一般是5到9人。每期疊代要完成的user story是固定的。每次疊代會産生一定的傳遞。
scrum的基本流程
- 産品負責人負責整理user story，形成左側的product backlog。
- 釋出計劃會議：product owner負責講解user story，對其進行估算和排序，釋出計劃會議的産出就是制定出這一期疊代要完成的story清單，sprint backlog。
- 疊代計劃會議：項目團隊對每一個story進行任務分解，分解的标準是完成該story的所有任務，每個任務都有明确的負責人，并完成工時的初估計。
- 每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什麼今天計劃做什麼，有什麼問題。
- 示範會議：疊代結束之後，召開示範會議，相關人員都受邀參加，團隊負責向大家展示本次疊代取得的成果。期間大家的回報記錄下來，由po整理，形成新的story。
- 回顧會議：項目團隊對本期疊代進行總結，發現不足，制定改進計劃，下一次疊代繼續改進，已達到持續改進的效果。
靈活中的測試
- 測試工作的核心内客是沒有變的，就是不斷地找Bug，隻是要調整好自己的心态，一切以靈活的原則為主
- 測試人員不能依賴文檔，測試用例作用減弱，更多的采用思維導圖、探索性測試（強調自由度，設計和執行同時執行，根據測試結果不斷調整測試計劃）、自動化測試
- 靈活講求合作，在靈活項目組中，測試人員應該更主動點，多向開發人員了解需求、讨論設計、一起研究Bug出現的原因
軟體測試V模型
流程如下：
- V模型早是由Paul Rook在20世紀80年代後期提出的，目的是改進軟體開發的效率和效果，是瀑布模型的變種
- 明确的标注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發過程期間各階段的對應關系
- V模型指出，單元和內建測試應檢測程式的執行是否滿足軟體設計的要求；系統測試應檢測系統功能、性能的品質特性是否達到系統要求的名額；驗收測試确定軟體的實作是否滿足使用者需要或合同的要求
- 局限性：僅僅把測試作為在編碼之後的一個階段，未在需求階段就進入測試
軟體測試W模型
流程如下：
可以看出來，W模型增加了軟體各開發階段中應同步進行的驗證和确認活動。
- W模型由兩個V字型模型組成，分别代表測試與開發過程，圖中明确表示出了測試與開發的并行關系。
- W模型特點：測試的對象不僅是程式，需求、設計等同樣要測試，測試與開發是同步進行的