| 第 1 頁(yè)：?jiǎn)芜x題 |
| 第 3 頁(yè)：論述題 |
| 第 4 頁(yè)：參考答案與解析 |
答案分析：
一、選擇題
1.分析：白盒測(cè)試又稱為邏輯驅(qū)動(dòng)測(cè)試，這種測(cè)試策略是對(duì)程序的邏輯結(jié)構(gòu)進(jìn)行檢查，從中獲取測(cè)試數(shù)據(jù)。所以說(shuō)白盒測(cè)試是一種以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的測(cè)試用例設(shè)計(jì)技術(shù)。
2.分析：白盒測(cè)試是程序員十分了解程序的前提下，對(duì)程序的邏輯結(jié)構(gòu)進(jìn)行的測(cè)試。而黑盒測(cè)試則將程序視為一個(gè)黑盒子，僅僅是測(cè)試人員提供數(shù)人數(shù)據(jù)，觀察輸出數(shù)據(jù)，并不了解程序是如何運(yùn)行的，結(jié)構(gòu)測(cè)試屬于白盒測(cè)試，關(guān)注的是如何選擇合適的程序或子程序路徑來(lái)執(zhí)行有效的檢查。功能測(cè)試則屬于黑盒測(cè)試，對(duì)功能的測(cè)試通常通過(guò)提供輸入數(shù)據(jù)，檢查實(shí)際輸出的結(jié)果，很少考慮程序的內(nèi)部結(jié)構(gòu)。
3.分析：程序設(shè)計(jì)過(guò)程中，要為程序調(diào)試做好準(zhǔn)備，主要體現(xiàn)在：①采用模塊化、結(jié)構(gòu)化的設(shè)計(jì)方法設(shè)計(jì)程序;②根據(jù)程序調(diào)試的需要，選擇并安排適當(dāng)?shù)闹虚g結(jié)果輸出必要的斷點(diǎn);③編寫(xiě)程序時(shí)要為調(diào)試提供足夠的靈活性。
4.分析：軟件測(cè)試是軟件開(kāi)發(fā)過(guò)程中重要和不可缺少的階段，其包含的內(nèi)容和步驟甚多，而測(cè)試過(guò)程的多種環(huán)節(jié)中最基礎(chǔ)的是單元測(cè)試。
5.分析：在邏輯覆蓋中，測(cè)試覆蓋最弱的是語(yǔ)句覆蓋。
6.分析：考察白盒測(cè)試中各種邏輯覆蓋之間的關(guān)系。
7.分析：軟件測(cè)試的目標(biāo)是發(fā)現(xiàn)缺陷，證明程序有錯(cuò)而非證明其正確。故A不正確。
8.分析：考察黑盒測(cè)試中的等價(jià)類劃分測(cè)試。
9.分析：考慮自動(dòng)測(cè)試的優(yōu)點(diǎn)就是為了解決重復(fù)的人工操作進(jìn)行的。
10.分析：同行評(píng)審是一種通過(guò)作者的同行來(lái)確定缺陷和需要變更區(qū)域的檢查方法。涉
及的內(nèi)容很多，主要可以分為管理評(píng)審、技術(shù)評(píng)審、文檔評(píng)審和過(guò)程評(píng)審。
11.分析：依據(jù)測(cè)試目的的不同，可以把軟件性能測(cè)試及與性能有關(guān)的其他測(cè)試分為以下幾類：
(1)性能測(cè)試(Performance Testing)
(2)并發(fā)測(cè)試(Concurrency Testing)
(3)壓力測(cè)試(Stress Testing)
(4)可靠性測(cè)試(Reliability Testing)
(5)負(fù)載測(cè)試(Load Testing)
(6)配置測(cè)試(Configuration Testing)
(7)失效恢復(fù)測(cè)試(Recovery Testing)
12.分析：與其他的軟件測(cè)試不同，軟件可靠性測(cè)試的目的不在于通過(guò)測(cè)試揭示軟件中的缺陷并通過(guò)修改軟件缺陷來(lái)提高軟件可靠性，而是通過(guò)受控的軟件測(cè)試過(guò)程來(lái)預(yù)測(cè)軟件在實(shí)際運(yùn)行中的可靠性，即收集軟件測(cè)試時(shí)揭示軟件故障的情況，并對(duì)其進(jìn)行整理從而為分析和預(yù)測(cè)軟件實(shí)際的可靠性提供幫助。
13.分析：由于面向?qū)ο缶哂蟹庋b的特點(diǎn)，在設(shè)計(jì)類的測(cè)試用例時(shí)，不僅要考慮各成員方法的輸入?yún)?shù)，還要考慮如何設(shè)計(jì)調(diào)用的序列。若類B繼承自類A，如果對(duì)B進(jìn)行了嚴(yán)格的測(cè)試，有些情況也許可以就不對(duì)類A進(jìn)行測(cè)試，但由于繼承的存在，就會(huì)導(dǎo)致類A的規(guī)格說(shuō)明可能與類B不一致，此時(shí)就必須按照類A的規(guī)格說(shuō)明重新對(duì)類A重新進(jìn)行測(cè)試。多態(tài)是指對(duì)一個(gè)類的引用可以與多個(gè)類的實(shí)現(xiàn)綁定。抽象類是指只有一些成員方法而沒(méi)有其實(shí)現(xiàn)的類，甚至有的抽象類中的所有成員方法都沒(méi)有實(shí)現(xiàn)，在測(cè)試抽象類時(shí)，需要為抽象類構(gòu)造一個(gè)子類，并實(shí)現(xiàn)所有抽象類沒(méi)有實(shí)現(xiàn)的成員方法，這也說(shuō)明構(gòu)造抽象類的驅(qū)動(dòng)程序顯然比構(gòu)造其他類的驅(qū)動(dòng)程序復(fù)雜。
14.分析：面向?qū)ο筌浖幕杉蓽y(cè)試策略的具體測(cè)試步驟為：①對(duì)基干中的每個(gè)模塊進(jìn)行孤立的、充分的測(cè)試。②對(duì)基干中的所有模塊進(jìn)行一次性集成，形成基干子系統(tǒng)，并使用一個(gè)驅(qū)動(dòng)模塊檢查使用經(jīng)過(guò)一次性集成的基干。此時(shí)采用的是大突擊集成方式。③對(duì)應(yīng)用的控制子系統(tǒng)進(jìn)行自頂向下的集成④集成基干和控制子系統(tǒng)，重新構(gòu)造控制子系統(tǒng)。⑤對(duì)各應(yīng)用子系統(tǒng)采用自底向上的集成策略。⑥集成基干子系統(tǒng)、控制子系統(tǒng)和各應(yīng)用子系統(tǒng)，形成整個(gè)系統(tǒng)�；杉傻膬�(yōu)點(diǎn)是集成了自底向上集成、自頂向下集成和大突擊集成三者的優(yōu)點(diǎn)，而對(duì)三者的缺點(diǎn)也進(jìn)行了控制，更適合于大型復(fù)雜項(xiàng)目的集成。
15.分析：Web應(yīng)用軟件表示層的測(cè)試主要集中在客戶端，測(cè)試的內(nèi)容包括：
(1)排版結(jié)構(gòu)的測(cè)試
(2)鏈接結(jié)構(gòu)的測(cè)試
(3)客戶端程序的測(cè)試
(4)瀏覽器兼容性測(cè)試
16.分析：通常Web應(yīng)用軟件的測(cè)試分為三層：表示層、業(yè)務(wù)層和數(shù)據(jù)層。其中表示層的測(cè)試主要集中在客戶端，測(cè)試內(nèi)容主要包括：①排版結(jié)構(gòu)的測(cè)試，②鏈接結(jié)構(gòu)的測(cè)試，③客戶端程序的測(cè)試，④瀏覽器兼容性測(cè)試。
17.分析：軟件兼容性的測(cè)試問(wèn)題包括：
符合最新HTML版本的頁(yè)面能否在瀏覽器中正確顯示腳本和插件是否適用于不同的瀏覽器，某些腳本和插件只適用于特定的瀏覽器，如Active X，只有IE瀏覽器支持不同的瀏覽器對(duì)于安全性的設(shè)置各有不同，需要測(cè)試不同瀏覽器是否可以為使用該Web應(yīng)用提供合適的安全設(shè)置
18.分析：易用性測(cè)試一般不僅針對(duì)應(yīng)用程序，還要包括用戶文檔，除了對(duì)用戶文檔的測(cè)試，易用性測(cè)試主要包括三個(gè)方面：易安裝性測(cè)試、功能易用性測(cè)試和用戶界面測(cè)試。而兼容性測(cè)試是與易用性測(cè)試并列的測(cè)試方法，二者不存在包含關(guān)系。
19.分析：面向構(gòu)件提供者的測(cè)試目標(biāo)是：①盡可能多地揭示構(gòu)件錯(cuò)誤，②驗(yàn)證構(gòu)件的功能、接口、行為和性能，以保證它們符合給定地構(gòu)件規(guī)約，檢查在特定平臺(tái)和操作環(huán)境中構(gòu)件的復(fù)用、打包和部署。而面向構(gòu)件復(fù)用者的測(cè)試目標(biāo)是：①驗(yàn)證可復(fù)用構(gòu)件的功能和性能，②在特定平臺(tái)和操作環(huán)境下，確保可復(fù)用構(gòu)件的正確使用和部署，③檢查可復(fù)用構(gòu)件定制而成的構(gòu)件的質(zhì)量，④檢查為特定項(xiàng)目而創(chuàng)建的新構(gòu)件的質(zhì)量。
20.分析：極限編程采用的是一種頻繁迭代的開(kāi)發(fā)方式，整個(gè)軟件項(xiàng)目由一系列增量式開(kāi)發(fā)組成。而極限測(cè)試本質(zhì)上就是為了滿足極限編程的思想和流程而設(shè)計(jì)的一套測(cè)試策略和流程，從極限測(cè)試流程圖中，我們可以看出，單元測(cè)試和驗(yàn)收測(cè)試是貫穿始終的關(guān)鍵步驟。
21.分析：定義軟件缺陷的狀態(tài)如下：
新錯(cuò)誤(New)--測(cè)試中新報(bào)告的軟件缺陷
更多新信息(New More Info)--開(kāi)發(fā)工程師認(rèn)為報(bào)告的缺陷信息不完整，要求缺陷報(bào)告者添加更準(zhǔn)確的缺陷信息
打開(kāi)(Open)--缺陷被確認(rèn)并分配給相關(guān)開(kāi)發(fā)工程師處理
拒絕(Declined)--拒絕修改缺陷
修正(Fixed)--開(kāi)發(fā)工程師已完成修正，等待測(cè)試人員驗(yàn)證
重新打開(kāi)(Reopen)--沒(méi)有正確修復(fù)的缺陷，需要進(jìn)一步修復(fù)
延期(Diferred)--不在當(dāng)前版本修復(fù)的缺陷，以后的版本修復(fù)，包括兩種情況：
�、傺悠�-下個(gè)版本(Diferred-Next Build)--本項(xiàng)目的下一個(gè)新版本修復(fù)
�、谘悠�-下個(gè)主要版本(Diferred-Next Main Release)--本項(xiàng)目不修復(fù)，本軟件下一個(gè)項(xiàng)目的版本修復(fù)關(guān)閉(Closed)--缺陷已被修復(fù)
22.分析：軟件缺陷報(bào)告是軟件測(cè)試過(guò)程中的核心測(cè)試產(chǎn)品之一，也是重要的測(cè)試產(chǎn)品，因此管理好軟件缺陷報(bào)告是軟件過(guò)程管理最起碼的要求。
23.分析：假如是軟件企業(yè)內(nèi)部測(cè)試團(tuán)隊(duì)開(kāi)展的軟件測(cè)試，由于軟件測(cè)試介入較早，在測(cè)試開(kāi)始時(shí)被測(cè)系統(tǒng)很可能是不完整的，會(huì)不斷有新的系統(tǒng)模塊加入到系統(tǒng)中，因此最適合采用H模型來(lái)組織測(cè)試，可以為每一個(gè)新增的系統(tǒng)模塊設(shè)計(jì)一次系統(tǒng)測(cè)試。
24.分析：軟件缺陷報(bào)告是測(cè)試人員和開(kāi)發(fā)人員交流的紐帶。
25.分析：白盒測(cè)試又稱為程序結(jié)構(gòu)測(cè)試，它主要進(jìn)行程序邏輯結(jié)構(gòu)的覆蓋測(cè)試。用QESAT/C工具進(jìn)行測(cè)試之前，首先應(yīng)定義項(xiàng)目文件，用以描述被測(cè)程序的組成，該項(xiàng)目文件通常以.pjt作為擴(kuò)展名的。用QESAT/C工具進(jìn)行軟件分析與測(cè)試時(shí)，被測(cè)源文件可放在任意目錄下。進(jìn)行軟件靜態(tài)分析不必運(yùn)行被測(cè)程序，便可得到程序的結(jié)構(gòu)信息及程序的復(fù)雜度信息，將被測(cè)程序運(yùn)行后才得到的信息就是動(dòng)態(tài)測(cè)試信息。
相關(guān)推薦：
2015年9月計(jì)算機(jī)等級(jí)考試各科目考前必做試題
2015計(jì)算機(jī)等級(jí)考試通關(guān)必看:一至四級(jí)備考分享
| 北京 | 天津 | 上海 | 江蘇 | 山東 |
| 安徽 | 浙江 | 江西 | 福建 | 深圳 |
| 廣東 | 河北 | 湖南 | 廣西 | 河南 |
| 海南 | 湖北 | 四川 | 重慶 | 云南 |
| 貴州 | 西藏 | 新疆 | 陜西 | 山西 |
| 寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
| 黑龍江 | 內(nèi)蒙古 |
