什么是需求？

滿足用戶期望或正式規定文檔（合同、標準、規范）所具有的條件和權能，包含用戶需求和軟件需求。

用戶需求

用戶需求：可以簡單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產品時必須要完成的任務。該需求一般比較簡略，通常是一句話。

??的需求是五花??，往往只是?句話?如：實現?個聲控燈，實現?個軟件的登錄功能。

軟件需求

軟件需求：或者叫功能需求，該需求會詳細描述開發人員必須實現的軟件功能。 軟件需求是測試人員進行測試工作的基本依據。

用戶需求和軟件需求的不同

案例一：?朋友餓了的例?

• ??需求：?朋友說：我餓了。這是?個??需求，很簡略。
• 軟件需求：需要你和她反復溝通，了解更加詳細具體的需求來制定解決?案。
  • ?如你問她：“想吃啥?”，她說：“隨便”
  • “吃?飯炒菜？”，“不想吃”；“那你想吃啥？”，“隨便”
  • “吃油潑?？”，“不想吃”；“那你想吃啥？”，“隨便”
  • …
  • 最終理解清楚??需求之后，知道?朋友想吃的是你做的紅燒?，那么再去研究?怎么買，怎么做等等的具體步驟，這是軟件需求。

在?作中我們實際?到的軟件需求?檔類似于下?的表述：

軟件需求規格說明書

?、??需求：

平臺?持郵箱注冊

?、軟件需求：

注意：??的需求不能直接作為開發和測試的依據。針對??的需求，產品經理需要對用戶需求進?需求分析（技術可?性、市場可?性、成本投?和收益占?等）后才可轉變為軟件需求。即把用戶需求轉化為軟件需求，開發人員和測試人員工作的直接依據就是軟件需求。

開發模型

開發模型實際上指的是開放一款軟件或功能所需要具備的開發流程。

什么是“模型”？

隨著軟件工程學科的發展，人們對計算機軟件的認識逐漸深入。軟件工作的范圍不僅僅局限在程序編寫，而是擴展到了整個軟件生命周期，如軟件基本概念的形成、需求分析、設計、實現、測試、安裝部署、運行維護，直到軟件被更新和替換新的版本。軟件工程還包括很多技術性的管理工作，例如過程管理、產品管理、資源管理和質量管理，在這些方面也逐步地建立起了標準或規范。

軟件的生命周期

?命周期指的是從?命的開始到?命結束的?段時間。

以?為例，?類的?命周期是從?命孕育的開始，中間會經歷幼年，童年，少年，?年，?年，最終直?死亡。

軟件/產品的?命周期也是如此，需求的開始是軟件?命的起點，中間會經歷需求的計劃、設計、程序開發、程序測試等階段，直?軟件不再進?維護便到了?命的重點。

軟件生命周期是指從軟件產品的設想開始到軟件不再使用而結束的時間。

如果把軟件看成是有生命的事物，那么軟件的生命周期可以分成6個階段，即需求分析、計劃、設計、編碼、測試、運行維護。

案例：

假如想要建造?套房?（別問，問就是?個?造房?），房?的?命周期（流程）是什么樣的？

步驟	總結	映射軟件流程
為什么要建房?？商品房還是普通住宅？建造100層技術上是否可?？	明確合理的建房?標	需求分析
什么時候開發建房?？計劃竣?時間？多久可以交房？	計劃好時間	計劃
建房前明確流程：先打地基，做基礎框架，砌墻、粉刷、?電?程…	設計好具體的建房流程	設計
按照前?的流程和時間實施建房中…	施?中	編碼
房屋建造完成，開發商驗收成果、買家驗收房?品質（房?是否牢固，是否漏?及其他偷?減料的地?，是否按照規定來建造的）	檢查房屋建造結果	測試
檢查結束開始逐步?住，使?中出現了各種情況如房屋漏?、墻?掉?、下?道堵塞等問題，?邊使??邊找物業修理	使?并及時維護	運?維護

因此，我們就得到了軟件（開發）的?命周期：

需求分析?計劃?設計?編碼?測試?運?維護

對于軟件的?命周期中，每個階段都在做什么呢？

階段	具體內容	產出
需求分析	分析??需求是否合理，分別從市場需求、技術等??進?分析。	該階段會輸出需求等?檔。
計劃	對成?的需求執?需求執?計劃，多?時間內完成該需求，每段時間具體完成哪些功能。	該階段會輸出計劃等?檔。
設計	將需求細化成?個個任務，團隊成員各司其職領取任務并進?技術設計（如何進?架構設計，設計哪些接?、采?什么技術）	該階段會輸出技術等?檔。
編碼	開發?員參考需求?檔、設計?檔、交互圖等等?件進?代碼的編寫。	代碼?件等?檔。
測試	測試?員需要介?到軟件的測試中來，參考測試?例對軟件進?測試。	測試?例、測試設計與計劃、測試報告等?檔
運行維護	項?測試結束之后，項?需要進?上線，并對產品進?線上的維護。線上的維護主要分為三個??。分別為修復性維護、完善性維護和預防性維護。 + **修復性維護：**對項?中未發現的問題進?修復。 + 完善性維護：對功能進?完善。 + **預防性維護：**居安思危，為了避免產品在線上出現?些其他不可預料的問題，進??些防護的?段。

常見的開發模型

瀑布模型（Waterfall Model）

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

瀑布模型的?個最?缺陷在于：可以運?的產品很遲才能被看到。這會給項?帶來很?的?險，尤其是集成的?險。因為如果在需求引?的?個缺陷要到測試階段甚?更后的階段才發現，通常會導致前?階段的?作??積返?，業界流?的說法是：“集成之?就是爆炸之?”。

盡管瀑布模型存在很?的缺陷，例如，在前期階段未發現的錯誤會傳遞并擴散到后?的階段，?在后?階段發現這些錯誤時，可能已經很難回頭再修正，從?導致項?的失敗。但是?前很多軟件企業還是沿?了瀑布模型的線性思想，在這個基礎上做出??的修改。例如細化了各個階段，在某些重點關注的階段之間摻?迭代的思想。在瀑布模型中，測試階段處于軟件實現后，這意味著必須在代碼完成后有?夠的時間預留給測試活動，否則將導致測試不充分，從?把缺陷直接遺留給??。

瀑布模型優缺點總結：

優點/特點	缺點
+ 強調開發的階段性 + 線性結構，每個階段只執??次 + 是其他模型的基礎框架	+ 測試后置 - 前?各階段遺留的?險推遲到測試階段才被發現，導致項???積返?，失去了及早修復的機會 - 必須留有?夠的時間給測試活動，否則導致測試不充分，將缺陷直接暴露給??（產品質量差） + 周期太?，產品很遲才能被看到和使?，可能會導致需求/功能過時

瀑布模型存在很嚴重的項??險，那瀑布模型就不能夠被采?了嗎？當然不是。

瀑布模型的適?場景：需求固定的?項?。

然?企業中存在許多些規模龐?、復雜度?、?險?的項?，這種情況下可以哪種模型呢？

螺旋模型

?般在軟件開發初期階段需求不是很明確時，采?漸進式的開發模式。螺旋模型是漸進式開發模型的代表之?，結合了瀑布模型的系統性和迭代模型的靈活性，同時融入了風險分析和評估機制。這對于那些規模龐?、復雜度?、?險?的項?尤其適合。

這種迭代開發的模式給軟件測試帶來了新的要求，它不允許有?段獨?的測試時間和階段，測試必須跟隨開發的迭代?迭代。因此，回歸測試的重要性就不??喻了。

以下是上圖的展開，也是瀑布模型的變形：

優點	缺點
+ 強調嚴格的全過程?險管理 + 強調各開發階段的質量 + 增加?險分析和原型	+ 項?中可能存在的?險性與?險管理?員的技能?平有直接關系 + 需求?員、資?、時間的增加和投?，可能會導致項?的成本太?

適?場景：規模龐?、復雜度?、?險?的項?。

增量模型、迭代模型

增量模型是一種軟件開發過程模型，它將軟件產品（大需求）分解為多個增量部分（小需求），每個部分（小需求）可以獨立開發、測試和交付。

增量開發能顯著降低項??險，結合軟件持續構建機制，構成了當今流?的軟件?程最佳實踐之?。增量開發模型，?勵??反饋，在每個迭代過程中，促使開發?組以?種循環的、可預測的?式驅動產品的開發。因此，在這種開發模式下，每?次的迭代都意味著可能有需求的更改、構建出新的可執?軟件版本，意味著測試需要頻繁進?，測試?員需要與開發?員更加緊密地協作。

與此類似的有?個迭代開發，增量開發和迭代開發往往容易被?認為是一樣的，但是其實兩者是有區別的。增量是逐塊建造的概念，迭代是反復求精的概念。 迭代模型通過反復循環的方式逐步細化和完善軟件產品。

• 增量模型是先畫?的頭部，再畫?體，再畫?腳……
• 迭代模型是先畫整體輪廓，再勾勒出基本雛形，再細化、著?……

適?場景：?型項?，需求不明確。

敏捷模型

在早期，迭代瀑布模型?常流?來完成?個項?。但是現在開發?員在使?它開發軟件時?臨著各種各樣的問題。主要困難包括**在項?開發期間處理來?客?的變更請求以及合并這些變更所需的?成本和時間。**為了克服瀑布模型的這些缺點，在1990年代中期提出了敏捷軟件開發模型。

敏捷模型主要旨在幫助項?快速適應變更請求。因此，敏捷模型的主要?的是促進項?的快速完成。要完成這項任務，需要敏捷。敏捷性是通過使過程適應項?，刪除對特定項?可能不是必需的活動來實現的。此外，避免任何浪費時間和精?的事情。

在敏捷模型中，需求被分解成許多可以增量開發的?部分。敏捷模型采?迭代開發。每個增量部分都是在迭代中開發的。每次迭代都旨在??易于管理，并且只能在?周內完成。?次為客?計劃、開發和部署?個迭代。沒有制定?期計劃。

敏捷模型中有?個?常重要的《敏捷宣?》，宣?內容：

• 個體與交互重于過程和?具：強調高效的溝通
• 可?的軟件重于完備的?檔：強調輕文檔，文檔不應作為驗收的標準
• 客?協作重于合同談判：主動及時了解當下的需求
• 響應變化重于遵循計劃：能夠主動的迎接變化

宣?中主要運?了對?的?法，然?，在每對?對中，后者并?全?價值，但我們更看重前者。

通過敏捷宣?可以總結出敏捷模型的四個特點：輕?檔，輕流程，重?標，重產出。

敏捷開發有很多種?式，其中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 的基本流程如上圖所?：

1. 產品負責?（product owner）負責整理 user story（收集和整理用戶需求），形成左側的產品代辦列表 product backlog。
2. 發布計劃會議：product owner 負責講解 user story，對其進?估算和排序，發布計劃會議的產出就是制定出這?期迭代要完成的 user story 列表，即 sprint backlog。
3. 迭代計劃會議：項?團隊對每?個 user story 進?任務分解，分解的標準是完成該 user story 的所有任務，每個任務都有明確的負責?，并完成?時的初估計。
4. 每?例會：每天 scrum master 召集站?會議，團隊成員回答昨天做了什么、今天計劃做什么、有什么問題。
5. 演?會議：迭代結束之后，召開演?會議（sprint review），相關?員都受邀參加。團隊負責向?家展?本次迭代取得的成果。期間?家的反饋記錄下來，由 product owner 整理，形成新的 user story。
6. 回顧會議：項?團隊對本期迭代進?總結，發現不?，制定改進計劃。下?次迭代繼續改進，以達到持續改進的效果。

敏捷中的測試

1. 輕?檔
   1. 敏捷模型中強調輕?檔，減少冗長的文檔編寫，所以測試?員不應使?傳統的 Excel 編寫測試?例的?法，更多的是使?思維導圖、探索性測試（強調?由度，設計和執?同時進?，根據測試結果不斷調整測試計劃）、?動化測試等。
2. 快速迭代
   1. 敏捷開發中的短周期迭代要求測試人員能夠快速響應需求變化，并在有限的時間內完成測試工作。
   2. 敏捷講求合作，在敏捷項?組中，測試?員應多主動跟開發?員了解需求、討論設計、?起研究bug出現的原因。

測試模型

測試模型中有兩個?常重要且具有標志性的測試模型： V 模型和 W 模型。

V 模型

• 單元測試：對代碼的最小單元（人為規定）執行測試。一般由開發人員進行。
• 集成測試：將各個模塊集成在一起進行測試，確保模塊之間的接口和交互正確。
• 系統測試：對整個系統進行測試，確保系統功能符合需求分析階段定義的需求。
• 驗收測試：最終由用戶或客戶進行驗收測試，確保系統滿足最終用戶的使用需求。

V 模型最早是由 Paul Rook 在 20 世紀 80 年代后期提出的，?的是改進軟件開發的效率和效果，是瀑布模型的變種。 它將傳統的瀑布模型的線性流程與測試活動進行了明確的對應。V 模型強調在每個開發階段都有相應的測試階段，確保在開發過程中盡早發現和修復缺陷。

優點：

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

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

W 模型（雙 V 模型）

V模型中未將測試前置的問題在W模型中得以解決。

W模型通過在需求分析和設計階段就開始制定測試計劃和設計測試用例，實現了測試活動的前置化，能夠更早發現和修復問題，特別適合需求明確且對質量要求較高的項目。

特點：

1. 測試前置：與 V 模型相比，W 模型將測試活動提前到需求分析和設計階段，使得測試人員可以更早參與項目。
2. 雙重驗證：每個開發階段都有對應的測試階段，形成兩個“V”形狀，因此稱為“雙V模型”。
3. 強調同步性：開發和測試活動高度同步，確保在開發過程中及時發現問題。

優點：

1. 早期發現問題：通過在需求分析和設計階段就開始制定測試計劃和設計測試用例，能夠在開發早期發現潛在問題，降低修復成本。
2. 提高測試覆蓋率：測試活動覆蓋了從需求到編碼的各個階段，確保全面驗證系統的功能和性能。
3. 增強協作：測試人員在項目早期就參與進來，與開發團隊緊密協作，共同為產品質量負責。

缺點：

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