軟件測試基本概念

軟件測試定義

    在規定的條件下對程序進行操做，以發現程序錯誤，衡量軟件質量，並對其是否能知足設計要求進行評估的過程。

軟件測試對象

    軟件測試，就是測試軟件。測試全部與交付軟件相關的內容。包括代碼（程序）、文檔（安裝文檔、幫助手冊、程序配套關係、軟件說明書、工具說明書等）、適配工具（各類使程序運行的適配包）等。除了軟件版本測試以外，不一樣的項目組可能還會有一些工具、腳本等的測試。在這裏說明軟件測試對象這一點，主要是讓你們清楚軟件測試不只僅是測試版本軟件測試。軟件測試是測試全部從大家測試組出去的交付件。

軟件測試基本流程

  測試需求分析 --> 測試設計（測試方案設計、測試用例設計）--> 測試執行 --> 測試報告 --> 測試總結（經驗總結、漏測分析）

  一、測試分析

    這裏的測試分析主要是指基於需求的測試分析，分析對象是需求規格說明書。即對需求進行分解，考慮需求自己，以及需求所影響的功能模塊，從而得出測試範圍。測試分析須要創建在對需求自己及對應的系統架構和實現細節的充分了解上，經過對數據流、狀態變化、邏輯時序、功能、性能、兼容性等方面進行分析，得出詳細的測試關注點的過程。

  對需求分析的基礎：

    （1）熟悉業務。熟悉產品的組網、業務是測試需求分析的基礎。若是業務不熟悉就沒法作好測試分析。

    （2）對用戶使用場景的瞭解（客戶化視角）。

    （3）產品功能（特性）矩陣。能夠理解爲交付產品的全部基礎特性。只有清楚全部的特性，才能儘量分析出新增需求對基礎特性的影響。可是從我的經歷過的幾個產品來看，還沒看到有專門去維護產品的功能矩陣。一般只有一些比較大的特性框架。

  需求分析的方法：

    業務流程分析：描述業務的正向流程。

    業務狀態分析：描述業務對象的狀態轉換。

    測試範圍分析：需求自己的功能模塊，受影響的模塊。

    固然還有基於開發實現的測試分析。一般來講，這個都是開發給出影響分析。可是記住，開發給出的影響範圍有必定的參考價值，可是測試必定不能徹底依賴開發的測試分析。測試必定要從測試的角度、客戶的角度給出測試的分析。

  二、測試設計

    測試設計，主要是指測試方案設計和測試用例設計。測試需求分析是測試方案和測試設計的基礎，根據需求內容使用相應的軟件測試方法、測試模板最終獲取測試人員可執行的場景。

    測試方案設計，一般就是測試點或者叫測試標題的集合。不一樣的項目組會有相應的測試方案設計模板，模板中一般會包括設計測試方案時須要考慮的測試設計維度，包括需求測試內容、需求約束條件、測試組網、性能、兼容性、安全性、可靠性、可服務性、測試經驗等等內容。使用模板能夠最大化的避免方案設計維度遺漏。測試方案設計完成以後須要需求相關人員（SE、開發、測試執行人員等）進行評審。並最終基線定稿。須要注意的是作測試方案設計時同時也是對需求規格說明書的一次詳細評審。針對規格說明書的問題須要儘快找SE確認、澄清，並跟蹤規格刷新。規格評審也是測試人員的一個責任。要記住測試設計的依據就只有規格說明書，有問題就必須讓SE刷新規格。

  測試用例設計，測試方案設計完成以後就能夠進行測試用例設計。測試用例設計一般也有相應測試用例設計模板。模板中包含的主要要素爲測試用例編號、測試用例標題、預置條件、測試步驟、測試預期結果、用例等級（level1/2/3）、是否自動化用例、測試執行人員等。確保設計出的測試用例要可以指導測試執行人員甚至不熟悉相關需求背景的人員進行測試執行。

  三、測試執行

   測試執行主要是指測試用例執行。過程當中包括測試環境搭建、測試用例執行、修改或補充測試用例等內容。測試用例執行不能按序就班的按照測試用例逐一執行。測試執行要先了解所有測試用例。根據測試用例優先級、測試用例對測試環境依賴、測試風險等因素判斷測試執行優先級。好比測試用例對測試資源的依賴。A用例須要使用測試組網A，B用例使用測試組網B，C用例使用測試組網A。若是按順序執行可能會出現重複搭建組網A的環境，致使時間浪費，甚至可能影響測試進度。

  四、測試報告

    撰寫測試報告的角色一般是測試經理或者版本測試負責人。測試報告是在版本測試結束，測試範圍內的全部內容測試結束後輸出。測試報告內容主要包括測試過程和測試質量的度量數據。包括測試執行人員、測試執行週期、測試環境和工具、測試組網、測試用例執行個數、測試發現缺陷個數和缺陷值等等。

  五、測試總結

   版本經驗總結，版本過程當中值的提倡內容以及版本測試過程當中須要改進的內容。以及漏測分析等。我的理解這一塊內容很是重要，可是實際上因爲項目週期、我的主觀能動性、測試管理等等的問題，作的並非很好。只有不斷輸出測試總結，輸出相關特性、工具、FAQ、測試方案等文檔。不斷的積累，一個產品的測試能力、測試效率和測試質量才能不斷迭代改進。全部的經驗不該該只存在每一個人的大腦裏甚至是電腦裏，而是應該進行分享或者是統一管理。否則組內每一個成員的離職就可能形成某種特性、工具測試能力的流失，一切從0開始。是很是惋惜的。這就須要測試管理者作好組內知識體系的建設、測試經驗的積累，確保技能、經驗、解決問題的能力是在一個良性循環中。

白盒測試和黑盒測試

  一、白盒測試

    知道產品內部工做過程，可經過測試來檢測產品內容動做是否按照規格說明書的規定正常運行，按照程序內部的結構測試程序，檢查程序彙總額每條路徑是否都能按預約要求正確工做。白盒測試主要方法有：

    語句覆蓋：程序中的每一條語句執行被執行一次。

    分支覆蓋或判斷覆蓋：程序中的每個分支至少走一次，即每一條語句的真值執行一次、假值也執行一次。

    條件覆蓋：當斷定式中含有多個條件時，要求每一個條件的取值均獲得檢驗。

    判斷/條件覆蓋：同時考慮條件的組合和斷定結果的檢驗。

    路徑覆蓋：使程序沿全部可能的路徑執行。

  二、黑盒測試

  在測試時，把程序看作一個不能打開的盒子，在徹底不考慮程序的內部結構和內部特性狀況下，檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息，而且保持外部信息的完整性。黑盒測試的主要方法有等價類、邊界值、因果圖、斷定表、錯誤推測、正交試驗設計、功能圖等。

  白盒測試的優點在於對程序內部實現的瞭解，黑盒測試的優點在於對用戶場景的把握。

軟件測試模型

    軟件測試模型則是軟件測試的工做框架,用於指導軟件測試過程。下面咱們就介紹經常使用的基本測試模型。

一、傳統瀑布模型

  瀑布模型是將軟件生存週期的各項活動規定爲按固定順序而鏈接的若干階段工做，形如瀑布流水，最終獲得軟件產品。其核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協做，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落（百度百科）。

  從定義和核心思想能夠看出，瀑布模型是一個有序的軟件開發活動。下一個環節的開展依賴於上一個環節。當前環節發現的問題若是是上一個環節形成的就刷新上一環節的工做。甚至可能須要層層向上反推。舉個栗子，假如在測試階段發現了一個規格設計的問題，須要怎麼處理？就須要從新刷新規格、從新設計、編碼、測試。那麼如何解決這個問題？一個是測試儘量提前的介入，一個是更適合的軟件開發模型，敏捷。這是另一個話題。本文裏描述的主要仍是圍繞儘量提早介入測試這一原則來講。這裏不是說瀑布模型就沒有價值，在某種背景下，任何新方法提出並能被普遍接受必定有其價值。存在即合理嘛。

二、V模型

    V模型是瀑布模型的一個演進，或者是叫優化。V模型是一個著名的、以測試爲驅動的開發模型。在V模型中明確了明確測試分層的概念，如圖中給出的單元測試、集成測試、系統測試、驗收測試等，分層中的測試類別的測試主體、測試依據、測試對象和測試目標有所不一樣。好比單元測試的測試主體主要是開發、測試依據主要是系統詳細設計說明書、測試對象主要是代碼中的函數、類等內容，確保其符合測試詳細設計，確保代碼中的函數、類是可靠、穩固的。

  V模型中有必定的不足，就是它沒有明確體現測試需"儘早地和不斷地進行軟件測試"的原則（這是找了一些資料參考的，我的理解，不必定準確）。

三、W模型

    在W模型中，測試與開發同時進行，增長了在開發階段輸出交付件的同步測試。與V模型對比，W模型明確體現"儘早地和不斷地進行軟件測試"的原則。測試提早介入，儘早發現問題。但不足的是W模型仍然不支持迭代，仍需按照流水線進行設計、編碼和測試。

   W模型也是我見過最主流的一個軟件開發模型。也就是在系統規格說明書基線以後。開發和測試就開始並行完成各自的工做。一般測試和開發工做環節以下

  開發：系統規格評審 -> 寫需求規格說明書 --> 概要設計、詳細設計 -> 編碼 -- > 測試（Code Revview/UT/ST/IT）--> 轉測試 -->修改bug 

  測試: 系統規格評審 --> 測試需求分析 --> 測試需求串講--> 測試方案設計&評審 --> 測試用例設計&評審--> [版本轉測試] --> 測試執行 （包括迴歸測試）--> 版本發佈

  測試須要在版本轉測試前完成測試用例基線。經過上述一個過程，能夠確保規格、需求問題最大程度的提早暴露，在版本轉測試前確保需求儘量是清晰的。其實流程中還包括開工會、工做量評估等內容。

四、H模型

    這個有點不太理解，抄個概念放這。方便各位自行理解。

   開發與測試過程活動徹底獨立，貫穿於整個產品的週期，與其餘流程併發地進行，某個測試點準備就緒時，就能夠從測試準備階段進行到測試執行階段；軟件測試能夠進行儘早的進行；軟件測試能夠根據被測物的不一樣而分層次進行。

軟件測試分層

  按照上述軟件測試模型，產生了軟件測試分層概念。下面分別介紹軟件測試分層中的UT、IT、ST、BBIT、SDV、SIT、SVT的概念和區別。閱讀下述內容時，最主要的仍是上文中提到的幾個關鍵內容。也就是每個分層測試的概念、測試依據、測試對象和測試出口準則。至於測試主體，我的認爲並非那麼重要。好比UT測試場景的測試主體是開發，但測試作UT也見過。根據各自產品的形態、團隊的人員技能去評估。

一、UT（Unit Test，單元測試）

    UT是指單元測試，測試對象是LLD文檔中所劃分定義的程序單元或模塊，它也是單元測試用例設計中可測試的最大單元。該測試對象可能由一個或多個函數或者類組成，測試設計就是對測試對象進行測試用例設計。

    UT的測試目的，是經過函數運行來檢查模塊代碼對於LLD文檔的順從性，驗證每一個函數的輸入輸出響應，與它在詳細設計文檔中預先定義的是否一致。函數是產品開發實現的最基本單位，下一個實現單位是模塊。

   從測試的角度看，但願UT完成後，每一個函數都牢固可靠，下一步的IT測試將聚焦在函數之間配合可否實現分配需求，而不用擔憂函數自己的輸入輸出響應問題。

    單元測試比較適合開發人員作。

二、IT（Intergration Test，集成測試）

     IT是指把若干個通過單元測試的單元組裝到一塊兒而進行的測試，IT測試對象主要爲HLD文檔，主要發現開發接口、依賴中的錯誤或不完善的地方。集成測試的對象爲若干個單元測試對象的組合，至少爲兩個。

　 IT的目的，是根據模塊設計對模塊的分解，從已驗證的函數開始，逐層向上集成，獲得一個可運行的模塊。

　 IT能夠由開發人員作，也能夠由測試人員作。不難看出，UT是面向每個單元的測試，IT是測試單元之間的接口，能夠把UT/IT歸爲「單元級」測試。

     說一句，我的常常容易把集成測試（IT）和系統集成測試混淆。不要被集成兩個字弄混了。IT測試仍是屬於單元級的測試，非系統級。

三、ST（System Test，系統測試）

    ST系統測試(System Test)針對軟件項目組所承擔開發的軟件系統進行的總體測試，將軟件系統做爲總體運行或實施明肯定義的軟件行爲子集的測試。

    ST測試對象爲模塊規格說明書，模塊SRS文檔給出了模塊的輸入輸出的相應要求。

    ST測試主要是驗證模塊內功能是否符合模塊規格說明書中有關需求規定的測試方法。不考慮程序內部實現邏輯，主要採用的測試方法是黑盒測試。

    一般但願在完成ST後，每一個模塊是牢固可用的。通常來講,ST也常被稱爲MST（Module ST），模塊集成測試。

四、BBIT（Building Block Integrated Test，模塊間接口測試）

    BBIT爲模塊間接口測試，驗證模塊之間的接口能不能配合，有時和聯調混在一塊兒，其實目的並不相同。

    BBIT的目的，是根據系統設計對系統的分解，從已經過驗證的模塊開始，逐層向上集成，獲得一個可運行的系統。而聯調通常涉及軟件、硬件或者不一樣產品間的配合測試。

    完成BBIT測試以後哦，模塊間的接口功能是正確的。

    MST和BBIT能夠歸到「模塊級」 的測試，一個驗證模塊，一個驗證模塊間的接口。以上UT/IT/MST/BBIT通常由開發人員完成，系統基本能夠運行起來了，測試人員能夠開展SDV、SIT、SVT了。

五、SDV（System Design Verify，系統設計驗證）

    SDV是系統設計驗證，測試對象爲系統規格說明書。SDV主要驗證系統實現是否知足系統規格說明書中的要求。驗證多個模塊集成之後是否知足設計需求。完成SDV測試以後，要求系統實現徹底符合系統規格說明書要求，系統功能所有實現。

六、SIT（System Intergration Test，系統集成測試 ）

    SIT是系統集成測試。也是驗證設計需求是否得以知足，與SDV不一樣的是，SIT徹底把系統看成一個黑盒來測試，不關心內部具體的實現。實際應用中，SDV和SIT 雖然都屬於系統一級的測試，每每由不一樣項目組（子系統）的測試人員分別測試，他們只關注各自的子系統，因此仍是把SDV和SIT歸爲「子系統級」的測試比較好。

    SIT測試主要關注系統間（爲了方便理解，你能夠將它理解爲不一樣產品之間）的接口是正確的。現網運行的一般都是一個解決方案的產品，部門內的產品只是一個組成單元，若是當前開發的功能須要兩個產品之間進行處理，在SIT測試時就須要重點關注。舉個例子，充值產品和計費產品歸屬於兩個部門。當充值系統中發送給計費系統的消息接口發生變化時，SIT測試就須要重點關注該接口測試。

七、SVT（System Verify Test，系統驗證測試）

    SVT是驗收測試，其測試對象是產品包需求（也就是客戶提出的最原始的需求，原始需求通過SE加工後的叫系統規格說明書）。產品包需求給出了產品的範圍，從產品可能的應用環境的角度刻畫系統，SVT的目的就是確認（或驗收）產品包需求給出的各類應用場景產品均能知足。產品包需求不考慮內部實現的差別，SVT也是從整個系統的角度考慮包需求的各類應用場景，屬於「系統級」的測試。

    各個分層的測試描述完成，結合開發測試模型能夠發現：

　　1）基於系統架構的分解結構（系統－子系統－模塊－單元），開發按照自頂向下的順序逐層設計，測試按照自底向上的順序逐層驗證，這個分解結構在每一層或每個階段，將開發和測試過程統一塊兒來。

　　2）在每一層，測試的對象是開發相應階段設計的輸出（包括需求和這個階段的設計文檔），測試的目的與開發相應階段設計的思路是相輔相成的，因此決定每一個階段的測試如何開展、評價一個測試過程時，若是離開開發過程，只談測試自身的話，是不繫統、不全面的。

　　3）除了「系統級」的SVT測試之外，其餘各層的測試均包含兩個方面：一是對這個層每一個構件的測試，有n個構件就要測試n次，二是這n個構件之間接口的測試。例如：nSDV（每一個測試項目組的SDV是一個SDV）和SIT、nMST（每一個開發項目組的MST是一個MST）和BBIT、nUT和IT。

參考文檔

一、UT-IT-ST-BBIT-SDV-SIT-SVT