軟件測試重點(diǎn)

1、第一章軟件測試概述1、軟件測試是對軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。2、軟件故障與硬件故障導(dǎo)致系統(tǒng)失效的比例為：10:13、軟件缺陷的典型例子：（1）千年蟲問題（銀行計(jì)算利息為負(fù)數(shù)）（2）愛國者導(dǎo)彈防御系統(tǒng)（系統(tǒng)時鐘錯誤積累，使導(dǎo)彈延時，美國的導(dǎo)彈誤殺了美國的士兵）（3）美國火星登陸事故（接口錯誤，沒有測試，導(dǎo)致飛船加速下降，撞成碎片）（4）Intel奔騰芯片缺陷（計(jì)算錯誤，損失巨大）（5）Windows 2000安全漏洞（系統(tǒng)，網(wǎng)站等受到攻擊）（6）迪斯尼的圣誕節(jié)禮物（7）沖擊波”計(jì)算機(jī)病毒4、軟件缺陷產(chǎn)生的原因：（1）、開發(fā)人員不太了解需求，軟件需求分析

2、不夠全面、準(zhǔn)確是導(dǎo)致軟件缺陷的最主要原因。（2）、軟件系統(tǒng)越來越復(fù)雜，開發(fā)人員不太可能精通所有的技術(shù) 。（3）、技術(shù)文檔普遍比較糟糕，文檔本身就有錯誤。（4）、軟件需求、設(shè)計(jì)報(bào)告、程序經(jīng)常發(fā)生變更，每次變更都可能產(chǎn)生新的錯誤。（5）、任何人在編程時都可能犯錯誤，導(dǎo)致程序中有錯誤。（6）、人們常處于進(jìn)度的壓力之下，急忙之下容易產(chǎn)生錯誤。（7）、人們過于自信，不真實(shí)的“沒問題”將產(chǎn)生真正的問題 。（8）、軟件設(shè)計(jì)和編碼過程中的失誤也會導(dǎo)致軟件缺陷的產(chǎn)生。（9）、但很多情況下，不正確的軟件設(shè)計(jì)是不正確的需求分析引起的，編碼階段出現(xiàn)的錯誤則是由需求分析和軟件設(shè)計(jì)不夠完善、準(zhǔn)確引起的。5、軟件測試的目的

3、和意義軟件測試的根本目的是以盡可能少的時間和人力發(fā)現(xiàn)并改正軟件中潛在的各種故障及缺陷，提高軟件的質(zhì)量。6、軟件測試原則：（1）盡早和不斷測試（2）每個程序員都應(yīng)當(dāng)測試自己的程序（份內(nèi)之事），但是不能作為該程序已經(jīng)通過測試的依據(jù)（所以項(xiàng)目需要獨(dú)立測試人員）（3）完全測試是不可能的（4）測試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測試（5）測試只能證明錯誤存在，不能證明錯誤不存在 （6）測試的主要困難是不知道如何進(jìn)行有效地測試，也不知道什么時候可以放心地結(jié)束測試（7）80-20原則：80的錯誤聚集在20的模塊中，經(jīng)常出錯的模塊改錯后還會經(jīng)常出錯（8）測試應(yīng)當(dāng)循序漸進(jìn)，不要企圖一次性干完，注意“欲速則

4、不達(dá)”7、軟件測試過程(1)單元測試（模塊測試）目的:檢測程序模塊中有無故障存在對象:軟件設(shè)計(jì)的最小單位，與程序設(shè)計(jì)和編程實(shí)現(xiàn)關(guān)系密切(2)集成測試（組裝測試、子系統(tǒng)測試）目的:發(fā)現(xiàn)與接口有關(guān)的模塊之間的問題方法：非增式集成測試法和增式集成測試法分類：非增式集成測試法對每一個模塊進(jìn)行單元測試在此基礎(chǔ)上按程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個整體進(jìn)行測試增式集成測試法不斷地把待測模塊連接到已測模塊集(或其子集)上，對待測模塊進(jìn)行測試，直到最后一個模塊測試完畢（3） 確認(rèn)測試目的：對軟件產(chǎn)品進(jìn)行評估以確定其是否滿足軟件需求的過程確認(rèn)測試的結(jié)果：a.測試結(jié)果滿足需求規(guī)格說明；b.與需求規(guī)

5、格有偏離。（4） 系統(tǒng)測試目的：針對系統(tǒng)中各個組成部分進(jìn)行的綜合性檢驗(yàn)，證明系統(tǒng)的性能測試人員要求：系統(tǒng)開發(fā)人員不能進(jìn)行系統(tǒng)測試。系統(tǒng)開發(fā)組織不能負(fù)責(zé)系統(tǒng)測試。（5） 驗(yàn)收測試目的：向用戶表明所開發(fā)的軟件系統(tǒng)能夠像用戶所預(yù)定的那樣工作主要任務(wù)：明確規(guī)定驗(yàn)收測試通過的標(biāo)準(zhǔn)；確定驗(yàn)收測試方法；確定驗(yàn)收測試的組織和可利用的資源；確定測試結(jié)果的分析方法；制定驗(yàn)收測試計(jì)劃并進(jìn)行評審；設(shè)計(jì)驗(yàn)收測試的測試用例；審查驗(yàn)收測試的準(zhǔn)備工作；執(zhí)行驗(yàn)收測試；分析測試結(jié)果，決定是否通過驗(yàn)收。8、軟件開發(fā)過程正規(guī)的軟件開發(fā)過程一般包括六個階段，即： 第一階段 計(jì)劃 第二階段 需求分析（開發(fā)人員和用戶共同決定） 第三階段

6、設(shè)計(jì)（包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)） 第四階段 程序編寫 第五階段 測試(單元，集成，確認(rèn)，驗(yàn)收) 第六階段 運(yùn)行和/維護(hù) 這六個階段構(gòu)成了軟件的生存周期。9、軟件測試與軟件開發(fā)的關(guān)系軟件測試在軟件開發(fā)中的作用：項(xiàng)目規(guī)劃階段：負(fù)責(zé)整個測試階段的監(jiān)控。需求分析階段：確定測試需求分析，制定系統(tǒng)測試計(jì)劃。測試需求分析是指產(chǎn)品生存周期中測試所需的資源、配置、各階段評審?fù)ㄟ^的標(biāo)準(zhǔn)等。概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)階段：制定集成測試計(jì)劃和單元測試計(jì)劃。編碼階段：開發(fā)相應(yīng)的測試代碼或測試腳本。測試階段：實(shí)施測試，并提交相應(yīng)的測試報(bào)告。10、軟件測試在軟件開發(fā)中的作用測試在軟件開發(fā)中占有重要地位測試成本占有開發(fā)成本的近一半11

7、、軟件測試工具（1）、白盒測試工具靜態(tài)測試工具職能：主要集中在需求文檔、設(shè)計(jì)文檔以及程序結(jié)構(gòu)上，可以進(jìn)行類型分析、接口分析、輸入輸出規(guī)格說明分析等。工具：McCabe & Associates 公司開發(fā)的McCabe Visual Quality ToolSet分析工具；ViewLog公司開發(fā)的LogiScope分析工具；Software Research公司開發(fā)的TestWork/Advisor分析工具及Software Emancipation公司開發(fā)的Discover分析工具，北京郵電大學(xué)開發(fā)的DTS缺陷測試工具等。動態(tài)測試工具職能：功能確認(rèn)與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等工

8、具：Compuware公司開發(fā)的DevPartner軟件、Rational公司研制的Purify系列等。（2）、黑盒測試工具工具：Rational公司的TeamTest，Compuware公司的QACenter。分類：功能測試工具和性能測試工具習(xí)題11什么是軟件測試？軟件測試的目的和意義是什么？2簡述軟件測試過程。3簡述軟件測試過程V模型和軟件測試過程W模型的主要區(qū)別。軟件測試過程V模型特點(diǎn)：非常明確地表明了測試的不同級別，清晰地展示了軟件測試與開發(fā)之間的關(guān)系。軟件開發(fā)是一個自頂向下逐步細(xì)化的過程，軟件測試則是一個自底向上逐步集成的過程。軟件測試過程W模型 形象的展示了開發(fā)與測試的并行，測試貫

9、穿與開發(fā)過程。第二章 黑盒測試1、黑盒測試是一種常用的軟件測試方法，它將被測軟件看作一個打不開的黑盒，主要根據(jù)功能需求設(shè)計(jì)測試用例，進(jìn)行測試黑盒測試的基本概念黑盒測試是一種從軟件外部對軟件實(shí)施的測試，也稱功能測試或基于規(guī)格說明的測試。其基本觀點(diǎn)是：任何程序都可以看作是從輸入定義域到輸出值域的映射，這種觀點(diǎn)將被測程序看作一個打不開的黑盒，黑盒里面的內(nèi)容(實(shí)現(xiàn))是完全不知道的，只知道軟件要做什么。因無法看到盒子中的內(nèi)容，所以不知道軟件是如何實(shí)現(xiàn)的，也不關(guān)心黑盒里面的結(jié)構(gòu)，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。目的：黑盒測試是從用戶觀點(diǎn)出發(fā)的測試，其目的是盡可能發(fā)現(xiàn)軟件的外部行為錯誤。在已知軟件產(chǎn)品功能的

10、基礎(chǔ)上，1）檢測軟件功能能否按照需求規(guī)格說明書的規(guī)定正常工作，是否有功能遺漏；2） 檢測是否有人機(jī)交互錯誤，是否有數(shù)據(jù)結(jié)構(gòu)和外部數(shù)據(jù)庫訪問錯誤，是否能恰當(dāng)?shù)亟邮諗?shù)據(jù)并保持外部信息（如數(shù)據(jù)庫或文件）等的完整性；3） 檢測行為、性能等特性是否滿足要求等；4） 檢測程序初始化和終止方面的錯誤等。優(yōu)點(diǎn)： 黑盒測試著眼于軟件的外部特征，通過上述方面的檢測，確定軟件所實(shí)現(xiàn)的功能是否按照軟件規(guī)格說明書的預(yù)期要求正常工作. 兩個顯著的優(yōu)點(diǎn)： 黑盒測試與軟件具體實(shí)現(xiàn)無關(guān)，所以如果軟件實(shí)現(xiàn)發(fā)生了變化，測試用例仍然可以使用； 設(shè)計(jì)黑盒測試用例可以和軟件實(shí)現(xiàn)同時進(jìn)行，因此可以壓縮項(xiàng)目總的開發(fā)時間。2幾種常用的黑盒測試

11、方法等價(jià)類劃分 邊界值分析法因果圖法 決策表法（1）等價(jià)類劃分法是一種典型的黑盒測試方法，它完全不考慮程序的內(nèi)部結(jié)構(gòu)，只根據(jù)程序規(guī)格說明書對輸入范圍進(jìn)行劃分，把所有可能的輸入數(shù)據(jù)，即程序輸入域劃分為若干個互不相交的子集，稱為等價(jià)類，然后從每個等價(jià)類中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例，進(jìn)行測試。所謂等價(jià)類是指輸入域的某個互不相交的子集合，所有等價(jià)類的并便是整個輸入域。等價(jià)類劃分測試用例設(shè)計(jì) 在設(shè)計(jì)測試用例時應(yīng)同時考慮有效等價(jià)類和無效等價(jià)類測試用例的設(shè)計(jì)。根據(jù)等價(jià)類表設(shè)計(jì)測試用例，具體步驟如下：（1）為每個等價(jià)類規(guī)定一個唯一的編號。（2) 設(shè)計(jì)一個新的測試用例，盡可能多地覆蓋尚未被覆蓋的有效等

12、價(jià)類，重復(fù)這一步，直到測試用例覆蓋了所有的有效等價(jià)類。（3) 設(shè)計(jì)一個新的測試用例，使其覆蓋并且只覆蓋一個還沒有被覆蓋的無效等價(jià)類。重復(fù)這一步，直至測試用例覆蓋了所有的無效等價(jià)類。（2）、邊界值分析法大量的軟件測試實(shí)踐表明，故障往往出現(xiàn)在定義域或值域的邊界上，而不是在其內(nèi)部。為檢測邊界附近的處理專門設(shè)計(jì)測試用例，通常都會取得很好的測試效果。因此邊界值分析法是一種很實(shí)用的黑盒測試用例方法，它具有很強(qiáng)的發(fā)現(xiàn)故障的能力。邊界條件1邊界是一些特殊情況。程序在處理大量中間數(shù)值時都是正確，但是在邊界處可能出現(xiàn)錯誤。邊界條件就是軟件計(jì)劃的操作界限所在的邊緣條件。2一些可能與邊界有關(guān)的數(shù)據(jù)類型有：數(shù)值，速度，

13、字符，地址，位置，尺寸，數(shù)量等。在等價(jià)類劃分基礎(chǔ)上進(jìn)行邊界值分析測試的基本思想是，選取正好等于、剛剛大于或剛剛小于等價(jià)類邊界的值作為測試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值做為測試數(shù)據(jù)。（3）、因果圖法因果圖法是基于這樣的一種思想：一些程序的功能可以用判定表（或稱決策表）的形式來表示，并根據(jù)輸入條件的組合情況規(guī)定相應(yīng)的操作。因果圖法的定義：是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。采用因果圖法設(shè)計(jì)測試用例的步驟：（1）根據(jù)程序規(guī)格說明書描述，分析并確定因（輸入條件）和果（輸出結(jié)果或程序狀態(tài)的改變），畫出因果圖。（2）將得到的因果

14、圖轉(zhuǎn)換為決策表（判定表）。（3）為決策表中每一列所表示的情況設(shè)計(jì)一個測試用例。使用因果圖法的優(yōu)點(diǎn)：（1）考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關(guān)系。（2）能夠幫助測試人員按照一定的步驟，高效率的開發(fā)測試用例。（3）因果圖法是將自然語言規(guī)格說明轉(zhuǎn)化成形式語言規(guī)格說明的一種嚴(yán)格的方法，可以指出規(guī)格說明存在的不完整性和二義性。因果圖法測試用例的設(shè)計(jì)步驟:（1）確定軟件規(guī)格中的原因和結(jié)果。分析規(guī)格說明中哪些是原因（即輸入條件或輸入條件的等價(jià)類），哪些是結(jié)果（即輸出條件），并給每個原因和結(jié)果賦予一個標(biāo)識符。（2）確定原因和結(jié)果之間的邏輯關(guān)系。分析軟件規(guī)格說明中的語義，找出原因與結(jié)果之間

15、、原因與原因之間對應(yīng)的關(guān)系，根據(jù)這些關(guān)系畫出因果圖。（3）確定因果圖中的各個約束。由于語法或環(huán)境的限制，有些原因與原因之間、原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。（4）把因果圖轉(zhuǎn)換為決策表。（5）根據(jù)決策表設(shè)計(jì)測試用例。（4）、決策表法在一個程序中，如果輸入輸出比較多，輸入之間和輸出之間相互制約的條件比較多，在這種情況下適宜用決策表，可以很清楚的表達(dá)它們之間的各種復(fù)雜關(guān)系。決策表 決策表是把作為條件的所有輸入的各種組合值以及對應(yīng)輸出值都羅列出來而形成的表格。 概念：決策表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況的工具。 優(yōu)點(diǎn)：它能夠?qū)?/p>

16、復(fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用決策表能夠設(shè)計(jì)出完整的測試用例集合。 在一些數(shù)據(jù)處理問題當(dāng)中，某些操作的實(shí)施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執(zhí)行不同的操作。決策表很適合于處理這類問題。決策表通常由條件樁、條件項(xiàng)、動作樁和動作項(xiàng)4部分組成。構(gòu)造決策表可采用以下5個步驟：（1）列出所有的條件樁和動作樁。（2）確定規(guī)則的個數(shù)。（3）填入條件項(xiàng)。（4）填入動作項(xiàng)，得到初始決策表。（5）簡化決策表，合并相似規(guī)則。n 決策表測試法適用于具有以下特征的應(yīng)用程序： if-then-else邏輯突出；輸入變量之間存在邏輯關(guān)系；涉及輸入變量子集的計(jì)算

17、；輸入與輸出之間存在因果關(guān)系。適用于使用決策表設(shè)計(jì)測試用例的條件： 規(guī)格說明以決策表形式給出，或較容易轉(zhuǎn)換為決策表。 條件的排列順序不會也不應(yīng)影響執(zhí)行的操作。 規(guī)則的排列順序不會也不應(yīng)影響執(zhí)行的操作。 當(dāng)某一規(guī)則的條件已經(jīng)滿足，并確定要執(zhí)行的操作后，不必檢驗(yàn)別的規(guī)則。 如果某一規(guī)則的條件要執(zhí)行多個操作，這些操作的執(zhí)行順序無關(guān)緊要。3、黑盒測試方法的比較與選擇幾種典型的黑盒測試方法，這些測試方法的共同特點(diǎn)是，它們都把程序看作是一個打不開的黑盒，只知道輸入到輸出的映射關(guān)系，根據(jù)軟件規(guī)格說明設(shè)計(jì)測試用例。n 在等價(jià)類分析測試中，通過等價(jià)類劃分來減少測試用例的絕對數(shù)量。n 邊界值分析方法則通過分析輸入

18、變量的邊界值域設(shè)計(jì)測試用例。n 在因果圖測試方法和決策表測試中，通過分析被測程序的邏輯依賴關(guān)系，構(gòu)造決策表，進(jìn)而設(shè)計(jì)測試用例。4、黑盒測試工具介紹黑盒測試是在已知軟件產(chǎn)品應(yīng)具有的功能的條件下，在完全不考慮被測程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，通過測試來檢測每個功能是否都按照需求規(guī)格說明的規(guī)定正常使用。 黑盒測試工具又分為：功能測試工具和性能測試工具。 功能測試工具:功能測試工具主要用于檢測被測程序能否達(dá)到預(yù)期的功能要求并能正常運(yùn)行。 性能測試工具:性能測試工具主要用于確定軟件和系統(tǒng)性能。黑盒功能測試工具，如Mercury Interactive公司的WinRunner，IBM Rational公

19、司的TeamTest和Robot，Compuware公司的QACenter等。第三章軟件測試用例設(shè)計(jì)1、黑盒測試方法：等價(jià)類劃分、邊界值分析、決策表測試、因果圖法白盒測試：數(shù)據(jù)流測試、邏輯覆蓋、路徑測試面向?qū)ο鬁y試：有限狀態(tài)機(jī)、Petri網(wǎng)、正交陣列法、UML測試2、白盒測試(White Box Testing,Glass Box Testing)又稱為結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。一般用來分析程序的內(nèi)部結(jié)構(gòu)?；诟采w的測試技術(shù)-白盒測試要求對被測程序的結(jié)構(gòu)特性做到一定程度的覆蓋，并以軟件中的某類成分是否都已經(jīng)得到測試為準(zhǔn)則來判斷軟件測試的充分性。白盒測試的目的：白盒測試通過檢查軟件

20、內(nèi)部的邏輯結(jié)構(gòu)，對軟件中的邏輯路徑進(jìn)行覆蓋測試； 在程序不同地方設(shè)立檢查點(diǎn)，檢查程序的狀態(tài)，以確定實(shí)際運(yùn)行狀態(tài)與預(yù)期狀態(tài)是否一致。白盒測試的特點(diǎn)：依據(jù)軟件設(shè)計(jì)說明書進(jìn)行測試；對程序內(nèi)部細(xì)節(jié)的嚴(yán)密檢驗(yàn)；針對特定條件設(shè)計(jì)測試用例；對軟件的邏輯路徑進(jìn)行覆蓋測試。白盒測試的實(shí)施過程：1.測試計(jì)劃階段：2.測試設(shè)計(jì)階段：依據(jù)程序設(shè)計(jì)說明書，按照一定規(guī)范化的方法進(jìn)行軟件結(jié)構(gòu)劃分和設(shè)計(jì)測試用例。3.測試執(zhí)行階段：4.測試總結(jié)階段：路徑測試1）控制流圖程序流程圖是一種程序控制結(jié)構(gòu)的圖形表示方式。在程序流程圖上的處理框內(nèi)常常標(biāo)明了處理要求或條件?？刂屏鲌D：為了更加突出控制流的結(jié)構(gòu)，需要對程序流程圖做些簡化，這種

21、簡化了的流程圖稱為控制流圖。 控制流圖中的符號：節(jié)點(diǎn)：以標(biāo)有編號的圓圈表示，代表程序流程圖中矩形框所表示的處理、菱形表示的分支及多選擇結(jié)構(gòu)點(diǎn)?？刂屏骶€：以帶箭頭的直線或弧表示，與程序流程圖中的數(shù)據(jù)流線是一致的，表明了控制的順序?？刂屏骶€通常標(biāo)有名字，如圖中所標(biāo)的a、b、c等。程序流程圖-控制流圖轉(zhuǎn)換的原則如下：控制流圖中的每一個節(jié)點(diǎn)可以表示程序流程圖中矩形框所表示的處理；菱形表示的兩個甚至多個出口判斷；多條流線相交的匯合點(diǎn)。2）基本路徑測試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路（圈）復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計(jì)測試用例的方法。邏輯覆蓋語句覆蓋 判定覆蓋（分支覆蓋）條件覆

22、蓋 判定/條件覆蓋條件組合覆蓋語句覆蓋準(zhǔn)則 在測試中，要求程序中的每條語句都得到運(yùn)行。在控制流圖中，要求所有的語句都被運(yùn)行的充分必要條件是覆蓋圖中的所有節(jié)點(diǎn)。語句覆蓋準(zhǔn)則的優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：可以很直觀地從源代碼得到測試用例，無須細(xì)分每條判定表達(dá)式。缺點(diǎn)：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件是無法測試的。如在多分支的邏輯運(yùn)算中無法全面的考慮。語句覆蓋是最弱的邏輯覆蓋。判定覆蓋準(zhǔn)則（分支覆蓋） 要求在測試中，每個分支都至少獲得一次“真”和一次“假”。在控制流圖中，分支表現(xiàn)為圖中的一條有向邊。分支（判定）覆蓋只能作到分支（判定）覆蓋仍無法確定判斷內(nèi)部條件的錯誤。判定覆蓋優(yōu)缺

23、點(diǎn)：優(yōu)點(diǎn)：分支（判定）覆蓋具有比語句覆蓋更強(qiáng)的測試能力。同樣分支（判定）覆蓋也具有和語句覆蓋一樣的簡單性，無須細(xì)分每個判定就可以得到測試用例。缺點(diǎn)：往往大部分的分支（判定）語句是由多個邏輯條件組合而成，若僅僅判斷其整個最終結(jié)果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。判定覆蓋仍是弱的邏輯覆蓋。條件覆蓋一個分支的條件是由謂詞組成的。單個謂詞稱為原子謂詞。（1）原子謂詞覆蓋準(zhǔn)則（條件覆蓋） 要求每個復(fù)合謂詞所包含的每一個原子謂詞都至少獲得一次“真”和一次“假”。即要使每個判斷中每個條件的可能取值至少滿足一次。 條件覆蓋優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：增加了對條件判定情況的測試，增加了測試路徑。缺點(diǎn)：原子謂

24、詞（條件）覆蓋不一定包含分支（判定）覆蓋。原子謂詞（條件）覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結(jié)果。判定/條件覆蓋準(zhǔn)則 要求不僅每個復(fù)合謂詞所包含的每一個原子謂詞都至少獲得一次“真”和一次“假”，而且每個復(fù)合謂詞本身也至少獲得一次“真”和一次“假”。即使得判斷中每個條件的所有可能至少出現(xiàn)一次，并且每個判斷本身的判定結(jié)果也至少出現(xiàn)一次。 判定/條件覆蓋優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：能同時滿足判定、條件兩種覆蓋標(biāo)準(zhǔn)。缺點(diǎn)：分支-謂詞（判定/條件）覆蓋準(zhǔn)則的缺點(diǎn)是未考慮條件的組合情況。從表面來看，它測試了所有條件的取值。但實(shí)際并不是這樣。因?yàn)橐恍l件往往掩蓋了另一些條件。對于條件表達(dá)式(A1)&(

25、B=0)來說，只要(A1)的測試為真，才需測試(B=0)的值來確定此表達(dá)式的值，但是若(A1)的測試值為假時，不需再測(B=0)的值就可確定此表達(dá)式的值為假，因而B=0沒有被檢查。同理，對于(A=2)|(X1)這個表達(dá)式來說，只要(A=2)測試結(jié)果為真，不必測試(X1)的結(jié)果就可確定表達(dá)式的值為真。所以對于判定/條件覆蓋來說，邏輯表達(dá)式中的錯誤不一定能夠查得出來。條件組合覆蓋準(zhǔn)則要求每個謂詞(判定)中條件的各種可能組合都至少出現(xiàn)一次。條件組合覆蓋優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：復(fù)合謂詞（條件組合）覆蓋準(zhǔn)則滿足分支（判定）覆蓋、原子謂詞（條件）覆蓋和分支-謂詞（判定/條件）覆蓋準(zhǔn)則，是前述幾種覆蓋標(biāo)準(zhǔn)中最強(qiáng)的。缺

26、點(diǎn)：線性地增加了測試用例的數(shù)量。邏輯覆蓋測試的5種標(biāo)準(zhǔn) 幾種覆蓋準(zhǔn)則間的關(guān)系 白盒測試策略1：桌前檢查桌前檢查是在程序員實(shí)現(xiàn)特定功能后，進(jìn)行單元測試之前，對源代碼進(jìn)行的初步檢查。該項(xiàng)工作的參與人員為開發(fā)人員，重點(diǎn)檢查編碼、語句的使用等是否符合編碼規(guī)范，并根據(jù)編碼規(guī)范調(diào)整自己的代碼以符合編碼規(guī)范的要求。2：單元測試單元測試也稱作模塊測試，在傳統(tǒng)結(jié)構(gòu)化程序中，以一個函數(shù)、過程為一個單元；在面向?qū)ο缶幊踢^程中，一般將類作為單元進(jìn)行測試。該項(xiàng)工作的參與人員為專門的白盒測試人員?？刹捎冒缀袦y試和黑盒測試相結(jié)合的方法。3：代碼評審代碼評審是在編碼初期或編寫過程中采用一種有同行參與的評審活動。該項(xiàng)工作需要所

27、有開發(fā)小組共同參與，通過大家共同閱讀代碼或由程序編寫者講解代碼，其他同行邊聽邊分析問題的方法。共同查看程序，可以找出問題，使大家的代碼風(fēng)格一致或遵守編碼規(guī)范。4：同行評審在同行評審中，由軟件產(chǎn)品創(chuàng)建者的同行們檢查該工作產(chǎn)品，識別產(chǎn)品的缺陷，改進(jìn)產(chǎn)品的不足。主要用于檢驗(yàn)工作產(chǎn)品是否正確的滿足了以往的工作產(chǎn)品中建立的規(guī)范，如需求或設(shè)計(jì)文檔；識別工作產(chǎn)品相對于標(biāo)準(zhǔn)的偏差，包括可能影響軟件可維護(hù)性的問題；向創(chuàng)建者提出改進(jìn)建議；促進(jìn)參與者之間的技術(shù)交流和學(xué)習(xí)等。根據(jù)CMM標(biāo)準(zhǔn)，該項(xiàng)工作的參與人員為程序員、設(shè)計(jì)師、單元測試工程師、維護(hù)者、需求分析師、編碼標(biāo)準(zhǔn)專家。至少需要開發(fā)人員，測試人員和設(shè)計(jì)師。5：代

28、碼走查代碼走查由測試小組組織或者專門的代碼走查小組進(jìn)行代碼走查，這時需要開發(fā)人員提交有關(guān)的資料文檔和源代碼給走查人員，并進(jìn)行必要的講解。代碼走查往往根據(jù)代碼檢查單來進(jìn)行，代碼檢查單常常是根據(jù)編碼規(guī)范總結(jié)出來的一些條目，目的是檢查代碼是否按照編碼規(guī)范來編寫的。當(dāng)然，代碼走查的最終目的還是為了發(fā)現(xiàn)代碼中潛在的錯誤和缺陷。該項(xiàng)工作的參與者為測試人員。代碼走查速度一般建議為：匯編代碼與C代碼 150行/小時，C+/Java 200-300行/小時。6：靜態(tài)分析靜態(tài)分析通常需要輔助工具支持，通過提取代碼信息，進(jìn)行統(tǒng)計(jì)，根據(jù)統(tǒng)計(jì)結(jié)果對源代碼進(jìn)行質(zhì)量評估。代碼規(guī)則檢查也是靜態(tài)分析的一個方面。該項(xiàng)工作的參與人

29、員為測試小組3、面向?qū)ο蟮臏y試用例設(shè)計(jì)有限狀態(tài)機(jī) Petri網(wǎng)正交陣列法 UML軟件測試將開發(fā)分為面向?qū)ο蠓治觯∣OA），面向?qū)ο笤O(shè)計(jì)（OOD），和面向?qū)ο缶幊蹋∣OP）三個階段。正交陣列法正交陣列法的應(yīng)用范圍：正交表測試法適用于輸入條件相互獨(dú)立，并且需要對輸入什么是正交測試法？正交測試源于正交試驗(yàn)設(shè)計(jì)方法。正交試驗(yàn)設(shè)計(jì)方法是一種研究多因素多水平的試驗(yàn)設(shè)計(jì)方法，它根據(jù)正交性從全面試驗(yàn)中挑選出部分有代表性的點(diǎn)進(jìn)行試驗(yàn)，這些有代表性的點(diǎn)具備了“均勻分散，齊整可比”的特點(diǎn)。正交試驗(yàn)設(shè)計(jì)方法一般使用已經(jīng)造好了的正交表格來安排試驗(yàn)并進(jìn)行數(shù)據(jù)分析。正交測試法與正交試驗(yàn)設(shè)計(jì)方法類似也使用已經(jīng)造好了的正交表格

30、來生成測試用例，它簡單易行，應(yīng)用性較好。什么是因素（Factor）在一項(xiàng)試驗(yàn)中，凡欲考察的變量稱為因素（變量）。什么是水平（位級） （Level）在試驗(yàn)范圍內(nèi)，因素被考察的值稱為水平（變量的取值）。什么是正交表？(源自古希臘)正交表是一個二維表格，它的構(gòu)成如下：行數(shù)(Runs)：正交表中的行的個數(shù)，即試驗(yàn)的次數(shù)。因素?cái)?shù)(Factors)：正交表中列的個數(shù)。水平數(shù)(Levels)：任何單個因素能夠取得的值的最大個數(shù)。正交表中的包含的值為從0到 “水平數(shù)-1”或從1到“水平數(shù)”。正交表的表示形式： L行數(shù)(水平數(shù)因素?cái)?shù))正交表的正交性1）每一列中各數(shù)字出現(xiàn)的次數(shù)都一樣多；2）任何兩列所構(gòu)成的各有序

31、數(shù)對出現(xiàn)的次數(shù)都一樣多。正交測試用例設(shè)計(jì)步驟（1）確定測試中有多少個相互獨(dú)立的變量，這映射到表中的因素?cái)?shù)（Factors）。（2）確定每個變量可以取值的個數(shù)，這映射到表中的水平數(shù)（Levels）。（3）選擇一個最適合的正交表，其因素?cái)?shù)=測試中的變量數(shù)，各因素的水平數(shù)=對應(yīng)變量的取值個數(shù)，另外，次數(shù)（Run）最少。（4）把因素和值映射到表中。（5）為剩下的水平數(shù)選取值。（6）把次數(shù)中所描述的組合轉(zhuǎn)化成測試用例，再增加一些沒有生成的但可疑的測試用例。UML軟件測試1. 場景法現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時的情景即為場景。而同一事件不同的觸發(fā)順序和處理結(jié)果就形成了事件流。運(yùn)用在

32、軟件設(shè)計(jì)中的場景法也可用在軟件測試中。兩個概念：基本流和備選流。第四章 集成測試1、集成測試概念集成（Integration）是指把多個單元組合起來形成更大的單元。 集成測試（Integration Testing）也叫組裝測試或聯(lián)合測試是在假定各個軟件單元已經(jīng)通過了單元測試的前提下，檢查各個軟件單元之間的相互接口是否正確。 一般情況，都采用黑盒測試，但隨著軟件復(fù)雜度的增加，常常使用灰盒測試。集成測試的目的和意義集成測試有以下不可替代的特點(diǎn)：單元測試具有不徹底性，對于模塊間接口信息內(nèi)容的正確性、相互調(diào)用關(guān)系是否符合設(shè)計(jì)無能為力。只能靠集成測試來進(jìn)行保障。同系統(tǒng)測試相比，由于集成測試用例是從程序

33、結(jié)構(gòu)出發(fā)的，目的性、針對性更強(qiáng)，測試項(xiàng)發(fā)現(xiàn)問題的效率更高，定位問題的效率也較高；能夠較容易地測試到系統(tǒng)測試用例難以模擬的特殊異常流程，從純理論的角度來講，集成測試能夠模擬所有實(shí)際情況；定位問題較快，由于集成測試具有可重復(fù)強(qiáng)、對測試人員透明的特點(diǎn)，發(fā)現(xiàn)問題后容易定位，所以能夠有效地加快進(jìn)度，減少隱患。集成測試、單元測試與系統(tǒng)測試的差別集成測試方法集成測試的策略比較多，如有基于功能分解的集成，基于調(diào)用圖的集成，基于路徑的集成，分層集成，高頻集成，基于進(jìn)度的集成，基于風(fēng)險(xiǎn)的集成和基于使用的集成等。一般的軟件測試及軟件工程中按照功能分解將集成測試方法分為非漸增式集成（大爆炸集成），漸增式集成，三明治集

34、成。非漸增式集成優(yōu)點(diǎn)：1.可并行調(diào)試所有模塊；2.需要的測試用例數(shù)目少；3.測試方法簡單、易行。非漸增式集成缺點(diǎn)：1.不能對接口進(jìn)行充分的測試；2.不能很好的對全局?jǐn)?shù)據(jù)結(jié)構(gòu)測試；3.多錯誤定位比較困難；4.即使測試通過，也會遺漏錯誤。非漸增式集成使用范圍：1.只需修改或增加少數(shù)幾個模塊的前期產(chǎn)品穩(wěn)定的項(xiàng)目；2.模塊少，功能少，邏輯簡單；3.開發(fā)零缺陷的產(chǎn)品，產(chǎn)品質(zhì)量和單元測試質(zhì)量相當(dāng)高的產(chǎn)品。漸增式測試方法不是獨(dú)立地測試每個單元，而是首先把下一個要被測試的單元同已經(jīng)測試過的單元集合組裝起來，然后再測試，在組裝的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題，最后通過漸增式方法逐步組裝成要求的軟

35、件系統(tǒng)。分自頂向下和自底向上的集成。漸增式集成測試兩個概念：驅(qū)動模塊（driver）：用以模擬待測模塊的上級模塊。樁模塊（stub）：也稱存根模塊，用以模擬待測模塊工作過程中所調(diào)用的模塊。自頂向下集成的步驟：a.對主控模塊進(jìn)行測試，測試時用樁模塊代替所有直接附屬于主控模塊的模塊；b.根據(jù)選定的結(jié)合策略（深度優(yōu)先或?qū)挾葍?yōu)先），每次用一個實(shí)際模塊代換一個樁模塊；c.在結(jié)合進(jìn)一個模塊的同時進(jìn)行測試；d.為了保證加入模塊沒有引進(jìn)新的錯誤，可能需要進(jìn)行回歸測試。從2開始不斷重復(fù)進(jìn)行上述過程，直到構(gòu)造起完整的軟件結(jié)構(gòu)為止。自頂向下集成的優(yōu)點(diǎn)在測試的過程中，可以較早地驗(yàn)證主要的控制和判斷點(diǎn)。選擇深度優(yōu)先組合

36、方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個完整的軟件功能，可先對邏輯輸入的分支進(jìn)行組裝和測試，檢查和克服潛藏的錯誤和缺陷，驗(yàn)證其功能的正確性，為此后主要分支的組裝和測試提供保證；能夠較早的驗(yàn)證功能可行性，給開發(fā)者和用戶帶來成功的信心；只有在個別情況下，才需要驅(qū)動程序（最多不超過一個），減少了測試驅(qū)動程序開發(fā)和維護(hù)的費(fèi)用；可以和開發(fā)設(shè)計(jì)工作一起并行執(zhí)行集成測試，能夠靈活的適應(yīng)目標(biāo)環(huán)境；容易進(jìn)行故障隔離和錯誤定位。自頂向下集成的缺點(diǎn)：在測試時需要為每個模塊的下層模塊提供樁模塊，樁模塊的開發(fā)和維護(hù)費(fèi)用大；底層組件的需求變更可能會影響到全局組件，需要修改整個系統(tǒng)的多個上層模塊。要求控制模塊具有比較高的可測試性；可能會導(dǎo)致底層模塊特別是被重用的模塊測試不夠充分。自頂向下集成的適用范圍：控制結(jié)構(gòu)比較清晰和穩(wěn)定的應(yīng)用程序；系統(tǒng)高層的模塊接口變化的可能性比較小；產(chǎn)品的低層模塊接口還未定義或可能會經(jīng)常因需求變更等原因被修改；產(chǎn)品中的控制模塊技