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

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

　　1)為什么要進(jìn)行單元測試：

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

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

　　2)單元測試的內容：

　　單元測試首先要理解單元原本是要做什么的，而不是它現在實(shí)際做了什么，我們更關(guān)心的是：模塊或函數是否做了它該做的事情而沒(méi)有做不該做的事情。

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

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

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

　　1)為什么要進(jìn)行集成測試，

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

　　2)集成測試的內容。

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

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

　　通過(guò)接口的覆蓋率進(jìn)行集成測試的評估。

　　基于V模型，針對需求規格說(shuō)明書(shū)的系統測試

　　1)為什么要進(jìn)行系統測試。

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

　　2)系統測試的內容。

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

　　系統測試評估的標準是對需求規格說(shuō)明書(shū)的覆蓋率。

　　基于系統測試層面的個(gè)人經(jīng)驗總結：

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

　　第一：測試用例的設計。在需求分析、概要設計、詳細設計階段均需要設計測試用例，測試用例設計的有效性和合理性對整個(gè)測試執行起著(zhù)至關(guān)重要的作用，它將直接影響缺陷發(fā)現率。如果用例如何設計的不太合理，滿(mǎn)足了出口準則，但在發(fā)布以后，產(chǎn)生的大量缺陷，將直接影響用戶(hù)滿(mǎn)意度，浪費時(shí)間和資源，那么，如何進(jìn)行測試用例的設計?怎么設計出高效率的測試用例呢?

　　1)要明確，對于開(kāi)發(fā)所關(guān)心的是功能是否可以被實(shí)現和如何具體實(shí)施，而對于測試來(lái)說(shuō)，關(guān)注的是功能是否被正確實(shí)現，而不管這些功能是如何被具體實(shí)施的;

　　2)在設計用例的過(guò)程中，要保證每一個(gè)功能點(diǎn)均有相應的用例所對應，保證測試用例對需求100%的覆蓋;

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

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

　　用例的設計是一個(gè)長(cháng)期經(jīng)驗積累的過(guò)程，需要我們在工作中多留心，才會(huì )有新發(fā)現、新思想。

　　第二：測試用例的執行。測試用例的執行過(guò)程將是缺陷產(chǎn)生和修復的過(guò)程，同時(shí)也是測試用例進(jìn)行更新和優(yōu)化的過(guò)程。

　　1)缺陷的提交與跟蹤;

　　測試人員進(jìn)行測試用例的執行，在執行過(guò)程中，做好每日缺陷的提交，測試主管對缺陷進(jìn)行分配及對修改時(shí)限的要求，開(kāi)發(fā)人員進(jìn)行缺陷的修改，修改完畢后，測試人員進(jìn)行回歸測試，并時(shí)刻關(guān)注缺陷庫缺陷的狀態(tài)及嚴重級別較高的缺陷進(jìn)行及時(shí)跟蹤。我們在亦莊的項目在這點(diǎn)就做的不錯。

　　2)缺陷的收集與度量;

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

原文轉自：http://kjueaiud.com