軟體測試模型-敏捷模型

敏捷模型是在網際網路的快節奏下應運而生的，也是當前最為主流的開發測試模型。

在V模型中，描述了基本的開發過程和測試行為，它的優點在於，非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了測試各階段和開發各階段的對應關係。

同時，它的侷限性也相當明顯，測試介入時間太晚，只是把測試作為編碼後的一個活動，需求分析等前期產生的錯誤，直到後期的驗收測試才能發現。

雖說“亡羊補牢”，但是測試越晚介入，付出的成本代價越大。基於V模型的痛點，引入了敏捷模型。

採用敏捷模型，相當於專案一誕生，就給它打了預防針。

關於敏捷模型的具體流程，如下圖所示：

以抖音為例，在需求分析階段，先收集使用者的需求：市場上目前缺少短視訊的APP，同時，有了今日頭條的成功，能不能沿用它的設計思路，將展現形式由文字轉變為短視訊，通過標籤推薦的演算法，向使用者推送他可能感興趣的短視訊呢？

基於這樣的需求，形成需求文件，接下來，產品經理拉著團隊裡開發、測試、設計一起做需求評審。

除了開發根據需求文件做開發計劃之外，與此同時，測試人員由於更早的介入到軟體專案當中，也可以根據需求文件開始編寫測試計劃了。

形成測試計劃之後，開始著手測試用例的設計與開發。

跟傳統的瀑布模型、V模型不同，等到開發人員提測的時候，測試用例已經設計開發完成，可以直接開展測試工作。

執行測試的過程中，發現了 bug 立即反饋給開發團隊進行修復，修復後進行迴歸測試，直到全部測試用例通過，由產品經理來驗收。

以上就是關於敏捷模型的介紹，現在的網際網路公司基本都會採用這樣一套流程，只是不同的公司會有些細小的差別。

至於為什麼越來越多的網際網路公司青睞於快速迭代的敏捷模型？

主要是因為競品的存在，例如抖音與快手、支付寶與微信支付、美團外賣與餓了麼等，只要其中一方開發了新功能，另一家就需要針對性的開發類似的功能，來保持自己的使用者粘性，不至於落後於競爭對手。

以上就是本篇文章所要分享的內容，歡迎各位大牛指正。你的指正，能讓我在測試之路上快速成長。

Leo Never Stop Fighting！