參考地址 http://www.docin.com/p-297467364.html
第一章：軟件測試基礎（18%）
1、學習目標
1.1 為什么需要軟件測試？ (K2)
① 通過具體的例子，來描述軟件中的缺陷會以什么樣的方式損害個人、損害環境或者損 害公司利益（K2）。
② 區分引起缺陷的根本原因及其影響（K2）。
●由人設計的程序代碼或文檔中會引入缺陷。時間，人員，代碼，系統，技術，環境都會引起軟件缺陷。
③ 通過舉例的方式說明為什么需要測試（K2）。
●可以減少軟件系統在運行環境中的風險，可以提高軟件系統的質量。
④ 描述為什么測試是質量保證(quality assurance)的一部分，通過舉例說明測試是如何來提高軟件質量的（K2）。
●測試就會幫助樹立對於軟件質量的信心。一個設計合理的測試過程完成並順利通過，可以降低整個系統存在問題的風險。
⑤ 理解術語錯誤（error，mistake）、缺陷（defect，bug）、故障（fault）、失效（failure）的概念以及相應的定義（K1）。
●錯誤（mistake）：產生不正確結果的人為行為。人為的原因導致一個不正確的結果。它可以是程序內的內部錯誤，也可能是文檔內的錯誤。甚至是環境方面的問題。
●錯誤（error）：計算機計算得到的、觀察到的、測量到的數值或者條件和理論上得到的正確的數值或者條件之間存在的差異。
●缺陷（defect）：程序或者軟件中不正確的步驟、過程或者數據定義等。比如錯誤的語句或者錯誤的標量定義等。缺陷是錯誤的具體表現，可以是不正確的文檔、程序段以及指令或者數據定義。
●失效/失敗（failure/fail）：軟件系統或單元無法實現需求文檔中規定的功能特性或者非功能特性。或者說單元/系統產生的結果與期望交付的服務或者結果存在偏差。http://www.51testing.com/html/91/n-229691.html
1.2 什么是測試 (K2)
●測試活動包含了測試執行之前和之后的一些活動，包括計划和控制、選擇測試條件、設計和執行測試用例、檢查測試結果、評估出口准則、報告測試過程及被測系統、在一個測試階段完成后要進行測試結束或總結工作
① 認識測試的總體目標（K1）。
●發現缺陷；增加對質量的信心；為決策提供信息；預防缺陷。
② 描述在軟件開發、軟件維護和軟件運行過程中，測試作為發現缺陷、提供信息和信心 以及預防缺陷的一種手段（K2）。
●不同的測試階段，需要考慮不同的測試目標。
●組件測試、集成測試和系統測試等，測試的主要目標是盡可能的發現失效；
●在驗收測試中，測試的主要目標是確認系統是否按照預期工作，是建立滿足了需求的信心；
●在運行測試階段，測試的主要目標是為了評估系統的特征；
1.3 軟件測試的基本原則 (K2)
說明測試的基本原則（K2）。
●測試顯示存在缺陷
●窮盡測試是不可行的
●測試盡早介入
●缺陷集群性
●殺蟲劑悖論
●測試活動依賴於測試背景
●不存在缺陷（就是有用系統）的謬論
1.4 基本的測試過程 (K1)
① 認識從計划到測試結束過程中測試的基本活動，以及在每個測試活動中的主要任務 （K1）。
基本的測試過程主要由下面一些活動組成：
●測試計划和控制；
●測試分析和設計；
●測試實現和執行；
●評估出口准則和報告；
●測試結束活動。
1.5 測試的心理學 (K2)
① 認識測試的成功與否，會受測試心理因素的影響（K1）：
●清晰的測試目標決定了測試人員效率；
●人們往往會忽視自己的錯誤；
●認識到就事論事的交流方式以及反饋與問題相關信息的重要性。
② 對比測試人員(tester)和開發人員(developer)的思維方式的差異（K2）。
●在系統中發現失效需要測試員具有一顆好奇心、專業的懷疑態度、一雙挑剔的眼睛、對細節的關注、與開發人員良好的溝通能力以及對常見的錯誤進行判斷的經驗。
2、練習題
2.1 下列術語中哪一個是ISTQB術語表中缺陷(Defect)的同義詞：B
a)Incident b)Bug c)Mistake d)Error
2.2 軟件測試目的可以是：B
A.發現缺陷
B.確認軟件能夠正常運行
C.預防缺陷
D.直接提高產品的售價
E.減少整個產品開發周期時間
a)A, B b)A, B, C c)A, B, C 和 D d)所有選項
2.3 根據ISTQB 定義的術語， “風險”是與下列哪一個選項關聯的？C
a)對測試者否定的反饋意見 b)將產生負面影響及其連鎖效應的因素
c)可能產生負面影響及其連鎖效應的因素 d)將對被測對象產生負面影響及其連鎖效應的因素
2.4 確認系統是否按照預期工作，從而在系統是否滿足系統需求方面獲取信心。這樣的測試目的最可能適用下面的哪個測試階段：C
a)組件測試 b)集成測試 c)系統測試 d)回歸測試
2.5 識別測試的任務、定義測試的目標以及為實現測試目標和任務的測試活動規格說明。上述行為主要發生在： A
a)計划和控制 b)分析和設計 c)實現和執行 d)測試結束活動
2.6 ISTQB術語中的回歸測試的目的是：C
a)驗證修改的成功 b)預防功能編寫的不完善或疏漏
c)確保修正過程中沒有引入新的缺陷 d)幫助程序員更好地進行單元測試
2.7 下列方式可以提高和改善測試人員和開發人員關系的是：B
a)理解項目經理工作的重要性 b)對所發現的可能的缺陷以一種中立的方式進行溝通
c)單元測試、集成測試和系統測試都由同一批測試人員來完成 d)測試人員參加代碼調試
2.8 基本的測試過程主要由下面哪些活動組成：D
A.計划和控制(control)
B.分析和設計
C.實現和執行
D.評估出口准則和測試報告
E.測試結束活動
a)A, B 和 C b)A, B, C 和 D c)除 E 以外所有選項 d)所有選項
2.9 對實現軟件測試組的獨立的方式，可以采用的是：B
A.測試的設計由開發隊伍的其他開發人員完成；
B.測試的設計由開發人員自己完成；
C.測試的設計獨立於本項目的開發隊伍；
D.測試的設計獨立於本開發企業，來自於獨立的第三方測試機構。
E.所有測試活動由開發人員來完成
a)A, B, C b)A, B, C, D c)A, C, E d)所有選項
2.10 以下關於測試原則的描述，正確的是： B
a)所有的軟件測試不需要追溯到用戶需求；
b)完全測試是不可能的；
c)測試可以顯示軟件潛在的缺陷；
d)程序員不需要避免檢查自己的程序。
2.11 軟件測試工作應該開始於：B
a)Coding之后； b)需求分析階段； c)概要設計階段； d)詳細設計階段。
2.12 作為一個軟件測試員，應具備哪些能力？D
A.具有好奇心；
B.職業悲觀心態；
C.批評的眼光；
D.關注系統的細節的能力
E.測試技能；
F.良好的溝通能力
a)A+B+C ； b)D+E+F ； c)E+F； d)以上都是。
2.13 以下可能導致缺陷的原因有：D
A.環境因素；(可能導致失效)
B.開發技術；
C.過程管理規范性；
D.個人能力
E.軟件的復雜性；
F.開發的周期長短
a)以上都是； b)以上都不是； c)A+B+C； d)D+E+F。
2.14 關於軟件質量保證和軟件測試的描述，不正確的是 D
a)軟件質量保證和軟件測試是軟件質量工程的兩個不同層面的工作；
b)在軟件質量保證的活動中也有一些測試活動；
c)軟件測試是保證軟件質量的一個重要環節；
d)軟件測試人員就是軟件質量保證人員。
2.15 關於測試充分性的描述，正確的是：B
a)只有進行完全的測試才充分；
b)在有限的時間和資源條件下，找出所有的軟件的錯誤，使軟件趨於完美，是不可能的；
c)當繼續測試沒有發現新缺陷時；
d)當全部測試用例都執行完后。
2.16 以下關於測試目的的觀點，不正確的是：B
a)軟件測試的目的是尋找錯誤，並且盡最大的可能找出最多的錯誤；
b)找出軟件開發人員的問題並評價開發人員能力；
c)一個成功的測試是發現了至今未發現的錯誤的測試；
d)測試的目的，是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質量，避免軟件發布后由於潛在的軟件缺陷和錯誤造成的隱患所帶來的商業風險。
2.17 以下關於測試作用的描述，不正確的是：B
a)測試無法顯示軟件潛在的缺陷；
b)測試能保證軟件的缺陷和錯誤全部找到；
c)測試只能證明軟件存在錯誤而不能證明軟件沒有錯誤；
d)所有的軟件測試都應追溯到用戶需求。
第二章：軟件生命周期中的測試（15%）
1、學習目標
1.1 軟件開發模型 (K2)
① 明白在開發生命周期中的軟件開發、測試活動和工作產品之間的相互關系，並根據項目和產品的特征以及它們的背景提供相應的例子（K2）。
●V-模型
② 知道必須根據項目背景和產品特征來選擇軟件開發的模型（K1）。
●原型開發、快速應用開發（RAD）、統一軟件開發過程（RUP）和敏捷開發模型
③ 理解在軟件測試中采用不同測試級別的原因，以及在任何生命周期模型中一個良好的 測試應該具備的特征（K1）。
●每個開發活動都有相對應的測試活動；
●每個測試級別都有其特有的測試目標；
●對於每個測試級別，需要在相應的開發活動過程中進行相應的測試分析和設計；
●在開發生命周期中，測試員在文檔初稿階段就應該參與文檔的評審。
1.2 測試級別(K2)
① 比較不同測試級別之間的區別：測試的主要目的、典型的測試對象、典型的測試目標 （功能性的或結構性的）、相關的工作產品、測試的人員、識別缺陷和失效的種類（K2）。
●單元測試
●測試依據：1.組件需求說明；2.詳細設計文檔；3.代碼。
●典型測試對象：1.組件；2. 程序；3. 數據轉換/移植程序；4. 數據庫模型。
●組件測試可能包括功能測試和特定的非功能特征測試。
●集成測試/系統測試/驗收測試（用戶驗收測試、操作（驗收）測試、合同和法規性驗收測試、Alpha和Beta（或現場）測試）
1.3 測試類型(K2)
① 通過舉例比較四種不同的軟件測試類型（功能測試、非功能測試、結構測試和與變更 相關的測試）（K2）。
② 明白功能測試和結構測試可以應用在任何測試級別（K1）。
●功能測試主要是考慮軟件的外部表現行為（黑盒測試）。
③ 根據非功能需求來識別和描述非功能測試的類型。（K2）。
●非功能性測試就是測試系統運行的表現如何。術語“非功能測試”是指：為了測量系統和軟件的特征，需要進行的測試。非功能測試關注的是軟件的外部行為表現，通常采用黑盒測試設計技術來實現測試用例。
④ 根據對軟件系統結構或構架的分析來識別和描述測試的類型（K2）。
●可以在任何測試級別上進行結構測試（白盒測試）。
●結構測試技術最好在進行基於規格說明的測試之后使用，以便通過評估結構類型的覆蓋來測量測試的完整性。
●結構測試方法也同樣可以運用到系統、系統集成或驗收測試級別（比如業務模型或菜單結構）。
⑤ 描述確認測試和回歸測試的目的（K2）。
●確認測試和回歸測試應該可以重復進行。將回歸測試自動化是很好的選擇。
1.4 維護測試 (K2)
① 比較維護測試（一個現存系統的測試）與一個新的應用軟件的測試在測試類型、測試 的觸發和測試規模等方面的區別（K2）。
●一旦對軟件或系統進行修改、移植或退役處理時，就需要進行維護測試。
② 識別維護測試的原因（由於修改、移植或退役等因素）（K1）。
●修改可以是計划中的功能增加。為移植（如從一個平台移植到另外一個平台）。為系統退役而進行的維護測試應該包括數據移植測試。
③ 描述回歸測試和變更的影響度分析在軟件維護中的作用（K2）。
●維護測試的范圍取決於變更的風險、現有系統的規模和變更的大小。確定變更如何影響現有系統的過程，稱之為影響分析，它有助於決定實施回歸測試的廣度和深度。
2、練習題
2.1 可維護性測試屬於：D
a)非功能測試 b)功能測試 c)結構測試 d)確認和回歸測試
2.2 有一個系統已經在市場上運行了，這種情況對系統進行修改，然后進行的測試： A
a)維護測試 b)驗收測試 c)組件測試 d)系統測試
2.3 下面哪些是一個好的測試的特點：C
A.每個開發活動都有相對應的測試行為
B.每個測試級別都有其特有的測試目標
C.對於每個測試級別，需要在相應的開發活動過程中進行相應的測試分析和設計
D.軟件測試的工作重點應該集中在系統測試上
a)C,D b)A,B c)A,B,C d)A,B,C,D
2.4 下面可以作為組件測試的測試對象的是：A
a)模塊、對象和類 b)程序中的某個子系統 c)整個軟件系統 d)模塊間的接口
2.5 組件測試的用例設計主要參考的工作產品是：A
a)組件規格說明 b)系統需求規格說明 c)用戶手冊 d)代碼
2.6 下面關於回歸測試敘述正確的是： D
a)回歸測試只能在系統測試這個級別進行，不能用於單元測試和集成測試
b)回歸測試只適用於功能測試，不適用於非功能測試
c)回歸測試都是自動化執行的
d)回歸測試是對已被測過的程序實體在修改缺陷后進行的重復測試，以此來確認在這些變更后是否有新的缺陷引入系統
2.7 語句的覆蓋率主要在下面哪個測試級別的測試設計中考慮：C
a)系統測試 b)集成測試 c)組件測試 d)驗收測試
2.8 傳統的或面向對象的單元測試，需要的開發工作：D
a)只要開發測試stub；
b)只要開發測試driver；
c)可能要同時開發一個stub和多個driver；
d)可能要同時開發一個driver和多個stub。(一個入口，多個輸出)
2.9 目前大部分的軟件錯誤來源於____。D
a)程序錯誤； b)分析和設計錯誤； c)測試本身的錯誤； d)需求錯誤。
第三章：靜態技術（7%）
1、學習目標
1.1 靜態技術和測試過程（K2）
① 了解可以通過不同的靜態技術來檢查並確認軟件工作產品的質量（K1）。
●靜態測試技術通過手工檢查（評審）或自動化分析（靜態分析）的方式對代碼或者其他的項目文檔進行檢查而不需要執行代碼。
② 描述了在評估軟件工作產品中運用靜態技術的重要性和它的價值（K2）。
③ 解釋靜態技術和動態技術之間的區別（K2）。
●與動態測試相比，靜態技術發現的是軟件失效的原因（缺陷）而不是失效本身。
④ 描述靜態分析和評審的目標，並且和動態測試進行對比（K2）。
●評審、靜態分析和動態測試具有共同的目標：識別缺陷。
●軟件評審的主要好處有：盡早發現和修改缺陷、改善開發能力、縮短開發時間、縮減測試成本和時間、減少產品生命周期成本、減少缺陷以及改善溝通等
1.2 評審過程（K2）
① 理解典型的正式評審過程中的階段、角色和職責定義（K1）。
●計划階段
●預備會階段
●個人准備階段
●檢查/評價/記錄結果（評審會議階段）
●返回階段
●跟蹤結果階段
② 解釋不同類型評審的區別：非正式評審(informal review)、技術評審(technical review)、走查(walkthrough)和審查(inspection)（K2）。
●非正式評審 主要目的：以較低的成本獲得收益。
●走查 主要目的：學習、增加理解、發現缺陷。
●技術評審 主要目的：討論、作決策、評估候選方案、發現缺陷、解決技術問題、檢查與規格及標准的符合程度。
③ 解釋影響評審成功的主要因素（K2）。
●每次評審都有預先明確定義的目標；
●針對評審目標，有合適的評審人員的參與； 測試人員參加評審不但有利於提高評審質量，還可以通過評審了解產品，為測試盡早開始做准備；
●對發現的缺陷持歡迎態度，並客觀地描述缺陷；
●能夠正確處理人員之間的問題以及心理方面的問題；
●評審應該在一種信任的氣氛中進行；並且結果不應用於對參與者的評價；
●采用的評審技術適合於要達到的目標、軟件工作產品的類型和級別以及參與評審的人員；
●選用合適的檢查表或定義合適角色，可以提高缺陷識別的有效性；
●提供評審技術方面的培訓，特別是針對正式的評審技術，比如審查；
●管理層對良好評審過程的支持；
●強調學習和過程的改進。
1.3 靜態分析的工具支持（K2）
① 理解通過靜態分析能夠識別的典型缺陷和錯誤，並與評審和動態測試之間進行比 較（K1）。
●靜態分析的執行並不需要使用工具去實際運行被測軟件。
●動態測試是真正運行軟件的代碼。靜態分析可以定位那些在測試過程很難發現的缺陷。與評審一樣，靜態分析通常發現的是缺陷而不是失效。
② 列出靜態分析的典型優點（K1）。
●在測試執行之前盡早發現缺陷；
●通過度量的計算（比如高復雜性測量），早期警示代碼和設計可能存在問題的方面；
●可以發現在動態測試過程不容易發現的一些缺陷；
●可以發現軟件模塊之間的相互依賴性和不一致性，例如鏈接；
●改進代碼和設計的可維護性；
●在開發過程中學習經驗教訓，從而預防缺陷。
③ 列出通過靜態分析工具識別的典型的代碼缺陷和設計缺陷（K1）。
●引用一個沒有定義值的變量；
●模塊和組件之間接口不一致；從未使用的變量；
●不可達代碼或死代碼；邏輯上的遺漏與錯誤（潛在的無限循環）；
●過於復雜的結構；違背編程規則；
●安全漏洞；
●代碼和軟件模型的語法錯誤。
2、練習題
2.1 多出口函數可能會發生__B____問題
a)產生邏輯錯誤 b)降低可靠性 c)產生內存泄漏 d)降低運行性能
2.2 使用靜態測試中的函數調用關系圖不能夠C
a)檢查函數的調用關系是否正確
b)發現是否存在孤立函數
c)明確函數被調用頻度，並對這些函數進行重點檢查
d)發現函數內部結構
2.3 下面對靜態測試和動態測試的區別描述正確的是：A
a)靜態測試並沒有真正的運行軟件，而動態測試需要運行軟件
b)靜態測試需要借助於專門的測試工具，而動態測試不需要
c)靜態測試是由開發人員執行的，而動態測試是由專門的測試人員完成
d)靜態測試是主要是為了增加測試人員對軟件的理解，而動態測試是為了發現缺陷
2.4 下面那個不屬於靜態分析：D
a)編碼規則的檢查 b)程序結構分析 c)程序復雜度分析 d)內存泄漏
2.5 技術評審的目的是:D
a)保證軟件在獨立的模式下進行開發
b)發現軟件業務錯誤
c)與項目管理無關
d)確認軟件符合預先定義的開發規范和標准
第四章：測試設計技術（30%）
1、學習目標
1.1 測試開發過程（K3）
① 區別：測試設計規格說明(test design specification)、測試用例規格說明(test case specification)和測試規程規格說明(test procedure specification) （K2）。
② 比較術語：測試條件、測試用例和測試規程(test procedure)（K2）。
③ 評估測試用例的質量（K3），它們是否滿足：
●顯示明確的與需求的可追溯性(traceability)；
●包含預期的結果。
④ 根據測試人員的理解水平，將測試用例轉換為不同詳細程度的結構合理的測試規 程規格說明（K3）。
1.2 測試設計技術的種類（K2）
① 復述在測試用例設計中，為什么需要采用基於規格說明的測試（黒盒測試）和基 於結構的測試（白盒測試）的方法？列舉出各自比較常用的技術（K1）。
●黑盒測試，顧名思義，不需要使用任何關於被測組件或系統的內部結構信息。
●白盒測試設計技術（也稱為結構化或基於結構的測試技術）是基於分析被測組件或系統的結構的測試技術。
② 解釋基於規格說明的測試、基於結構的測試和基於經驗的測試三者的特征和區別 （K2）。
●基於規格說明的測試技術具有以下共同特點：
- 使用正式或非正式的模型來描述需要解決的問題、軟件或其組件等；
- 根據這些模型，可以系統地導出測試用例。
●基於結構的技術的共同特點：
- 根據軟件的結構信息設計測試用例，比如軟件代碼和詳細設計信息；
- 可以通過已有的測試用例測量軟件的測試覆蓋率，並通過系統化的導出設計用例來提高覆蓋率。
●基於經驗的方法具有以下共同特點：
- 測試用例根據參與人員的經驗和知識來編寫；
- 測試人員、開發人員、用戶和其他的利益相關者對軟件、軟件使用和環境等方面所掌握的知識作為信息來源之一；
- 對可能存在的缺陷及其分布情況的了解作為另一個信息來源。
1.3 基於規格說明的或黒盒測試技術（K3）
① 使用下列測試設計技術，對指定的軟件模塊編寫測試用例：（K3）
●等價類划分(equivalence partitioning)；
●邊界值分析(boundary value analysis)；
●決策表測試(decision table testing)；
●狀態轉換測試(state transition testingm)；
② 理解這四種測試設計技術各自的主要目的，這些技術可以應用於什么測試級別和 測試類型，以及如何測量測試覆蓋(test coverage)（K2）。
③ 理解用例測試（use case testing）的概念和應用這種技術的優點（K2）。
●每個用例都有測試的前置條件，這是用例成功執行的必要條件
●每個用例結束后都存在后置條件，這是在用例執行完成后能觀察到的結果和系統的結束狀態。
●用例通常有一個主場景（即最有可能發生的場景）和可選場景。
1.4 基於結構的技術或白盒技術（K3）
① 描述代碼覆蓋(code coverage)的概念及其重要性（K2）。
② 解釋語句覆蓋(statement coverage）和判定覆蓋(decision coverage)等概念， 理解這些概念除了可以應用在組件測試(component testing)外，還可以應用在其 他任何測試級別上（比如系統級別上的業務過程測試）（K2）。
●判定覆蓋，和分支測試相關，是指評價在一個測試用例套中已經執行的判定（例如if語句的true和false選項）輸出的百分比。
③ 根據給定的控制流，使用下面的測試設計技術設計測試用例（K3）：
●語句測試；
●判定測試；
④ 評估語句覆蓋和判定覆蓋的完整性（K3）。
●覆蓋的概念也可以用於其他的測試級別（比如集成測試級別等），在一個測試用例套件中被執行的模塊、組件或類覆蓋的百分比可以分別稱為模塊覆蓋、組件覆蓋或類的覆蓋。
1.5 基於經驗的技術（K2）
① 復述在哪些情況下使用基於直覺、基於經驗和知識、基於對常見缺陷的認識來編 寫測試用例（K1）。
●錯誤推測法
●探索性測試
② 比較基於經驗的方法和基於規格說明的方法之間的區別（K2）。
1.6 選擇測試技術（K2）
① 針對不同類型的問題選擇不同的測試用例設計技術，列舉出會影響設計技術選擇 的因素，比如系統的類型、風險、客戶
2、練習題
2.1 關於邊界值的說法不正確的是： D
a)邊界值分析是一種補充等價划分的測試用例技術
b)它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例
c)程序在處理大量中間數值時都是對的，但是在邊界處極可能出現錯誤
d)邊界值分析法考慮了輸入變量之間的依賴關系
2.2 對於測試錯誤的說法是:B
a)測試的設計可以用80-20規則作為指導。
b)測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比
c)應該在測試工作真正開始前的較長時間內進行測試計划
d)測試的效果由測試用例的多少及規定的覆蓋指標確定
2.3 根據測試章程中包含的測試目標，同時進行測試設計、測試執行的是： A
a)探索性測試 b)錯誤推測 c)白盒測試 d)黑盒測試
2.4 下面哪個屬於靜態分析：D
A.編碼規則的檢查
B.程序結構分析
C.程序復雜度分析
D.內存泄漏
a)除C以外 b)除A和C以外 c)除C和D以外 d)除D以外
2.5 如果程序的功能說明中含有輸入條件的組合情況，則一開始就可以選用__B__和判定表法。
a)等價類划分法 b)因果圖法 c)正交試驗法 d)場景法
2.6 通常情況下基本功能測試和性能測試的執行順序是：C
a)基本功能的測試和性能測試同時進行
b)先執行性能測試，然后再進行基本功能的測試
c)先進行基本功能的測試，然后再執行性能測試
d)基本功能測試和性能測試哪個先執行都無所謂
2.7 如果一個4變量函數，使除一個以外的所有變量取正常值，使剩余變量取最小值、略高於最小值、正常值、略低於最大值和最大值，對每個變量都重復進行。這樣，對於一個4變量函數，邊界值分析產生的測試用例數為：B
a)15 b)17 c)18 d)20
2.8 一個參數的取值范圍是正整數，那么這個參數的有效邊界值的數目是： A
a)一個 b)二個 c)三個 d)四個
2.9 某個程序有三個輸入參數A,B和C，輸入參數的有效條件是A<B 和 C>B，如果應用等價類划分的技術，可以生成的等價類有：
A、A>=B,C>=B B、A<B,C<=B
C、A<=B,C>B D、A<B,C>B
a)A,C b)A,B,C c)C,D d)A,B,C,D
2.10 判定覆蓋和語句覆蓋之間的比較：A
a)100％的判定覆蓋可以保證100％的語句覆蓋，反之則不行
b)100％的語句覆蓋可以保證100％的判定覆蓋，反之則不行
c)100％的語句覆蓋可以保證100％的判定覆蓋，反之亦然
d)100％的語句覆蓋和100％的判定覆蓋之間沒有直接的聯系
2.11 在規格說明不完全的情況，最適合采用的測試技術是：B
a)基於結構的測試技術(白盒測試)
b)基於經驗的測試技術
c)基於規格說明的測試技術
d)以上都適合
2.12 什么是等價類划分C
A.將測試對象的輸入或輸出域划分成若干部分
B.從每一個子集中選取少數具有代表性的數據
C.是一種白盒測試方法
D.有效值的等價類
E.無效值的等價類
a)A,B,C,D b)A,B,C c)A,B,D,E d)D,E
2.13 描述黑盒測試和白盒測試過程的不同：A
A.黑盒測試在測試對象的表面進行
B.白盒測試是在源代碼已知的情況下進行
C.黑盒測試用例是通過測試對象的使用說明或需求設計
D.黑盒測試包括語句覆蓋和分支覆蓋方法
E.白盒測試是通過因果圖的分析方法進行的
a)A,B,C b)A,C c)A,B,C,D,E d)D,E
2.14 狀態轉換測試用例設計的完全定義內容：C
A.測試對象的初始化狀態
B.測試對象的輸入
C.預期結果或預期的行為
D.預期的最終狀態
a)A,B,C b)A,C c)A,B,C,D d)C,D
2.15 根據黑盒測試方法可以設計變量0 <= X <= 100的測試用例：C
a)0,20,100 b)20,50,100 c)-1,0,1,50,99,100,101 d)-100,30,100,200
2.16 根據以下流程圖設計語句覆蓋的測試用例：D
a)測試用例a=5，c=7；a=10，c=12
b)測試用例a=11，c=6；a=0，c=2
c)測試用例a=9，c=11；a=15, c=11
d)測試用例a=5，c=7；a=11，c=6
2.17 請根據條件（x>3，y<5）設計條件組合覆蓋測試用例：A
A.x=6，y=3
B.x=6，y=8
C.x=2，y=3
D.x=2，y=8
a)A,B,C,D b)A,B,C c)A,B,D d)C,D
2.18 黑盒測試技術包括C
a)邊界值分析、判定表、等價類划分、經驗法
b)判定覆蓋、語句覆蓋、用例分析
c)邊界值分析、等價類划分、因果圖分析、隨機法
d)判定表技術、路徑覆蓋、條件覆蓋
2.19 語句覆蓋和判定覆蓋有什么不同 D
A.語句覆蓋程序中每一個判斷至少要執行一次
B.判定覆蓋程序中每個判斷的取真分支和取假分支至少經歷一次。
C.判定覆蓋程序中各種組合至少執行一次
D.語句覆蓋是指程序中每一條語句至少被執行一次
a)A,C b)A,B c)C,D d)B,D
第五章：測試管理（20%）
1、學習目標
1.1 測試的組織結構（K2）
① 認識獨立測試的重要性（K1）。
●通過獨立的測試員進行測試和評審，發現缺陷的效率會提高。
② 列出在組織內進行獨立測試的優點和缺點（K2）。
獨立測試的優點：
●獨立的測試員是公正的，可以發現一些其他不同的缺陷。；
●一個獨立的測試員可以驗證在系統規格說明和實現階段所做的一些假設。
獨立測試的缺點：
●與開發小組脫離（如果完全獨立）；
●開發人員可能喪失對軟件質量的責任感；
●獨立的測試員可能被視為瓶頸或者成為延時發布而被責備的對象。
③ 考慮使用不同團隊的成員來成立測試小組（K1）。
④ 了解測試領導人(test leader)和測試員的任務（K1）。
1.2 測試計划和估算（K2）
① 認識測試計划的不同級別和目標（K1）。
② 根據“軟件測試文檔標准（IEEE 829）” 總結《測試計划》、《測試設計規格說明》 和《測試規程》的目的及內容（K2）。
③ 區分屬於二類不同概念（預防型Preventative 和應對型Reactive）的各種測試 方法，如基於分析、基於模型、基於方法、符合過程/標准的、動態/啟發式的、 咨詢式或基於面向可重用的方法（K2）。
入口准則主要包含：●測試環境已經准備就緒並可用；●測試工具在測試環境中已經准備就緒；●可測的代碼可用；●測試數據可用。
出口准則主要包含：●完整性測量，比如代碼、功能或風險的覆蓋率；●對缺陷密度或可靠性度量的估算；●成本；● 遺留風險，例如沒有被修改的缺陷或在某些部分測試覆蓋不足；●進度表，例如基於交付到市場的時間。
④ 區分為系統而做測試計划和為安排測試執行做測試計划的內容上的不同之處 （K2）。
⑤ 在綜合考慮優先級、技術和邏輯依賴后，為給定的測試用例集編寫測試執行計划 （K3）。
⑥ 列出在測試計划時應該考慮的測試准備和執行活動（K1）。
⑦ 認識影響測試開銷的主要因素（K1）。
⑧ 從概念上區別兩種不同的估算方法：基於度量的方法和基於專家的方法（K2）。
⑨ 理解/解釋針對特定測試級別和測試用例組所定義的恰當的出口准則（例如對於集 成測試、驗收測試或可用性測試的測試用例）（K2）。
1.3 測試進度監控（K2）
① 認識用於監督測試准備和執行的常見度量項（K1）。
常用的測試度量項有：
●測試用例准備工作完成的百分比（或按計划已編寫的測試用例的百分比）；
●測試環境准備工作完成的百分比；
●測試用例執行情況（例如：執行/沒有執行的測試用例數，通過/失敗的測試用例數）；
●缺陷信息（例如：缺陷密度、發現並修改的缺陷、失效率、重新測試的結果）；
●需求、風險或代碼的測試覆蓋率；
●測試員對產品的主觀信心；
●測試里程碑的日期；
●測試成本，包括尋找下一個缺陷或執行下一輪測試所需成本與收益的比較。
② 理解和解釋針對測試報告和測試控制的測試度量（例如已發現和已修復的缺陷、已通過或失敗的測試）（K2）。
③ 根據“軟件測試文檔標准（IEEE 829）”總結測試報告的目的和內容（K2）。
1.4 配置管理（K2）
① 總結配置管理如何支持測試（K2）。
●配置管理可以幫助他們唯一地標識（並且復制）測試項、測試文檔、測試用例和測試用具。
1.5 風險和測試（K2）
① 將可能會威脅一個或多個利益相關者實現項目目標的可能問題描述為風險（K2）。
② 知道風險是由可能性（發生的可能性）和影響力（發生后所造成的危害）來決定 的（K1）。
③ 區別項目風險和產品風險（K2）。
●項目風險是圍繞項目按目標交付的能力的一系列風險。在軟件或系統中的潛在失效部分（即將來可能發生不利事件或危險）稱之為產品風險
④ 了解典型的產品風險和項目風險（K1）。
⑤ 通過例子來描述在測試計划中如何進行風險分析和風險管理（K2）。
1.6 事件管理（K3）
① 按照“軟件測試文檔標准（IEEE 829）”認識事件報告的內容（K1）。
② 針對測試過程中發現的失效編寫事件報告（K3）。
事件報告的主要目標如下：
●為開發人員和其他人員提供問題反饋，在需要的時候可以進行識別、隔離和糾正；
●為測試組長提供一種有效跟蹤被測系統質量和測試進度的方法；
●為測試過程改進提供資料。
事件報告的具體內容主要包括：
●提交事件的時間，提交的組織和作者；
●預期和實際的結果；
●識別測試項（配置項）和環境；
●發現事件時軟件或系統所處的生命周期階段；
●為了能確保重現和解決事件需要描述事件（包括日志、數據庫備份或截屏）；
●對利益相關者的影響范圍和程度；
●對系統影響的嚴重程度；
●修復的緊迫性/優先級；
●事件狀態（例如：打開的、延期的、重復的、待修復的、修復后待重測的或關閉的等）；
●結論、建議和批准；
●全局的影響，比如事件引起的變更可能會對系統的其他部分產生影響；
●變更歷史記錄，比如針對事件的隔離、修改和已修改的確認，項目組成員所采取的行動順序；
●參考，包括發現問題所用的測試用例規格說明的標識號。
2、練習題
2.1 測試計划主要由哪個角色負責制定：D
a)測試人員 b)項目經理 c)開發人員 d)測試經理
2.2 對於監控測試周期時采用的度量方法，下列敘述中不當的是： c
a)基於故障和基於失效的度量：統計特定軟件版本中的故障數。
b)基於測試用例的度量：統計各優先級的測試用例數量。
c)基於測試對象的度量：統計代碼和安裝平台等覆蓋情況。
d)基於成本的度量：統計已經花費的測試成本，下一測試周期的成本與預期收益的關系。
2.3 通常情況下，承擔測試監控任務的人員是： A
a)測試系統管理員 b)測試經理 c)測試執行人員 d)測試設計人員
2.4 下列哪個是測試組獨立的缺點？c
a)測試人員需要額外的培訓
b)測試人員需要花時間了解所要測試的產品的需要、架構、代碼等
c)開發人員可能會失去對產品質量的責任心
d)設立獨立測試組會花費更多成本
2.5 如果沒有做好配置管理工作，那么可能會導致：d
a)開發人員相互篡改各自編寫的代碼
b)集成工作難以開展
c)問題分析和故障修正工作被復雜化
d)測試評估工作受阻
2.6 對於測試過程來說，哪些工作產品要納入配置管理？A
a)測試對象（The test object）、測試材料（the test material）和測試環境
b)問題報告和測試材料
c)測試對象
d)測試對象和測試材料
2.7 下面有關基於風險的方法的描述哪個是不正確的？C
a)識別的風險經常用於決定哪些需要更多測試，哪些可以減少測試
b)識別的風險經常用於決定多少測試服務
c)識別的風險經常用於決定使用何種測試工具
d)識別的風險經常用於決定使用何種測試技術
2.8 下列活動中，不屬於測試計划活動的是：A
a)設計測試用例 b)確定測試環境 c)定義測試級別 d)估算測試成本
2.9 事件報告中可能包括的錯誤有：D
A.程序錯誤
B.規格說明中的錯誤
C.用戶手冊中的錯誤
a)A b)A、C c)B、C d)A、B、C
2.10 下列風險中，屬於產品風險的是：B
a)軟件需求不明確
b)由於使用軟件產品而導致人員傷亡
c)軟件測試人員和軟件開發人員溝通不暢
d)軟件源代碼質量低下
2.11 軟件測試團隊的組織一般可分為：___A___和基於項目的組織模式。
a)基於測試的組織模式；
b)基於技能的組織模式；
c)基於團隊的組織模式；
d)基於軟件的組織模式。
2.12 測試報告不包含的內容有：D
a)測試時間、人員、產品、版本；
b)測試環境配置；
c)測試結果統計；
d)測試通過/失敗的標准。
2.13 測試人員（Tester）在軟件配置管理中工作主要是：A
a)根據配置管理計划和相關規定，提交測試配置項和測試基線；
b)建立配置管理系統；
c)提供測試的配置審計報告；
d)建立基線。
2.14 測試經理的任務通常不包括： C
a)編寫測試計划
b)選擇合適的測試策略和方法
c)建立和維護測試環境
d)選擇和引入合適的測試工具
第六章：軟件測試工具（10%）
1、學習目標
1.1 測試工具的類型（K2）
① 根據測試過程活動，對不同類型的測試工具進行分類（K2）。
② 了解能夠幫助開發者進行測試的工具（K1）。
1.2 有效使用工具：潛在的利益和風險（K2）
① 總結測試自動化和使用測試工具的潛在利益和風險（K2）。
使用工具的潛在收益包括：
●減少重復性的工作；
●更好的一致性和可重復性；
●客觀的評；
●容易得到測試和測試的相關信息。
使用工具存在的風險：
●對工具抱有不切實際的期望（包括功能性和易用性）；
●低估首次引入工具所需的時間、成本和工作量；
●低估從工具中獲得較大和持續性收益需要付出的時間和工作量；
●低估了對工具生成的結果進行維護所需的工作量；
●對工具過分依賴；●忽視了在工具中對測試對象的版本控制；
●忽視了多個重要工具之間的關聯和互操作性；
●工具供應商破產、 停止維護工具或將工具賣給其他供應商的風險；
●供應商對工具的支持、 升級和缺陷修復反應不力；
●開源/免費工具項目中止的風險；
●其他不可預知的風險，例如不能支持新平台。
② 了解測試執行工具可以有包括數據驅動和關鍵字驅動的不同腳本技術（K1）。
●數據驅動的方法是將測試輸入（數據） 與測試用例分離，並將測試輸入存放在一個電子表格中，這樣可以使用不同的數據進行相同的測試。
1.3 組織中工具的引入（K1）
① 闡述將工具引入組織中的主要步驟（K1）。
② 闡述為評估工具所進行的學習調查/試點項目階段的目的（K1）。
●對工具有更多的認識；
●評估工具與現有的過程以及實踐的配合程度，確定哪些方面需要作修改；
●定義一套標准的方法來使用、管理、儲存 和維護工具及測試資產；
●評估在付出合理的成本后能否得到預期的收益。
③ 了解要獲得好的工具支持，僅靠購置工具是不夠的，還需要考慮其他因素（K1）
●逐步在組織的其余部分將工具推廣到測試中；
●調整並改進過程來配合工具的使用；
●為新使用者提供培訓和指導；
●定義使用指南；
●實施一種在實際運用中收集工具使用情況的方法；
●監控工具的使用和收益情況；
●為測試團隊使用工具提供支持；
●在所有團隊內收集經驗和教訓。
2、練習題
2.1 測試管理工具可能包括的功能：D
A.管理軟件需求 B.管理測試計划 C.缺陷跟蹤 D.測試過程中各類數據的統計和匯總
2.2 下列關於自動化測試工具的說法中，錯誤的是 D
a)錄制/回放可能是不足夠的，還需要進行腳本編程
b)既可用於功能測試，也可用於非功能測試
c)自動化測試工具適用於回歸測試
d)自動化測試關鍵的時候能代替手工測試
2.3 測試用具（test harness）主要可用於D
a)組件測試、集成測試
b)集成測試、系統測試
c)組件測試、部分系統測試
d)組件測試、集成測試、部分系統測試
2.4 下列關於工具使用風險的說法中，不恰當的是：A
a)工具能夠或多或少提高測試效率
b)沒有好的測試過程或成熟的測試方法，工具並不能像預期的那樣降低成本
c)與手工測試相比較，使用自動化工具也可能會增加測試成本
d)培訓和指導有助於降低工具使用的風險
2.5 在下列測試類型中，不適合采用手工測試的是b
a)安全測試 b)負載測試 c)集成測試 d)再測試