軟件測試入門


2.1    軟件測試與軟件質量

2.1.1    什么是軟件測試
       “軟件測試”的經典定義四在規定條件下對程序進行操作,以發現錯誤,對軟件質量進行評估。
2.2    軟件測試目的
     早期的軟件定義支出軟件測試的目的是尋找錯誤,並且盡最大的可能找出最多的錯誤。
  • 測試是程序的執行過程,目的在於發現錯誤;
  • 一個好的測試用例在於能發現至今未發現的錯誤;
  • 一個成功的測試是發現了至今未發現的錯誤的測試。
     測試的目的,是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷,通過修正各種錯誤和缺陷提高軟件質量,回避軟件發布后由於潛在的軟件缺陷和錯誤造成的隱患所帶來的商業風險。
2.3    軟件測試原則
  • 所有的軟件測試都應追溯到用戶需求。
  • 應當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座右銘。
  • 完全測試是不可能的,測試需要終止。
  • 測試無法顯示軟件潛在的缺陷。
  • 充分注意測試中的群集現象。
  • 程序員應避免檢查自己的程序。
  • 盡量避免測試的隨意性。    
2.4    軟件測試對象
     根據軟件定義,軟件包括程序、數據和文檔,所以軟件測試並不僅僅是程序測試。
  • 在軟件編碼結束后,對編寫的每一個程序模塊進行測試,成為“模塊測試”或“單元測試”;
  • 在模塊集成后,對集成在一起的模塊組件,有時也可稱為“部件”,進行測試,成為“集成測試”;
  • 在集成測試后,需要監測與正式軟件是否滿足軟件需求說明書中規定的要求,這就成為“確認測試”;
  • 將整個程序模塊即成為軟件系統,安裝在運行環境下,對硬件、網絡、操作系統及支撐平台構成的整體系統進行測試,成為“系統測試”。
2.5    軟件測試分類
2.5.1    按照開發階段划分
  • 單元測試
  • 集成測試
  • 系統測試
  • 確認測試
  • 驗收測試
2.5.2    按照測試實施組織划分
  • 開發方測試(驗證測試或α測試)
  • 用戶測試(β測試)
  • 第三方測試
2.5.3    按照測試技術划分
  • 白盒測試
      通過對程序內部結構的分析、檢測來尋找問題。白盒測試可以把程序看成裝在一個透明的白盒子里,也就是清楚了解程序結構和處理過程,檢查是否所有的結構及路徑都是正確的,檢查軟件內部動作是否按照設計說明的規定正常進行。白盒測試又稱結構測試。
  • 黑盒測試
     通過軟件的外部表現來發現其缺陷和錯誤。黑盒測試法把測試對象看成一個黑盒子,完全不考慮程序內部結構和處理過程。黑盒測試是在程序界面處進行測試,他只是建成樣序是否按照需求規格說明書的規定正常實現。
  • 灰盒測試
     介於白盒測試與黑盒測試之間的測試。灰盒測試關注輸出對於輸入的正確性;同時也關注內部表現,但這種關注不想白盒測試那樣詳細、完整,只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態。
2.6    軟件測試過程模型
2.6.1    V模型
2.6.2    W模型

2.6.3    H模型
      
2.6.4    X模型

2.6.5    前置測試模型

2.7    軟件生命周期測試策略
2.7.1    軟件開發與軟件測試
    
2.7.2    軟件測試策略
       測試過程按4個步驟進行,即單元測試、集成測試、確認測試、系統測試。

(1)單元測試
      通常單元測試是在編碼階段進行的。
      模塊並不是一個獨立的程序,在考慮測試模塊時,同時要考慮它和外界的聯系,用一些輔助模塊去模擬與所測模塊相聯系的其他模塊。這些輔助模塊分為兩種:
      驅動模塊(driver)——相當於所測模塊的主程序。它接受測試數據,把這些數據傳送給所測模塊,最后再輸出實際結果。
      樁模塊(stub)——也叫做存根模塊。用以代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作,不需要把子模塊所有功能都帶進來,但不允許什么事情也不做。
      
      模塊的內聚程度高,可以簡化單元測試過程。如果每一個模塊只完成一種功能,則需要的測試用例數目將明顯減少,模塊中的錯誤也容易被預測和發現。
(2)集成測試
      集成測試也叫作組裝測試或聯合測試。通常,在單元測試的基礎上,需要將所有模塊按照概要設計說明書和詳細設計說明書的要求進行組裝。
(3)確認測試
      確認測試的任務是驗證軟件的功能
(4)系統測試
       系統測試是將通過集成測試的軟件,作為整個基於計算機系統的一個元素,與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起,在實際或者模擬運行(使用)環境下,對計算機系統進行一系列測試。
(5)驗收測試
       驗收測試是以用戶為主的測試。
2.8    軟件失效分類與管理
2.8.1    軟件失效分類
  • 軟件錯誤(software error)
  • 軟件缺陷(software defect)
  • 軟件故障(software fault)
  • 軟件失效(software failure)
     ①軟件錯誤:在可以預見的時期內,軟件仍將有人來開發。在整個軟件生存期的各個階段,都貫穿着人的直接或間接的干預。然而,人難免犯錯誤,這必然給軟件留下不良的痕跡。軟件錯誤是指在軟件生存期內的不希望或不可接受的人為錯誤,其結果是導致軟件缺陷的產生。可見,軟件錯誤是一種人為過程,相對於軟件本身,是一種外部行為。
     ②軟件缺陷:軟件缺陷是存在於軟件(文檔、數據、程序)之中的那些不希望或不可接受的偏差,如少一逗點、多一語句等。其結果是軟件運行於某一特定條件時出現的軟件故障,這時稱軟件缺陷被激活。
     ③軟件故障:軟件故障是指軟件運行過程中出現的一種不希望或不可接受的內部狀態。譬如,軟件處於執行一個多余循環過程時,我們說軟件出現故障。
     ④軟件失效:軟件失效是指軟件運行時產生的一種不希望或不可接受的外部行為結果。
2.8.2    缺陷與錯誤分布
2.8.3    缺陷與錯誤嚴重性和優先級
       給軟件缺陷與錯誤划分嚴重性和優先級的通用是:
       ①表示軟件缺陷所造成的危害的惡劣程度;
       ②優先級表示修復缺陷的重要程度與次序。
  • 嚴重級
        ①嚴重:系統崩潰、數據丟失、數據毀壞。
        ②較嚴重:操作性錯誤、錯誤結果、遺漏功能。
        ③一般:小問題、錯別字、UI布局、罕見故障。
        ④建議:不影響使用的瑕疵或更好的實現。
  •  優先級
        ①最高優先級:立即修復,停止進一步測試。
        ②次高優先級:在產品發布之前必須修復。
        ③中等優先級:如果時間允許應該修復。
        ④最低等優先級:可能會修復,但是也能發布。
2.8.4    軟件錯誤跟蹤管理
     1.錯誤跟蹤管理
         (1)Bug記錄信息
           主要包括以下幾項內容。
  • 測試軟件名稱
  • 測試版本號
  • 測試人名稱
  • 測試事件
  • 測試軟件和硬件配置環境
  • 發現軟件錯誤的類型
  • 錯誤的嚴重等級
  • 詳細步驟
  • 必要的附圖
  • 測試注釋
          (2)Bug處理信息
  • 處理者姓名
  • 處理時間
  • 處理步驟
  • 錯誤記錄的當前狀態
     2.軟件錯誤的狀態
  • 新信息(new):測試中新報告的軟件Bug
  • 打開(Open):被確認並分配給相關
  • 修正(Fixed):開發人員已完成修正,等待測試人員驗證。
  • 拒絕(Declined):拒絕修改Bug
  • 延期(Deferred):不在當前版本修復的錯誤,下一版修復
  • 關閉(Closed):Bug已被修復
     3.錯誤管理流程
  • 測試人員提交新的錯誤入庫,錯誤狀態為“New”
  • 高級測試人員驗證錯誤
       ①如果確認是錯誤,分配給相應的開發人員,設置狀態為“Open”
       ②如果不是錯誤,則拒絕,設置為“Declined”狀態
  •  開發人員查詢狀態為“Open”的錯誤,做如下處理。
       ①如果不是錯誤,則置狀態為“Declined”。
       ②如果是錯誤,則修復並置狀態為“Fixed”。
       ③如果不能解決的錯誤,要留下文字說明並保持錯誤為“Open”狀態。
       ④對於不能解決和延期解決的錯誤,不能由開發人員自己決定,一般要通過某種會議(評審會)通過才能認可。
  • 測試人員查詢狀態為“Fixed”的錯誤,驗證錯誤是否已解決,做如下處理。
       ①如問題解決了,置錯誤的狀態為“Closed”。
       ②如問題沒有解決,則置狀態為“Reopen”。
      4.錯誤流程管理原則
       錯誤流程管理遵照以下原則。
       ①為了保證錯誤處理的正確性,需要有豐富測試經驗的測試人員驗證發現的錯誤是否是真正的錯誤,書寫的測試步驟是否准確,可以重復。
       ②每次對錯誤的處理都要保留處理信息,包括處理姓名、時間、處理方法、處理意見、Bug狀態。
       ③拒絕或延期處理錯誤不能由程序員單方面決定,應該有項目經理、測試經理、設計經理共同決定。
       ④錯誤修復后必須由報告錯誤的測試人員驗證,確認已經修復后,才能關閉錯誤。
  • 加強測試人員與程序員之間的交流,對於某些不能重復的錯誤,可以請測試人員補充詳細的測試步驟和方法,以及必要的測試用例。
2.9    白盒測試
       白盒測試也稱結構測試或邏輯驅動測試,它是按照程序內部的結構測試程序,通過測試來檢測產品內部動作是夠按照設計規格說明書的規定正常進行,檢驗程序中的每條通路是否都能按預定要求正確工作。
       常用軟件測試方法有兩大類:靜態測試方法和動態測試方法。
2.10   黑盒測試
       黑盒測試也稱功能測試,他是通過測試來檢測每個功能是否都能正常使用。在測試時,把程序看作一個不能打開的黑盒子,在完全不考慮程序內部結構和內部特性的情況下,在程序接口進行測試,它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接受輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進行測試。
       具體的黑盒測試用例設計方法包括等價類划分、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。
       等價類划分的辦法是把程序的輸入域划分成若干部分,然后從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價於這一類中的其他值。
       邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界,而且也必須考慮輸出域邊界。
       錯誤推測設計方法就是基於經驗和直覺推測程序中所有可能存在的各種錯誤,從而有針對性的設計測試用例的方法。
       因果圖方法是從用自然語言書寫的程序規格說明的描述中找出因(輸入條件)和果(輸出或程序狀態的改變),可以通過因果圖轉換為判定表。
       正交試驗設計法,就是使用已經造好了的正交表格來安排試驗並經行數據分析的一種方法,目的是用最少的測試用例達到最高的測試覆蓋率。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM