軟件測試規范(2)

　　驗證(Verification)，則試圖證明在軟件生存期各個階段，以及階段間的邏輯協調性、完備性和正確性。

　　確認與驗證工作都屬于軟件測試。在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中，任何一個環節上發生了問題都可能在軟件測試中表現出來。

　　1.4. 測試信息流

　　測試信息流如圖1所示。測試過程需要三類輸入：

　　軟件配置：包括軟件需求規格說明、軟件設計規格說明、源代碼等;

　　測試配置：包括測試計劃、測試用例、測試驅動程序等;

　　測試工具：測試工具為測試的實施提供某種服務。例如，測試數據自動生成程序、靜態分析程序、動態分析程序、測試結果分析程序、以及驅動測試的工作臺等。

　　測試之后，用實測結果與預期結果進行比較。如果發現出錯的數據，就要進行調試。對已經發現的錯誤進行錯誤定位和確定出錯性質，并改正這些錯誤，同時修改相關的文檔。修正后的文檔一般都要經過再次測試，直到通過測試為止。

　　通過收集和分析測試結果數據，對軟件建立可靠性模型。

　　如果測試發現不了錯誤，那么可以肯定，測試配置考慮得不夠細致充分，錯誤仍然潛伏在軟件中。這些錯誤最終不得不由用戶在使用中發現，并在維護時由開發者去改正。但那時改正錯誤的費用將比在開發階段改正錯誤的費用要高出40倍到60倍。

　　.5. 測試與軟件開發各階段的關系

　　軟件開發過程是一個自頂向下，逐步細化的過程，而測試過程則是依相反的順序安排的 自底向上，逐步集成的過程。低一級測試為上一級測試準備條件。參看圖1.2，首先對每一個程序模塊進行單元測試，消除程序模塊內部在邏輯上和功能上的錯誤和缺陷。再對照軟件設計進行集成測試，檢測和排除子系統(或系統)結構上的錯誤。隨后再對照需求，進行確認測試。最后從系統全體出發，運行系統，看是否滿足要求。

　　2. 程序錯誤分類

　　由于人們對錯誤有不同的理解和認識，所以目前還沒有一個統一的錯誤分類方法。錯誤難于分類的原因，一方面是由于一個錯誤有許多征兆，因而它可以被歸入不同的類。另一方面是因為把一個給定的錯誤歸于哪一類，還與錯誤的來源和程序員的心理狀態有關。

　　2.1 按錯誤的影響和后果分類

　　較小錯誤：只對系統輸出有一些非實質性影響。如，輸出的數據格式不合要求等。

　　中等錯誤：對系統的運行有局部影響。如輸出的某些數據有錯誤或出現冗余。

　　較嚴重錯誤：系統的行為因錯誤的干擾而出現明顯不合情理的現象。比如開出了0.00元的支票，系統的輸出完全不可信賴。

　　嚴重錯誤：系統運行不可跟蹤，一時不能掌握其規律，時好時壞。

　　非常嚴重的錯誤：系統運行中突然停機，其原因不明，無法軟啟動。

　　最嚴重的錯誤：系統運行導致環境破壞，或是造成事故，引起生命、財產的損失。

　　2.2 按錯誤的性質和范圍分類

　?、?功能錯誤

　　規格說明錯誤：規格說明可能不完全，有二義性或自身矛盾。

　　功能錯誤：程序實現的功能與用戶要求的不一致。這常常是由于規格說明中包含錯誤的功能、多余的功能或遺漏的功能所致。

　　測試錯誤：軟件測試的設計與實施發生錯誤。軟件測試自身也可能發生錯誤。

　　測試標準引起的錯誤：對軟件測試的標準要選擇適當，若測試標準太復雜，則導致測試過程出錯的可能就大。

　?、?系統錯誤

　　外部接口錯誤：外部接口指如終端、打印機、通信線路等系統與外部環境通信的手段。所有外部接口之間，人與機器之間的通信都使用形式的或非形式的專門協議。如果協議有錯，或太復雜，難以理解，致使在使用中出錯。此外還包括對輸入/輸出格式錯誤理解，對輸入數據不合理的容錯等等。

　　內部接口錯誤：內部接口指程序之間的聯系。它所發生的錯誤與程序內實現的細節有關。例如，設計協議錯、輸入/輸出格式錯、數據保護不可靠、子程序訪問錯等。

　　硬件結構錯誤：這類錯誤在于不能正確地理解硬件如何工作。例如，忽視或錯誤地理解分頁機構、位址生成、信道容量、I/O指令、中斷處理、設備初始化和啟動等而導致的出錯。

原文轉自：http://www.uml.org.cn/Test/201511262.asp