模型的開發和測試

在談論開發模型和測試模型之前，我們先在談論開發模型和測試模型之前，我們先來了解一下軟體的生命週期

軟體的生命週期分為六個階段：需求分析、計畫、設計、編碼、測試、執行維護。一、開發模型

1.瀑布模型（wate***ll model）

適用場景：適合需求變化少的專案、是序列的。

優點：（1）強調開發的階段性；

（2）強調早期計畫及需求調查；

（3）強調產品測試。

缺點：（1）依賴於早期進行的唯一一次需求調查，不能適應需求的變化；

（2）流程單一，開發中的經驗教訓不能反饋應用於本產品的過程；

（3）風險性延遲至後期的測試階段才顯露，失去了早糾正的機會。

2.螺旋模型（spiral model）

適用場景：強點風險分析，適合規模大的、複雜度高的專案。

優點：（1）強調嚴格的過程風險管理；

（2）強調各開發階段的質量；

（3）提供機會檢討專案是否有價值繼續下去。

缺點：引入非常嚴格的風險識別、風險分析和風險控制，這對風險管理的技能水平提出了很高的要求。這需要人員、資金和時間的投入。

3.增量、迭代

增量是指一塊一塊來進行測試、而迭代是指先整體再細化。

舉個例子：比如畫乙個人物肖像，用增量，就是先畫頭，再畫胳膊，再畫腿；而用迭代就是先描繪出來乙個整體的輪廓，然後再將每乙個部分細化。

增量通常和迭代混為一塊，可以降低風險，和螺旋結構相似。

4.敏捷

（1）《敏捷宣言》

- 個體與互動重於過程和工具（強調「人與人的溝通」）

- 可用的軟體重於完備的文件（強調「輕文件」，對文件的依賴性不高）

- 客戶協作重於合同談判（強調「客戶參與」）

- 響應變化重於遵循計畫（強調「擁抱變化」）

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

（2）敏捷中的角色

scrum有product owner（類似於「產品經理」），scrum master（類似於「專案經理」），team（研發團隊）組成。

product owner負責整理user story（使用者故事），定義其商業價值，對其進行排序，制定發布計畫，對產品負責。 scrum master負責召開各種會議，協調專案，為研發團隊服務。研發團隊由不同技能的成員組成，通過緊密協同，完成每一次迭代的目標，交付產品。

（3）敏捷中的測試挑戰1：輕文件（即：對文件的依賴性比較少）挑戰2：快速迭代（即：最長不超過一句話，一般是兩周）

通過以上學習，敏捷這份工作的有趣之處還有很多，有興趣的老鐵們可以自己上網查一查二、測試模型

1.軟體測試v模型（瀑布模型的變種）

優點：該模型明確標註了測試過程中存在的不同型別的測試，並且清楚地描述了這些測試階段和開發過程期間各個階段的對應關係。缺點：本模型具有侷限性（僅僅把測試作為編碼之後的乙個階段，未在需求階段就進入測試）。

2.軟體測試的w模型（雙「v」模型）

優點：從中我們不難發現，在w模型下，測試和開發的並行的關係。這樣有利於盡早的全面的發現問題。例如，在需求分析結束後，測試人員就應該盡早的參與到需求驗證和確認活動中，以便於盡早的發現缺陷所在。缺點：該模型還是有一定的侷限性，雖然說開發和測試是並行的，但該模型整體還是序列的。無法支援敏捷開發模式。

配置管理器（configuration mangement）：是通過對在軟體生命週期不同的時間點上的軟體配置進行標識、並對這些被標識的軟體配置項的更改進行系統控制，從而達到保證軟體產品的完整性和可塑性的過程。