📢博客主頁：https://blog.csdn.net/2301_779549673
📢博客倉庫：https://gitee.com/JohnKingW/linux_test/tree/master/lesson
📢歡迎點贊 👍 收藏 ?留言 📝 如有錯誤敬請指正！
📢本文由 JohnKi 原創，首發于 CSDN🙉
📢未來很長，值得我們全力奔赴更美好的生活?

---

11111111
11111111
11111111
11111111
**** 11111111

🏳??🌈一、什么是需求

在多數軟件公司，會有兩部分需求，一部分是用戶需求，一部分是軟件需求。

1.1 用戶需求

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

用戶的需求是五花八門，往往只是一句話
比如:實現一個聲控燈，實現一個軟件的登錄功能

1.2 軟件需求

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

用戶需求和軟件需求有什么不同呢?看看下面的案例

女朋友餓了的例子
用戶需求:
女朋友說,我餓了,這是一個用戶需求.很簡略.
軟件需求:
需要你和她反復的溝通了解更加詳細具體的需求,來制定解決方案
比如你問她，"想吃啥?"她說，“隨便”
“吃米飯炒菜?”“不想吃”;“那你想吃啥?”“隨便”
“吃油潑面?”“不想吃”;“那你想吃啥?”“隨便”
最終理解清楚用戶需求之后,知道女朋友想吃的是你做的紅燒肉,那么再去研究肉怎么買,怎么做等等的具體步驟,是軟件需求.

🏳??🌈二、開發模型

2.1 什么是“模型”

你以為的模型

實際的模型

隨著軟件工程學科的發展，人們對計算機軟件的認識逐漸深入。

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

2.2 軟件的生命周期

認識具體的開發模型之前先了解軟件的生命周期。

什么是生命周期?

• 生命周期指的是從生命的開始到生命結束的一段時間。以人為例，人類的生命周期是從生命孕育的開始，中間會經歷幼年，童年，少年，青年，老年，最終直至死亡。

案例:
假如我想要建造一套房子(別問，問就是一個人造房子)，房子的生命周期(流程)是什么樣的?

因此，我們就得到了軟件(開發)的生命周期:

• 需求分析–計劃–設計–編碼–測試–運行維護

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

2.3 常見開發模型

2.3.1 瀑布模型

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

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

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

瀑布模型優缺點總結:

瀑布模型存在很嚴重的項目風險，那瀑布模型就不能夠被采用了嗎?

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

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

2.3.2 螺旋模型

在瀑布模型的基礎上，給各階段引入了原型和風險分析，原型是基本版本

一般在軟件開發初期階段需求不是很明確時，采用漸進式的開發模式。螺旋模型是漸進式開發模型的代表之一。

這對于那些規模龐大、復雜度高、風險大的項目尤其適合。 這種迭代開發的模式給軟件測試帶來了新的要求，它不允許有一段獨立的測試時間和階段，測試必須跟隨開發的迭代而迭代。因此，回歸測試的重要性就不言而喻了。

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

2.3.3 增量模型、迭代模型

增量開發能顯著降低項目風險，結合軟件持續構建機制，構成了當今流行的軟件工程最佳實踐之一。

增量開發模型，鼓勵用戶反饋，在每個迭代過程中，促使開發小組以一種循環的、可預測的方式驅動產品 的開發。因此，在這種開發模式下，每一次的迭代都意味著可能有需求的更改、構建出新的可執行軟件 版本，意味著測試需要頻繁進行，測試人員需要與開發人員更加緊密地協作。

與此類似的有一個迭代開發，增量開發和迭代開發往往容易被人混淆，但是其實兩者是有區別的。增量是逐塊建造的概念，迭代是反復求精的概念。

例如畫一幅人物畫

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

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

2.3.4 敏捷模型

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

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

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

敏捷模型中有一個非常重要的《敏捷宣言》，宣言內容:

1. 個體與交互重于過程和工具 - 強調高效的溝通
2. 可用的軟件重于完備的文檔 - 強調請文檔，文檔不應該作為工作驗收的標準
3. 客戶協作重于合同談判 - 能夠主動迎接變化，即使了解當下的需求
4. 響應變化重于遵循計劃 - 能夠主動迎接變化

宣言中主要運用了對比的手法，然而，在每對比對中，后者并非全無價值，但我們更看重前者。

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

敏捷開發有很多種方式，其中 scrum 是比較流行的一種。

Scrum是敏捷模型中的一種，又稱為迭代式增量軟件開發模型。

在scrum模型中，主要有三個角色和五個重要會議。
三個角色:

scrum由 product owner(產品經理)、scrum master(項目經理) 和 team(研發團隊) 組成。·

1. 其中 product owner(產品經理) 負責整理 user story(用戶故事)，定義其商業價值，對其進行排序，制定發布計劃，對產品負責。
2. scrum master(項目經理)，負責召開各種會議，協調項目，為研發團隊服務。
3. team(研發團隊)，則由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品。

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

scrum的基本流程如上圖所示:

• 產品負責人負責整理userstory(用戶故事)，形成左側的 productbacklog(產品待辦列表) 。

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

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

• 敏捷模型中強調輕文檔，所以測試人員不應使用傳統的Excel編寫測試用例的方法，更多的使用思維導圖、探索性測試(強調自由度，設計和執行同時進行，根據測試結果不斷調整測試計劃)、自動化測試等
• 敏捷講求合作，在敏捷項目組中，測試人員應多主動跟開發人員了解需求、討論設計、一起。研究bug出現的原因。

2.4 測試模型

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

2.4.1 V模型

V模型最早是由Paul Rook在20世紀80年代后期提出的，目的是改進軟件開發的效率和效果。是瀑布模型的變種。

優點:

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

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

2.4.2 W模型(雙V模型)

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

W模型增加了軟件各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的并行關系。

特點:

• 測試的對象不僅是程序，需求、設計等同樣要測試，測試與開發是同步進行的

優點:

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

缺點:

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

---

👥總結

本篇博文對 【測試開發】概念篇 - 從理解需求到認識常見開發、測試模型 做了一個較為詳細的介紹，不知道對你有沒有幫助呢

覺得博主寫得還不錯的三連支持下吧！會繼續努力的~