計算機(jī)四級軟件測試工程師-97

1、計算機(jī)四級軟件測試工程師 -97( 總分： 72.01 ，做題時間： 90 分鐘 )一、選擇題 (總題數(shù)： 25，分?jǐn)?shù)： 52.00)1. 不影響系統(tǒng)的基本使用，但沒有很好地實現(xiàn)功能，沒有達(dá)到預(yù)期的效果，如次要功能喪失、提示信息不 太準(zhǔn)確，或用戶界面差、操作時間長等，這屬于軟件缺陷級別中的 。A) 致命的缺陷B) 嚴(yán)重的缺陷C) 一般的缺陷D) 微小的缺陷 (分?jǐn)?shù)： 2.50 )A.B.C. VD.解析： 解析 軟件缺陷一旦被發(fā)現(xiàn)，就要設(shè)法找出引起該缺陷的原因，分析對產(chǎn)品質(zhì)量的影響，然后確定 軟件缺陷的嚴(yán)重性和處理這個缺陷的優(yōu)先級。一般來說，問題越嚴(yán)重，其處理的優(yōu)先級越高，越要得到及 時的糾正

2、。軟件缺陷有 4 種級別，分別為：致命的 (Fatal) ，嚴(yán)重的 (Critical) ，一般的 (Major) ，微小的 (Minor) 。一般的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實現(xiàn)功能，沒有達(dá)到預(yù)期的效果。2. 軟件可靠性與硬件可靠性的區(qū)別體現(xiàn)在 。A. 唯一性B .物理退化C .邏輯復(fù)雜性D .以上都是(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析： 解析 軟件可靠性與硬件可靠性的區(qū)別在于，軟件可靠性是唯一的，不以物理退化而失效，但軟件 的邏輯更為復(fù)雜，并且版本更新更為頻繁。3. 以下關(guān)于軟件性能測試的說法中，正確的是A) 軟件性能測試的主要目的是檢驗軟件是否能充分發(fā)揮硬

3、件的潛能B) 軟件性能測試通常采用數(shù)據(jù)流測試技術(shù)生成測試用例C) 軟件性能測試實際上是一種軟件可靠性測試D) 軟件性能測試的實施通常需要依賴性能測試輔助軟件(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析： 解析 軟件性能測試的目標(biāo)是發(fā)現(xiàn)缺陷、性能調(diào)優(yōu)、能力檢驗與規(guī)劃。軟件性能測試和可靠性測試 是同一級別的測試。4. 不是軟件測試評估的目的是 。A) 量化測試過程，判定測試進(jìn)行的狀態(tài)B）決定什么時候測試可以結(jié)束C）保證每個階段的測試任務(wù)得到執(zhí)行D）為最后的測試或質(zhì)量分析報告生成所需的量化數(shù)據(jù)（分?jǐn)?shù)： 2.00 ）A.B.C. VD.解析： 解析 軟件測試評估的目的是： 量化測試過程， 判定測試進(jìn)

4、行的狀態(tài)， 決定什么時候測試可以結(jié)束； 為最后的測試或質(zhì)量分析報告生成所需的量化數(shù)據(jù)。5. 單元測試中的主要測試方法為 。A）黑盒測試 B） 灰盒測試C） 回歸測試 D） 白盒測試 （分?jǐn)?shù)： 2.00 ）A.B.C.D. V解析：解析 單元測試的對象是實現(xiàn)了具體功能的程序單元，所以采用的主要測試方法為基于代碼的白盒 測試。6. 下列測試用例設(shè)計方法中，不會在協(xié)議一致性測試中使用的是 。A. 等價類測試B 基于風(fēng)險的測試C. 規(guī)范導(dǎo)出法D .邊界值測試（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：7. 關(guān)于自動比較方式，說法正確的是 。A. 田于動態(tài)比較有助于為測試用例輸入一些智能，故使用率在

5、逐步提升B. 用于對發(fā)送到屏幕以外的輸出進(jìn)行比較的應(yīng)是執(zhí)行后比較C. 屏幕輸出上許多細(xì)微的變化可能造成動態(tài)比較強(qiáng)調(diào)許多不重要的差異，此時會造成測試工具更新預(yù)期輸 出比較困難D. 測試執(zhí)行工具通常包括對執(zhí)行后比較的直接支持（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：8. 在結(jié)構(gòu)化測試用例設(shè)計中， 有語句覆蓋、條件覆蓋、判定覆蓋(也稱分支覆蓋 ) 、路徑覆蓋等， 其中是最強(qiáng)的覆蓋準(zhǔn)則。A) 語句覆蓋 B) 條件覆蓋 C) 判定覆蓋 D) 路徑覆蓋(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析： 解析 在題目所述邏輯覆蓋中，路徑覆蓋是最強(qiáng)的覆蓋準(zhǔn)則。路徑覆蓋強(qiáng)于判定覆蓋，判定覆蓋強(qiáng) 于語句覆蓋。

6、9. 從下列敘述中選出能夠與軟件開發(fā)需求分析、設(shè)計、編碼相對應(yīng)的軟件測試 。A) 集成測試、確認(rèn)測試、單元測試B) 單元測試、集成測試、確認(rèn)測試C) 單元測試、確認(rèn)測試、組裝測試D) 確認(rèn)測試、集成測試、單元測試 (分?jǐn)?shù)： 2.00 )A.B.C.D. V解析： 解析 軟件開發(fā)需求分析對應(yīng)的是測試階段的確認(rèn)測試，軟件設(shè)計對應(yīng)的是集成測試，編碼階段對 應(yīng)的是單元測試。10. 下列關(guān)于面向?qū)ο筌浖y試的說法中，不正確的是 。A. 面向?qū)ο筌浖陌缀袦y試不能不加改變地照搬傳統(tǒng)軟件的白盒測試準(zhǔn)則B. 在存在多態(tài)的情況下，為了達(dá)到較高的測試充分性，應(yīng)對所有可能的綁定都進(jìn)行測試C. 假設(shè)類B是類A的子類，

7、如果類A已進(jìn)行了充分的測試， 在測試類B時不必測試任何類 B繼承類A的成 員方法D. 對于一棵繼承樹上的多個類，處于葉子節(jié)點的類也需要測試(分?jǐn)?shù)： 2.00 )A.B.C. VD.解析： 解析 封裝、繼承和多態(tài)是面向?qū)ο筌浖^(qū)別于傳統(tǒng)的結(jié)構(gòu)化軟件的三個主要特點，然而這些特點都可能對測試帶來困難。選項C中考察繼承和繼承與多態(tài)的復(fù)合對測試的影響，假設(shè)類B是類A的子類，如果類A已進(jìn)行了充分的測試，若按傳統(tǒng)的測試充分性準(zhǔn)則，在測試類B時可以把關(guān)注點放在類 B自身定義的成員變量和成員方法上，但在實際測試類B時，這樣的測試往往會不夠充分，還是要對類B繼承類A的成員方法進(jìn)行測試的，而且對于一棵繼承樹上的多個

8、類，僅對處于葉節(jié)點的類進(jìn)行測試也是不充分的。11. 軟件性能測試的目標(biāo)不僅僅是發(fā)現(xiàn)性能缺陷，具體軟件性能測試不包括下述中的 。A) 發(fā)現(xiàn)缺陷 B) 性能調(diào)優(yōu) C) 能力檢測與規(guī)劃 D) 安全入侵檢測分?jǐn)?shù)： 2.00 )A.B.C.D. V解析：解析軟件性能測試的目標(biāo)不僅僅是發(fā)現(xiàn)(和改正)性能缺陷(Perform-ance Bug)，還包括探索和規(guī)劃軟件的實際性能。具體軟件性能測試以下目標(biāo)：發(fā)現(xiàn)缺陷，性能調(diào)優(yōu)，能力檢驗與規(guī)劃。12. 對測試用例進(jìn)行管理，可以依據(jù)測試用例編寫過程的屬性、組織過程的屬性和A) 創(chuàng)建過程的屬性 B) 測試過程的屬性C) 執(zhí)行過程的屬性 D) 管理過程的屬性 (分?jǐn)?shù)：

9、2.00 )A.B.C. VD.解析： 解析 測試用例要經(jīng)過創(chuàng)建、修改和不斷完善的過程。測試用例的屬性有：優(yōu)先次序、目標(biāo)性、所 屬的范圍、關(guān)聯(lián)性、階段性、狀態(tài)性、時效性、所有者、日期等特性。根據(jù)測試用例的屬性及編號等可對 測試用例進(jìn)行基于數(shù)據(jù)庫方式的良好管理，另外也可以依據(jù)測試用例編寫過程的屬性、組織過程的屬性和 執(zhí)行過程的屬性來對測試用例進(jìn)行有效管理。13. 以下哪一項不屬于兼容性測試關(guān)注的范疇A) 操作系統(tǒng)是否能運(yùn)行于不同的硬件平臺B) 殺毒軟件在清除病毒時是否會影響辦公軟件的正常工作C) Web 應(yīng)用軟件是否支持不同的關(guān)系型數(shù)據(jù)庫D) 軟件用戶手冊中的功能說明與實際功能是否一致(分?jǐn)?shù)：

10、2.00 )A.B.C.D. V解析： 解析 兼容性測試包括：與操作系統(tǒng)的兼容性；與數(shù)據(jù)庫的兼容性；與瀏覽器的兼容性；與中間件 的兼容性；與其他軟件的兼容性；與平臺軟件的兼容性。14. 為了提高測試的效率，正確的做法是 。A) 選擇發(fā)現(xiàn)錯誤可能性大的數(shù)據(jù)作為測試用例B) 隨機(jī)選取測試用例C) 取一切可能的輸入數(shù)據(jù)作為測試用例D) 在完成程序的編碼之后再制訂軟件的測試計劃(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析： 解析 對于一個軟件，其可能的輸入數(shù)據(jù)數(shù)量一般是非常驚人的，所以要想全部將其作為測試用例是不現(xiàn)實的，應(yīng)當(dāng)選擇發(fā)現(xiàn)錯誤可能性大的數(shù)據(jù)作為測試用例，不能隨機(jī)選取測試用例，故A正確，B、

11、C錯誤。軟件測試貫穿于軟件開發(fā)的各個階段，D項錯誤。15. 走查的最主要目標(biāo)有。發(fā)現(xiàn)缺陷、遺漏和矛盾的地方改進(jìn)產(chǎn)品 考慮可替換的實現(xiàn)方法 A） 和 B） 和C）和D）、和（分?jǐn)?shù)： 3.00 ）A.B.C.D. V解析： 解析 走查的目的是要評價一個產(chǎn)品，通常是程序代碼，走查一直以來都與代碼檢查聯(lián)系在一起， 其實走查也可以應(yīng)用到產(chǎn)品的其他階段，如結(jié)構(gòu)設(shè)計、詳細(xì)設(shè)計、測試計劃等文檔上。走查的最主要目標(biāo) 是要發(fā)現(xiàn)缺陷、遺漏和矛盾的地方，改進(jìn)產(chǎn)品，考慮可替換的實現(xiàn)方法。16. 在極限測試過程中，貫穿始終的是 。A. 單元測試和集成測試 B 單元測試和系統(tǒng)測試C. 集成測試和系統(tǒng)測試 D 單元測試和驗收

12、測試（分?jǐn)?shù)： 2.00 ）A.B.C.D. V解析： 解析 極限編程采用的是一種頻繁迭代的開發(fā)方式，整個軟件項目由一系列增量式開發(fā)組成。而極 限測試本質(zhì)上就是為了滿足極限編程的思想和流程而設(shè)計的一套測試策略和流程，從極限測試流程圖中我 們可以看出，單元測試和驗收測試是貫穿始終的關(guān)鍵步驟。17. 閱讀以下程序，采用邏輯覆蓋進(jìn)行測試，下列測試用例（a ,b,c）的輸入值，可以達(dá)到條件覆蓋的是 Int func（int a, b, c）Int k=1:lf（a >0）| （b v 0）|（a+c>0）k=k+a ；Else k=k+b ：lf（c > 0）k=k+c ：Return

13、 k'A） （1， 1， 1）， （-1 ，1，1） B） （1，1， 1）， （-1 ， -1 ，-1）C） （1， 1， -1） ， （1 ，1，1） D） （1，1， -1） ， （-1 ， 1，1）（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析： 解析 條件覆蓋是指設(shè)計若干測試用例，運(yùn)行被測程序，使得每個判定的每個條件的可能取值至少評價一次。A、C D選項中b的取值條件不全。故本題選 B18. 下列情況表明出錯處理功能有錯誤和缺陷的是 。A. 顯示的錯誤與實際遇到的錯誤不符B. 顯示的錯誤信息難以理解C. 對異常處理的不得當(dāng)D. 以上全部(分?jǐn)?shù)： 2.00 )A.B.C.D.

14、V解析：19. 功能或性能沒有實現(xiàn)，主要功能部分喪失，次要功能完全喪失，或致命的錯誤生命，這屬于軟件缺陷級 別中的 。A) 致命的缺陷 (fatal)B) 嚴(yán)重的缺陷 (critical)C) 一般的缺陷 (major)D) 微笑的缺陷 (minor)(分?jǐn)?shù)： 2.00 )A.B. VC.D.解析：解析 軟件缺陷一旦被發(fā)現(xiàn)，就要設(shè)法找出引起該缺陷的原因，分析對產(chǎn)品質(zhì)量的影響，然后確定 軟件缺陷的嚴(yán)重性和處理這個缺陷的優(yōu)先級。一般來說，問題越嚴(yán)重，其處理的優(yōu)先級越高，越要得到及 時的糾正。軟件缺陷有四種級別：致命的缺陷 (fatal) 、嚴(yán)重的缺陷 (critical) 、一般的缺陷 (majo

15、r) 、微 小的缺陷 (minor) 。20. 軟件可靠性分析方法通常不依賴于概率統(tǒng)計的方法，下面屬于軟件可靠性分析方法的是 。A.失效模式影響分析法(FMEA法)B 故障樹和事件樹分析法C.潛在線路分析法D 以上全部(分?jǐn)?shù)： 1.00 )A.B.C.D. V解析： 解析 目前主要的軟件可靠性分析方法有失效模式影響分析法、嚴(yán)酷度分析法、故障樹分析法、事 件樹分析法、潛在線路分析法。21. 技術(shù)評審分為正式和非正式兩種，通常由技術(shù)負(fù)責(zé)人制度詳細(xì)的評審計劃，包括 。A.評審時間B 對所需文件的定義C.評審地點D .以上全部(分?jǐn)?shù)： 2.00 )A.B.C.解析：22. 自底向上單元測試的策略是首先

16、對模塊調(diào)用圖上的哪一層模塊進(jìn)行測試 A) 最底層 B) 下一層 C) 最高層 D) 上一層(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析： 解析 自底向上測試與自頂向下測試的測試策略都是增量式的測試，軟件是分層設(shè)計的，主模塊調(diào) 用子模塊，子模塊又依次調(diào)用更低層次的模塊，依此類推。在自底向上單元測試的策略中，應(yīng)首先測試最 底層的模塊，利用輔助的測試驅(qū)動模塊調(diào)用他們并傳遞測試數(shù)據(jù)，然后再測試更高層次的模塊，再較高層 次的模塊測試中可以直接調(diào)用已測試過的較低層次的模塊。23. 下面有關(guān)軟件質(zhì)量保證活動目標(biāo)的說法中不正確的是 。A) 客觀地驗證軟件產(chǎn)品和各項任務(wù)是否遵循適用的標(biāo)準(zhǔn)、規(guī)程和需求B) 用最

17、少的時間和人力，找出軟件中潛在的各種錯誤和缺陷C) 高層管理人員能夠參與并幫助解決項目中不能解決的不相容問題D) 規(guī)劃軟件質(zhì)量保證任務(wù) (分?jǐn)?shù)： 2.50 )A.B. VC.D.解析： 解析 軟件質(zhì)量保證活動的目標(biāo)為：制定和規(guī)劃軟件質(zhì)量保證的任務(wù)，客觀地驗證軟件產(chǎn)品和各項 任務(wù)是否遵循適用的標(biāo)準(zhǔn)、規(guī)程和需求，相關(guān)小組和個人保持良好的溝通，及時通知他們在軟件質(zhì)量保證 方面的認(rèn)識和結(jié)果，高層管理人員能夠參與并幫助解決項目中不能解決的不相容問題。而選項B( 用最少的時間和人力，找出軟件中潛在的各種錯誤和缺陷) 應(yīng)為軟件測試的目標(biāo)，兩者要區(qū)分開來。24. 桌上檢查 (Desk Checking) 是一

18、種 的檢查方法。A) 程序員自己檢查自己編寫的程序B) 由同行幫忙檢查自己編寫的程序C) 幾個同行自行組成小組，以小組為單位檢查編寫的程序D) 程序員在桌子上檢查編寫程序的活動(分?jǐn)?shù)： 3.00 )A. VB.C.D.解析： 解析 桌上檢查 (Desk checking) 是一種傳統(tǒng)的檢查方法，由程序員自己檢查自己編寫的程序。程 序員在程序通過編譯之后，進(jìn)行單元測試設(shè)計之前，對源程序代碼進(jìn)行分析，對照錯誤列表進(jìn)行檢查，對 程序推演測試數(shù)據(jù)，并補(bǔ)充相關(guān)的文檔。桌上檢查的目的就是發(fā)現(xiàn)程序中的錯誤。25. 以下關(guān)于 Web應(yīng)用軟件測試的說法中，正確的是 。A. 數(shù)據(jù)完整性測試是 Web應(yīng)用軟件數(shù)據(jù)層測試的一項重要內(nèi)容B. 內(nèi)容測試是 Web應(yīng)用軟件易用性測試的一項重要內(nèi)容C. 表單測試是 Web應(yīng)用軟件表示層測試的一項重要內(nèi)容D. 鏈接結(jié)構(gòu)的測試是 Web應(yīng)用軟件安全性測試的一項重要