軟件測試技術(shù)_第1頁
軟件測試技術(shù)_第2頁
軟件測試技術(shù)_第3頁
軟件測試技術(shù)_第4頁
軟件測試技術(shù)_第5頁
已閱讀5頁,還剩598頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1章

軟件工程與軟件測試1.1軟件工程1.2軟件質(zhì)量1.3軟件測試1.4軟件測試人員的基本素質(zhì)

嚴(yán)格地說,軟件工程是應(yīng)用計算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開發(fā)軟件的工程。通俗地說,軟件工程是實現(xiàn)一個大型程序的一套原則方法,即按工程化的原則和方法組織軟件開發(fā)工作。軟件測試是軟件工程的一個重要環(huán)節(jié),相當(dāng)于工程領(lǐng)域中的質(zhì)量檢驗部分,是確保軟件工程質(zhì)量的重要手段。1.1軟件工程1.1.1

軟件工程的目標(biāo)及其一般開發(fā)過程一個軟件產(chǎn)品從形成概念開始,經(jīng)過開發(fā)、使用和維護(hù),直到最后退出使用的全過程稱為軟件生存周期。軟件生存周期根據(jù)軟件所處的狀態(tài),以及軟件開發(fā)活動的目的和任務(wù),可劃分為若干個階段。一般軟件生存周期包括軟件定義、軟件開發(fā)以及軟件使用與維護(hù)3個部分。1.軟件定義可行性分析的任務(wù)是了解用戶的要求及實現(xiàn)環(huán)境,從技術(shù)、經(jīng)濟(jì)和社會等幾個方面研究并論證軟件系統(tǒng)的可行性。需求分析的任務(wù)是確定所要開發(fā)軟件的功能需求、性能需求和運行環(huán)境約束,編制軟件需求規(guī)格說明、軟件系統(tǒng)的確認(rèn)測試準(zhǔn)則。軟件的性能需求包括軟件的適應(yīng)性、安全性、可靠性、可維護(hù)性錯誤處理等。2.軟件開發(fā)軟件開發(fā)是按照需求規(guī)格說明的要求,由抽象到具體,逐步生成軟件的過程。軟件開發(fā)一般由設(shè)計、實現(xiàn)和測試等階段組成。3.軟件使用和維護(hù)軟件的使用是在軟件通過測試后,將軟件安裝在用戶確定的運行環(huán)境中移交給用戶使用。軟件的維護(hù)是對軟件系統(tǒng)進(jìn)行修改或?qū)浖枨笞兓龀龇磻?yīng)的過程。1.1.2軟件過程模型軟件開發(fā)過程中存在各種復(fù)雜因素,為了解決由此而帶來的種種問題,軟件開發(fā)者們經(jīng)過多年的摸索,給出了多種實現(xiàn)軟件工程的方式——軟件過程模型,如瀑布過程模型、螺旋過程模型和增量過程模型等。1.瀑布過程模型瀑布過程模型反映了人們早期對軟件工程的認(rèn)識水平,是人們所熟悉的一種線性思維的體現(xiàn)。瀑布過程模型強調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性,是一種嚴(yán)格線性的、按階段順序的、逐步細(xì)化的開發(fā)模式,如圖1-1所示。圖1-1瀑布過程模型2.螺旋過程模型螺旋過程模型的基本思路是,依據(jù)前一個版本的結(jié)果構(gòu)造新的版本,這個不斷重復(fù)迭代的過程形成了一個螺旋上升的路徑,如圖1-2所示。圖1-2螺旋過程模型3.增量過程模型有些時候可能會用一種幾乎連續(xù)的過程小幅度地推進(jìn)項目,這就是增量過程模型,如圖1-3所示。圖1-3增量過程模型1.2軟件質(zhì)量

軟件質(zhì)量是軟件的生命,它直接影響軟件的使用與維護(hù)。通常軟件質(zhì)量由以下幾方面進(jìn)行評價。①軟件需求是衡量軟件質(zhì)量的基礎(chǔ),不符合需求的軟件就不具備質(zhì)量。設(shè)計的軟件應(yīng)在功能、性能等方面都符合要求,并能可靠地運行。

②軟件結(jié)構(gòu)良好,易讀、易于理解,并易于修改、維護(hù)。

③軟件系統(tǒng)具有友好的用戶界面,便于用戶使用。

④軟件生存周期中各階段文檔齊全、規(guī)范,便于配置、管理。1.2.1質(zhì)量與質(zhì)量模型軟件的質(zhì)量因素很多,如正確性、精確性、可靠性、容錯性、性能、效率、易用性、可理解性、簡潔性、可復(fù)用性、可擴(kuò)充性、兼容性等。軟件質(zhì)量因素也稱為軟件質(zhì)量特性,反映了質(zhì)量的本質(zhì)。討論一個軟件的質(zhì)量,問題最終要歸結(jié)到定義軟件的質(zhì)量特性。

面對眾多的質(zhì)量因素如何取折衷,這實際上就是區(qū)分質(zhì)量因素對軟件質(zhì)量影響程度輕重的問題,這個問題已經(jīng)有了解決方案,即軟件質(zhì)量模型。圖1-4所示為ISO/IEC9126-1991標(biāo)準(zhǔn)規(guī)定的軟件質(zhì)量度量模型。它由3層組成,其中第1層稱為質(zhì)量特性,第2層稱為質(zhì)量子特性,第3層稱為度量。圖1-4ISO軟件質(zhì)量度量模型

軟件質(zhì)量評價的目的是為了直接支持開發(fā)并獲得能滿足用戶要求的軟件。最終目標(biāo)是保證產(chǎn)品能提供所要求的質(zhì)量,即滿足用戶明確的和隱含的要求。軟件產(chǎn)品的一般評價過程是,確定評價需求,然后規(guī)定、設(shè)計和執(zhí)行評價,如圖1-5所示。圖1-5軟件評價過程1.2.2軟件質(zhì)量保證為了在軟件開發(fā)過程中保證軟件的質(zhì)量,軟件的質(zhì)量保證活動應(yīng)貫穿整個軟件生存周期的每一個階段。軟件的質(zhì)量保證的措施主要有檢查、評審和測試。如圖1-6所示,軟件質(zhì)量保證的工作從項目一開始就應(yīng)介入。圖1-6質(zhì)量保證活動1.3軟件測試

1.3.1軟件測試的定義及目的簡單地說,軟件測試就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

在IEEE提出的軟件工程標(biāo)準(zhǔn)術(shù)語中,軟件測試被定義為:“使用人工和自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清楚預(yù)期結(jié)果與實際結(jié)果之間的差別?!避浖y試是與軟件質(zhì)量密切聯(lián)系在一起的,歸根結(jié)底,軟件測試是為了保證軟件質(zhì)量。

軟件測試是一個找錯的過程。軟件測試的過程亦是程序運行的過程。程序運行需要數(shù)據(jù),為測試設(shè)計的數(shù)據(jù)稱為測試用例。測試用例的設(shè)計原則是盡可能暴露程序中的錯誤。

軟件是由人來完成的,所有由人做的工作都不會是完美無缺的。軟件開發(fā)是個很復(fù)雜的過程,期間很容易產(chǎn)生錯誤。無論是軟件從業(yè)人員、專家和學(xué)者做了多大的努力,軟件錯誤仍然存在。因而大家也得到了一種共識:軟件中殘存著錯誤,這是軟件的一種屬性,是無法改變的。所以通常說軟件測試的目的就是為了發(fā)現(xiàn)盡可能多的缺陷,并期望通過改錯來把缺陷統(tǒng)統(tǒng)消滅,以期提高軟件的質(zhì)量。一個成功的測試用例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。

軟件測試的目的是以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷,通過修正各種錯誤和缺陷提高軟件質(zhì)量,回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患所帶來的商業(yè)風(fēng)險。1.3.2軟件測試信息流為進(jìn)一步說明軟件測試的過程,這里給出軟件測試的信息流示意圖,如圖1-8所示。圖1-8軟件測試信息流1.3.3軟件測試與軟件開發(fā)過程的關(guān)系對于軟件測試與軟件開發(fā)過程之間的關(guān)系,套用固定的模型不是聰明之舉。比如“程序設(shè)計”與“測試”之間的關(guān)系,習(xí)慣上總以為程序設(shè)計在先,測試在后,如圖1-9(a)所示。而對于一些復(fù)雜的程序,將測試分為同步測試與總測試更有效,如圖1-9(b)所示。圖1-9程序設(shè)計與測試的關(guān)系

現(xiàn)在還有一種全新的軟件開發(fā)模式——以測試驅(qū)動軟件開發(fā),總的思想是:軟件測試是貫穿于軟件開發(fā)過程的。軟件生存周期的各個階段中都少不了相應(yīng)的測試,軟件生存周期各個階段的測試分別對應(yīng)于軟件測試過程中的單元測試、集成測試、系統(tǒng)測試和確認(rèn)測試,如圖1-10所示。這種對應(yīng)關(guān)系有利于軟件開發(fā)過程的管理和軟件質(zhì)量的控制。圖1-10軟件測試與軟件開發(fā)的關(guān)系1.3.4軟件測試與質(zhì)量保證的區(qū)別1.質(zhì)量保證質(zhì)量保證(QA)工作通過預(yù)防、檢查與改進(jìn)來保證軟件質(zhì)量。QA采用“全面質(zhì)量管理”和“過程改進(jìn)”的原理開展質(zhì)量保證工作。2.軟件測試測試雖然也與開發(fā)過程緊密相關(guān),但關(guān)心的不是過程的活動,而是對過程的產(chǎn)物以及開發(fā)出的軟件進(jìn)行剖析。測試人員要“執(zhí)行”軟件,對過程中的產(chǎn)物——開發(fā)文檔和源代碼進(jìn)行走查,運行軟件,以找出問題,報告質(zhì)量。測試人員必須假設(shè)軟件存在潛在的問題,測試中所做的操作是為了找出更多的問題,而不僅僅是為了驗證每一件事是正確的。

對測試中發(fā)現(xiàn)的問題的分析、追蹤與回歸測試也是軟件測試中的重要工作,因此軟件測試是保證軟件質(zhì)量的一個重要環(huán)節(jié)。軟件質(zhì)量保證活動與軟件測試的關(guān)系可用圖1-11說明。圖1-11軟件質(zhì)量保證活動與測試的關(guān)系1.3.5軟件測試的發(fā)展歷程及趨勢軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的,有了軟件的生成和運行就必然有軟件測試。在早期的軟件開發(fā)過程中,測試的含義比較窄,將測試等同于“調(diào)試”,目的是糾正軟件中已經(jīng)知道的故障,常常由軟件開發(fā)人員自己完成這部分工作。對測試的投入極少,測試介入得也晚,常常是等到形成代碼,產(chǎn)品已經(jīng)基本完成時才進(jìn)行測試。

直到1957年,軟件測試才開始與調(diào)試區(qū)別開來,成為一種發(fā)現(xiàn)軟件缺陷的活動。直到20世紀(jì)80年代早期,“質(zhì)量”的號角才開始吹響。軟件測試的定義發(fā)生了改變,測試不單純是一個發(fā)現(xiàn)錯誤的過程,而且包含軟件質(zhì)量評價的內(nèi)容。軟件開發(fā)人員和測試人員開始坐在一起探討軟件工程和測試問題。制定了各類標(biāo)準(zhǔn),包括IEEE標(biāo)準(zhǔn)、美國ANSI標(biāo)準(zhǔn)和ISO國際標(biāo)準(zhǔn)。20世紀(jì)90年代,測試工具終于盛行起來。到了2002年,Rich和Stefan在《系統(tǒng)的軟件測試》一書中對軟件測試做了進(jìn)一步定義:“測試是為了度量和提高被測軟件的質(zhì)量,對測試軟件進(jìn)行工程設(shè)計、實施和維護(hù)的整個生命周期過程”。這些經(jīng)典論著對軟件測試研究的理論化和體系化產(chǎn)生了巨大的影響。

近20年來,隨著計算機(jī)和軟件技術(shù)的飛速發(fā)展,軟件測試技術(shù)的研究也取得了很大的突破,測試專家總結(jié)了很好的測試模型,如著名的V模型,在單元測試、自動化測試等方面涌現(xiàn)了大量優(yōu)秀的軟件測試工具。

雖然軟件測試技術(shù)的發(fā)展很快,但是其發(fā)展速度仍落后于軟件開發(fā)技術(shù)的發(fā)展速度,使得軟件測試在今天面臨著很大的挑戰(zhàn),主要體現(xiàn)在以下幾個方面。

①軟件在國防現(xiàn)代化、社會信息化和國民經(jīng)濟(jì)信息化領(lǐng)域中的作用越來越重要,由此產(chǎn)生的測試任務(wù)越來越繁重。

②軟件規(guī)模越來越大,功能越來越復(fù)雜,如何進(jìn)行充分而有效的測試成為難題。③面向?qū)ο蟮拈_發(fā)技術(shù)越來越普及,但是面向?qū)ο蟮臏y試技術(shù)卻剛剛起步。

④對分布式系統(tǒng)的整體性能還不能進(jìn)行很好的測試。

⑤對實時系統(tǒng)缺乏有效的測試手段。

⑥隨著安全問題的日益突出,對信息系統(tǒng)的安全性如何進(jìn)行有效的測試與評估,成為世界性難題。

根據(jù)國內(nèi)外軟件測試的發(fā)展現(xiàn)狀,可以看到軟件測試有以下的發(fā)展趨勢。

①測試工作將進(jìn)一步前移。

②軟件架構(gòu)師、開發(fā)工程師、QA人員、測試工程師將進(jìn)行更好的融合。

③測試職業(yè)將得到充分的尊重。④設(shè)置獨立的軟件測試部門將成為越來越多的軟件公司的共識。軟件測試部門將和開發(fā)部、質(zhì)量保證部一樣作為一個重要的獨立部門存在。

⑤測試外包服務(wù)將快速增長。和軟件開發(fā)外包一樣,軟件測試外包將成為全球化的一種趨勢??梢岳寐殬I(yè)測試專家隊伍與機(jī)構(gòu)為自己的產(chǎn)品進(jìn)行測試,而且可以節(jié)省測試費用。1.4軟件測試人員的基本素質(zhì)

軟件測試人員應(yīng)具備下列基本素質(zhì)。1.具有良好的計算機(jī)編程基礎(chǔ)2.具有創(chuàng)新精神和超前意識3.不懈努力,追求完美4.具有整體觀念,對細(xì)節(jié)敏感5.團(tuán)隊合作精神第2章軟件測試的基本知識

2.1軟件測試貫穿于整個的軟件開發(fā)生命周期2.2測試模型2.3軟件測試的分類2.4軟件測試的原則2.5軟件測試策略2.6軟件測試流程2.7測試的成功經(jīng)驗2.1軟件測試貫穿于整個的軟件開發(fā)生命周期2.1.1軟件測試中使用的各種術(shù)語

①軟件錯誤

②軟件缺陷

③軟件故障

④軟件失效2.1.2軟件測試貫穿于整個的軟件開發(fā)生命周期

20世紀(jì)70年代中期以來,形成了軟件開發(fā)生命周期的概念。測試工作應(yīng)該著眼于整個軟件開發(fā)生命周期,特別是著眼于編碼以前各開發(fā)階段的工作來保證軟件的質(zhì)量。也就是說,測試應(yīng)該從軟件開發(fā)生命周期的第一個階段開始,并貫穿于整個的軟件開發(fā)生命周期。

談到測試,首先是為什么要進(jìn)行測試的問題。所有的測試都是為了發(fā)現(xiàn)和消除軟件的缺陷。明確為什么要進(jìn)行軟件測試的問題之后,就需要明確測試什么的問題。

軟件的開發(fā)有其自己的生命周期,在整個軟件生命周期中,軟件都有各自的相對于各生命周期的階段性的輸出結(jié)果,其中也包括需求分析、概要設(shè)計、詳細(xì)設(shè)計及程序編碼等各階段所產(chǎn)生的文檔,包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細(xì)設(shè)計規(guī)格說明以及源程序,而所有這些輸出結(jié)果都應(yīng)成為被測試的對象。

隨著人們對軟件工程化的重視以及軟件規(guī)模的日益擴(kuò)大,軟件分析、設(shè)計的作用越來越突出,而且有資料表明,60%以上的軟件錯誤并不是程序錯誤,而是分析和設(shè)計錯誤。因此,做好軟件需求和設(shè)計階段的測試工作就顯得非常重要。這就是傳統(tǒng)的測試概念的擴(kuò)大化,從而提出了軟件全生命周期測試的概念。

測試過程包括了軟件開發(fā)生命周期的每個階段。在需求階段,重點要確認(rèn)需求定義是否符合用戶的需要;在設(shè)計和編程階段,重點要確定設(shè)計和編程是否符合需求定義;在測試和安裝階段,重點是審查系統(tǒng)執(zhí)行是否符合系統(tǒng)規(guī)格說明;在維護(hù)階段,要重新測試系統(tǒng),以確定更改的部分和沒有更改的部分是否都正常工作。2.1.3軟件測試的手段1.驗證和確認(rèn)通常在測試中,使用驗證來檢查中間可交付的結(jié)果,使用確認(rèn)來評估可執(zhí)行代碼的性能。一般來說,驗證回答這樣的問題:“是否建立了正確的系統(tǒng)?”,而確認(rèn)回答的問題是:“建立的系統(tǒng)是否正確?”。

所謂驗證,是指如何決定軟件開發(fā)的每個階段、每個步驟的產(chǎn)品是否正確無誤,并與其前面的開發(fā)階段和開發(fā)步驟的產(chǎn)品相一致。驗證工作意味著在軟件開發(fā)過程中開展一系列活動,旨在確保軟件能夠正確無誤地實現(xiàn)軟件的需求。所謂確認(rèn),是指如何決定最后的軟件產(chǎn)品是否正確無誤。2.功能和結(jié)構(gòu)測試當(dāng)測試人員測試項目小組的解決方案時,將利用驗證和確認(rèn)技術(shù)完成功能和結(jié)構(gòu)測試。功能測試通常也被稱為黑盒測試,因為測試案例中都不涉及系統(tǒng)的內(nèi)部邏輯。

相反,結(jié)構(gòu)測試通常被稱為白盒測試,因為系統(tǒng)的內(nèi)部邏輯常被用于假想的測試案例。結(jié)構(gòu)測試主要使用驗證技術(shù)。如上所述,測試人員用驗證技術(shù),通過評審系統(tǒng)的結(jié)構(gòu)和邏輯來確認(rèn)系統(tǒng)的合理性。而確認(rèn)要嚴(yán)格應(yīng)用于物理測試,來確定是否產(chǎn)生了預(yù)期的結(jié)果。執(zhí)行結(jié)構(gòu)測試將主要使用驗證技術(shù),而執(zhí)行功能測試則主要使用確認(rèn)技術(shù)。2.2測試模型

就像軟件開發(fā)有過程模型一樣,測試也有測試模型。描述以上測試過程的就是測試模型。最具有代表意義的測試模型稱為V模型。V模型如圖2-1所示。圖2-1V模型示意圖

在開發(fā)過程中,從需求階段到編碼階段,主要是采用驗證手段進(jìn)行測試,如需求評審、設(shè)計評審、代碼走查以及代碼審查等,從而完成對開發(fā)的中間結(jié)果的正確性的評估。編碼完成并經(jīng)過代碼審查等測試之后,此時的測試主要在軟件的可執(zhí)行模式下進(jìn)行,即利用確認(rèn)手段進(jìn)行測試,確認(rèn)測試包括單元測試、集成測試、系統(tǒng)測試以及用戶驗收測試等,其相應(yīng)的關(guān)系如圖2-2所示。圖2-2V模型中的測試2.3軟件測試的分類

按照不同的分類方法,軟件測試可分為以下幾種類型。1.按照開發(fā)階段劃分按照開發(fā)階段劃分,軟件測試可分為單元測試、集成測試、系統(tǒng)測試和驗收測試。2.按照測試實施組織劃分按照測試實施組織劃分,軟件測試可分為開發(fā)方測試、用戶測試(β測試)和第三方測試。3.按照測試技術(shù)劃分按照測試技術(shù)劃分,軟件測試可分為白盒測試和黑盒測試,也可分為靜態(tài)測試和動態(tài)測試。2.4軟件測試的原則

軟件測試的原則尚沒有標(biāo)準(zhǔn)的說法,大多是經(jīng)驗之談,一般有下面幾條可作為測試的基本原則。(1)所有的測試都應(yīng)追溯到用戶需求。(2)應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件測試者的座右銘。(3)設(shè)計時應(yīng)完成測試計劃,詳細(xì)的測試用例定義可在設(shè)計模型確定后開始,測試可在代碼產(chǎn)生之前進(jìn)行計劃和設(shè)計。(4)pareto原則:測試發(fā)現(xiàn)的錯誤中80%很可能起源于20%的模塊中。應(yīng)孤立這些疑點模塊,進(jìn)行重點測試。(5)完全測試是不可能的,測試需要終止。(6)應(yīng)由獨立的第三方來構(gòu)造測試。(7)充分注意測試中的群集現(xiàn)象。(8)要盡量避免測試的隨意性。(9)兼顧合理的輸入和不合理的輸入數(shù)據(jù)。(10)程序修改后要回歸測試(11)應(yīng)長期保留測試用例,直至系統(tǒng)廢棄。2.5軟件測試策略

軟件測試策略描述軟件測試活動的總體方法和目標(biāo)。為了檢驗開發(fā)的軟件能否符合規(guī)格說明書的要求,測試活動可以采用各種不同的策略。這些策略的區(qū)別在于它們表明了不同的出發(fā)點、不同的思路以及采用不同的手段和方法。具體地說,包括要使用的測試技術(shù)和工具;測試完成標(biāo)準(zhǔn);影響資源分配的特殊考慮等。通常,制定軟件測試策略要考慮如下的內(nèi)容。(1)要使用的測試方法。(2)確定質(zhì)量風(fēng)險。(3)測試完成和測試成功所采用的評價標(biāo)準(zhǔn)。(4)有關(guān)資源要求或涉及進(jìn)度的特殊考慮。(5)測試類型、評估標(biāo)準(zhǔn)以及測試方法。(6)確定資源。

在軟件測試策略所包含的內(nèi)容中最主要的部分有兩個,一是要進(jìn)行的測試過程,另外一個就是要執(zhí)行的測試類型。1.測試過程共分為以下4個過程。

①單元測試

②集成測試

③系統(tǒng)測試

④驗收測試2.測試類型對于測試類型的說法多種多樣,最多的能有30多種測試類型。而實際工作中很多測試是互相包含的。按照企業(yè)中實際工作需要,測試主要包含下面的類型。①功能測試②健壯性測試③接口測試④強度測試⑤壓力測試⑥性能測試⑦用戶界面測試⑧安全測試⑨可靠性測試⑩安裝/反安裝測試

11.文檔測試12.恢復(fù)測試13.兼容性測試14.α測試15.β測試2.6軟件測試流程

軟件測試工作必須要通過制定測試計劃、設(shè)計測試、實施測試、執(zhí)行測試、評估測試幾個階段來完成。其流程如圖2-4所示。圖2-4軟件測試流程2.6.1制定測試計劃測試計劃是對每個產(chǎn)品,或是對各個開發(fā)階段的產(chǎn)品開展測試的策略。

計劃的目的是用來識別任務(wù)、分析風(fēng)險、規(guī)劃資源和確定進(jìn)度。計劃并不是一張時間進(jìn)度表,而是一個動態(tài)的過程,最終以系列文檔的形式確定下來。擬定軟件測試計劃需要測試項目管理人員的積極參與,這是因為主項目計劃已經(jīng)確定了整體項目的一個時間框架,軟件測試作為階段工作必須服從計劃和資源上的約定。

一般來說,一個完整的測試計劃應(yīng)該包含以下幾個方面。(1)對測試范圍(即測試活動需要覆蓋的范圍)的界定(2)風(fēng)險的確定(3)資源的規(guī)劃(4)時間表的制定2.6.2設(shè)計測試設(shè)計測試階段要設(shè)計測試用例和測試過程,要保證測試用例完全覆蓋測試需求。設(shè)計測試階段最重要的是如何將測試需求分解,如何設(shè)計測試用例。1.如何對測試需求進(jìn)行分解對測試需求進(jìn)行分解需要反復(fù)檢查并理解各種信息,和用戶交流,理解他們的要求??梢园凑找韵虏襟E執(zhí)行。(1)確定軟件提供的主要任務(wù)。(2)對每個任務(wù),確定完成該任務(wù)所要進(jìn)行的工作。(3)確定從數(shù)據(jù)庫信息引出的計算結(jié)果。

(4)對于對時間有要求的交易,確定所要的時間和條件。(5)確定會產(chǎn)生重大意外的壓力測試,包括內(nèi)存、硬盤空間、高的交易率。(6)確定應(yīng)用需要處理的數(shù)據(jù)量。(7)確定需要的軟件和硬件配置。

(8)確定其他與應(yīng)用軟件沒有直接關(guān)系的商業(yè)交易。(9)確定安裝過程。(10)確定沒有隱含在功能測試中的用戶界面要求。2.如何設(shè)計測試用例測試用例一般指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述,體現(xiàn)測試方案、方法、技術(shù)和策略。值得提出的是,測試數(shù)據(jù)都是從數(shù)量極大的可用測試數(shù)據(jù)中精心挑選出具有代表性或特殊性的。測試用例是軟件測試系統(tǒng)化、工程化的產(chǎn)物,而測試用例的設(shè)計一直是軟件測試工作的重點和難點。

設(shè)計測試用例即設(shè)計針對特定功能或組合功能的測試方案,并編寫成文檔。測試用例應(yīng)該體現(xiàn)軟件工程的思想和原則。

傳統(tǒng)的測試用例文檔編寫有兩種方式。一種是填寫操作步驟列表:將在軟件上進(jìn)行的操作步驟一步一步詳細(xì)記錄下來,包括所有被操作的項目和相應(yīng)的值。另一種是填寫測試矩陣:將被操作項作為矩陣中的一個字段,而矩陣中的一條條記錄,則是這些字段的值。評價測試用例的好壞有以下兩個標(biāo)準(zhǔn)。①是否可以發(fā)現(xiàn)尚未發(fā)現(xiàn)的軟件缺陷?②是否可以覆蓋全部的測試需求?2.6.3實施測試實施測試是指準(zhǔn)備測試環(huán)境、獲得測試數(shù)據(jù)、開發(fā)測試規(guī)程,以及為該過程挑選和準(zhǔn)備輔助測試工具的過程。1.準(zhǔn)備測試環(huán)境(1)測試技術(shù)準(zhǔn)備(2)配置軟件、硬件環(huán)境(3)人員2.獲得測試數(shù)據(jù)需要測試的常見情形如下。(1)正常事務(wù)的測試(2)使用無效數(shù)據(jù)的測試創(chuàng)建測試數(shù)據(jù)時主要考慮如下步驟。

①識別測試資源

②識別測試情形

③排序測試情形

④確定正確的處理結(jié)果

⑤創(chuàng)建測試事務(wù)

確定實際的測試數(shù)據(jù)時,必須說明處理測試數(shù)據(jù)的以下4個屬性。(1)深度(2)寬度(3)范圍(4)結(jié)構(gòu)3.測試腳本概要所謂腳本,是完整的一系列相關(guān)終端的活動。一般測試腳本有5個級別,分別是:單元腳本,用于測試特定單元/模塊的腳本;并發(fā)腳本,用于當(dāng)兩個或多個用戶同時訪問同一文件時測試的腳本;集成腳本,用于確定各模塊是否可以前當(dāng)連接;回歸腳本,用于確定系統(tǒng)未改變的部分在系統(tǒng)改變時是否改變;強度/性能腳本,用于驗證系統(tǒng)在被施加大量事務(wù)時的性能。(1)測試腳本的結(jié)構(gòu)為了提高測試腳本的可維護(hù)性和可復(fù)用性,必須在執(zhí)行測試腳本之前對它們進(jìn)行構(gòu)建。(2)記錄技術(shù)為使測試腳本獲得更高的可維護(hù)性,應(yīng)該以最不易受測試對象變化影響的方式來記錄測試腳本。(3)數(shù)據(jù)驅(qū)動的測試許多測試過程包括在給定的數(shù)據(jù)輸入屏幕內(nèi)輸入幾組字段數(shù)據(jù),檢查字段確認(rèn)功能、錯誤處理等。(4)測試腳本同步和時間安排當(dāng)進(jìn)行重點測試時,通常需要同步測試腳本以便它們在預(yù)先確定的時間啟動。(5)測試和調(diào)試測試腳本在記錄測試腳本的同一測試軟件上執(zhí)行這些最近記錄的測試腳本時,不應(yīng)該發(fā)生任何錯誤。4.輔助測試工具為了實施高效的測試工作,還需要有高效、好用的輔助工具,做軟件測試通常需要以下一些基本工具。①優(yōu)秀的辦公處理軟件②秒表③錯誤跟蹤系統(tǒng)④自動測試工具⑤軟件分析工具⑥好的操作系統(tǒng)⑦多樣化平臺2.6.4執(zhí)行測試執(zhí)行測試是執(zhí)行所有的或選定的一些測試用例,并觀察其測試結(jié)果的過程。盡管為執(zhí)行測試所做的準(zhǔn)備和計劃工作會貫穿于軟件開發(fā)生命周期之中,但是執(zhí)行測試往往都會在軟件開發(fā)生命周期的末期,或者接近末期進(jìn)行,即在編碼完成之后進(jìn)行。由于測試過程一般分成代碼審查、單元測試、集成測試、系統(tǒng)測試和驗收測試幾個階段,盡管這些階段在實現(xiàn)細(xì)節(jié)方面都不相同,但其工作流程方面卻是一致的。

執(zhí)行測試的過程由以下4個部分組成。

①輸入。要完成工作所必須的入口標(biāo)準(zhǔn)或可交付的結(jié)果。

②執(zhí)行過程。從輸入到輸出的過程或工作任務(wù)。

③檢查過程。確定輸出是否滿足標(biāo)準(zhǔn)的處理過程。

④輸出。推出標(biāo)準(zhǔn)或工作流程產(chǎn)生的可交付的結(jié)果。執(zhí)行測試過程如圖2-5所示。圖2-5執(zhí)行測試過程2.6.5評估測試軟件測試的主要評測方法包括測試覆蓋和質(zhì)量評測。測試覆蓋是對測試完全程度的評測,它是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的。質(zhì)量評測是對測試對象(系統(tǒng)或測試的應(yīng)用程序)的可靠性、穩(wěn)定性以及性能的評測,它建立在對測試結(jié)果的評估和對測試過程中確定的變更請求(缺陷)分析的基礎(chǔ)上。1.覆蓋評測覆蓋指標(biāo)提供了“測試的完全程度如何”這一問題的答案。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋。簡而言之,測試覆蓋是就需求(基于需求的)或代碼的設(shè)計/實施標(biāo)準(zhǔn)(基于代碼的)而言的完全程度的任意評測,如用例的核實(基于需求的)或所有代碼行的執(zhí)行(基于代碼的)。2.質(zhì)量評測測試覆蓋的評估提供對測試完全程度的評測,在測試過程中已發(fā)現(xiàn)缺陷的評估提供了最佳的軟件質(zhì)量指標(biāo)。3.性能評測評估測試對象的性能行為時,可以使用多種評測,這些評測側(cè)重于獲取與行為相關(guān)的數(shù)據(jù),如響應(yīng)時間、計時配置文件、執(zhí)行流、操作可靠性和限制。2.7測試的成功經(jīng)驗

為了減少系統(tǒng)的開發(fā)費用,越早測試越好,這是多年來軟件行業(yè)的一個成功經(jīng)驗,即在整個軟件開發(fā)生命周期中通過各種軟件工程技術(shù)盡量早地完成各種軟件測試任務(wù)。首先,軟件的整個測試生命周期是與軟件的開發(fā)生命周期基本平齊的過程

在軟件開發(fā)生命周期中,軟件是通過迭代來不斷加以完善的。在這種環(huán)境中,對于每個作為測試目標(biāo)的工作版本,測試的生命周期還都必須具有一種迭代方法。對于針對每個工作版本執(zhí)行的測試,都做出了增補和改進(jìn),并累積為一個測試體,用于后續(xù)階段的回歸測試。

通過迭代是軟件開發(fā)把原來的整個軟件開發(fā)生命周期分成多個迭代周期,在每個迭代周期都進(jìn)行測試,這樣在很大程度上提前了軟件系統(tǒng)測試發(fā)生的時間,這可以在很大程度上降低項目風(fēng)險和項目開發(fā)成本。第3章軟件測試的方法和技術(shù)3.1軟件測試方法概述3.2白盒測試3.3黑盒測試3.4測試用例設(shè)計3.1軟件測試方法概述

軟件測試的種類大致可分為人工測試和基于計算機(jī)的測試。而基于計算機(jī)的測試又可分為黑盒測試和白盒測試。1.黑盒測試黑盒測試是根據(jù)軟件產(chǎn)品的功能設(shè)計規(guī)格,在計算機(jī)上進(jìn)行測試,以證實每個已經(jīng)實現(xiàn)的功能是否符合要求。黑盒測試意味著測試要在軟件的接口處進(jìn)行。2.白盒測試白盒測試是根據(jù)軟件產(chǎn)品的內(nèi)部工作過程,在計算機(jī)上進(jìn)行測試,以證實每種內(nèi)部操作是否符合設(shè)計規(guī)格要求,所有內(nèi)部成分是否已經(jīng)過檢查。白盒測試把測試對象看做一個打開的盒子,允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息,設(shè)計或選擇測試用例,對程序所有邏輯路徑進(jìn)行測試。通過在不同點檢查程序的狀態(tài),確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致。3.2白盒測試

白盒測試也稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試,前提是知道產(chǎn)品內(nèi)部工作過程,可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行,按照程序內(nèi)部的結(jié)構(gòu)測試程序,檢驗程序中的每條通路是否都能夠按預(yù)定要求正確工作,而不管產(chǎn)品的功能,主要用于軟件驗證。

白盒測試方法又可分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試是一種不通過執(zhí)行程序而進(jìn)行測試的技術(shù),其關(guān)鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義。它瞄準(zhǔn)的是糾正軟件系統(tǒng)在描述、表示和規(guī)格上的錯誤,是任何進(jìn)一步測試的前提。而動態(tài)測試需要軟件的執(zhí)行,當(dāng)軟件系統(tǒng)在模擬的或真實的環(huán)境中執(zhí)行之前、之中和之后,對軟件系統(tǒng)行為的分析是動態(tài)測試的主要特點。它顯示了一個系統(tǒng)在檢查狀態(tài)下是正確還是不正確。

白盒測試的動態(tài)測試要根據(jù)程序的控制結(jié)構(gòu)設(shè)計測試用例,其原則是:(1)保證一個模塊中的所有獨立路徑至少被使用一次;(2)對所有邏輯值均需測試true和false;(3)在上下邊界及可操作范圍內(nèi)運行所有循環(huán);(4)檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。

下面將介紹幾種實用的白盒測試用例設(shè)計方法,包括程序插樁、邏輯覆蓋、基本路徑測試等。3.2.1程序插樁在軟件動態(tài)測試中,程序插樁是一種基本的測試手段,有著廣泛的應(yīng)用。1.方法簡介程序插樁方法是借助往被測程序中插入操作,來實現(xiàn)測試目的的方法。

如果我們想要了解一個程序在某次運行中所有可執(zhí)行語句被覆蓋的情況,或是每個語句的實際執(zhí)行次數(shù),最好的辦法是利用插樁技術(shù)。這里僅以計算整數(shù)X和整數(shù)Y的最大公約數(shù)程序為例,說明插樁方法的要點。圖3-3給出了這一程序的流程圖。圖3-3插樁后求最大公約數(shù)程序的流程圖設(shè)計插樁程序時需要考慮的問題包括:①探測哪些信息;②在程序的什么部位設(shè)置探測點;③需要設(shè)置多少個探測點。2.?dāng)嘌哉Z句在程序中特定部位插入某些用以判斷變量特性的語句,使得程序執(zhí)行中這些語句得以證實,從而使程序的運行特性得到證實。我們把插入的這些語句稱為斷言。這一做法是程序正確性證明的基本步驟,盡管算不上嚴(yán)格的證明,但方法本身仍然是很實用的。下面以求兩個非負(fù)數(shù)NUM和DEN之商的Wensley迭代算法為例,對斷言語句的作用做一簡要說明。圖3-5計算非負(fù)數(shù)之商的迭代程序

圖3-6插入斷言后的迭代程序3.2.2邏輯覆蓋邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù),是通過對程序邏輯結(jié)構(gòu)的遍歷實現(xiàn)程序的覆蓋,它是一系列測試過程的總稱,這組測試過程逐漸進(jìn)行越來越完整的通路測試。這一方法要求測試人員對程序的邏輯結(jié)構(gòu)有清楚的了解,甚至要能掌握源程序的所有細(xì)節(jié)。它屬于動態(tài)測試。

從覆蓋源程序語句的詳細(xì)程度分析,邏輯覆蓋標(biāo)準(zhǔn)有語句覆蓋、判定覆蓋、條件覆蓋、條件判定組合覆蓋、多條件覆蓋和修正條件判定覆蓋。為便于理解,使用如下所示的程序,圖3-7所示的是其流程圖。圖3-7參考例子流程圖intfunction1(boola,boolb,boolc){intx;x=0;if(a&&(b||c))x=1;returnx;}1.語句覆蓋為了暴露程序中的錯誤,程序中的每條語句至少應(yīng)該執(zhí)行一次。所以,語句覆蓋的含義是:選擇足夠多的測試數(shù)據(jù),使被測程序中每條語句至少執(zhí)行一次。2.判定覆蓋比語句覆蓋稍強的覆蓋標(biāo)準(zhǔn)是判定覆蓋。按判定覆蓋準(zhǔn)則進(jìn)行測試是指,設(shè)計若干測試用例,運行被測程序,使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次,即判斷的真假值均曾被滿足。判定覆蓋又稱為分支覆蓋。3.條件覆蓋在設(shè)計程序中,一個判定語句是由多個條件組合而成的復(fù)合判定。條件覆蓋的含義是:構(gòu)造一組測試用例,使得每一判定語句中每個邏輯條件的可能值至少滿足一次。4.條件判定組合覆蓋條件判定組合覆蓋的含義是:設(shè)計足夠的測試用例,使得判定中每個條件的所有可能(真/假)至少出現(xiàn)一次,并且每個判定本身的判定結(jié)果(真/假)也至少出現(xiàn)一次。5.多條件覆蓋多條件覆蓋也稱為條件組合覆蓋,它的含義是:設(shè)計足夠的測試用例,使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。6.修正條件判定覆蓋它要求滿足兩個條件:首先,每一個程序模塊的入口和出口點都要考慮至少被調(diào)用一次,每個程序的判定到所有可能的結(jié)果值要至少轉(zhuǎn)換一次;其次,程序的判定被分解為通過邏輯操作符(and、or)連接的bool條件,每個條件對于判定的結(jié)果值是獨立的。7.測試覆蓋準(zhǔn)則(1)Foster的ESTCA覆蓋準(zhǔn)則前面所介紹的邏輯覆蓋其出發(fā)點似乎是合理的。所謂“覆蓋”,就是想要做到全面而無遺漏。但是,事實表明,它并不能真的做到無遺漏。

K.A.Foster從測試工作實踐的教訓(xùn)出發(fā),吸收了計算機(jī)硬件的測試原理,提出了一種經(jīng)驗型的測試覆蓋準(zhǔn)則。(2)Woodward等人的層次LCSAJ覆蓋準(zhǔn)則

Woodward等人曾經(jīng)指出結(jié)構(gòu)覆蓋的一些準(zhǔn)則,如分支覆蓋或路徑覆蓋,都不足以保證測試數(shù)據(jù)的有效性。為此,他們提出了一種層次LCSAJ覆蓋準(zhǔn)則。3.2.3基本路徑測試上節(jié)的例子是個比較簡單的程序段,只有兩條路徑。但在實際問題中,即使一個不太復(fù)雜的程序,其路徑的組合都是一個龐大的數(shù)字。如果把覆蓋的路徑數(shù)壓縮到一定限度內(nèi),例如,程序中的循環(huán)體只執(zhí)行零次和一次,就成為基本路徑測試。設(shè)計出的測試用例要保證在測試中程序的每一條可執(zhí)行語句至少執(zhí)行一次。1.程序的控制流圖控制流圖是描述程序控制流的一種圖示方式。其中基本的控制結(jié)構(gòu)對應(yīng)的圖形符號如圖3-8所示。在圖3-8所示的圖形符號中,圓圈稱為控制流圖的一個結(jié)點,它表示一個或多個無分支的語句或源程序語句。圖3-8控制流圖的圖形符號

圖3-9(a)所示的是一個程序的流程圖,它可以映射成圖(b)所示的控制流圖。圖3-9程序流程圖和對應(yīng)的控制流圖2.計算程序環(huán)路復(fù)雜性進(jìn)行程序的基本路徑測試時,程序的環(huán)路復(fù)雜性給出了程序基本路徑集合中的獨立路徑條數(shù),這是確保程序中每個可執(zhí)行語句至少執(zhí)行一次所必須的測試用例數(shù)目的上界。所謂獨立路徑,是指包括若干未曾處理的語句或條件的一條路徑。

基本路徑集不是惟一的,對于給定的控制流圖,可以得到不同的基本路徑集。通常環(huán)路復(fù)雜性可用以下3種方法求得。

①將環(huán)路復(fù)雜性定義為控制流圖中的區(qū)域數(shù)。

②設(shè)E為控制流圖的邊數(shù),N為圖的結(jié)點數(shù),則定義環(huán)路的復(fù)雜性為V(G)=E?N+2。

③若設(shè)P為控制流圖中的判定結(jié)點數(shù),則有V(G)=P+1。3.基本路徑測試法步驟基本路徑測試法適用于模塊的詳細(xì)設(shè)計及源程序,其主要步驟如下。

①以詳細(xì)設(shè)計或源代碼作為基礎(chǔ),導(dǎo)出程序的控制流圖。

②計算得到的控制流圖G的環(huán)路復(fù)雜性V(G)。

③確定線性無關(guān)的路徑的基本集。

④生成測試用例,確?;韭窂郊忻織l路徑的執(zhí)行。3.2.4程序的靜態(tài)測試1.源程序靜態(tài)分析在靜態(tài)結(jié)構(gòu)分析中,測試者通過使用測試工具分析程序源代碼的系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)接口、內(nèi)部控制邏輯等內(nèi)部結(jié)構(gòu),生成函數(shù)調(diào)用關(guān)系圖、模塊控制流圖、內(nèi)部文件調(diào)用關(guān)系圖、子程序表、宏和函數(shù)參數(shù)表等各類圖形圖表,可以清晰地標(biāo)識整個軟件系統(tǒng)的組成結(jié)構(gòu),使其便于閱讀與理解,然后可以通過分析這些圖表,檢查軟件有沒有存在缺陷或錯誤。

通常采用以下一些方法進(jìn)行源程序的靜態(tài)分析。(1)生成各種引用表

①標(biāo)號交叉引用表

②變量交叉引用表

③子程序(宏、函數(shù))引用表

④等價表

⑤常數(shù)表(2)錯誤靜態(tài)分析錯誤靜態(tài)分析主要用于確定在源程序中是否有某類錯誤或“危險”結(jié)構(gòu)。

①類型和單位分析

②引用分析

③表達(dá)式分析

④接口分析2.人工測試靜態(tài)分析中進(jìn)行人工測試的主要方法有桌前檢查、代碼審查和走查。經(jīng)驗表明,使用這種方法能夠有效地發(fā)現(xiàn)30%~70%的邏輯設(shè)計和編碼錯誤。(1)桌前檢查由程序員自己檢查自己編寫的程序。程序員在程序通過編譯之后,進(jìn)行單元測試設(shè)計之前,對源程序代碼進(jìn)行分析、檢驗,并補充相關(guān)的文檔,目的是發(fā)現(xiàn)程序中的錯誤。(2)代碼審查代碼審查是由若干程序員和測試員組成一個審查小組,通過閱讀、討論和爭議,對程序進(jìn)行靜態(tài)分析的過程。代碼審查分兩步。第一步,小組負(fù)責(zé)人提前把設(shè)計規(guī)格說明書、控制流程圖、程序文本及有關(guān)要求、規(guī)范等分發(fā)給小組成員,作為審查的依據(jù)。小組成員在充分閱讀這些材料后,進(jìn)入審查的第二步,召開程序?qū)彶闀#?)走查走查與代碼審查基本相同,其過程分為兩步。第一步也把材料先發(fā)給走查小組每個成員,讓他們認(rèn)真研究程序,然后再開會。開會的程序與代碼審查不同,不是簡單地讀程序和對照錯誤檢查表進(jìn)行檢查,而是讓與會者“充當(dāng)”計算機(jī),即首先由測試組成員為被測程序準(zhǔn)備一批有代表性的測試用例,提交給走查小組。走查小組開會,集體扮演計算機(jī)角色,讓測試用例沿程序的邏輯運行一遍,隨時記錄程序的蹤跡,供分析和討論用。3.2.5其他白盒測試方法簡介1.域測試域測試是一種基于程序結(jié)構(gòu)的測試方法。域測試正是在分析輸入域的基礎(chǔ)上,選擇適當(dāng)?shù)臏y試點以后進(jìn)行測試的。2.符號測試符號測試的基本思想是允許程序的輸入不僅僅是具體的數(shù)值數(shù)據(jù),而且包括符號值,這一方法也因此而得名。3.Z路徑覆蓋分析程序中的路徑是指檢驗程序從入口開始,執(zhí)行過程中經(jīng)歷的各個語句,直到出口。4.程序變異程序變異方法是一種錯誤驅(qū)動測試。所謂錯誤驅(qū)動測試方法,是指該方法是針對某類特定程序錯誤的。經(jīng)過多年的測試?yán)碚撗芯亢蛙浖y試的實踐,人們逐漸發(fā)現(xiàn)要想找出程序中所有的錯誤幾乎是不可能的。比較現(xiàn)實的解決辦法是將錯誤的搜索范圍盡可能地縮小,以利于專門測試某類錯誤是否存在。錯誤驅(qū)動測試主要有兩種,即程序強變異和程序弱變異。

最后,歸納一下白盒測試中各種測試方法的應(yīng)用策略。在白盒測試中,可以使用各種測試方法的綜合策略如下。(1)在測試中,應(yīng)盡量先使用工具進(jìn)行靜態(tài)結(jié)構(gòu)分析。(2)測試中可采取先靜態(tài)后動態(tài)的組合方式:先進(jìn)行靜態(tài)結(jié)構(gòu)分析、代碼檢查,再進(jìn)行覆蓋率測試。

(3)利用靜態(tài)分析的結(jié)果作為導(dǎo)引,通過代碼檢查和動態(tài)測試的方式對靜態(tài)發(fā)現(xiàn)結(jié)果進(jìn)行進(jìn)一步的確認(rèn),使測試工作更為有效。(4)覆蓋率測試是白盒測試的重點,一般可使用基本路徑測試法達(dá)到語句覆蓋標(biāo)準(zhǔn);對于軟件的重點模塊,應(yīng)使用多種覆蓋率標(biāo)準(zhǔn)衡量代碼的覆蓋率。

(5)在不同的測試節(jié)點,測試的側(cè)重點不同:在單元測試階段,以代碼檢查、邏輯覆蓋為主;在集成測試階段,需要增加靜態(tài)結(jié)構(gòu)分析等;在系統(tǒng)測試階段,應(yīng)根據(jù)黑盒測試的結(jié)果,采取相應(yīng)的白盒測試。3.3黑盒測試

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試,前提是已知產(chǎn)品所具有的功能,通過測試來檢測每個功能是否都正常使用。黑盒測試方法主要有等價類劃分、邊界值分析、因果圖、錯誤推測、功能圖法等,主要用于軟件確認(rèn)測試。3.3.1等價類劃分法等價類劃分是一種典型的黑盒測試方法。使用這一方法時,完全不考慮程序的內(nèi)部結(jié)構(gòu),只依據(jù)程序的規(guī)格說明來設(shè)計測試用例。由于不可能用所有可以輸入的數(shù)據(jù)來測試程序,而只能從全部可供輸入的數(shù)據(jù)中選擇一個自己進(jìn)行測試。如何選擇適當(dāng)?shù)淖蛹蛊浔M可能多地發(fā)現(xiàn)錯誤,解決的辦法之一就是等價類劃分。

首先,把數(shù)目極多的輸入數(shù)據(jù),包括有效的和無效的,劃分為若干等價類,而所謂等價類,是指某個輸入域的子集合。在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。并合理地假定:測試某等價類的代表值就等價于對這一類其他值的測試。因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可用少量代表性測試數(shù)據(jù),取得較好的測試結(jié)果。等價類的劃分有以下兩種不同的情況。

①有效等價類

②無效等價類劃分等價類的原則如下。①按區(qū)間劃分②按數(shù)值劃分③按數(shù)值集合劃分④按限制條件或規(guī)則劃分

在確立了等價類之后,建立等價類表,列出所有劃分出的等價類,如表3-6所示。

再從劃分出的等價類中按以下原則選擇測試用例。

①為每一個等價類規(guī)定一個惟一的編號。

②設(shè)計一個新的測試用例,使其盡可能多地覆蓋尚未覆蓋的有效等價類;重復(fù)這一步驟,直到所有的有效等價類都被覆蓋為止。

③設(shè)計一個新的測試用例,使其僅覆蓋一個無效等價類,重復(fù)這一步驟,直到所有的無效等價類都被覆蓋為止。3.3.2邊界值分析法人們從長期的測試工作經(jīng)驗得知,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤。使用邊界值分析方法設(shè)計測試用例,首先應(yīng)確定邊界情況。

選擇測試用例的原則如下。

①如果輸入條件規(guī)定了值的范圍,則應(yīng)該取剛達(dá)到這個范圍的邊界值,以及剛剛超過這個范圍邊界的值作為測試輸入數(shù)據(jù)。

②如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù)、最小個數(shù)、比最大個數(shù)多1個、比最小個數(shù)少1個的數(shù)作為測試數(shù)據(jù)。③根據(jù)規(guī)格說明的每一個輸出條件,使用規(guī)則1。

④根據(jù)規(guī)格說明的每一個輸出條件,使用規(guī)則2。

⑤如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合(如有序表、順序文件等),則應(yīng)選取集合的第一個和最后一個元素作為測試用例。⑥如果程序用了一個內(nèi)部結(jié)構(gòu),應(yīng)該選取這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界值作為測試用例。⑦分析規(guī)格說明,找出其他可能的邊界條件。3.3.3錯誤推測法人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤,從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是:列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)它們選擇測試用例。3.3.4因果圖法因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。利用因果圖生成測試用例的基本步驟如下。

①分析軟件規(guī)格說明的描述中哪些是原因,哪些是結(jié)果。原因是輸入條件或輸入條件的等價類,結(jié)果是輸出條件。②分析軟件規(guī)格說明描述中的語義,找出原因與結(jié)果之間、原因與原因之間對應(yīng)的關(guān)系,根據(jù)這些關(guān)系,畫出因果圖。

③標(biāo)明約束條件。由于語法或環(huán)境的限制,有些原因和結(jié)果的組合情況是不可能出現(xiàn)的。為表明這些特定的情況,在因果圖上使用若干標(biāo)準(zhǔn)的符號標(biāo)明約束條件。④把因果圖轉(zhuǎn)換成判定表。

⑤為判定表中的每一列設(shè)計測試用例。通常在因果圖中,用Ci表示原因,Ei表示結(jié)果,其基本符號如圖3-12所示。圖3-12因果圖的基本符號

對于黑盒測試方法來說,以上4種方法是基本的測試方法,除此之外還有判定表驅(qū)動法、正交試驗法、功能圖法和場景法等。在實際測試中,往往是綜合使用各種方法才能有效地提高測試效率和測試覆蓋率,這就需要認(rèn)真掌握這些方法的原理,積累更多的測試經(jīng)驗,以有效地提高測試水平。

以下是各種測試方法選擇的綜合策略,可供讀者在實際應(yīng)用過程中參考。

①首先進(jìn)行等價類劃分,包括輸入條件和輸出條件的等價劃分,將無限測試變成有限測試,這是減少工作量和提高測試效率最有效的方法。

②在任何情況下都必須使用邊界值分析方法。經(jīng)驗表明,用這種方法設(shè)計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強。③可以用錯誤推測法追加一些測試用例,這需要依靠測試工程師的智慧和經(jīng)驗。

④對照程序邏輯,檢查已設(shè)計出的測試用例的邏輯覆蓋程度。如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn),應(yīng)當(dāng)再補充足夠的測試用例。

⑤如果程序的功能說明中含有輸入條件的組合情況,則一開始就可選用因果圖法和判定表驅(qū)動法。⑥對于參數(shù)配置類的軟件,要用正交試驗法選擇較少的組合方式達(dá)到最佳效果。

⑦功能圖法也是很好的測試用例設(shè)計方法,我們可以通過不同時期條件的有效性設(shè)計不同的測試數(shù)據(jù)。

⑧對于業(yè)務(wù)流清晰的系統(tǒng),可以利用場景法貫穿整個測試案例過程,在案例中綜合使用各種測試方法。3.3.5場景法現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的,事件觸發(fā)時的情景便形成了場景,而同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流。這種在軟件設(shè)計方面的思想也可以引入到軟件測試中,可以比較生動地描繪出事件觸發(fā)時的情景,有利于測試設(shè)計者設(shè)計測試用例,同時使測試用例更容易理解和執(zhí)行。

用例場景用來描述流經(jīng)用例的路徑,從用例開始到結(jié)束遍歷這條路徑上所有基本流和備選流。1.基本流和備選流

如圖3-14所示,圖中經(jīng)過用例的每條路徑都用基本流和備選流來表示,直黑線表示基本流,是經(jīng)過用例的最簡單的路徑。備選流用不同的色彩表示,一個備選流可能從基本流開始,在某個特定條件下執(zhí)行,然后重新加入基本流中(如備選流1和3);也可能起源于另一個備選流(如備選流2),或者終止用例而不再重新加入到某個流(如備選流2和4)。圖3-14基本流和備選流2.ATM例子(1)例子描述圖3-15所示是ATM例子的流程示意圖。圖3-15ATM流程示意圖(2)場景設(shè)計表3-8所示是生成的場景。(3)用例設(shè)計對于這7個場景中的每一個場景都需要確定測試用例??梢圆捎镁仃嚮驔Q策表來確定和管理測試用例。下面顯示了一種通用格式,其中各行代表各個測試用例,而各列則代表測試用例的信息。本示例中,對于每個測試用例,存在一個測試用例ID、條件(或說明)、測試用例中涉及的所有數(shù)據(jù)元素(作為輸入或已經(jīng)存在于數(shù)據(jù)庫中)以及預(yù)期結(jié)果。(4)數(shù)據(jù)設(shè)計一旦確定了所有的測試用例,則應(yīng)對這些用例進(jìn)行復(fù)審和驗證以確保其準(zhǔn)確且適度,并取消多余或等效的測試用例。測試用例一經(jīng)認(rèn)可,就可以確定實際數(shù)據(jù)值(在測試用例實施矩陣中)并且設(shè)定測試數(shù)據(jù),如表3-10所示。3.4測試用例設(shè)計

3.4.1測試用例的基本概念簡單地說,測試用例就是設(shè)計一個情況,軟件程序在這種情況下,必須能夠正常運行并且達(dá)到程序所設(shè)計的執(zhí)行結(jié)果。

如果程序在這種情況下不能正常運行,而且這種問題會重復(fù)發(fā)生,那就表示已經(jīng)測出軟件有缺陷,這時候就必須將這個問題標(biāo)示出來,并且輸入到問題跟蹤系統(tǒng)內(nèi),通知軟件開發(fā)人員。軟件開發(fā)人員接到通知后,將問題修改完成于下一個測試版本內(nèi),測試工程師取得新的測試版本后,必須利用同一個測試用例來測試這個問題,確保該問題已修改完成。

在測試時,不可能進(jìn)行窮舉測試,為了節(jié)省時間和資源,提高測試效率,必須要從數(shù)量極大的可用測試數(shù)據(jù)中精心挑選出具有代表性或特殊性的測試數(shù)據(jù)來進(jìn)行測試。

使用測試用例的好處主要體現(xiàn)在以下幾個方面。

①在開始實施測試之前設(shè)計好測試用例,可以避免盲目測試并提高測試效率。

②測試用例的使用令軟件測試的實施重點突出、目的明確。③在軟件版本更新后只需修正少部分的測試用例便可開展測試工作,降低工作強度,縮短項目周期。

④功能模塊的通用化和復(fù)用化使軟件易于開發(fā),而測試用例的通用化和復(fù)用化則會使軟件測試易于開展,并隨著測試用例的不斷精化其效率也不斷提高。

測試用例主要有如下幾種。

①功能測試用例。包含功能測試、健壯性測試、可靠性測試。

②性能測試用例。包含性能測試、壓力測試、強度測試。

③集成測試用例。包含接口測試、健壯性測試、可靠性測試。④安全測試用例。安全測試用例。⑤用戶界面測試用例。用戶界面測試用例、少量功能測試用例。⑥安裝/反安裝測試用例。安裝/反安裝測試用例。測試種類、階段和用例的關(guān)系如表3-11所示。

測試工作和開發(fā)通常一同進(jìn)行,所以在完成測試計劃編寫后,就可以進(jìn)行用例的編寫工作了。測試和開發(fā)的對應(yīng)關(guān)系如表3-12所示。3.4.2測試用例的設(shè)計步驟測試按照階段分為單元測試、集成測試以及系統(tǒng)測試。而各階段都有相應(yīng)的測試用例。這里,以單元測試的用例設(shè)計為依據(jù)來說明測試用例的設(shè)計步驟。

單元測試說明實際上由一系列單元測試用例組成,每個測試用例應(yīng)該包含以下4個關(guān)鍵元素。

①被測單元模塊初始狀態(tài)聲明,即測試用例的開始狀態(tài)(僅適用于被測單元維持了調(diào)用間狀態(tài)的情況)。

②被測單元的輸入,包含由被測單元讀入的任何外部數(shù)據(jù)值。③該測試用例實際測試的代碼,用被測單元的功能和測試用例設(shè)計中使用的分析來說明,如單元中哪一個決策條件被測試。

④測試用例的期望輸出結(jié)果。測試用例的期望輸出結(jié)果總是應(yīng)該在測試進(jìn)行之前在測試說明中定義。下面說明測試用例的設(shè)計步驟。(1)步驟1:使被測單元運行這個階段適合的技術(shù)有:

①模塊設(shè)計導(dǎo)出的測試;

②對等區(qū)間劃分。(2)步驟2:正面測試(PositiveTesting)這個階段適合的技術(shù)有:

①設(shè)計說明導(dǎo)出的測試;

②等價類分析;

③狀態(tài)轉(zhuǎn)換測試。(3)步驟3:負(fù)面測試(NegativeTesting)這個階段適合的技術(shù)有:

①錯誤猜測;

②邊界值分析;

③內(nèi)部邊界值測試;

④狀態(tài)轉(zhuǎn)換測試。(4)步驟4:需求中其他測試特性用例設(shè)計這個階段適合的技術(shù)有:設(shè)計說明導(dǎo)出的測試。(5)步驟5:覆蓋率測試用例設(shè)計這個階段適合的技術(shù)有:

①分支測試;

②條件測試;

③數(shù)據(jù)定義——使用測試;

④狀態(tài)轉(zhuǎn)換測試。其中①和②均屬于邏輯覆蓋范疇。(6)步驟6:測試執(zhí)行(7)步驟7:完善代碼覆蓋這個階段適合的技術(shù)有:

①分支測試;

②條件測試;

③設(shè)計定義——試驗測試;

④狀態(tài)轉(zhuǎn)換測試。最后,總結(jié)一下用例設(shè)計的一般原則。

通常應(yīng)該避免依賴先前測試用例的輸出,測試用例的執(zhí)行序列早期發(fā)現(xiàn)的錯誤可能導(dǎo)致其他的錯誤而減少測試執(zhí)行時實際測試的代碼量。

測試用例設(shè)計過程中,包括作為試驗執(zhí)行這些測試用例時,常??梢栽谲浖?gòu)建前就發(fā)現(xiàn)BUG。還有可能在測試設(shè)計階段比測試執(zhí)行階段發(fā)現(xiàn)更多的BUG。

在整個單元測試設(shè)計中,主要的輸入應(yīng)該是被測單元的設(shè)計文檔。在某些情況下,需要將試驗實際代碼作為測試設(shè)計過程的輸入,測試設(shè)計者必須意識到不是在測試代碼本身。3.4.3測試用例的編寫1.測試用例計劃的編寫2.測試設(shè)計說明3.測試用例說明測試用例的編寫請參考表3-13。表3-13 測試用例

4.測試程序說明圖3-16所示是“Windows計算器”的測試程序說明的例子片斷。圖3-16測試程序說明片斷3.4.4測試用例設(shè)計實例1.軟件設(shè)計說明導(dǎo)出的測試2.基本路徑測試3.等價類劃分4.因果圖法5.邊界值分析3.4.5測試用例的管理可以把測試用例看成程序——測試工程師編寫的程序,這個程序也要經(jīng)過“設(shè)計”、“開發(fā)”、“測試”、“版本管理”、“發(fā)布”、“維護(hù)”等一系列操作。1.用例評審有效的用例評審?fù)ǔS上旅鎯煞N形式組成。①測試部門外部評審②測試部門內(nèi)部評審?fù)ǔG闆r下先執(zhí)行內(nèi)部評審,然后執(zhí)行外部評審。很多時候,內(nèi)部評審會被忽略,建議要進(jìn)行內(nèi)部評審。2.用例管理版本管理是用例管理的核心部分,建議采用工具(例如VisualSourceSafe)對用例進(jìn)行控制。建議用例參照圖3-19進(jìn)行管理。圖3-19用例管理示意圖第

4章

軟件測試過程4.1軟件測試過程概述4.2單元測試4.3集成測試4.4系統(tǒng)測試4.5驗收測試4.6回歸測試4.7系統(tǒng)排錯4.1軟件測試過程概述

軟件測試過程與軟件工程的開發(fā)過程是相對的。第2章圖2-1采用V形圖表示軟件開發(fā)與軟件測試的對應(yīng)關(guān)系,也可以采用圖4-1所示的螺旋形圖來表示這種關(guān)系。圖4-1測試過程

單元測試的目的是保證每個模塊單獨運行正確,多采用白盒技術(shù),檢查模塊控制結(jié)構(gòu)的某些特殊路徑,期望覆蓋盡可能多的出錯點。經(jīng)單元測試后的模塊,組裝為軟件包,對軟件包進(jìn)行集成測試,主要測試軟件結(jié)構(gòu)問題,因測試建立在模塊間的接口上,所以多為黑盒測試,適當(dāng)輔以白盒測試技術(shù),以便能對主要控制路徑進(jìn)行測試。

系統(tǒng)測試主要是檢驗軟件是否滿足功能、行為和性能方面的要求,這一步完全采用黑盒測試技術(shù)。驗收測試是檢驗軟件產(chǎn)品的最后一道工序,與前面各種測試過程的不同之處主要在于它突出了客戶的作用,同時軟件開發(fā)人員也要參與。4.2單元測試

單元測試是對軟件設(shè)計的最小單元——模塊進(jìn)行正確性檢驗的測試工作,主要測試模塊在語法、格式和邏輯上的錯誤。

單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑進(jìn)行測試,以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試是檢查軟件源程序的第一次機(jī)會,通過孤立地測試每個單元,確保每個單元工作正常,這樣比單元作為一個更大系統(tǒng)的一個部分更容易發(fā)現(xiàn)問題。在單元測試中,每個程序模塊可以并行、獨立地進(jìn)行測試工作。4.2.1單元測試的主要任務(wù)單元測試是針對每個程序模塊進(jìn)行測試,單元測試的主要任務(wù)是解決以下5個方面的測試問題。1.模塊接口測試針對模塊接口測試應(yīng)進(jìn)行的檢查,主要涉及以下幾方面的內(nèi)容。①模塊接受輸入的實際參數(shù)個數(shù)與模塊的形式參數(shù)個數(shù)是否一致。

②輸入的實際參數(shù)與模塊的形式參數(shù)的類型是否匹配。

③輸入的實際參數(shù)與模塊的形式參數(shù)所使用單位是否一致。④調(diào)用其他模塊時,所傳送的實際參數(shù)個數(shù)與被調(diào)用模塊的形式參數(shù)的個數(shù)是否相同。

⑤調(diào)用其他模塊時,所傳送的實際參數(shù)與被調(diào)用模塊的形式參數(shù)的類型是否匹配。

⑥調(diào)用其他模塊時,所傳送的實際參數(shù)與被調(diào)用模塊的形式參數(shù)的單位一致。

⑦調(diào)用內(nèi)部函數(shù)時,參數(shù)的個數(shù)、屬性和次序是否正確。⑧在模塊有多個入口的情況下,是否有引用與當(dāng)前入口無關(guān)的參數(shù)。⑨是否會修改了只讀型參數(shù)。⑩出現(xiàn)全局變量時,這些變量是否在所有引用它們的模塊中都有相同的定義。11.有沒有把某些約束當(dāng)做參數(shù)來傳送。2.模塊局部數(shù)據(jù)結(jié)構(gòu)測試3.模塊中所有獨立執(zhí)行路徑測試4.各種錯誤處理測試5.模塊邊界條件測試4.2.2單元測試的執(zhí)行過程一般情況下,在完成了程序編寫、復(fù)查和語法正確性驗證后,就應(yīng)進(jìn)行單元測試。測試用例設(shè)計應(yīng)與復(fù)審工作相結(jié)合,根據(jù)設(shè)計信息選取數(shù)據(jù),將增大發(fā)現(xiàn)上述各類錯誤的可能性。

在進(jìn)行單元測試時,需設(shè)置若干輔助測試模塊。輔助模塊有兩種,一種是驅(qū)動模塊(Driver),用以模擬被測試模塊的上級模塊。另一種是被調(diào)用模擬子模塊(Sub),用以模擬被測模塊工作過程中所調(diào)用的模塊。圖4-2顯示了一般的單元測試環(huán)境。圖4-2一般單元測試環(huán)境4.2.3單元測試技術(shù)和測試數(shù)據(jù)用于單元測試的主要技術(shù)如下。1.靜態(tài)測試2.白盒測試3.狀態(tài)轉(zhuǎn)換測試4.功能測試和非功能測試

單元測試中使用的數(shù)據(jù),通常不使用真實數(shù)據(jù)。當(dāng)被測試單元的功能不涉及操縱或使用大量數(shù)據(jù)時,測試中可以使用有代表性的一小部分手工制作的測試數(shù)據(jù)。在創(chuàng)建測試數(shù)據(jù)時,應(yīng)確保數(shù)據(jù)充分地測試單元的邊界條件。當(dāng)被測試單元要操縱大量數(shù)據(jù),并且有很多單元都有這種需求時,可以考慮使用真實數(shù)據(jù)的一個較小的有代表性的樣本。測試時還要考慮往樣本數(shù)據(jù)中引入一些手工制作的數(shù)據(jù),以便測試單元的某個具體特性,例如對錯誤條件的響應(yīng)等。

當(dāng)測試一個單元要從遠(yuǎn)程數(shù)據(jù)源接收數(shù)據(jù)時(例如,從一個客戶端/服務(wù)器系統(tǒng)中接收數(shù)據(jù)),有必要在單元測試中使用測試輔助程序,來模擬對這些數(shù)據(jù)的訪問。但在考慮這種選擇時,必須首先對開發(fā)的測試輔助程序進(jìn)行測試,以保證模擬的真實性。4.2.4單元測試人員單元測試一般由開發(fā)設(shè)計人員本身完成,一般由開發(fā)組在組長的監(jiān)督下進(jìn)行,由編寫該單元的開發(fā)設(shè)計者設(shè)計所需的測試用例和測試數(shù)據(jù),來測試該單元并修改缺陷。開發(fā)組組長負(fù)責(zé)保證使用合適的測試技術(shù),在合理的質(zhì)量控制和監(jiān)督下執(zhí)行充分的測試。4.3集成測試將經(jīng)過單元測試的模塊按設(shè)計要求連接起來,組成所規(guī)定的軟件系統(tǒng)的過程稱為“集成”。4.3.1集成測試的主要任務(wù)集成測試是組裝軟件的系統(tǒng)測試技術(shù)之一,按設(shè)計要求把通過單元測試的各個模塊組裝在一起之后,進(jìn)行集成測試的主要任務(wù)是要求軟件系統(tǒng)符合實際軟件結(jié)構(gòu),發(fā)現(xiàn)與接口有關(guān)的各種錯誤。單元測試的主要任務(wù)是解決以下5個方面的測試問題。①將各模塊連接起來,檢查模塊相互調(diào)用時,數(shù)據(jù)經(jīng)過接口是否丟失。

②將各個子功能組合起來,檢查能否達(dá)到預(yù)期要求的各項功能。

③一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響。

④全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題,會不會被異常修改。

⑤單個模塊的誤差積累起來,是否被放大,從而達(dá)到不可接受的程度。4.3.2集成測試方法集成測試包括兩種不同方法:非增量式集成和增量式集成。1.非增量式測試方法概括來說,非增量式測試方法是采用一步到位的方法來進(jìn)行測試,即對所有模塊進(jìn)行個別的單元測試后,按程序結(jié)構(gòu)圖將各模塊連接起來,把連接后的程序當(dāng)做一個整體進(jìn)行測試。圖4-3給出的是采用這種非增量式的集成測試方法的一個經(jīng)典例子。2.增量式測試方法(1)自頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按結(jié)構(gòu)圖自上而下進(jìn)行的。即模塊集成的順序是首先集成主控模塊(主程序),然后按照軟件控制層次結(jié)構(gòu)向下進(jìn)行集成。圖4-4自頂向下集成集成測試的整個過程由下列3個步驟完成。

①主控模塊作為測試驅(qū)動器,把對主控模塊進(jìn)行單元測試時引入的被調(diào)用模擬子模塊用實際模塊替代。

②依照所選用的模塊集成策略(深度優(yōu)先和廣度優(yōu)先),下層的被調(diào)用模擬子模塊一次一個地被替換為真正的模塊。

③在每個模塊被集成時,都必須立即進(jìn)行測試一遍。

回到第2步重復(fù)進(jìn)行,直到整個系統(tǒng)結(jié)構(gòu)被集成完成。圖4-5給出了一個按廣度優(yōu)先策略進(jìn)行集成測試的典型例子。圖4-5自頂向下增量式測試(廣度優(yōu)先策略)(2)自底向上增量式測試自底向上增量式測試是從最底層的模塊開始,按結(jié)構(gòu)圖自下而上逐步進(jìn)行集成和測試。圖4-6表示了采用自底向上增量式測試實現(xiàn)同一實例的過程。圖4-6自底向上增量式測試4.3.3集成測試技術(shù)和測試數(shù)據(jù)集成測試主要測試軟件的結(jié)構(gòu)問題,因為測試建立在模塊的接口上,所以多為黑盒測試,適當(dāng)輔以白盒測試。

執(zhí)行集成測試應(yīng)遵循下面的方法。

①確認(rèn)組成一個完整系統(tǒng)的模塊之間的關(guān)系。

②評審模塊之間的交互和通信需求,確認(rèn)出模塊間的接口。

③使用上述信息產(chǎn)生一套測試用例。

④采用增量式測試,依次將模塊加入到(擴(kuò)充)系統(tǒng),并測試新合并后的系統(tǒng),這個過程以一個邏輯/功能順序重復(fù)進(jìn)行,直至所有模塊被功能集成進(jìn)來形成完整的系統(tǒng)為止。

此外,在測試過程中尤其要注意關(guān)鍵模塊,所謂關(guān)鍵模塊一般都具有下述一個或多個特征。

①對應(yīng)幾條需求。

②具有高層控制功能。

③復(fù)雜,易出錯。

④有特殊的性能要求。

因為集成測試的主要目的是驗證組成軟件系統(tǒng)的各模塊的接口和交互作用,因此集成測試對數(shù)據(jù)的要求無論從難度和內(nèi)容來說一般不是很高。集成測試一般也不使用真實數(shù)據(jù),測試人員可以使用手工制作一部分代表性的測試數(shù)據(jù)。在創(chuàng)建測試數(shù)據(jù)時,應(yīng)保證數(shù)據(jù)充分測試軟件系統(tǒng)的邊界條件。在單元測試時,根據(jù)需要生成了一些測試數(shù)據(jù),在集成測試時可適當(dāng)?shù)刂赜眠@些數(shù)據(jù),這樣可節(jié)省時間和人力。4.3.4集成測試遵循的原則集成測試很不好把握,應(yīng)針對總體設(shè)計盡早開始籌劃。為了做好集成測試,需要遵循以下原則。①所有公共接口都要被測試到。②關(guān)鍵模塊必須進(jìn)行充分的測試。③集成測試應(yīng)當(dāng)按一定的層次進(jìn)行。④集成測試的策略選擇應(yīng)當(dāng)綜合考慮質(zhì)量、成本和進(jìn)度之間的關(guān)系。

⑤集成測試應(yīng)當(dāng)盡早開始,并以總體設(shè)計為基礎(chǔ)。

⑥在模塊與接口的劃分上,測試人員應(yīng)當(dāng)和開發(fā)人員進(jìn)行充分的溝通。

⑦當(dāng)接口發(fā)生修改時,涉及的相關(guān)接口必須進(jìn)行再測試。

⑧測試執(zhí)行結(jié)果應(yīng)當(dāng)如實記

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論