V模型
軟件測試若使用經典的V模型階段可以分爲
- 單元測試
- 集成測試
- 系統測試
- V模型是最具有代表意義的測試模型 。
- V模型是軟件開發瀑布模型的變種，它反映了測試活動與分析和設計的關係 。
- 從左到右，描述了基本的開發過程和測試行爲，非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。
- 左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
用戶需求 驗收測試
需求分析和系統設計 確認測試和系統測試
概要設計 集成測試
詳細設計 單元測試
編碼
- V模型問題：
- 1.測試是開發之後的一個階段。
- 2.測試的對象就是程序本身。
- 3.實際應用中容易導致需求階段的錯誤一直到最後系統測試階段才被發現。
- 4.整個軟件產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度
V模型是在快速應用開發 (RAD，Rap Application Development)模型基礎上演變而來，由於將整個開發過程構造成一個V字形而得名。V模型強調軟件開發的協作和速度，將軟件實現和驗證有機地結合起來，在保證較高的軟件質量情況下縮短開發週期。
下面通過對這種模型的水平和垂直的關聯和比較分析，理解軟件開發和測試的關係，理解V模型具有面向客戶、效率高、質量預防意識等特點，能幫助我們建立一套更有效的、更具有可操作性的軟件開發過程。
從水平對應關係看
左邊是設計和分析，是軟件設計實現的過程，同時伴隨着質量保證活動——審覈的過程，也就是靜態的測試過程；右邊是對左邊結果的驗證，是動態測試的過程，即對設計和分析的結果進行測試，以確認是否滿足用戶的需求。如：
需求分析和功能設計對應驗收測試，說明在做需求分析、產品功能設計的同時，測試人員就可以閱讀、審查需求分析的結果，從而瞭解產品的設計特性、用戶的真正需求，確定測試目標，可以準備用例(Use Case)並策劃測試活動。
當系統設計人員在做系統設計時，測試人員可以瞭解系統是如何實現的，基於什麼樣的平臺，這樣可以設計系統的測試方案和測試計劃，並事先準備系統的測試環境，包括硬件和第三方軟件的採購。因爲這些準備工作，實際上是要花去很多時間。
當設計人員在做在做詳細設計時，測試人員可以參與設計，對設計進行評審，找出設計的缺陷，同時設計功能、新特性等各方面的測試用例，完善測試計劃，並基於這些測試用例以開發測試腳本。
在編程的同時，進行單元測試，是一種很有效的辦法，可以儘快找出程序中的錯誤，充分的單元測試可以大幅度提高程序質量、減少成本。
從中可以看出，V模型使我們能清楚地看到質量保證活動和項目同時展開, 項目一啓動，軟件測試的工作也就啓動了,避免了瀑布模型所帶來的誤區——軟件測試是在代碼完成之後進行。
從垂直方向看
水平虛線上部表明，其需求分析、定義和驗收測試等主要工作是面向用戶，要和用戶進行充分的溝通和交流，或者是和用戶一起完成。水平虛線下部的大部分工作，相對來說，都是技術工作，在開發組織內部進行，主要是由工程師、技術人員完成。
從垂直方向看，越在下面，白盒測試方法使用越多，到了集成、系統測試，更多是將白盒測試方法和黑盒測試方法結合起來使用，形成灰盒測試方法。而在驗收測試過程中，由於用戶一般要參與，使用黑盒測試方法。
他通過開發和測試同時進行的方式來縮短開發週期，提高開發效率。可以說，V模型是軟件開發測試中最重要的一種模型。
V模型大體可以劃分爲下面幾個不同的階段步驟，既需求分析、概要設計、祥細設計、編碼、單元測試、集成測試、系統測試、驗收測試。
需求分析：既你首先要明確客戶需要的是什麼，需要軟件作成什麼樣子，需要有那幾項功能，這一點上比較關鍵的是分析師和客戶溝通時的理解能力與交互性。要求分析師能準確的把客戶所需要達到的功能，實現方式，等表述出來，給出分析結果，寫出規格文檔說明書。
概要設計：主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務。
祥細設計：對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等，這一階段要求達到僞代碼級別，已經把程序的具體實現的功能，現象等描述出來。
編碼：按照祥細設計好的模塊功能表，編程人員編寫出實際的代碼。
單元測試：按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，爲的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同，比如有具體到模塊的測試，也有具體到類，函數的測試等。
集成測試：經過了單元測試後，將各單元組合成完整的體系，主要測試各模塊間組合後的功能實現情況，以及模塊接口連接的成功與否，數據傳遞的正確性等。是軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。
系統測試：經過了單元測試和集成測試以後，我們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等
驗收測試：主要就是用戶在拿到軟件的時候，會根據前邊所提到的需求，以及規格說明書來做相應測試，以確定軟件達到符合效果的。
下邊這張表格可以更明確的表述這幾種步驟的過程：
| 名稱 | 目標 | 活動描述 |
| 需求分析 | 明白客戶需要，表述客戶需要 | 與客戶交流，瞭解客戶需求，寫出說明書 |
| 概要設計 | 搭構架，明確模塊功能，各模塊間交互的實現方法，數據傳送方法等 | 把客戶需要細分,確定不同的功能模塊，把各模塊連接方法，數據傳輸方法確定。 |
| 祥細設計 | 表述出模塊間組合功能實現方法， | 對各模塊進行進一步分析，設計模塊間組合功能實現過程，寫出僞代碼 |
| 編碼 | 寫程序 | 按照設計好的功能模塊功能需求，設計不同的功能模塊，寫出代碼，寫出連接模塊的代碼， |
| 單元測試 | 測試需要的最小單元的功能 | 按照設定好的最小測試單元（或者叫組件）進行按測試，確保各模塊被正確的編譯執行 |
| 集成測試 | 檢查單元和單元間組合成後是否存在問題，如組合後的功能，接口等， | 將已經分別通過測試的單元模塊按設計需求組合進行整體功能，性能等測試， |
| 系統測試 | 把集成後的軟件放到系統中進行測試， | 搭建不同的計算機軟硬件系統，把被測軟件放入其中進行的非功能性測試，主要包括安全可靠性，性能等 |
| 驗收測試 | 驗證系統是否達到了客戶需求 | 用戶進行易用性，兼容性，安裝測試等 |
對於軟件測試過程來說，所有的測試都應追溯到用戶需求。軟件測試的目標在於揭示錯誤。而最嚴重的錯誤（從用戶角度來看）是那些導致程序無法滿足需求的錯誤.所以，V模式要求在測試工作真正開始前的較長時間內就進行測試計劃。測試計劃可以在需求模型一完成就開始或者說應該和需求分析一起進行，在進行需求分析的時候就把系統測試用例根據需求文檔說明書而作出來，詳細的測試用例定義可以在概要設計模型被確定後立即開始。因此，所有測試應該在任何代碼被產生前就進行計劃和設計。這其實是V 模型佔軟件開發測試模型中重要地位的原因。
從這個角度上來說，就可以這樣來考慮：單元測試所對應的是祥細設計環節，也就是說，單元測試的測試用例是和祥細設計一起出現的，在做研發人員做做祥細設計的時候，相應的測試人員也就把測試用例寫了出來。集成測試呢，對應的爲概要設計，在做模塊功能分析及模塊接口，數據傳輸方法的時候，就把集成測試用例根據概要設計中模塊功能及接口等實現方法編寫出
V模型體現了測試 設計分層和測試執行 分 層的概念，本文以作者自身的理解談談測試執行分層，不過從實際項目運作情況來看，
真正做到測試執行分層的並不多，這裏原因有很多種，暫且不論。
1. UT
單元測試 的對象是LLD中所劃分定義的程序單元或模塊，它也是 單元測試用例設計中可測試的最大單元。該測試對象可能由一
個或多個函數或者類組成，測試設計就是對測試對象進行測試用例設計。
UT的目 的，是通過函數運行來檢查模塊代碼對於LLD文檔的順從性，驗證每個函數的輸入輸出響應，與它在詳細設計文檔中預
先定義的是否一致。函數是產品開發實現的 最基本單位，下一個實現單位是模塊，從測試的角度看，希望UT完成後，每個函數都牢
固可靠，下一步的IT測試將聚焦在函數之間配合能否實現分配需求，而不 用擔心函數本身的輸入輸出響應問題。
單元測試比較適合開發人員做。
2. IT
集成測試是指把若干個經過單元測試的單元組裝到一起而進行的測試，集成測試應依據HLD，主要發現接口、依賴中的錯誤或
不完善的地方。集成測試的對象爲 若干個單元測試對象的組合，至少爲兩個。
IT的目的，是根據模塊設計對模塊的分解，從已驗證的函數開始，逐層向上集成，得到一個可運行 的模塊。
IT可以由開發人員做，也可以由測試人員做。
不難看出，UT是面向每一個單元的測試，IT是測試單元之間的 接口，可以把UT/IT歸爲“單元級”測試。
3. ST
CMM定義的系統測試 ： 系統測試是針對軟件項目組所承擔開發的軟件系統進行的整體測試，將軟件系統作爲整體運行或實施明
確定義的軟件行爲子集的測試。主要採用的測試方法是黑盒測試 ， 即不管程序內部的實現邏輯，以檢驗輸入輸出信息是否符合規
格說明書中有關需求規定的測試方法。可見ST的測試對象是規格說明書，更確切的說，是模塊需求規 格說明書，所以一般也稱爲
MST。模塊SRS文檔給出了模塊的輸入輸出的相應要求。MST後，每個模塊是牢固可用的。
4. BBIT
BBIT爲模塊間接口測試，驗證模塊之間的接口能不能配合，有時和聯調混在一起，其實目的並不相同。 BBIT的目的，是根據系
統設計對系統的分解，從已通過驗證的模塊開始，逐層向上集成，得到一個可運行的系統。而聯調一般涉及軟件、硬件或者不同產
品間的 配合測試。MST和BBIT可以歸到“模塊級” 的測試，一個驗證模塊，一個驗證模塊間的接口。
以上UT/IT/MST/BBIT一般 由開發人員完成，系統基本可以運行起來了，測試人員可以開展SDV、SIT、SVT了。
5. SDV
SDV雖然屬於測試人員開展的系統測試，但是有點偏灰盒測試，因爲SDV驗證各子系統的配合是否滿足設計需求（DR），對內部
的實現還是關注的，驗證多 個模塊集成以後是否滿足設計需求。
6. SIT
SIT也是驗證設計需求是否得以 滿足，與SDV不同的是，SIT完全把系統當作一個黑盒來測試，不關心內部具體的實現。實際應
用中，SDV和SIT 雖然都屬於系統一級的測試，往往由不同項目組（子系統）的測試人員分別測試，他們只關注各自的子系統，所以
還是把SDV和SIT歸爲“子系統級”的測試比 較好。
7. SVT
SVT是驗收測試，其測試對象是產品包需求OR。產品包需求 給出了產品的範圍，從產品可能的應用環境的角度刻畫系統，SVT的
目的就是確認（或驗收）產品包需求給出的各種應用場景產品均能滿足。
產品包需求不考慮內部實現的差異，SVT也是從整個系統的角度考慮包需求的各種應用場景，屬於“系統級”的測試。
各個級別的測試描述完 畢，回頭再看看這個分層測試的模型圖，不難發現以下幾個特徵：
1）基於系統架構的分解結構（系統－子系統－模塊－單元），開發按照自頂 向下的順序逐層設計，測試按照自底向上的順序
逐層驗證，這個分解結構在每一層或每一個階段，將開發和測試過程統一起來。
2）在每一層， 測試的對象是開發相應階段設計的輸出（包括需求和這個階段的設計文檔），測試的目的與開發相應階段設計
的思路是相輔相成的，所以決定每個階段的測試如何開 展、評價一個測試過程時，如果離開開發過程，只談測試自身的話，是不繫
統、不全面的。
3）除了“系統級”的SVT測試以外，其他 各層的測試均包含兩個方面：一是對這個層每個構件的測 試，有n個構件就要測試n
次，二是這n個構件之間接口的測試。例如：nSDV（每個測試項目組的SDV是一個SDV）和SIT、nMST（每個開發項目組 的MST是一個
MST）和BBIT、nUT和IT。
轉:
最近在各博客中看到不少同仁在聊現在越來越熱的測試技術和測試工程方法，而本人也在一個通訊公司專職測試摸爬滾打了多年，其中有些心得，希望使用容易理解的語言組織成系列和廣大同仁分享。其中可能涉及測試技術、測試設計方法、測試建模、測試流程/開發流程、測試管理、測試度量等方面，如有不確之處，還請多多討論。
搞技術的都知道，技術鑽研的越深，越容易有技術情節，但不論如何，測試本身就是一個發展中的行業，特別需要不同方面的聲音，希望大家着重關心不同情況下適用的技術本質，而不是無謂的爭吵。
總體來介紹一下一般的測試活動，目前一般比較上規模的創新技術公司或企業，會設立專門的測試崗位，而測試崗位根據具體職位不同有很大的區別，例如廠驗（出廠測試，抽樣檢驗產品的合格率），SIT系統集成測試（在開發後期，根據用戶使用場景進行測試），SDV系統設計驗證（在系統開發階段，轉測試的第一個環節）等等，總體來說，測試工作越向前介入開發階段，測試含金量越高。而目前各大技術公司逐漸從瀑布、螺旋開發模式逐漸向迭代開發、增量開發、敏捷開發靠攏，越來越關注測試在設計階段的重要作用，這些都會在後面系列逐一介紹。
我們一般用戶接觸到的也有測試，例如最近Firefox的Beta測試，微軟的體驗測試等，這些測試都有一個共性--看不到系統的實現方式，純黑盒體驗測試。方纔也提到，測試活動越靠前，越瞭解系統，越懂得各個開發階段所使用的測試方法。
在瀑布模型中，開發一般必做的是單元測試，自己寫代碼，自己打樁寫測試代碼，主要驗證語法、邏輯等基本問題，這裏有個問題，測試有個主要的思想是“避免讓程序員測試自己的程序”，這是一般是指系統測試，開發人員進行單元測試的效率是很高的，首先自己保證沒有導致編譯不通過的低級錯誤、內存泄露等隱藏很深的錯誤，此類錯誤在系統測試也可以測試，但成本太高；同事之間的代碼Review也是很好的錯誤檢測方法；在各個模塊接口完成後，可以進行基本功能聯調，這時出現的接口問題是主要的攔路虎。一般有積累的系統，會使用模擬器仿真系統，在實際仿真環境調試，這樣效率很高。
對於轉測試後的系統，一般有BBIT、SDV、SIT、發佈測試等環節，BBIT是在開發系統轉測試前，由測試人員對開發人員交付的系統進行轉測試驗收的測試活動，保證轉測試的系統滿足可測試性要求，如果是分幾段合入得子特性，也可以做BBIT測試，依避免新合入的特性對主線版本較大的質量衝擊，BBIT 測試是一個很好的測試把關環節，如果BBIT不通過，可根據情況打回版本或特性，並針對DI（遺留缺陷）進行質量回溯，避免重複錯誤。SDV測試時針對系統中不同的功能特性進行單獨驗證，一般是搭建一個完整的系統環境，由不同的測試人員進行單個功能特性測試，例如通信系統中OSPF、BGP、MPLS LDP等是組成路由器的核心功能，可以由三個測試人員分別驗證這三個特性，可根據特性規格、產品規格、標準、使用場景等進行單個特性的功能點測試，保證單個特性的可交付性，這裏，在SDV階段一般不進行性能測試和壓力測試，因爲此時在基本功能還存在Bug的是否進行性能、壓力測試只能讓開發忙於解決致命問題，可能有火上澆油的意思，而沒有時間思考和反覆驗證合入的修改代碼是否會引起新問題。在SDV各個功能點驗證基本充分後時，可以進行性能摸底測試，輸出性能摸底報告，給出性能結論。此時，如果性能遠不滿足要求，而提升的手段也不足以產生質的變化時，這時，就有必要反思一下系統設計階段的結論了。例如在非常複雜的路由器系統中，可以使用性能建模來分析將來系統的指標。SIT測試中，主要是針對實際應用場景進行特性疊加測試，例如一般在接入側用戶會同時使用 OSPF和MPLS完成域內隧道搭建，這兩個特性同時使能是否會有干擾，例如目前很火的VPN技術就是BGP+MPLS的交叉技術，此時在系統中同時使能 L3VPN+MPLS+BGP+OSPF是否可以順利完成各自的功能，性能是否有影響等。
總之，測試層次分的越深，各個環節的輸入件和交付件的質量關係到整個測試環節的整體質量。後面的系列中會介紹在測試流程中的各個環節是如何緊密結合的，各個環節的輸入和交付件等。