第9章面向?qū)ο蟮臏y試課件_第1頁
第9章面向?qū)ο蟮臏y試課件_第2頁
第9章面向?qū)ο蟮臏y試課件_第3頁
第9章面向?qū)ο蟮臏y試課件_第4頁
第9章面向?qū)ο蟮臏y試課件_第5頁
已閱讀5頁,還剩44頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

第9章面向?qū)ο蟮臏y試

測試是軟件開發(fā)周期的最后一個階段,也是保證軟件質(zhì)量至關(guān)重要的一個環(huán)節(jié)。

本章學(xué)習(xí)內(nèi)容9.1軟件測試的概念9.2黑盒測試9.3白盒測試9.4多模塊程序的測試9.5面向?qū)ο蟮臏y試方法9.1軟件測試的概念一、軟件測試的概念1.什么是軟件測試軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。通過在計算機上執(zhí)行程序,暴露程序中潛在的錯誤。然后對程序錯誤進(jìn)行糾錯。2.軟件測試的目的(1)以最少的時間和人力,系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試,我們就能夠發(fā)現(xiàn)軟件中的錯誤。(2)測試的附帶收獲是,它能夠證明軟件的功能和性能與需求說明相符合。(3)實施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。(4)測試不能表明軟件中不存在錯誤,它只能說明軟件中存在錯誤。3.測試與糾錯的關(guān)系測試評價糾錯程序測試用例測試結(jié)果期望結(jié)果錯誤信息改正信息4.軟件測試的指導(dǎo)原則(1)應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘。(2)測試用例應(yīng)由測試輸入數(shù)據(jù)和對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。(3)程序員應(yīng)避免檢查自己的程序。(4)在設(shè)計測試用例時,應(yīng)包括合理的輸入條件和不合理的輸入條件。(5)充分注意測試中的群集現(xiàn)象。經(jīng)驗表明,測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。(6)嚴(yán)格執(zhí)行測試計劃,排除測試的隨意性。(7)應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查。(8)妥善保存測試計劃,測試用例,出錯統(tǒng)計和最終分析報告,為維護(hù)提供方便。二、軟件測試的特性1.挑剔性

測試是為了證明程序有錯,而不是證明程序無錯。因此,只有抱著為證明程序有錯的目的去測試,才能把程序中潛在的大部分錯誤找出來。

2.復(fù)雜性

設(shè)計測試用例是一項需要細(xì)致和高度技巧的工作,稍有不慎就會顧此失彼,發(fā)生不應(yīng)有的疏漏。

3.不徹底性

“程序測試只能證明錯誤的存在,但不能證明錯誤不存在”。也就是說一切實際測試都是不徹底的,不能夠保證測試后的程序不存在遺留的錯誤。

4.經(jīng)濟(jì)性

為了降低測試成本,在程序測試中,選擇一些典型的、有代表性的測試用例,進(jìn)行有限的測試。以便能使用盡可能少的測試用例,發(fā)現(xiàn)盡可能多的程序錯誤。

三、軟件測試的種類及測試的文檔1.測試種類程序測試靜態(tài)分析(程序不執(zhí)行)動態(tài)測試(程序執(zhí)行)靜態(tài)分析器分析(自動方式)人工方式代碼評審代碼會審走查辦公桌檢查黑盒測試(測試程序功能)白盒測試(測試程序結(jié)構(gòu))2測試文檔為了保證測試質(zhì)量,軟件測試必須完成規(guī)定的文檔。按照軟件工程的要求,測試文檔主要應(yīng)包括:測試計劃、測試報告兩個方面的內(nèi)容。

測試計劃的主體是“測試內(nèi)容說明”,它包括測試項目的名稱、各項測試的目的、步驟、進(jìn)度以及測試用例的設(shè)計等。

測試報告的主體是“測試結(jié)果”,它包括測試項目名稱、實測結(jié)果與期望結(jié)果的比較、發(fā)現(xiàn)的問題以及測試達(dá)到的效果等。

3測試用例和測試結(jié)果的定義

測試用例

={測試數(shù)據(jù)

+期望結(jié)果}

測試結(jié)果

={測試數(shù)據(jù)

+期望結(jié)果

+實際結(jié)果}9.2黑盒測試黑盒測試就是把測試程序看成是一個黑盒子,測試人員只針對輸入與輸出的關(guān)系,對被測試程序功能及外部特性進(jìn)行測試,而不考慮其內(nèi)部邏輯和內(nèi)部特性,所以也稱為功能測試。用黑盒法設(shè)計測試用例,常用技術(shù)有:等價分類法、邊界值分析法、錯誤猜測法等。一、等價分類法1.特點

等價分類法就是把輸入數(shù)據(jù)的可能值劃分為若干等價類,使每類中的任何一個測試用例,都能代表同一等價類中的其它測試用例。

例:某工廠公開招工,規(guī)定報名者年齡應(yīng)在16周歲至35周歲之間(假定到2002年3月30日止)。即出生年月不在上述范圍內(nèi),將拒絕接受,并顯示“年齡不合格”等出錯信息。試用等價分類法設(shè)計對這一程序功能的測試用例。解第一步:劃分等價類。假定已知出生年月由6位數(shù)字字符表示,前4位代表年,后2位代表月,則可以劃分為3個有效等價類,7個無效等價類,如下表所示。

輸入數(shù)據(jù)有效等價類無效等價類出生年月(1)6位數(shù)字字符(2)有非數(shù)字字符(3)少于6個數(shù)字符(4)多于6個數(shù)字符對應(yīng)數(shù)值(5)在196702~198603之間(6)<196702(7)>198603月份對應(yīng)數(shù)值(8)在1~12之間(9)等于“0”(10)>12第二步:設(shè)計有效等價類需要的測試用例。上表中的(1),(5),(8)等3個有效等價類,可以公用一個測試用例,例如:測試數(shù)據(jù)期望結(jié)果測試范圍

197011輸入有效(1),(5),(8)第三步:為每一無效等價類至少設(shè)計一個測試用例。本例具有7個無效等價類,需要7個測試用例:

測試數(shù)據(jù)期望結(jié)果測試范圍

MAY,70輸入無效(2)

19705輸入無效(3)1970011輸入無效(4)195512年齡不合格(6)197012年齡不合格(7)196200輸入無效(9)196222輸入無效(10)2.采用這一技術(shù)要注意以下兩點:

1)劃分等價類不僅要考慮代表“有效”輸入值的有效等價類,還須考慮代表“無效”輸入值的無效等價類;2)每一無效等價類至少要用一個測試用例,不然就可能漏掉某一類錯誤,但允許若干有效等價類合用同一個測試用例。二、邊界值分析法1.含義所謂邊界值分析,就是要把測試的重點放在各個等價類的邊界上,選取剛好等于、剛剛大于和剛剛小于邊界值的數(shù)據(jù)為測試數(shù)據(jù),并據(jù)此設(shè)計出相應(yīng)的測試用例。

2.特點

由于在處理邊界情況時,很容易因疏忽或考慮不周發(fā)生編碼錯誤,采用邊界值分析法,就是要這樣來選擇在邊界值及其附近運行的測試用例,使得被測程序能更有效地暴露程序中潛藏的錯誤。

[例]程序同上例。試用邊界值分析法設(shè)計其測試用例。[解]用等價分類法設(shè)計測試用例時,測試數(shù)據(jù)可以在等價類值域內(nèi)任意選取。就拿上例來說,為了只接受年齡合格的報名者,程序中可能設(shè)有語句

if(196702<=value(birthdate)<=198603)thenread(birthdate)elsewrite“invalidage”

三、錯誤猜測法1.特點就是猜測被測程序在哪些地方容易出錯,然后針對可能的薄弱環(huán)節(jié)來設(shè)計測試用例。它比前2種方法更多地依靠測試人員的直覺與經(jīng)驗。9.3白盒測試白盒測試是對系統(tǒng)的內(nèi)部過程性細(xì)節(jié)做細(xì)致的檢查,把被測試的程序看成是透明的盒子,所以也稱為結(jié)構(gòu)測試。用白盒法設(shè)計測試用例,常用技術(shù)有:邏輯覆蓋測試法、路徑測試法等。一、邏輯覆蓋測試法1.特點

邏輯覆蓋測試法通過流程圖來設(shè)計測試用例,它考察的重點是圖中的判定框(菱形框)。因為這些判定若不是與選擇結(jié)構(gòu)有關(guān),就是與循環(huán)結(jié)構(gòu)有關(guān),是決定程序結(jié)構(gòu)的關(guān)鍵成份。

2.邏輯覆蓋測試的5種覆蓋標(biāo)準(zhǔn)發(fā)現(xiàn)錯誤的能力

強語句覆蓋每條語句至少執(zhí)行一次判定覆蓋每一判定的每個分支至少執(zhí)行一次條件覆蓋每一判定中的每個條件,分別按“真”、“假”至少各執(zhí)行一次判定/條件覆蓋同時滿足判定覆蓋和條件覆蓋的要求條件組合覆蓋求出判定中所有條件的各種可能組合值,每一可能的條件組合至少執(zhí)行一次二、路徑測試法1.含義

路徑測試就是著眼于程序執(zhí)行路徑的測試方法,對程序圖中每一條可能的程序執(zhí)行路徑至少測試一次。如果程序中含有循環(huán)(在程序圖中表現(xiàn)為環(huán)),則每個循環(huán)至少執(zhí)行一次。

2.特點1)滿足結(jié)構(gòu)測試的最低要求。

2)

有利于安排循環(huán)測試。

9.4多模塊程序的測試實際的應(yīng)用程序大都是多模塊程序,在軟件工程中,軟件測試主要指多模塊程序的測試。多模塊程序要比單模塊小程序復(fù)雜得多。這種復(fù)雜性的主要表現(xiàn)是測試的層次性,多模塊程序的測試共包括4個層次。第一層為單元測試

第二層為集成測試第三層為確認(rèn)測試第四層是系統(tǒng)測試

一、單元測試1.含義

以模塊或子程序為單位進(jìn)行測試,又稱模塊測試。2.目的與任務(wù)目的:是通過對模塊的靜態(tài)分析與動態(tài)測試,使其代碼達(dá)到模塊說明書的需求。任務(wù):對模塊代碼進(jìn)行編譯,發(fā)現(xiàn)并糾正其語法錯誤;對模塊代碼進(jìn)行靜態(tài)分析,并據(jù)此設(shè)計一組測試用例和必要的測試軟件;用選定的測試用例對模塊進(jìn)行測試,直至滿足測試終止標(biāo)準(zhǔn)為止;最后,編制單元測試報告。

3.測試步驟編譯--其檢查對象是代碼中的語法錯誤。

靜態(tài)分析器檢查代碼評審動態(tài)測試--重點是發(fā)現(xiàn)單元的功能性錯誤。

檢查對象已從語法錯誤改變?yōu)橐越Y(jié)構(gòu)性錯誤為主的其它錯誤

4.特點

單元不是獨立的程序。在多模塊程序中,每一模塊都可能調(diào)用其它模塊或者被其它模塊所調(diào)用。所以在單元測試時,需要為被測模塊編制若干測試軟件,給它的上級模塊或下級模塊作替身。替身模塊應(yīng)該是真實模塊的簡化,僅須模擬與被測模塊直接相關(guān)的一部分功能。二、集成測試1.含義

通過了單元測試的模塊,按照一定的策略在組裝為完整的程序的過程中進(jìn)行的測試,稱為集成測試或組裝測試。2.目的與任務(wù)

是將經(jīng)過單元測試的模塊逐步組裝成具有良好一致性的完整的程序。

三、確認(rèn)測試1.含義

確認(rèn)測試是對整個程序的測試,用于確認(rèn)組裝完畢的程序確能滿足用戶的全部需求。2.目的與任務(wù)

確認(rèn)測試?yán)^集成測試之后進(jìn)行,其目的在于確認(rèn)組裝完畢的程序是否滿足軟件需求規(guī)格說明書(SRS)的要求。

四、系統(tǒng)測試1.含義

系統(tǒng)測試是將已經(jīng)確認(rèn)的軟件、計算機硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起,進(jìn)行軟件系統(tǒng)的各種組裝測試和確認(rèn)測試。2.目的與任務(wù)

測試的目的,是檢查把確認(rèn)測試合格的軟件安裝到系統(tǒng)中以后,能否與系統(tǒng)的其余部分協(xié)調(diào)運行,并且完成SRS對它的要求。9.5面向?qū)ο蟮臏y試方法面向?qū)ο鬁y試應(yīng)擴大到包括對OOA和OOD模型的復(fù)審,以便及早發(fā)現(xiàn)錯誤。面向?qū)ο筌浖腔陬?對象的,而傳統(tǒng)軟件則基于模塊。

一、面向?qū)ο筌浖臏y試面向?qū)ο筌浖y試和傳統(tǒng)軟件測試一樣,也是從單元測試開始,然后經(jīng)集成測試,最后進(jìn)入確認(rèn)與系統(tǒng)測試的。1.面向?qū)ο筌浖膯卧獪y試

(1)面向?qū)ο筌浖膯卧獪y試是對類和對象進(jìn)行測試(2)面向?qū)ο筌浖念悳y試是由封裝在類中的操作和類的狀態(tài)行為所驅(qū)動的。

(3)在面向?qū)ο蟮膯卧獪y試中不僅要發(fā)現(xiàn)類的所有操作中存在的問題,還要考查一個類與其他的類協(xié)同工作時可能出現(xiàn)的錯誤。

2.面向?qū)ο筌浖募蓽y試

(1)面向?qū)ο蟮募蓽y試主要關(guān)注于系統(tǒng)的結(jié)構(gòu)和內(nèi)部的相互作用,以便發(fā)現(xiàn)僅當(dāng)各類相互作用時才會產(chǎn)生的錯誤。

(2)此外,面向?qū)ο蟪绦蚓哂袆討B(tài)特性,程序的控制流往往無法確定,因此只能做基于黑盒方法的集成測試。3.面向?qū)ο筌浖拇_認(rèn)與系統(tǒng)測試

(1)面向?qū)ο筌浖拇_認(rèn)測試與系統(tǒng)測試忽略類連接的細(xì)節(jié),主要采用傳統(tǒng)的黑盒子法對OOA階段的用例所描述的用戶交互進(jìn)行測試。(2)OOA階段的對象行為模型、事件流圖等都可以用于導(dǎo)出面向?qū)ο笙到y(tǒng)測試的測試用例。第10章軟件項目管理10.1軟件的度量10.2軟件估算模型10.3軟件成本估計10.4人員的分配與組織10.5項目進(jìn)度安排10.1軟件的度量軟件度量可劃分為1.軟件項目度量:目的在于改進(jìn)軟件產(chǎn)品的質(zhì)量;

2.軟件過程度量:目的在于改進(jìn)企業(yè)的軟件開發(fā)過程,提高整個過程的質(zhì)量。

一、項目度量的內(nèi)容

1.5種基本度量

度量常用單位Size規(guī)模LOC,KLOCEffort工作量人-月Duration時間(或Schedule進(jìn)度)月Quality質(zhì)量錯誤數(shù)/KLOCCost成本(或Rework返工)元2.特點(1)以代碼行(LOC)表示的軟件規(guī)模是最基本的度量。它直接關(guān)系到軟件的成本、開發(fā)工作量和完成時間。

(2)在項目度量中,所有的基本度量都是以代碼行LOC為基礎(chǔ)的。例如,軟件成本(元)=LOC×每行代碼的成本(行/元)開發(fā)工作量(人-月)=LOC/每人-月開發(fā)的代碼行(行/人-月)(3)軟件的規(guī)模、成本和工作量通常都分階段進(jìn)行度量。

3.面向功能的項目度量中心思想任何軟件都包含若干種功能,每種功能又包含具有不同復(fù)雜度的若干個功能點。因此,軟件的規(guī)模也可用功能點數(shù)量的多少來表示,以代替原來常用的LOC表示法。

一、過程度量

1.含義

過程度量可以認(rèn)為是對整個企業(yè)中全體項目組開發(fā)能力的衡量。

2.特點

把對于項目組中個人的度量組合起來,可形成對項目的度量;把所有項目組的項目度量組合起來,就形成了對整個企業(yè)的過程度量。

10.2軟件估算模型

估算在軟件度量中占有重要的地位。一般地說,估算是在軟件開發(fā)之前進(jìn)行的。

資源模型可用來估算軟件在開發(fā)中花費的資源。

典型的資源模型:靜態(tài)單變量資源模型Putnam資源模型COCOMO模型一、靜態(tài)單變量資源模型

1.特點

這種模型在計算軟件開發(fā)的資源花費時,只需要設(shè)定被開發(fā)軟件的一種參數(shù),故稱為單變量型。

2.形式

資源=C1×(估計的軟件特征)C2

二、Putnam資源模型

1.形式

L=CK1/3T4/3或K=L3/

(C3T4)

2.特點(1)Putnam模型是一種多變量資源模型。(2)Putnam模型是在同一個模型中給出了K(或E)、L和T三者之間的關(guān)系。(3)Putnam模型方程揭示了E與T之間的關(guān)系。根據(jù)這一方程,開發(fā)工作量E與開發(fā)時間T的四次方成反比。這表明,開發(fā)時間的小量變化,會引起開發(fā)工作量相當(dāng)大的變化。三、COCOMO模型

特點

以靜態(tài)單變量模型為基礎(chǔ),但在下列兩個方面作了較大的改進(jìn):

(1)按照軟件的應(yīng)用領(lǐng)域和復(fù)雜程度,將它們分為組織、半獨立和嵌入三種類型,每類分別使用一組不同的模型方程,

(2)在模型中增加一個工作量調(diào)節(jié)因子EAF,反映各種有關(guān)因素對軟件開發(fā)的影響。這些因素歸結(jié)為4類、15種因子,

10.3軟件成本估計

資源模型是估計成本的一種手段,成本估計是軟件費用管理的核心,成本估計方法分為“自頂向下估計”、“由底向上估計”和“算法模型估計”

溫馨提示

  • 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

提交評論