軟件測試整理復習(判斷題)
1(√) 發現錯誤多的模塊,殘留在模塊中的錯誤也多。
2(×) 目前在進行集成測試時普遍采用非漸增式測試方法。
分析:因為非漸增式測試方法先是對每一個子模塊進行測試(單元測試階段),然後將所有模塊一次性的全部集成起來進行集成測試 。很難確定出錯的真正位置、所在的模塊、錯誤的原因。
3(×) Alpha測試在一個或多個客戶場所進行,Beta測試由用戶在開發者的場所進行。
分析:驗收測試分為正式驗收測試、Alpha測試、Beta測試。Alpha測試在開發者的場所進行,Beta測試由用戶在一個或多個客戶場所進行。
4(√) 單元測試通常應該先進行“人工走查”,再以白盒法為主,輔以黑盒法進行動態測試。
5(×) 測試只要做到語句覆蓋和分支覆蓋,就可以發現程序中的所有錯誤.
6(×) 成功的測試是沒有發現錯誤的測試
分析:成功的測試是發現了至今為止沒有發現的錯誤的測試
7(√) 確認測試也稱為驗收測試,它的目的是驗證軟件的有效性。
8(×) 軟件測試是通過運行程序來查看錯誤。
分析:靜態測試不運行程序
9(√) 類的私有方法可以測試。
10(√) 源程序代碼的邏輯簡單明晰,易讀易懂是好程序的一個重要標準。
11(×) 邊界測試中所選擇的輸入測試數據一定是有效數據。
分析:邊界測試的測試用例選擇原則:如果輸入條件規定了值的範圍,則應該取剛達到這個範圍的邊界值,以及剛剛超過這個範圍邊界的值作為測試輸入數據
12(×) 抽象類可以測試。
分析:抽象類本身無法實例化,所以不能測試
13(√) 如數據流具有明顯的事務特點時(有一個明顯的事務中心),以采用事務分析方法為宜.
14(√) 結構化程序設計是一種設計程序的技術,它采用自頂向下逐步求精的設計方法和單入口單出口的控制結構。
15(√) 在程序設計過程中,我們盡量采用自頂向下和逐步細化的原則,由粗到細,一步步展開。
16(√) 程序流程圖本質上不是逐步求精的好工具,它誘使程序員過早地考慮程序的控制流程,而不去考慮程序的全局結構。
17(×) 良好的單元測試可以代替集成測試。
18(×) 在面向對象測試領域,對子類展開測試,既要測試子類的屬性和方法,也要測試從父類的屬性和方法。但是對於子類當中的重載方法,僅僅需要測試子類中的方法。
19(×) 等價劃分屬於白盒測試技術而控制結構測試屬於黑盒測試。
分析:等價劃分屬於黑盒測試技術而控制結構測試屬於白盒測試。
20(√) 靜態分析工具可用於軟件測試中直接分析源代碼,輔助生成測試用例。
21(√) 動態測試工具並不適用於需要大量交互操作的回歸測試場合
22(×) 靜態分析工具能分析測試用例對判定的覆蓋程度
23(√) 靜態分析工具通常把被測程序看作為字符流輸入,經檢查與分析後,產生出一份分析報告。
24(×) 良好的單元測試可以代替集成測試。
25(√) 軟件測試的目的是盡可能多的找出軟件的缺陷。
26(√) Beta測試是驗收測試的一種。
27(√) 驗收測試是由最終用戶來實施的。
28(√) 項目立項前測試人員不需要提交任何工件。
29(√) 單元測試能發現約80%的軟件缺陷。
30(×) 代碼評審是檢查源代碼是否達到模塊設計的要求。
分析:軟件評審目的盡早發現產品中的缺陷
31(√) 自底向上集成需要測試員編寫驅動程序。
32(×) 負載測試是驗證要檢驗的系統的能力最高能達到什麽程度。
分析:系統的最高能力是壓力測試,而負載測試是在超荷情況下的性能測試
33(×) 測試人員要堅持原則,缺陷未修復完堅決不予通過。
34(×) 代碼評審員一般由測試員擔任。
分析:一般是開發人員評審
35(×) 我們可以人為的使得軟件不存在配置問題。
36(×) 集成測試計劃在需求分析階段末提交。
分析:
37(√) 軟件測試是有風險的行為,並非所有的軟件缺陷都能夠被修復。
38(×) 軟件質量保證和軟件測試是同一層次的概念。
分析:測試只是質量保證工作中的一個環節。軟件質量保證和軟件測試是軟件質量工程的兩個不同層面的工作。
39(×) 我們有理由相信只要能夠設計出盡可能好的測試方案,經過嚴格測試之後的軟件可以沒有缺陷。
40(×) 程序員兼任測試員可以提高工作效率。
分析: 程序員不能測自己的程序
41(√) 在設計測試用例時,應當包括合理的輸入條件和不合理的輸入條件。
42(√) 傳統測試是在開發的後期才介入,現在測試活動已經擴展到了整個生命周期。
43(√) 傳統測試以發現錯誤為目的,現在測試已經擴展到了錯誤預防的範疇。
44(√) 軟件測試的生命周期包括測試計劃、測試設計、測試執行、缺陷跟蹤、測試評估。
45(×) 調試從一個已知的條件開始,使用預先定義的過程,有預知的結果;測試從一個未知的條件開始,結束的過程不可預計。
分析:測試從一個已知的條件開始,使用預先定義的過程,有預知的結果;調試從一個未知的條件開始,結束的過程不可預計
46(×) 白盒測試往往會造成測試用例之間可能存在嚴重的冗余和未測試的功能漏洞。
分析:黑盒測試往往會造成測試用例之間可能存在嚴重的冗余和未測試的功能漏洞。
47(×) 在邊界值方法中,對於一個有n個變量的函數作最壞情況測試,生成的測試用例個數是7n 個。
分析:4n+1
48(×) 軟件生存周期是從軟件開始開發到開發結束的整個時期。
分析:軟件生存周期是從軟件的產生直到報廢的生命周期
49(√) 在所有的黑盒測試方法中,基於決策表的測試是最為嚴格、最具有邏輯性的測試方法。
50(√) 永遠有缺陷類型會在測試的一個層次上被發現,並且能夠在另一個層次上逃避檢測。
51(×) 測試用例的數目越多,測試的效果越好。
52(×) 只要能夠達到100%的邏輯覆蓋率,就可以保證程序的正確性。
53(×) 單元測試屬於動態測試。
分析:單元測試既可以使用靜態分析,也可以使用動態測試
54(√) 驗收測試是以最終用戶為主的測試。
55(√) 沒有發現錯誤的測試是沒有價值的。
56(×) 可以把不合格的開發人員安排做測試。
57(√) 移動應用測試面臨的一個困難是軟件(app)運行的硬件平臺太多。
58(√) 眾測是解決移動測試待測平臺太多困境的有效方法。
59(√) 在Voas的PIE模型中,執行了錯誤語句(Fault),程序不一定進入錯誤狀態(Error),並且即使進入錯誤狀態,程序最終也有可能不表現出失效(Failure),我們把這種情況稱之為偶然正確性。
60(√) 回歸測試是用於驗證改變了的系統或組件是否保持原有的特性。
軟件測試整理復習(判斷題)