軟件測試課后習(xí)題

1、 第一章軟件測試概述1.名詞解釋？軟件缺陷：即計(jì)算機(jī)系統(tǒng)或者程序中存在的任何一種破壞正常運(yùn)行能力的問題、錯(cuò)誤，或者隱藏的功能缺陷、瑕疵。缺陷會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。 軟件缺陷的準(zhǔn)確定義，通常有以下5條描述：（1）軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能。（2）軟件出現(xiàn)了產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤。（3）軟件超出實(shí)現(xiàn)了產(chǎn)品說明書提到的功能。（4）軟件實(shí)現(xiàn)了產(chǎn)品說明書雖未明確指出但應(yīng)該實(shí)現(xiàn)的目標(biāo)。（5）軟件難以理解，不易使用，運(yùn)行緩慢或者終端用戶認(rèn)為不好軟件測試：軟件測試就是在軟件投入運(yùn)行前，對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。通常對(duì)軟件測試的定義

2、有如下描述： 軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。靜態(tài)測試：靜態(tài)測試就是通過對(duì)被測程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛在的錯(cuò)誤。動(dòng)態(tài)測試：動(dòng)態(tài)測試的對(duì)象必須是能夠由計(jì)算機(jī)真正運(yùn)行的被測試的程序黑盒測試：黑盒測試是一種從用戶觀點(diǎn)出發(fā)的測試，又稱為功能測試，數(shù)據(jù)驅(qū)動(dòng)測試和基于規(guī)格說明的測試。白盒測試：白盒測試基于產(chǎn)品的內(nèi)部結(jié)構(gòu)來進(jìn)行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個(gè)部分功能是否得到充分利用。單元測試:單元測試是針對(duì)每個(gè)單元的測試，是軟件測試的最小單位。：集成測試：集成測試是對(duì)已測試過的模塊進(jìn)行組裝，進(jìn)行集成測試的目的主要在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。確認(rèn)測試:是檢驗(yàn)所開發(fā)的軟件能否滿足

3、所有功能和性能需求的最后手段，通常采用黑盒測試方法。系統(tǒng)測試:系統(tǒng)測試的主要任務(wù)是檢測被測軟件與系統(tǒng)的其他部分的協(xié)調(diào)性。驗(yàn)收測試:驗(yàn)收測試是軟件產(chǎn)品質(zhì)量的最后一關(guān)。這一環(huán)節(jié)，測試主要從用戶的角度著手，其參與者主要是用戶和少量的程序開發(fā)人員。 ©®2.簡述軟件測試發(fā)展的歷史及軟件測試的現(xiàn)狀？軟件測試的現(xiàn)狀: 在我國，軟件測試可能算不上一個(gè)真正的產(chǎn)業(yè)，軟件開發(fā)企業(yè)對(duì)軟件測試認(rèn)識(shí)淡薄，軟件測試人員與軟件開發(fā)人員往往比例失調(diào)，而在發(fā)達(dá)國家和地區(qū)軟件測試已經(jīng)成了一個(gè)產(chǎn)業(yè)。 我們?cè)谲浖y試實(shí)現(xiàn)方面并不比國外差，國際上優(yōu)秀的測試工具，我們基本都有，這些工具所體現(xiàn)的思想我們也有深刻的理解，

4、很多大型系統(tǒng)在國內(nèi)都得到了很好的測試。3.談?wù)勀銓?duì)軟件測試的重要性的理解？4.簡述軟件測試的目標(biāo)及標(biāo)準(zhǔn)？ 軟件測試的目的包括以下三點(diǎn)：(1) 測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤，不能證明程序的正確性，僅限于處理有限種的情況。(2) 檢查系統(tǒng)是否滿足需求，這也是測試的期望目標(biāo)。(3) 一個(gè)好的測試用例在于發(fā)現(xiàn)還未曾發(fā)現(xiàn)的錯(cuò)誤；成功的測試是發(fā)現(xiàn)了錯(cuò)誤的測試。 軟件測試標(biāo)準(zhǔn)如下：(1)軟件測試的目標(biāo)在于揭示錯(cuò)誤。測試人員要始終站在用戶的角度去看問題，系統(tǒng)中最嚴(yán)重的錯(cuò)誤的是那些導(dǎo)致程序無法滿足用戶需求的錯(cuò)誤。(2)軟件測試必須基于“質(zhì)量第一”的思想去開展各項(xiàng)工作。(3)事先定義好產(chǎn)品的質(zhì)量標(biāo)準(zhǔn)。只

5、有建立了質(zhì)量標(biāo)準(zhǔn)，才能根據(jù)測試的結(jié)果，對(duì)產(chǎn)品的質(zhì)量進(jìn)行分析和評(píng)估。(4)軟件項(xiàng)目一啟動(dòng)，軟件測試也就開始，而不是等程序?qū)懲?，才開始進(jìn)行測試。(5)測試用例是設(shè)計(jì)出來的，不是寫出來的，所以要根據(jù)測試的目的，采用相應(yīng)的方法去設(shè)計(jì)測試用例，從而提高測試的效率，更多的發(fā)現(xiàn)錯(cuò)誤，提高程序的可靠性。(6)對(duì)發(fā)現(xiàn)錯(cuò)誤較多的程序段，應(yīng)進(jìn)行更深入的測試。 5.簡述軟件測試的原則？5.1應(yīng)當(dāng)把盡早地和不斷地進(jìn)行軟件測試作為軟件開發(fā)者的座右銘。堅(jiān)持在軟件開發(fā)的各個(gè)階段的技術(shù)評(píng)審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預(yù)防錯(cuò)誤，把出現(xiàn)的錯(cuò)誤克服在早期，杜絕某些隱患，提高軟件質(zhì)量。5.2測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期

6、輸出結(jié)果這兩部分組成。如果對(duì)測試輸入數(shù)據(jù)沒有給出預(yù)期的程序輸出結(jié)果，那么就缺少了檢驗(yàn)實(shí)測結(jié)果的基準(zhǔn)，就有可能把一個(gè)似是而非的錯(cuò)誤結(jié)果當(dāng)成正確結(jié)果。5.3程序員應(yīng)避免檢查自己的程序。如果由別人來測試程序員編寫的程序，可能會(huì)更客觀，更有效，并更容易取得成功5.4在設(shè)計(jì)測試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。5.5充分注意測試中的群集現(xiàn)象。測試時(shí)不要以為找到了幾個(gè)錯(cuò)誤問題就已解決，不需繼續(xù)測試了。應(yīng)當(dāng)對(duì)錯(cuò)誤群集的程序段進(jìn)行重點(diǎn)測試，以提高測試投資的效益。5.6嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性。對(duì)于測試計(jì)劃，要明確規(guī)定，不要隨意解釋。5.7應(yīng)當(dāng)對(duì)每一個(gè)測試結(jié)果做全面檢查。這是一條最明顯

7、的原則，但常常被忽視。必須對(duì)預(yù)期的輸出結(jié)果明確定義，對(duì)實(shí)測的結(jié)果仔細(xì)分析檢查，抓住關(guān)鍵，暴露錯(cuò)誤。5.8妥善保存測試計(jì)劃，測試用例，出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。6.簡述軟件測試與軟件開發(fā)的關(guān)系？6.1測試與軟件開發(fā)各階段的關(guān)系軟件開發(fā)過程是一個(gè)自頂向下，逐步細(xì)化的過程，首先在軟件計(jì)劃階段定義了軟件的作用域，然后進(jìn)行軟件需求分析，建立軟件的數(shù)據(jù)域、功能和性能需求、約束和一些有效性準(zhǔn)則。接著進(jìn)入軟件開發(fā)，首先是軟件設(shè)計(jì)，然后再把設(shè)計(jì)用某種程序設(shè)計(jì)語言轉(zhuǎn)換成程序代碼。而測試過程則是依相反的順序安排的自底向上，逐步集成的過程，低一級(jí)測試為上一級(jí)測試準(zhǔn)備條件6.2測試與開發(fā)的并行性 在軟件的

8、需求得到確認(rèn)并通過評(píng)審后，概要設(shè)計(jì)工作和測試計(jì)劃制定設(shè)計(jì)工作就要并行進(jìn)行。如果系統(tǒng)模塊已經(jīng)建立，對(duì)各個(gè)模塊的詳細(xì)設(shè)計(jì)、編碼、單元測試等工作又可并行。待每個(gè)模塊完成后，可以進(jìn)行集成測試、系統(tǒng)測試。6.3測試與開發(fā)模型軟件測試不僅僅是執(zhí)行測試，而是一個(gè)包含很多復(fù)雜活動(dòng)的過程，并且這些過程應(yīng)該貫穿于整個(gè)軟件開發(fā)過程。 第二章軟件測試過程與策略1對(duì)軟件的經(jīng)濟(jì)性進(jìn)行總結(jié)分析。2.闡述軟件測試的充分性準(zhǔn)則。3.如何描述測試流程整體框架。4.簡述單元測試的目標(biāo)。單元測試的主要目標(biāo)是確保各單元模塊被正確地編碼。單元測試除了保證測試代碼的功能性，還需要保證代碼在結(jié)構(gòu)上具有可靠性和健全性，并且能夠在所有條件下正確

9、響應(yīng)。進(jìn)行全面的單元測試，可以減少應(yīng)用級(jí)別所需的工作量，并且徹底減少系統(tǒng)產(chǎn)生錯(cuò)誤的可能性。如果手動(dòng)執(zhí)行，單元測試可能需要大量的工作，自動(dòng)化測試會(huì)提高測試效率。5.解釋驅(qū)動(dòng)模塊簡述軟件測試的復(fù)雜性。6.和樁模塊概念。助模塊可分為兩種：(1) 驅(qū)動(dòng)模塊（driver）：相當(dāng)于被測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測模塊，最后輸出實(shí)測結(jié)果。(2) 樁模塊（stub）：用以代替被測模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子模塊所有功能都帶進(jìn)來，但不允許什么事情也不做。7.簡述集成測試的層次劃分。l 模塊內(nèi)集成測試；l 子系統(tǒng)內(nèi)集成測試；l 子系統(tǒng)間集成測試。 對(duì)于面向?qū)ο蟮?/p>

10、應(yīng)用系統(tǒng)來說，可以把集成測試分為兩個(gè)階段：l 類內(nèi)集成測試；l 類間集成測試。8.歸納確認(rèn)測試階段的工作。9.簡述系統(tǒng)測試的流程。10.歸納驗(yàn)收測試常用的策略。常用策略有三種，它們分別是： (1) 正式驗(yàn)收(2) 非正式驗(yàn)收或 Alpha 測試 (3) Beta 測試 11.簡述驗(yàn)收測試的流程。12.簡述靜態(tài)測試和動(dòng)態(tài)測試的區(qū)別。13.比較闡述黑盒測試和白盒測試的優(yōu)缺點(diǎn)。 黑盒測試白盒測試優(yōu)點(diǎn) 適用于各個(gè)測試階段； 從產(chǎn)品功能角度進(jìn)行測試； 容易入手生成測試數(shù)據(jù)。 可構(gòu)成測試數(shù)據(jù)使特定程序部分得到測試； 有一定充分性度量手段； 可獲較多工具支持。缺點(diǎn) 某些代碼得不到測試； 如果規(guī)則說

11、明有誤，無法發(fā)現(xiàn)； 不易進(jìn)行充分行測試。 不易生成測試數(shù)據(jù)；無法對(duì)未實(shí)現(xiàn)規(guī)格說明的部分進(jìn)行測試；工作量大，通常只用于單元測試，有應(yīng)用局限性。 黑盒測試白盒測試性質(zhì)一種確認(rèn)技術(shù)，目的是確認(rèn)“設(shè)計(jì)的系統(tǒng)是否正確”。一種驗(yàn)證技術(shù)，目的是驗(yàn)證“系統(tǒng)的設(shè)計(jì)是否正確”。 第三章黑盒測試及其實(shí)例設(shè)計(jì)1. 敘述黑盒測試技術(shù)的實(shí)質(zhì)及要點(diǎn)。 黑盒測試方法著重測試軟件的功能需求，是在程序接口上進(jìn)行測試，主要是為了發(fā)現(xiàn)以下錯(cuò)誤：l 是否有不正確的功能，是否有遺漏的功能；l 在接口上，是否能夠正確地接收輸入數(shù)據(jù)并產(chǎn)生正確的輸出結(jié)果；l 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息訪問錯(cuò)誤；l 性能上是否能夠滿足要求；l 是否

12、有程序初始化和終止方面的錯(cuò)誤。2. 常用的黑盒測試用例設(shè)計(jì)方法有哪些？各有什么優(yōu)缺點(diǎn)？ 等價(jià)類劃分法、邊界值分析法、決策表法和因果圖法。決策表最突出的優(yōu)點(diǎn)是，能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用決策表能夠設(shè)計(jì)出完整的測試用例集合。運(yùn)用決策表設(shè)計(jì)測試用例，可以將條件理解為輸入，將動(dòng)作理解為輸出。3. 使用等價(jià)類劃分法設(shè)計(jì)三角形問題的測試用例。R1=a，b，c：邊為a，b，c 的等邊三角形R2=a，b，c：邊為a，b，c 的等腰三角形R3=a，b，c：邊為a，b，c 的一般三角形R4=a，b，c：邊為a，b，c 不能構(gòu)成三角形 測試用例abc預(yù)期輸出TC120

13、2020等邊三角形TC2202010等腰三角形TC35810一般三角形TC43610不構(gòu)成三角形4. 程序要求某個(gè)輸入為6位正整數(shù)，試用不同的測試方法設(shè)計(jì)所有的測試用例。5. 測試銀行提款機(jī)上的提款功能，要求用戶輸入的提款金額的有效數(shù)值是50-2000，并以50為最小單位（即取款金額為50的倍數(shù)），且小數(shù)點(diǎn)后為00，除小數(shù)點(diǎn)外，不可以出現(xiàn)數(shù)字以外的任何符號(hào)和文字。試用等價(jià)類劃分法和邊界值分析法設(shè)計(jì)測試用例。6. 某程序要求輸入日期，規(guī)定變量month、day、year的取值范圍為：1month12，1day31，1958year2058，試用邊界值分析法設(shè)計(jì)測試用例。 第四章白盒測試及其實(shí)例設(shè)

14、計(jì) 1. 闡述白盒測試的各種方法，進(jìn)行分析總結(jié)。 語句覆蓋、判斷覆蓋、條件覆蓋、判斷/條件覆蓋、條件組合覆蓋和路徑覆蓋六種覆蓋測策略。2. 分析歸納邏輯覆蓋測試的6種覆蓋策略的各自特點(diǎn)。 語句覆蓋：每個(gè)語句至少執(zhí)行一次。判定覆蓋：在語句覆蓋的基礎(chǔ)上，每個(gè)判定的每個(gè)分支至少執(zhí)行一次。條件覆蓋：在語句覆蓋的基礎(chǔ)上，使每個(gè)判定表達(dá)式的每個(gè)條件都取到各種可能的結(jié)果。判定/條件覆蓋：即判定覆蓋和條件覆蓋的交集。條件組合覆蓋：每個(gè)判定表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次。路徑覆蓋：每條可能的路徑都至少執(zhí)行一次，若圖中有環(huán)，則每個(gè)環(huán)至少經(jīng)過一次 3. 簡述獨(dú)立路徑測試的基本步驟。 獨(dú)立路徑測試的步驟包括

15、3個(gè)方面：l 導(dǎo)出程序控制流圖l 求出程序環(huán)形復(fù)雜度l 設(shè)計(jì)測試用例（Test Case）4. 對(duì)下列C語言程序設(shè)計(jì)邏輯覆蓋測試用例。Void test(int X, int A, int B)If (A>1&& B0) then X=X/AIf (A=2| X>1) then X=X+1; 第五章軟件測試計(jì)劃與文檔1. 簡述測試計(jì)劃的定義。 ANSI/IEEE軟件測試文檔標(biāo)準(zhǔn)829-1983將測試計(jì)劃定義為：“一個(gè)敘述了預(yù)定的測試活動(dòng)的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測試項(xiàng)、被測特征、測試任務(wù)、人員安排，以及任何偶發(fā)事件的風(fēng)險(xiǎn)?！?. 概括測試文檔的含義

16、。 測試文檔（Testing Documentation）記錄和描述了整個(gè)測試流程，它是整個(gè)測試活動(dòng)中非常重要的文件。測試過程實(shí)施所必備的核心文檔是：測試計(jì)劃、測試用例（大綱）和軟件測試報(bào)告3. 簡述測試計(jì)劃的制定原則。 4. 簡述測試文檔的內(nèi)容。 包括以下幾個(gè)內(nèi)容：l 測試計(jì)劃 l 測試設(shè)計(jì)規(guī)格說明 l 測試用例規(guī)格說明l 測試步驟規(guī)格說明l 測試日志l 測試事件報(bào)告l 測試總結(jié)報(bào)告5. 簡述軟件生存周期各階段的測試任務(wù)與可交付的文檔。5.1需求階段（1）測試輸入需求計(jì)劃（來自開發(fā)）。（2）測試任務(wù)制定驗(yàn)證和確認(rèn)測試計(jì)劃；對(duì)需求進(jìn)行分析和審核；分析并設(shè)計(jì)基于需求的測試，構(gòu)造對(duì)應(yīng)的需求覆蓋或追

17、蹤矩陣。（3）可交付的文檔驗(yàn)證測試計(jì)劃；驗(yàn)證測試計(jì)劃（針對(duì)需求設(shè)計(jì)）；驗(yàn)證測試報(bào)告（針對(duì)需求設(shè)計(jì)）。 5. 2功能設(shè)計(jì)階段（1）測試輸入 功能設(shè)計(jì)規(guī)格說明（來自開發(fā)）。（2）測試任務(wù)功能設(shè)計(jì)驗(yàn)證和確認(rèn)測試計(jì)劃；分析和審核功能設(shè)計(jì)規(guī)格說明；可用性測試設(shè)計(jì)；分析并設(shè)計(jì)基于功能的測試，構(gòu)造對(duì)應(yīng)的功能覆蓋矩陣；實(shí)施基于需求和基于功能的測試。（3）可交付的文檔主確認(rèn)測試計(jì)劃；驗(yàn)證測試計(jì)劃（針對(duì)功能設(shè)計(jì)）；驗(yàn)證測試報(bào)告（針對(duì)功能設(shè)計(jì)）。 5.3 詳細(xì)設(shè)計(jì)階段（1）測試輸入 詳細(xì)設(shè)計(jì)規(guī)格說明（來自開發(fā)）。（2）測試任務(wù)詳細(xì)設(shè)計(jì)驗(yàn)證測試計(jì)劃；分析和審核詳細(xì)設(shè)計(jì)規(guī)格說明；分析并設(shè)計(jì)基于內(nèi)部的測試。（3）可交付的

18、文檔詳細(xì)確認(rèn)測試計(jì)劃；驗(yàn)證測試計(jì)劃（針對(duì)詳細(xì)設(shè)計(jì)）；驗(yàn)證測試報(bào)告（針對(duì)詳細(xì)設(shè)計(jì)）；測試設(shè)計(jì)規(guī)格說明。 5.4編碼階段（1）測試輸入代碼（來自開發(fā)）。（2）測試任務(wù)代碼驗(yàn)證測試計(jì)劃；分析代碼；驗(yàn)證代碼；設(shè)計(jì)基于外部的測試；設(shè)計(jì)基于內(nèi)部的測試。（3）可交付的文檔 測試用例規(guī)格說明；需求覆蓋或追蹤矩陣；功能覆蓋矩陣；測試步驟規(guī)格說明；驗(yàn)證測試計(jì)劃（針對(duì)代碼）；驗(yàn)證測試報(bào)告（針對(duì)代碼）。 5.5測試階段（1）測試輸入要測試的軟件；用戶手冊(cè)。（2）測試任務(wù)制定測試計(jì)劃；審查由開發(fā)部門進(jìn)行的單元和集成測試；進(jìn)行功能測試；進(jìn)行系統(tǒng)測試；審查用戶手冊(cè)。（3）可交付的文檔測試記錄；測試事故報(bào)告；測試總結(jié)報(bào)告。

19、5.6運(yùn)行/維護(hù)階段（1）測試輸入 已確認(rèn)的問題報(bào)告； 軟件生存周期。軟件生存周期是一個(gè)重復(fù)的過程。如果軟件被修改 了，開發(fā)和測試活動(dòng)都要回歸到與修改相對(duì)應(yīng)的生存周期階段。（2）測試任務(wù) 監(jiān)視驗(yàn)收測試； 為確認(rèn)的問題開發(fā)新的測試用例； 對(duì)測試的有效性進(jìn)行評(píng)估。（3）可交付的文檔 可升級(jí)的測試用例庫。6. 舉例說明測試用例的設(shè)計(jì)方法。、 7. 選擇一個(gè)小型應(yīng)用系統(tǒng)，為其做出系統(tǒng)測試的計(jì)劃書、設(shè)計(jì)測試用例并寫出測試總結(jié)報(bào)告。 第六章軟件自動(dòng)化測試1. 簡述軟件測試自動(dòng)化的意義和作用。 2. 簡述自動(dòng)化測試和手工測試有什么主要區(qū)別？3. 自動(dòng)化測試工具大致可以分為幾類？舉例說明幾種與之相對(duì)應(yīng)的測試工

20、具。 可以分為白盒測試工具、黑盒測試工具和測試管理工具。 白盒測試工具工具名支持語言環(huán)境簡介JtestJava代碼分析和動(dòng)態(tài)類、組件測試JcontractJava實(shí)時(shí)性能監(jiān)控以及分析優(yōu)化C+ TestC，C+代碼分析和動(dòng)態(tài)測試CodeWizardC，C+代碼靜態(tài)分析Insure+C，C+實(shí)時(shí)性能監(jiān)控以及分析優(yōu)化.test.Net代碼分析和動(dòng)態(tài)測試 黑盒測試工具工具名公司名官方站點(diǎn)WinRunnerMercury InteractiveAstra QuicktestMercury InteractiveLoadRunnerMercury InteractiveRobotIBM/RationalT

21、eamTestIBM/RationalQARunCompuwareQALoadCompuwareSilkTestSegue SoftwareSilkPerformerSegue Softwaree-TestEmpirixe-LoadEmpirixWASMSWebLoadRadviewOpenSTAOpenSTA 測試管理工具測試管理工具的代表有Rational公司的TeamManager、Compuware公司的TrackRecord、Mercury Interactive公司的TestDirector等軟件。除此之外，還有專用于性能測試的工具包括有：Radview公司的WebLoad；Mic

22、rosoft公司的WebStress等工具；針對(duì)數(shù)據(jù)庫測試的TestBytes；對(duì)應(yīng)用性能進(jìn)行優(yōu)化的EcoScope等工具。4. 簡述對(duì)常用測試自動(dòng)化工具的認(rèn)識(shí)。5. 試從網(wǎng)絡(luò)上免費(fèi)下載自動(dòng)化測試工具，并在客戶機(jī)或服務(wù)器上安裝和運(yùn)行。6. 下載本章所介紹的白盒測試、黑盒測試、負(fù)載測試等工具，學(xué)習(xí)其主要功能及使用方法，嘗試進(jìn)行實(shí)例測試。 第7章 軟件測試管理1. 質(zhì)量保證部門與測試部門的職責(zé)是否一樣？歸納它們的共同點(diǎn)和不同點(diǎn)。2. ISO 9000標(biāo)準(zhǔn)與軟件測試的關(guān)系是什么？3. 簡述CMM的具體等級(jí)劃分。 （1）等級(jí)1（初始級(jí)）。該等級(jí)的軟件開發(fā)過程是隨意的，甚至是混亂的。項(xiàng)目能否成功依靠個(gè)人

23、的能力和運(yùn)氣，具有偶然性。軟件開發(fā)過程沒有定義，沒有通用計(jì)劃，難以監(jiān)視和控制。開發(fā)的時(shí)間和費(fèi)用無法預(yù)知。測試過程和其他過程混雜在一起。（2）等級(jí)2（可重復(fù)級(jí)）。該等級(jí)成熟度主要集中在項(xiàng)目級(jí)。建立基本的項(xiàng)目管理過程去跟蹤成本、進(jìn)度、功能和質(zhì)量?？梢越梃b以前成功項(xiàng)目的經(jīng)驗(yàn)，應(yīng)用到新項(xiàng)目中。軟件開發(fā)具有一定的組織性，使用了基本軟件測試行為，例如測試計(jì)劃和測試用例。（3）等級(jí)3（已定義級(jí)）。該等級(jí)具備了組織化思想，而不僅僅是針對(duì)具體項(xiàng)目。軟件開發(fā)中的管理活動(dòng)和工程活動(dòng)被文檔化和標(biāo)準(zhǔn)化，并且形成整個(gè)軟件組織的標(biāo)準(zhǔn)軟件過程。所有項(xiàng)目均采用在標(biāo)準(zhǔn)軟件過程中進(jìn)行。（4）等級(jí)4（已管理級(jí)）。在該成熟度等級(jí)中，組

24、織過程處于在統(tǒng)計(jì)的控制下。軟件過程和產(chǎn)品質(zhì)量有具體的度量標(biāo)準(zhǔn)，軟件過程和產(chǎn)品質(zhì)量得到了定量理解和控制。（5）等級(jí)5（優(yōu)化級(jí)）。通過來自過程、新技術(shù)和新思想等各方面的定量信息反饋，著能夠進(jìn)行持續(xù)地過程改進(jìn)，以期達(dá)到質(zhì)量更佳的等級(jí)。 第八章 面向?qū)ο蟮能浖y試1. 簡述面向?qū)ο蟮奶攸c(diǎn)與其測試的概念。 2. 面向?qū)ο蟮能浖y試與傳統(tǒng)的軟件測試有什么區(qū)別？ 傳統(tǒng)的軟件測試策略是從“小型測試”開始，逐步走向“大型測試”。即從單元測試開始，然后逐步進(jìn)入集成測試，最后是有效性和系統(tǒng)測試。在傳統(tǒng)應(yīng)用中，單元測試集中在最小的可編譯程序單位子程序（如：模塊、子例程、進(jìn)程），一旦這些單元都已經(jīng)被獨(dú)立的測試過之后，就

25、被集成在程序結(jié)構(gòu)中，然后進(jìn)行一系列的回歸測試以發(fā)現(xiàn)模塊的接口錯(cuò)誤和由于新單元的加入而產(chǎn)生的副作用，最后，把系統(tǒng)作為一個(gè)整體進(jìn)行測試以發(fā)現(xiàn)需求規(guī)格說明中的錯(cuò)誤。 面向?qū)ο蟪绦虻慕Y(jié)構(gòu)不再是傳統(tǒng)的功能模塊結(jié)構(gòu)，作為一個(gè)整體，原有集成測試所要求的逐步將開發(fā)的模塊搭建在一起進(jìn)行測試的方法已成為不可能。而且，面向?qū)ο筌浖仐壛藗鹘y(tǒng)的開發(fā)模式，對(duì)每個(gè)開發(fā)階段都有不同于以往的要求和結(jié)果，已經(jīng)不可能用功能細(xì)化的觀點(diǎn)來檢測面向?qū)ο蠓治龊驮O(shè)計(jì)的結(jié)果。因此，傳統(tǒng)的測試模型對(duì)面向?qū)ο筌浖呀?jīng)不再適用。 3. 通常情況下，類測試驅(qū)動(dòng)程序是由測試人員還是程序員進(jìn)行開發(fā)的？4. 如何對(duì)抽象類進(jìn)行測試？ (1)一般情況下，利用Java的內(nèi)類機(jī)制，在抽象類的測試驅(qū)動(dòng)程序內(nèi)引入內(nèi)類，讓內(nèi)類實(shí)現(xiàn)對(duì)被測試抽象類的繼承，然后把它作為引用體，這樣對(duì)內(nèi)類的測試就等價(jià)于對(duì)被測試抽象類的測試。 如果抽象類被具體類繼承，那么，在創(chuàng)建該具體類的測試驅(qū)動(dòng)程序時(shí)要繼承抽象類的測試驅(qū)