基于V模型的單元測試,集成測試,系統測試

發表于:2011-11-11來源:未知作者:領測軟件測試網采編點擊數: 標簽:
基于V模型,針對詳細設計的單元測試 1)為什么要進行單元測試: 系統測試是一種黑盒測試,也就是不需要了解系統內部結構,只關心外部實現,那么這樣發現的問題將不會太徹底,而單元測試是一種白盒測試,只有深入到系統內部,才能對軟件內部邏輯

  基于V模型,針對詳細設計的單元測試

  1)為什么要進行單元測試

  系統測試是一種黑盒測試,也就是不需要了解系統內部結構,只關心外部實現,那么這樣發現的問題將不會太徹底,而單元測試是一種白盒測試,只有深入到系統內部,才能對軟件內部邏輯控制結構上的問題進行清除,對發現、定位和解決問題將是最直接,最徹底的方式;在效率方面,單元測試往往是集成測試的2倍,系統測試的3倍;成本方面,一個問題如果遺留到后期階段解決,那么付的代價將會很高,而且是成倍遞增。

  單元測試有效的驗證代碼是否與設計相符,盡早發現設計和需求中存在的錯誤,以及在編碼階段引入的錯誤。

  2)單元測試的內容:

  單元測試首先要理解單元原本是要做什么的,而不是它現在實際做了什么,我們更關心的是:模塊或函數是否做了它該做的事情而沒有做不該做的事情。

  主要依據詳細設計的描述和源程序清單針對五部分內容進行測試:模塊接口、局部數據結構、邊界條件、出錯處理、獨立路徑。首先模塊與周圍環境的接口有無差錯應首先得到檢驗,否則其內部的各種測試工作將是徒勞;局部數據結構也是常見的錯誤來源,對基本控制流進行測試同樣也會發現大量的錯誤;異常處理要給予適當的出錯處理對策,以便在程序出錯時,能對出錯程序重新做出安排,保證其邏輯上的正確性;邊界測試,對數據流的測試將是單元測試的最后一步。

  單元測試評估的標準是邏輯覆蓋率。

  基于V模型,針對概要設計的集成測試

  1)為什么要進行集成測試,

  集成測試的目的是確保各單元組合在一起后能夠按既定意圖協作運行,并確保增量的行為正確,當一個系統還沒有完成,設計相應的樁和驅動模塊進行集成測試,便于早期發現接口問題以及集成后的功能問題,同時編碼不是一個可以一次性通過的過程,對最初的單元測試中一些被忽略和遺漏的BUG,也將會在集成測試階段被發現。

  2)集成測試的內容。

  概要設計的對象主要為系統,系統子系統,模塊,子模塊,函數等,通過體系結構進行模塊的劃分,并進行數據設計、接口設計,遵循高內聚、低耦合的原則,對其進行分解描述,依賴關系描述,接口描述等,并保持模塊與需求的對應關系,因此,對集成測試的重點,將主要測試模塊之間的接口和接口數據傳遞關系,以及模塊組合后的整體功能。

  確保各單元組合在一起后能夠按既定意圖協作運行,并確保增量的行為正確,驗證接口是與設計相符合?發現設計與需求中存在的錯誤是集成測試的工作內容。

  通過接口的覆蓋率進行集成測試的評估。

  基于V模型,針對需求規格說明書的系統測試

  1)為什么要進行系統測試。

  系統測試是我們傳統觀念的一種測試方式,也就是一般放在項目功能基本實現后的功能和性能等方面的測試,目前軟件測試已由開發的后期介入擴展到了整個生命周期,由基于代碼運行擴展到靜態走讀,由傳統的發現錯誤為目的擴展到了對缺陷的預防。

  2)系統測試的內容。

  系統測試主要驗證功能是否符合需求規格定義,是一種在實際環境下的測試,同時也是全面的系統級測試,其內容包括產品功能、性能指標、兼容性、可靠性、容錯能力、可維護性、安全性等方面;功能方面主要檢查是否有不正確或遺漏了的功能,性能測試目標是度量系統相對于預定義目標的差距,必須要有工具的支持;GUI測試界面實現與界面設計的吻合,以及界面處理的正確性,是直接面對用戶的首要條件,因此相對在易用性方面顯的較為重要;兼容性,可靠性的、容錯性,可維護性,安全性等根據項目要求的不同,具體情況具體分析。

  系統測試評估的標準是對需求規格說明書的覆蓋率。

  基于系統測試層面的個人經驗總結:

  (一)用例設計、執行、管理、溝通:

  第一:測試用例的設計。在需求分析、概要設計、詳細設計階段均需要設計測試用例,測試用例設計的有效性和合理性對整個測試執行起著至關重要的作用,它將直接影響缺陷發現率。如果用例如何設計的不太合理,滿足了出口準則,但在發布以后,產生的大量缺陷,將直接影響用戶滿意度,浪費時間和資源,那么,如何進行測試用例的設計?怎么設計出高效率的測試用例呢?

  1)要明確,對于開發所關心的是功能是否可以被實現和如何具體實施,而對于測試來說,關注的是功能是否被正確實現,而不管這些功能是如何被具體實施的;

  2)在設計用例的過程中,要保證每一個功能點均有相應的用例所對應,保證測試用例對需求100%的覆蓋;

  3)測試人員需要對被測軟件的需求和業務進行全面了解,否則對被測對象了解不深,只能就被測單元的功能設計用例,而對于該功能點所要執行的流程無法正確保證,此時可與需求分析人員和客戶進行交流,以獲得更多的業務方面的信息;

  4)采用各種測試用例設計方法,用最適合的方法來達到用盡量少的用例來發現盡量多的BUG,如針對功能測試的等價類,邊界值,因果圖法,狀態遷移圖,正交分析法,錯誤猜測法,場景路徑覆蓋;針對單元測試的語句覆蓋,分支覆蓋,條件覆蓋,條件組合覆蓋,路徑覆蓋,循環覆蓋,針對類的功能性和結構性測試、數據流測試,異常測試,對類的方法的測試等。

  用例的設計是一個長期經驗積累的過程,需要我們在工作中多留心,才會有新發現、新思想。

  第二:測試用例的執行。測試用例的執行過程將是缺陷產生和修復的過程,同時也是測試用例進行更新和優化的過程。

  1)缺陷的提交與跟蹤;

  測試人員進行測試用例的執行,在執行過程中,做好每日缺陷的提交,測試主管對缺陷進行分配及對修改時限的要求,開發人員進行缺陷的修改,修改完畢后,測試人員進行回歸測試,并時刻關注缺陷庫缺陷的狀態及嚴重級別較高的缺陷進行及時跟蹤。我們在亦莊的項目在這點就做的不錯。

  2)缺陷的收集與度量;

  測試人員要保證所描述的缺陷是清楚的、準確的,必要時要配有截圖,開發人員修改完畢后,要保證注明原因和解決的辦法,有了上述兩條的保證,缺陷的收集和度量工作將變的非常容易,對缺陷進行分析如發現缺陷多位于邊界值,那么可以根據此項對公司的編程規范進行相應的完善。當對幾個項目進行缺陷收集和度量后,具備一定的條件情況下,將可對類似項目進行缺陷的預防工作。

原文轉自:http://www.anti-gravitydesign.com

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97