需求

• 用戶需求：沒有經過合理的評估，通常就是一句話

• 軟件需求：是開發人員和測試人員執行工作的依據

用戶的需求不能直接作為開發和測試的依據。針對用戶的需求，產品經理需要進行需求分析(技術可行性、市場可行性、成本投入和收益占比等)后才可轉變為軟件需求。

開發模型

規范的流程是在時代的演變下逐漸成型，并不是一開始就是規范的流程

軟件生命周期

• 軟件生命周期實際就是軟件的開發模型（認識具體的開發模型之前先了解軟件的生命周期）

需求的開始是軟件生命的起點，中間會經歷需求的計劃、設計程序開發，程序測試等階段，直至軟件不再進行維護便到了生命的重點

• 軟件流程：需求分析、計劃、設計、編碼、測試、運行維護
• 開發:設計開發文檔(用什么技術、用什么框架等等)
• 測試:明確需求，設計測試用例、測試計劃(明確本次測試設計到的工具、設計到的測試類型…)
• 運行維護：軟件上線之后，在線上環境使用下可能會出現一些意向不到的情況

修復性維護:對項目中未發現的問題進行修復。
完善性維護:對功能進行完善。
預防性維護:居安思危，為了避免產品在線上出現一些其他不可預料的問題，進行一些防護的手段。
正常使用沒有問題，但是在極端的情況下會出現問題(性能問題)

軟件的通用流程

階段	具體內容	產出
需求分析	分析用戶需求是否合理，分別從市場需求、技術等方面進行分析。	該階段會輸出需求等文檔。
計劃	對成立的需求執行需求執行計劃，多長時間內完成該需求，每段時間具體完成哪些功能。	該階段會輸出計劃等文檔。
設計	將需求細化成一個個任務，團隊成員各司其職領取任務并進行技術設計(如何進行架構設計，設計哪些接口、采用什么技術)	該階段會輸出技術等文檔。
編碼	開發人員參考需求文檔、設計文檔、交互圖等等文件進行代碼的編寫。	代碼文件等文檔。
測試	測試人員需要介入到軟件的測試中來，參考測試用例對軟件進行測試	測試用例、測試設計與計
運行維護	項目測試結束之后，項目需要進行上線，并對產品進行線上的維護。線上的維護主要分為三個方面。分別為修復性維護、完善性維護和預防性維護。

瀑布模型

瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎框架。瀑布模型的每一個階段都只執行一次，因此是線性順序進行的軟件開發模式。

優點/特點

1. 強調開發的階段性
2. 線性結構，每個階段只執行一次
3. 是其他模型的基礎框架

缺點

1. 測試后置

• 前面各階段遺留的風險推遲到測試階段才被發現，導致項目大面積。返工，失去了及早修復的機會
• 必須留有足夠的時間給測試活動，否則導致測試不充分，將缺陷直接暴露給用戶(產品質量差)

2. 周期太長，產品很遲才能被看到和使用，可能會導致需求/功能過時

瀑布模型的適用場景:需求固定的小項目

螺旋模型

螺旋模型中各個階段都引入的風險分析+原型
引入的目的是減少各階段遺留的風險問題，避免把問題留到后面的階段
優點

1. 強調嚴格的全過程風險管理
2. 強調各開發階段的質量
3. 增加風險分析和原型

缺點

1. 項目中可能存在的風險性與風險管理人員的技能水平有直接關系
2. 需求人員、資金、時間的增加和投入，可能會導致項目的成本太高

適用場景:規模龐大、復雜度高、風險大的項目。

增量模型、迭代模型

• 增量模型：將大需求拆分成小需求，每個小需求獨立開發上線
  
• 迭代模型：基礎板本->優化版本1->優化版本2->……
• 增量模型將一個大的需求修改成多個小功能，每個功能獨立開發上線
• 迭代模型會上線一個基礎版本，但是基礎版本所有的功能都有只不過功能比較簡陋，后期再繼續迭代優化上線

增量是逐塊建造的概念，迭代是反復求精的概念。

迭代模型和增量模型在現在已經不會單獨去使用，而是配合著去使用

適用場景:大型項目，需求不明確

敏捷模型

克服在項目開發期間處理來自客戶的變更請求以及合并這些變更所需的高成本和時間。

• 敏捷模型主要旨在幫助項目快速適應變更請求。因此，敏捷模型的主要目的是促進項目的快速完成。
• 敏捷性是通過使過程適應項目，刪除對特定項目可能不是必需的活動來實現的。此外，避免任何浪費時間和精力的事情。
• 在敏捷模型中，需求被分解成許多可以增量開發的小部分。
• 敏捷模型采用迭代開發。每個增量部分都是在迭代中開發的。每次迭代都旨在小而易于管理，并且只能在幾周內完成。
• 一次為客戶計劃、開發和部署一個迭代。沒有制定長期計劃。

《敏捷宣言》

1. 個體與交互重于過程和工具

強調高效的溝通

2. 可用的軟件重于完備的文檔

強調輕文檔，文檔不應該作為工作驗收的標準

3. 客戶協作重于合同談判

主動及時了解當下的需求

4. 響應變化重于遵循計劃

能夠主動迎接變化

敏捷模型的四個特點:輕文檔，輕流程，重自標，重產出

Scrum

• Scrum是敏捷模型中的一種，又稱為迭代式增量軟件開發模型。
• 在scrum模型中，主要有三個角色和五個重要會議。
• 三個角色不是指三個人，而是三類角色

三個角色:scrum由product owner(產品經理)、scrum master(項目經理)和team(研發團隊)組成。

1. product owner負責整理userstory(用戶故事)，定義其商業價值，對其進行排序，制定發布計劃，對產品負責。

產品經理收集需求，產出軟件需求文檔

2. scrum master負責召開各種會議，協調項目為研發團隊服務。
3. 研發團隊則由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品。

由很多角色組成:開發人員(前端、后端)、測試、交互、設計……

迭代開發：scrum將產品的開發分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的userstorv是固定的。每次迭代會產生一定的交付。

Scrum的流程

• 產品負責人負責整理user story，形成product backlog。
• 發布計劃會議:product owner負責講解user story，對其進行估算和排序，發布計劃會議的產出就是制定出這一期迭代要完成的story列表，sprint backlog。
• 迭代計劃會議:項目團隊對每一個story進行任務分解，分解的標準是完成該story的所有任務，每個任務都有明確的負責人，并完成工時的初估計。
• 每日例會:每天scrum master召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。
• 演示會議:迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取期間大家的反饋記錄下來，由po整理，形成新的story。得的成果。
• 回顧會議:項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次選代繼續改進，以達到持續改進的效果。

敏捷中的測試
輕文檔和快速迭代

• 敏捷模型中強調輕文檔，所以測試人員不應使用傳統的Excel編寫測試用例的方法，更多的是0使用思維導圖、探索性測試(強調自由度，設計和執行同時進行，根據測試結果不斷調整測試計劃)、自動化測試等

輕文檔：測試用例、測試計劃文檔、測試報告……

• 敏捷講求合作，在敏捷項目組中，測試人員應多主動跟開發人員了解需求、討論設計、一起研究bug出現的原因。

測試模型

V模型

V模型：目的是改進軟件開發的效率和效果。是瀑布模型的變種。

優點:

1. 明確的標注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發過程期間各階段的對應關系，有效提升測試的質量和效率。
2. V模型指出:
   單元和集成測試應檢測程序的執行是否滿足軟件設計的要求
   系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標
   驗收測試確定軟件的實現是否滿足用戶需要或合同的要求

缺點:僅僅把測試作為在編碼之后的一個階段，未在需求階段就介入測試。缺點同瀑布模型。

W模型（雙V模型）

開發V模型并不是單單指編碼階段，而是為產品開發流程而實施的各個階段
特點:測試的對象不僅是程序，需求、設計等同樣要測試，測試與開發是同步進行的

優點：有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險及早制定應對措施，顯著減少總體測試時間，加快項目進度。
缺點:

1. 需求、設計、編碼等活動被視為串行的;
2. 測試和開發活動也保持著一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。
3. 重流程，無法支持敏捷開發模式。對于當前軟件開發復雜多變的情況，W模型并不能解除測試管理面臨著困惑。