測試—概念篇

1. 什么是需求

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

1.1 用戶需求

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

用戶的需求是五花八門，往往只是?句話

?如：實現?個聲控燈，實現?個軟件的登錄功

1.2 軟件需求?

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

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

朋友餓了的例?用戶需求：

朋友說, 我餓了, 這是?個用戶需求. 很簡略.

軟件需求：

需要你和她反復的溝通了解更加詳細具體的需求, 來制定解決?案. ?如你問她, "想吃啥?", 她說, "隨便"

"吃?飯炒菜?", "不想吃"; "那你想吃啥?", "隨便" "吃油潑??", "不想吃"; "那你想吃啥?", "隨便" ...

最終理解清楚??需求之后, 知道?朋友想吃的是你做的紅燒?, 那么再去研究?怎么買, 怎么做等等的具體步驟, 是軟件需求.

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

軟件需求規格說明書

?、用戶需求：平臺?持郵箱注冊

?、軟件需求：

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

2. 開發模型

2.1 什么是“模型”

你以為的模型

實際的模型：

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

2.2 軟件的生命周期

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

什么是生命周期？

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

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

案例：

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

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

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

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

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

階段	具體內容	產出
需求分析	分析用戶需求是否合理，分別從市場需求、技術等方面進?分析。	該階段會輸出需求等?檔。
計劃	對成?的需求執?需求執?計劃，多?時間內完成該需求，每段時間具體完成哪些功能。	該階段會輸出計劃等?檔。
設計	將需求細化成?個個任務，團隊成員各司其職領取任務并進?技術設計（如何進?架構設計，設計哪些接?、采?什么技術）	該階段會輸出技術等?檔。
編碼	開發?員參考需求?檔、設計?檔、交互圖等等?件進?代碼的編寫。	代碼?件等?檔。

測試

測試?員需要介?到軟件的測試中來，參考測試?例對軟件進?測試。

測試?例、測試設計與計劃、測試報告等?檔

運?維護

項?測試結束之后，項?需要進?上線，并對產品進?線上的維護。線上的維護主要分為三個??。分別為修復性維護、完善性維護和預防性維護。

修復性維護：對項?中未發現的問題進?修復。

完善性維護：對功能進?完善。

預防性維護：居安思危，為了避免產品在線上出現?些其他不可預料的問題，進??些防護的?段。

2.3 常見開發模型——軟件的開發流程（軟件的生命周期）

2.3.1 瀑布模型

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

瀑布模型的?個最大缺陷在于，可以運行的產品很遲才能被看到。這會給項目帶來很大的分險，尤其是集成的分險。因為如果在需求引入的?個缺陷要到測試階段甚?更后的階段才發現，通常會導致前面階段的工作大面積返?，業界流行的說法是：“集成之日就是爆炸之日”。盡管瀑布模型存在很大的缺陷，例如，在前期階段未發現的錯誤會傳遞并擴散到后面的階段，而在后?階段發現這些錯誤時，可能已經很難回頭再修正，從而導致項目的失敗。但是目前很多軟件企業還是沿用了瀑布模型的線性思想，在這個基礎上做出自己的修改。例如細化了各個階段，在某些重點關注的階段之間摻?迭代的思想。在瀑布模型中，測試階段處于軟件實現后，這意味著必須在代碼完成后有足夠的時間預留給測試活動，否則將導致測試不充分，從而把缺陷直接遺留給用戶。

瀑布模型優缺點總結：

優點/特點

缺點

?強調開發的階段性；
線性結構，每個階段只執??次
?是其他模型的基礎框架

測試后置

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

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

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

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

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

2.3.2 螺旋模型

?般在軟件開發初期階段需求不是很明確時，采用漸進式的開發模式。螺旋模型是漸進式開發模型的代表之?。
這對于那些規模龐大、復雜度高、分險?的項目尤其適合，因為螺旋模型中各個階段都引入了風險分析+原型。這種迭代開發的模式給軟件測試帶來了新的要求，它不允許有?段獨立的測試時間和階段，測試必須跟隨開發的迭代而迭代。因此，回歸測試的重要性就不言而喻了。

上面的簡化就是：

螺旋模型中各個階段都引入了風險分析+原型，目的就是減少各個階段遺留的風險問題，避免把問題留到后面的階段；一次在螺旋模型中需要額外招聘專業的風險分析人才，各階段是否遺留問題完全取決于風險分析人員，這跟風險分析人員的技術能力直接掛鉤。

螺旋模型優缺點總結：

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

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

2.3.3 增量模型、迭代模型

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

隨著互聯網的發展，已經很少有企業會獨立的使用這兩個模型，而是配合著一起去使用。

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

與此類似的有增量開發和迭代開發，但是其實兩者是有區別的。增量是逐塊建造的概念，迭代是反復求精的概念。

例如畫?幅?物畫：

增量模型是先畫?的頭部，再畫?體，再畫?腳……

迭代模型是先畫整體輪廓，再勾勒出基本雛形，再細化、著?...

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

2.3.4 敏捷模型

在早期，迭代瀑布模型非常流行來完成?個項目。但是現在開發?員在使用它開發軟件時面臨著各種各樣的問題。主要困難包括在項目開發期間處理來自客戶的變更請求以及合并這些變更所需的高成本和時間。為了克服瀑布模型的這些缺點，在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的基本流程如上圖所示：

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

敏捷中的測試：

輕文檔和快速迭代

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