國家開放大學(xué)《軟件測試（本）》形考任務(wù)1-4參考答案

1、國家開放大學(xué)軟件測試（本）形考任務(wù)1-4參考答案形考任務(wù)1一、選擇題（從4個選項中，選其一項的標(biāo)號填入（ ）1軟件測試是為了檢查出并改正盡可能多的錯誤，不斷提高軟件的（）。A. 質(zhì)量和效能B. 設(shè)計和技巧C. 質(zhì)量和可靠性D. 功能和效率2軟件測試工作應(yīng)該開始于（）。A. 需求分析階段B. 概要設(shè)計階段C. 編碼之后D. 詳細(xì)設(shè)計階段3.關(guān)于軟件質(zhì)量保證和軟件測試的描述，不正確的是 （）。A. 軟件質(zhì)量保證和軟件測試是軟件質(zhì)量工程的兩個不同層面的工作B. 軟件測試人員就是軟件質(zhì)量保證人員C. 軟件測試是保證軟件質(zhì)量的一個重要環(huán)節(jié)D. 在軟件質(zhì)量保證的活動中也有一些測試活動4.一個測試團隊計劃持

2、續(xù)在一被測系統(tǒng)中檢測90%-95%的缺陷比率。雖然測試經(jīng)理認(rèn)為無論就測試團隊角度還是行業(yè)標(biāo)準(zhǔn)而言這已經(jīng)是一個標(biāo)準(zhǔn)很高的缺陷檢測率。但高層管理者對測試結(jié)果失望，認(rèn)為測試團隊仍漏檢了太多的缺陷。而用戶對此系統(tǒng)使用滿意度相對較好，雖有失效發(fā)生，但總體負(fù)面影響不大。針對上述情況，作為一個測試經(jīng)理可應(yīng)用以下的哪一個通用測試原則去向高層管理者解釋為什么系統(tǒng)中仍會存在未被檢測到的缺陷（）。A. 窮盡測試是不可能的B. 缺陷集群性C. 殺蟲劑悖論D. 測試依賴于測試內(nèi)容5.關(guān)于軟件測試對軟件質(zhì)量的意義，有以下觀點：度量與評估軟件的質(zhì)量；保證軟件質(zhì)量；改進軟件開發(fā)過程；發(fā)現(xiàn)軟件錯誤。其中正確的是（ ）。A. 、

3、B. 、C. 、D. 、6.下面的描述中，不能體現(xiàn)前置測試模型要點的是（）。A. 前置測試模型將開發(fā)和測試的生命周期整合在一起，標(biāo)識了項目生命周期從開始到結(jié)束之間的關(guān)鍵行為，提出業(yè)務(wù)需求最好在設(shè)計和開發(fā)之前就被正確定義。B. 前置測試模型主張根據(jù)業(yè)務(wù)需求進行測試設(shè)計，認(rèn)為需求分析階段是進行測試計劃和測試設(shè)計的最好時機。C. 前置測試將測試執(zhí)行和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼測試編碼測試的方式來體現(xiàn)，強調(diào)對每一個交付的開發(fā)結(jié)果都必須通過一定的方式進行測試。D. 前置測試模型提出驗收測試應(yīng)該獨立于技術(shù)測試，以保證設(shè)計及程序編碼能夠符合最終用戶的需求。7.軟件可移植性應(yīng)從如下（）方面進行測試。A

4、. 可適應(yīng)性、成熟性、兼容性、易替換性。B. 可適應(yīng)性、易安裝性、共享性、易替換性。C. 可適應(yīng)性、易安裝性、兼容性、易替換性。D. 可適應(yīng)性、易安裝性、可伸縮性、易替換性。8.軟件缺陷被描述為在軟件使用上的各種障礙，即可能產(chǎn)生的各種問題統(tǒng)。對軟件缺陷的精確定義，通常業(yè)界普遍認(rèn)同下列描述（）。軟件未達到產(chǎn)品說明書中已標(biāo)明的功能軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤軟件未達到產(chǎn)品說明書中雖未指出但應(yīng)（隱含）達到的目標(biāo) 軟件功能超出了產(chǎn)品說明書中指明的范圍 測試者認(rèn)為軟件難以理解、不易使用，或最終用戶認(rèn)為軟件使用效果不良。A. 、B. 、C. 、D. 、9.軟件測試貫穿于整個于軟件生命周期，其測

5、試的基本問題是（ ）明確測試目標(biāo)確認(rèn)測試對象建立測試生命周期制定和實施測試策略選擇測試類型運用測試方法A. 、B. 、C. 、D. 、10.軟件能力成熟度模型（CMM）將軟件能力成熟度自低到高依次劃分為5級。目前，達到CMM第3級（已定義級）是許多軟件組織努力的目標(biāo)，該級別的核心是（）。A. 使用標(biāo)準(zhǔn)開發(fā)過程（或方法論）構(gòu)建（或集成）系統(tǒng)B. 建立基本的項目管理和實踐來跟蹤項目費用、進度和功能特性C. 連續(xù)地監(jiān)督和改進標(biāo)準(zhǔn)化的系統(tǒng)開發(fā)過程D. 管理層尋求更主動地應(yīng)對系統(tǒng)的開發(fā)問題二、判斷題11.一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤。（）12.測試可以證明程序有錯，也可以證明程序沒有錯誤。（&

6、#215;）13.所有的軟件測試都應(yīng)追溯到用戶需求。（）14.軟件測試是測試人員的事，與開發(fā)人員無關(guān)。（×）15.測試可以證明缺陷存在，但不能證明缺陷不存在。（）16.只要做了充分的測試，就能保證軟件沒有缺陷。（×）17.根據(jù)經(jīng)驗，通常情況下缺陷并非平均分布，80%缺陷集中在20%程序模塊中。（）18.V模型描述了測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。（）19.軟件測試貫穿于軟件定義和開發(fā)的整個過程。（）20.軟件開發(fā)模式與軟件測試關(guān)系密切，系統(tǒng)測試計劃應(yīng)在詳細(xì)設(shè)計階段產(chǎn)生。（×）21.軟件質(zhì)量度量包含軟件的功能特征和非功能特征。（）22.TMM優(yōu)化級別主要進行

7、質(zhì)量控制的測試。（×）形考任務(wù)2一、選擇題（每題5分）1.對于軟件的測試，下列描述正確的是 （）。A. 測試是在軟件公司內(nèi)部展開的測試，由公司非專業(yè)測試人員執(zhí)行的測試。B. 測試是在軟件公司外部展開的測試，可由非專業(yè)測試人員執(zhí)行的測試。C. 測試是在軟件公司內(nèi)部展開的測試，由公司專業(yè)測試人員執(zhí)行的測試。D. 測試是在軟件公司外部展開的測試，由專業(yè)測試人員執(zhí)行的測試。2.下列選項中不屬于黑盒測試特點的是（）。A. 黑盒測試可用于軟件測試的各個階段B. 黑盒測試與軟件具體實現(xiàn)無關(guān)C. 黑盒測試用例設(shè)計可與軟件實現(xiàn)同步進行D. 黑盒測試可以檢查出程序內(nèi)部結(jié)構(gòu)的錯誤3.廣義的軟件測試包括：

8、（）。A. 單元測試、集成測試、系統(tǒng)測試和用戶測試B. 確認(rèn)、驗證和測試C. 需求測試、單元測試、集成測試和驗證測試D. 需求評審、設(shè)計評審、單元測試和綜合測試4.組件測試類別可以包括 （）。靜態(tài)測試 動態(tài)測試 手工測試 自動化測試A. B. C. D. 5.若某軟件系統(tǒng)的關(guān)鍵模塊是在結(jié)構(gòu)圖的底部，那么最適合采用的集成測試策略是（）。A. 隨意集成測試B. 自底向上集成測試C. 自頂向下集成測試D. 中樞集成測試6.以下各項中，（）屬于安裝測試應(yīng)關(guān)注的內(nèi)容。 安裝手冊的評估 安裝選項和設(shè)置的測試 安裝順序測試 修復(fù)、安裝測試與卸載測試A. B. C. D. 7.對靜態(tài)測試和動態(tài)測試的區(qū)別描述正

9、確的是：（）。A. 靜態(tài)測試并沒有真正的運行軟件，而動態(tài)測試需要運行軟件B. 靜態(tài)測試是由開發(fā)人員執(zhí)行的，而動態(tài)測試是由專門的測試人員完成C. 靜態(tài)測試是主要是為了增加測試人員對軟件的理解，而動態(tài)測試是為了發(fā)現(xiàn)缺陷D. 靜態(tài)測試需要借助于專門的測試工具，而動態(tài)測試不需要8.技術(shù)評審的目的是:（）。A. 發(fā)現(xiàn)軟件業(yè)務(wù)錯誤B. 確認(rèn)軟件符合預(yù)先定義的開發(fā)規(guī)范和標(biāo)準(zhǔn)C. 與項目管理無關(guān)D. 保證軟件在獨立的模式下進行開發(fā)9.走查主要包括以下哪些內(nèi)容 （）。A.檢查代碼和設(shè)計的一致性B.標(biāo)準(zhǔn)的遵循和可讀性C.評審對象主要是軟件代碼D.不安全、不明確和模糊的部分A. 除A以外B. 除A和D以外C. 以上

10、全部都是D. 除D以外10.下面對數(shù)據(jù)流分析方法描述錯誤的是（ ）。A. 數(shù)據(jù)流異常通常不明顯，并且每個異常都會導(dǎo)致不正確的行為。B. 數(shù)據(jù)流分析是在程序代碼經(jīng)過的路徑上檢查數(shù)據(jù)的用法。C. 數(shù)據(jù)流分析不一定能夠發(fā)現(xiàn)缺陷，但可以發(fā)現(xiàn)異常。D. 數(shù)據(jù)流分析過程中，需要檢查每個變量的使用情況。二、判斷題（每題5分）11.組件測試通常在編碼前進行，組件測試大多是從程序外部結(jié)構(gòu)出發(fā)設(shè)計測試用例。（×）12.文檔檢查有多種不同技術(shù)，可通過檢查強度、形式、必要的人力和時間資源以及它們的目的進行區(qū)分。（）13.白盒測試是一種針對程序結(jié)構(gòu)進行的測試，是邏輯驅(qū)動的測試或基于程序內(nèi)部的測試。（）14.黑

11、盒測試是一種從用戶觀點（依需求確定）出發(fā)的測試，其基本思想是：任何程序都可看作是從輸入定義域映射到輸出值域的函數(shù)過程。（）15.針對測試是否運行軟件和執(zhí)行程序劃分測試為靜態(tài)測試與動態(tài)測試。（）16.靜態(tài)測試主要由人工方式進行，這將充分發(fā)揮人的邏輯思維優(yōu)勢，同時靜態(tài)測試也借助測試專用工具進行自動化測試。（）17.數(shù)據(jù)流分析方法是在程序代碼經(jīng)過的路徑上檢查數(shù)據(jù)的用法。這種方式并不一定能夠發(fā)現(xiàn)缺陷，但可發(fā)現(xiàn)數(shù)據(jù)流異常。（）18.走查是以發(fā)現(xiàn)書面文檔中的缺陷、含糊的表達和問題為目的的正式評審。（×）19.靜態(tài)分析和評審是從不同的方式和角度來尋找和預(yù)防軟件的缺陷或故障，消除和減低軟件失效幾率的

12、措施與過程。（）20.軟件評審是動態(tài)測試的主要方法之一，評審可應(yīng)用人類的分析能力來檢查和評估復(fù)雜的問題。（×）形考任務(wù)3一、選擇題（每題5分）1.下面關(guān)于動態(tài)測試的描述錯誤的是（）。A. 動態(tài)測試必須由專門的測試人員完成B. 動態(tài)測試需要對輸入與輸出的對應(yīng)關(guān)系進行分析C. 動態(tài)測試必須運行被測試程序D. 動態(tài)測試適用于軟件生命周期的各個階段2.下面（）不屬于動態(tài)測試的內(nèi)容。A. 檢查內(nèi)存使用情況B. 檢查程序編碼規(guī)則C. 檢查各個組件功能D. 評估系統(tǒng)性能3.系統(tǒng)測試階段動態(tài)測試的目標(biāo)是（）。A. 對提交的軟件進行驗證性測試B. 檢測組件中的不合格品C. 功能和非功能的動態(tài)測試D.

13、動態(tài)檢測模塊與接口4.下面對基于直覺的動態(tài)測試方法的描述錯誤的是（）。A. 既不是黑盒測試也不屬于白盒測試B. 此方法的基礎(chǔ)是測試人員的技術(shù)、經(jīng)驗和知識C. 可以發(fā)現(xiàn)運用系統(tǒng)化方法進行測試時無法發(fā)現(xiàn)的問題D. 使用此方法時需要需求規(guī)格說明書和源代碼5.通過黑盒測試無法發(fā)現(xiàn)（）。A. 程序功能使用異常B. 程序內(nèi)部結(jié)構(gòu)錯誤C. 程序初始化錯誤D. 外部數(shù)據(jù)訪問異常6.黑盒測試技術(shù)包括（）。A. 邊界值分析、等價類劃分、因果圖、路徑覆蓋B. 邊界值分析、因果圖、等價類劃分、狀態(tài)轉(zhuǎn)換C. 判定覆蓋、語句覆蓋、決策表、正交實驗D. 決策表、狀態(tài)轉(zhuǎn)換、條件覆蓋、基本路徑測試7.黑盒測試屬于基本窮舉輸入的

14、測試方法，但通常輸入所有可能的測試將要受到較大客觀條件限制，無法實現(xiàn)窮盡，其原因是（）。輸入的組合太多輸出的結(jié)果太多軟件實現(xiàn)的途徑太多軟件規(guī)格說明沒有客觀標(biāo)準(zhǔn)A. B. C. D. 8.下面對等價類劃分法描述錯誤的是（）。A. 等價類劃分的主要依據(jù)是需求規(guī)格說明書B. 只需要考慮程序中合理的、有意義的輸入數(shù)據(jù)C. 將測試對象的輸入域劃分成若干部分D. 從每個部分中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例9.某程序輸入X取值于一個固定的枚舉類型1,4,9,16，并且程序要對這4個輸入值分別進行處理，根據(jù)等價類劃分法，這種情況下對輸入X劃分正確的是（）。A. 劃分為4個有效等價類、1個無效等價類B.

15、劃分為1個有效等價類、4個無效等價類C. 劃分為1個有效等價類、1 個無效等價類D. 劃分為1個有效等價類、2個無效等價類10.以下的測試方法中，允許對源代碼進行操作的是（）。A. 函數(shù)覆蓋B. 路徑測試C. 程序插樁D. 條件覆蓋二、判斷題（每題5分）11.動態(tài)測試并不貫穿于軟件產(chǎn)品生命周期的每個階段。（×）12.等價類劃分測試技術(shù)的測試準(zhǔn)則（即等價類劃分覆蓋率）可定義為總共描述的等價類數(shù)量與已執(zhí)行的等價類數(shù)量之比。（×）13.動態(tài)測試內(nèi)容有功能確認(rèn)與接口測試、覆蓋率分析、性能分析及內(nèi)存泄露分析等。（）14.邊界值分析法基于可靠性理論中的“多故障”假設(shè)，即兩個或兩個以上故

16、障同時出現(xiàn)而導(dǎo)致軟件失效的情況非常多。（×）15.邊界值覆蓋率=（已執(zhí)行的邊界值數(shù)量/總的邊界值數(shù)量）x 100%。（）16.因果圖法能幫助測試者按一定步驟，高效開發(fā)測試用例，以檢測程序輸入條件的各種組合情況。（）17.決策表是分析和表達多邏輯條件下執(zhí)行不同操作情況下的一種工具，可把復(fù)雜的邏輯關(guān)系與多種條件組合情況表達的既具體而又明確。（）18.邏輯覆蓋是黑盒測試中的主要方法之一，是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的測試技術(shù)，是通過對程序邏輯結(jié)構(gòu)的遍歷實現(xiàn)程序設(shè)計的覆蓋。（×）19.路徑覆蓋的目的就是要設(shè)計足夠多的測試用例，要求遍歷測試對象的所有不同的路徑。（）20.Z路徑覆蓋只

17、考慮循環(huán)體執(zhí)行一次和跳過循環(huán)體這兩種情況。（×）形考任務(wù)4一、選擇題（每題5分）1.在下列給出的各項中，關(guān)于軟件自動化測試的描述性定義是（）。A使用一種自動化測試工具來驗證軟件測試的需求B測試按照測試者的預(yù)定計劃自動地進行C自動化測試的目標(biāo)著重于發(fā)現(xiàn)舊的軟件缺陷D自動化測試可部署在各個測試階段A. AB. A、B、CC. A、CD. A、B、D2.（ ）是將測試輸入存儲在獨立的文件中，而不是綁定在腳本中。在腳本中存放控制信息，其優(yōu)點包括腳本與數(shù)據(jù)分離，數(shù)據(jù)文件以適當(dāng)?shù)奈募袷絾为毦S護，測試設(shè)計者不必具備專業(yè)的腳本技術(shù)或編程知識。A. 共享式腳本B. 結(jié)構(gòu)化腳本C. 關(guān)鍵字驅(qū)動腳本D.

18、 數(shù)據(jù)驅(qū)動腳本3.在下面給出的幾項中，（）是針對自動化測試腳本描述。A. 腳本自身在脫離了所依附的系統(tǒng)時，依然能夠運行B. 測試腳本也會存在缺陷或故障C. 腳本與測試一樣，根據(jù)測試模式和測試方法不同，腳本以多種形式出現(xiàn)D. 測試腳本是指測試自動執(zhí)行中的程序和過程4.在測試腳本的錄制、編寫與調(diào)試過程中，需要注意的原則是（）。A. 自動化回歸測試建議采用以錄制腳本為主、編寫腳本為輔的實現(xiàn)方式B. 測試腳本錄制包含兩種模式：控件識別模式和模擬操作模式?？丶R別模式中使用鍵盤操作實現(xiàn)兩種模式混合錄制效果C. 測試工具的選擇直接影響到實施的具體細(xì)節(jié)，而試用和比較是非常簡單有效的方法D. 腳本錄制與測試執(zhí)

19、行同期進行，腳本錄制完成后應(yīng)立即完成其主要調(diào)試工作5.引入自動化測試工具時，屬于次要考慮因素的是（）。A. 與測試對象進行交互的質(zhì)量B. 廠商的支持和服務(wù)質(zhì)量C. 使用的腳本語言類型D. 工具支持的平臺6.測試計劃主要由哪個角色負(fù)責(zé)制定：（）。A. 測試經(jīng)理B. 開發(fā)人員C. 測試人員D. 項目經(jīng)理7.對于監(jiān)控測試周期時采用的度量方法，下列敘述中不當(dāng)?shù)氖牵海ǎ?。A. 基于測試用例的度量：統(tǒng)計各優(yōu)先級的測試用例數(shù)量。B. 基于故障和基于失效的度量：統(tǒng)計特定軟件版本中的故障數(shù)。C. 基于成本度量：統(tǒng)計已經(jīng)花費的測試成本，下一測試周期成本與預(yù)期收益的關(guān)系。D. 基于測試對象的度量：統(tǒng)計代碼和安裝平臺等覆蓋情況。8.如果沒有做好配置管理工作，那么可能會導(dǎo)致：（）。A員相開發(fā)人互篡改各自編寫的代碼;B集成工作難以開展C問題分析和故障修正工