1. 試述軟件的概念和特點？軟件復用的含義？構件包括哪些？
2. 瀑布模型和螺旋模型的主要區別是什么？
3. 軟件生存周期及其模型是什么？
4. 什么是軟件測試？軟件測試的目的與原則
5. 凈室軟件工程的策略是什么？
6. 軟件配置管理的作用？軟件配置包括什么？
7. 什么是軟件質量？軟件包是什么？
8. 目前主要的測試用例設計方法是什么？
9. 軟件的安全性應從哪幾個方面去測試？
參考答案：
1. 答案如下：
1. 軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序、文檔的完整集合。
2. 軟件復用(Software Reuse)是將已有軟件的各種有關知識用於建立新的軟件,以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和質量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
3. 可以被復用的軟件成分一般稱作可復用構件
2. 答案如下：
1. 參照TP書上第六章45/46頁的講解，參考一下書上的說法進行對比即可。考慮彈性、風險、成本，等幾個方面。
3. 答案如下：
1. 軟件生存周期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發布維護的過程。
2. 在經歷需求、分析、設計、實現、部署后，軟件將被使用並進入維護階段，直到最后由於缺少維護費用而逐漸消亡。這樣的一個過程，稱為“生命周期模型“（Life Cycle Model）。
4. 答案如下：
1. 使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
2. 軟件測試的目的：
1. 測試是程序的執行過程，目的在於發現錯誤
2. 一個成功的測試用例在於發現至今未發現的錯誤
3. 一個成功的測試是發現了至今未發現的錯誤的測試
4. 確保產品完成了它所承諾或公布的功能，並且用戶可以訪問到的功能都有明確的書面說明。
5. 確保產品滿足性能和效率的要求
6. 確保產品是健壯的和適應用戶環境的
3. 軟件測試的原則：
教材的說法：
1. 軟件測試應盡早執行，並貫穿於整個軟件生命周期
2. 軟件測試應追溯需求
3. 測試應由第三方來構造
4. 窮舉測試是不可能的,要遵循Good-enough原則
5. 必須確定預期輸出（或結果）
6. 必須徹底檢查每個測試結果
7. 充分注意測試中的群集現象
8. 缺陷的二八定理
9. 嚴格執行測試計划，排除測試的隨意性
10. 注意合法合理的輸入，也要注意非法的非預期的輸入
11. 檢查程序是否是否做了不該做的
12. 測試應從”小規模”開始，逐步轉向”大規模”
13. 反復使用同樣的測試會使軟件具有抵抗力
14. 關注缺陷的修復
另一種說法：
15. 應當把”盡早和不斷地測試”作為開發者的座右銘。
16. 程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。
17. 設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態和意外狀態，比如網絡異常中斷、電源斷電等情況。
18. 一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關系。
19. 對測試錯誤結果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
20. 制定嚴格的測試計划，並把測試時間安排得盡量寬松，不要希望在極短的時間內完成一個高水平的測試。
21. 回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象並不少見。
22. 妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
5. 答案如下：
1. 增量計划。開發一個采用增量策略的項目計划，建立每個增量的功能、它的項目大小、以及凈室開發進度表。必須特別小心以保證通過認證的增量將被定時集成。
2. 需求收集。使用類似於在第11 章引入的技術，為每個增量開發一個客戶級需求的更詳細的描述。
3. 盒結構規約。使用一個運用盒結構的規約方法［HEV93］來描述功能規約。遵從操作分析原則，盒結構”在每一個精化級別上分離和分開行為、數據及過程的創造性定義”。
4. 形式化設計。使用盒結構方法，凈室設計是規約的自然的無縫的擴展。雖然，在兩個活動間可進行清楚的區分，但是，規約(稱為”黑盒”)是被遞進地求精(在一個增量內)以成為類似於體系結構的和過程的設計(分別稱為”狀態盒”和”清晰盒”)。
5. 正確性驗證。凈室小組對設計及代碼進行一系列嚴格的正確性驗證活動。驗證從最高層次的盒結構(規約)開始，然后移向設計細節和代碼。正確性驗證的第一層次通過應用一組”正確性問題”［LIN88］來進行，如果這沒有證明規約是正確的，則使用更形式化的(數過學的)驗證方法。
6. 代碼生成、檢查和驗證。以某種專門語言表示的盒結構規約被轉換為合適的程序設計語言。然后，使用標准的走查或檢查技術(第8 章)來保證代碼和盒結構的語義相符性，以及代碼的語法正確性。然后，對源代碼進行正確性驗證。
7. 統計性測試計划。分析軟件的項目級使用情況，計划和設計一組執行用途的”概率分布”的測試用例(25.4 節)。如圖25－1 所示，這個凈室活動是和規約、驗證及代碼生成並行進行的。
8. 統計性使用測試。記住，對計算機軟件進行徹底測試是不可能的，因此，總需要設計有限數量的測試用例。統計性使用技術［POO88］執行一系列由特定對象的所有用戶的所有可能的程序執行的統計樣本(上面提到的概率分布)所導出的測試。認證。一旦完成驗證、檢查和使用測試(並且所有錯誤被修正)，則開始進行增量集成前的認證工作。
6. 答案如下：
1. 軟件配置管理作為軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命周期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持作用。一個軟件開發組織真正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具有可重復性，大大提高軟件組織的競爭力。
2. 軟件配置包括如下內容：
1. 配置項識別
2. 工作空間管理
3. 版本控制
4. 變更控制
5. 狀態報告
6. 配置審計
7. 答案如下：
1. 簡單的說：軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。
比較長的說法：
現代質量管理認為，質量是客戶要求或者期望的有關產品或者服務的一組特性，落實到軟件上，這些特性可以是軟件的功能、性能和安全性等等。這些特性決定了軟件產品保證客戶滿意的能力，並且，這些特性應該是可以度量的。
我們還可以從另一個角度，即軟件產品是如何生產出來的，來間接的推斷軟件質量。我們稱之為軟件的流程質量，以有別於前面所說的軟件產品質量。所謂流程，我們可以將其理解為一個活動序列和與此相關的輸入、輸出、約束條件、實現方法、輔助工具等等因素共同組成的系統。ISO9001 和SW-CMM 都主要是從流程角度來探討軟件質量和質量改進的。
當然，我們還能從其它角度，比如軟件的生產者-人的素質，來詮釋軟件質量，但不管怎樣，軟件的產品質量是最終的檢驗標准，而最終的檢驗者就是客戶。從這個意義上說，軟件質量就是客戶滿意度。
2. 軟件包(Software Package)是指具有特定的功能，用來完成特定任務的一個程序或一組程序。可分為應用軟件包和系統軟件包兩大類。應用軟件包與特定的應用領域有關，又可分為通用包及專用包兩類。通用軟件包根據社會的一些共同需求開發，專用軟件包則是生產者根據用戶的具體需求定制的，可以為適合其特殊需要進行修改或變更。
8. 答案如下：
1. 白盒測試：
1. 邏輯覆蓋
2. 循環覆蓋
3. 基本路徑覆蓋
2. 黑盒測試：
1. 邊界值分析法
2. 等價類划分
3. 錯誤猜測法
4. 因果圖法
5. 狀態圖法
6. 測試大綱法
7. 隨機測試
8. 場景法
9. 答案如下：
軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。
1. 用戶認證安全的測試要考慮問題：
1. 明確區分系統中不同用戶權限
2. 系統中會不會出現用戶沖突
3. 系統會不會因用戶的權限的改變造成混亂
4. 用戶登陸密碼是否是可見、可復制
5. 是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）
6. 用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統
2. 系統網絡安全的測試要考慮問題
1. 測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上
2. 模擬非授權攻擊，看防護系統是否堅固
3. 采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
4. 采用各種木馬檢查工具檢查系統木馬情況
5. 采用各種防外掛工具檢查系統各組程序的外掛漏洞
3. 數據庫安全考慮問題：
1. 系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）
2. 系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對於這個系統的功能實現有了障礙）
3. 系統數據可管理性
4. 系統數據的獨立性
5. 系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）
1. 什么是測試用例 什么是測試腳本 兩者的關系是什么？
2. 簡述什么是靜態測試、動態測試、黑盒測試、白盒測試、α測試
β測試
3. 軟件質量保證體系是什么 國家標准中與質量保證管理相關的幾個標准是什么?他們的編號和全稱是什么?
4. 軟件產品質量特性是什么?
5. 軟件測試的原則與策略是什么?
6. 結構化系統測試和功能性系統測試分別采用了哪些方法和技術?
7. 軟件測試分為幾個階段 各階段的測試策略和要求是什么?
8. 面向對象的測試用例設計有幾種方法？如何實現?
9. 在軟件測試各個階段通常完成什么工作？各個階段的結果文件是什么？包括什么內容？
參考答案：
1. 答案如下：
1. 為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。
2. 測試腳本是為了進行自動化測試而編寫的腳本。
3. 測試腳本的編寫必須對應相應的測試用例，
2. 答案如下：
1. 靜態測試是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
2. 動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，並分析系統運行效率和健壯性等性能。
3. 黑盒測試一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性。
4. 白盒測試根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。
5. α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成。
6. β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。
3. 答案如下：
1. 來自Wikipedia對SQA的定義，軟件質量保證（SQA）：
Software Quality Assurance (SQA) consists of the software engineering processes and methods used to ensure quality. SQA encompasses the entire software development process, which may include processes such as reviewing requirements documents, source code control, code reviews, change management, configuration management, release management and of course, software testing.
SQA由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。
1. 國家標准：
1. GB/T 8567-2006 計算機軟件文檔編制規范
2. GB/T 11457-2006 信息技術 軟件工程術語
3. GB/T 16260.1-2006 軟件工程 產品質量 第1部分：質量模型
4. GB/T 16260.2-2006 軟件工程 產品質量 第2部分：外部度量
5. GB/T 16260.3-2006 軟件工程 產品質量 第3部分：內部度量
6. GB/T 16260.4-2006 軟件工程 產品質量 第4部分：使用質量的度量
7. GB/Z 20156-2006 軟件工程 軟件生成周期過程 用於項目管理的指南
8. GB/T 20157-2006 信息技術 軟件維護
9. GB/T 20158-2006 信息技術 軟件生成周期過程 配置管理
1. 答案如下：
1. 功能性：適應性、准確性、互操作性、依從性、安全性。
2. 可靠性：成熟性、容錯性、以恢復性。
3. 可使用性：易理解性、易學習性、易操作性。
4. 效率：時間特性、資源特性。
5. 可維護性：易分析性、易變更性、穩定性、易測試性。
6. 可移植性： 適應性、易安裝性、遵循性、易替換性。
2. 答案如下：
1. 軟件測試的原則：
教材的說法：
1. 軟件測試應盡早執行，並貫穿於整個軟件生命周期
2. 軟件測試應追溯需求
3. 測試應由第三方來構造
4. 窮舉測試是不可能的,要遵循Good-enough原則
5. 必須確定預期輸出（或結果）
6. 必須徹底檢查每個測試結果
7. 充分注意測試中的群集現象
8. 缺陷的二八定理
9. 嚴格執行測試計划，排除測試的隨意性
10. 注意合法合理的輸入，也要注意非法的非預期的輸入
11. 檢查程序是否是否做了不該做的
12. 測試應從”小規模”開始，逐步轉向”大規模”
13. 反復使用同樣的測試會使軟件具有抵抗力
14. 關注缺陷的修復
另一種說法：
1. 應當把”盡早和不斷地測試”作為開發者的座右銘。
2. 程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。
3. 設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態和意外狀態，比如網絡異常中斷、電源斷電等情況。
4. 一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關系。
5. 對測試錯誤結果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6. 制定嚴格的測試計划，並把測試時間安排得盡量寬松，不要希望在極短的時間內完成一個高水平的測試。
7. 回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象並不少見。
8. 妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
1. 軟件測試策略：在一定的軟件測試標准、測試規范的指導下，依據測試項目的特定環境約束而規定的軟件測試的原則、方式、方法的集合。
1. 答案如下：
1. 結構化系統測試技術：用於驗證所開發的系統及程序的運行情況。目標是要確保產品設計在結構上合理，功能上正確。為確定實現的配置及其各功能共同作用以完成特定任務提供了一種機制。結構化測試技術由以下幾種：
1. 1）壓力測試：確定系統以期望的容量執行。
壓力測試技術用於檢查系統面對意外情況下的大數據量時是否可以正常運行。所涉及的方面包括輸入事務、內部表、磁盤空間、輸出、通信、計算機容量以及人機交互等。
當應用系統所能正常處理的工作量並不確定時需要使用壓力測試。壓力測試意圖通過對系統施加超負載事務量來達到破壞系統的目的。弱點在於准備測試的時間與在測試的實際執行過程中所消耗的資源數量都非常之大，通常在應用程序投入使用之前這種技術是無法進行的。
2. 執行測試：系統能達到期望的熟練性。
舉例：事務輪轉時間充分；軟硬件使用良好。
執行測試技術用於檢查系統是否達到了預期在產品狀態下的成熟度。執行測試可以驗證系統的響應時間、輪轉時間及設計性能。
在開發過程的早期就應該進行執行測試，盡早制定已經完成的系統沒有達到性能指標是非常有價值的。在關鍵時間點進行。關鍵時間點指的是當前的結果會影響甚至改變系統結構的時間點。
3. 恢復測試：系統失效之后可以恢復到可操作狀態。
舉例：引入失敗；評估備份數據的充分性。
恢復測試技術用於確保系統在經歷災難后可以繼續正常運行，它不僅可以驗證恢復過程，而且可以驗證過程各組件的有效性。
當用戶認為系統操作的連續性對於其所涉及領域的某些功能至關重要時，需要進行恢復測試。
4. 操作測試：系統以正常操作狀態執行。
舉例：確定系統可以依據文檔進行運行；JCL（工作控制語言）充分。
操作測試技術主要用於檢查系統在正常的操作狀態下是否可以執行。操作測試可以與其它測試聯合執行。
任何應用程序在成為產品之前都應進行操作測試。
5. （與過程的）一致性測試：系統的開發與標准和規程相一致。
舉例：按標准執行；文檔完整。
一致性測試技術用於驗證應用程序的開發是否與信息技術指標、過程及准則相一致。一致性測試最有效的方法是過程審查。
系統開發標准和過程的一致性程度依賴於管理層對於所需遵循的特定過程和執行標准的重視程度。
6. 安全性測試：根據組織的重要性對系統進行保護。
舉例：訪問拒絕；規程適當。
安全性測試技術用於評價保護性程序及安全對策的充分性。安全性缺陷不如其它類型的缺陷那么明顯。安全性測試是測試過程中高度專業化的部分。分物理安全性（針對利用物理方法收集信息的手段）和邏輯安全性（針對使用計算機處理和通信能力進行非法活動信息的手段）。
當系統保護信息和資產對於組織來說意義重大時，需要進行安全性測試。
2. 功能性系統測試用於確保系統需求與定義都得到了滿足。該過程通常包含創建用於評價應用程序正確性的測試條件。用於執行功能測試的幾種測試技術包括：
1. 需求測試：系統按制定方式執行。
舉例：證明系統需求；與政策、規則相一致。
需求測試技術驗證系統是否正確執行其功能，並且能保證在相當長的一段時間內保持其正確性。需求測試的執行主要通過執行創建的測試條件以及功能檢查單來完成，通過需求得到測試條件，然后以類似於SDLC這種特定的方式表現，生成用於評價實現的應用系統的測試數據。
任何應用程序都應該對需求進行測試，此過程應該開始於需求階段，並一直持續到系統運行和維護階段。
2. 回歸測試：驗證系統中沒有改變的部分仍能正確運行。
舉例：未變更的部分正常運行；未變更的人工規程正確。
回歸測試技術對已經測試過的部分進行重新測試，以保證它們在應用程序其它部分發生變更之后仍能正常運行。
當變更會對應用程序中沒有變更的部分產生高風險的影響時需要進行回歸測試。
3. 錯誤處理測試：錯誤可以得到防止或檢測，並被修復。
舉例：將錯誤引入測試；錯誤的再次注入。
人工系統與自動系統之間差別的特點之一就是預定義的錯誤處理特性。錯誤處理測試技術用於檢查應用系統正確處理發生異常的能力。錯誤處理測試需要一組知識豐富的人員來預見應用系統可能發生的錯誤。它是測試錯誤的引入、錯誤的處理，控制條件以及條件的再次正確輸入。
在系統整個生命周期中都應該進行錯誤測試。在開發過程中，應該識別錯誤帶來的問題並且采取相應的措施將錯誤減少到可以接受的程度。
4. 人工支持測試：人機交互有效。
舉例：具備人工規程；人員接受過培訓。
人工支持測試技術主要包括人員在准備數據以及使用來源於自動程序數據的過程中執行所有功能。
在生命周期的全過程都應該驗證人工系統功能的正確性。
5. 系統間測試：數據可以正確地在系統間傳遞。
舉例：系統間參數變化；系統間文檔更新。
系統間測試技術用於保證應用程序間相互管理的正確性。系統間測試的一個最好的工具是集成測試工具，它允許在產品環境下進行測試，可以以最小的代價測試系統間的耦合性。
在應用系統間的參數發生變更時需要進行系統間的測試。測試的程度和類型依賴於與出錯的參數相關聯的風險情況。
6. 控制測試：將系統風險控制降低到可以接受的級別。
舉例：文件一致性規程正常；人工控制正確。
控制測試技術包括數據確認、文件完整性控制、評審追蹤、備份和恢復、文檔，以及與系統完整性相關的其它方面。主要用於確保對系統特定功能的檢查。可以用於控制測試的一個方法是生成風險矩陣。
控制測試是系統測試中的一個完整的部分，占測試時間的很大比例。
7. 平行測試：發現原系統與新系統之間的意外差異。
舉例：原系統與新系統一致；原系統仍然可以工作。
平行測試技術用於檢查新應用程序的結果是否與原來的應用程序或者上一版本應用程序的處理相一致。它執行冗余處理以保證新版本或者新應用程序執行的正確性；給出同一應用程序不同版本之間一致的和不一致的地方。平行測試可以對整個應用程序進行，也可對應用程序的一部分進行。
當不能確定新應用程序處理的正確性，或者當新舊版本的應用程序非常類似時，需要進行平行測試。
2. 答案如下：
1. 軟件測試按階段划分可以分為單元測試、集成測試、系統測試和<驗收測試>（不一定有）幾個階段
2. 單元測試測試策略：
1. 自頂向下的單元測試策略
方法：先對最頂層的基本單元進行測試，把所有調用的單元做成樁模塊。然后再對第二層的基本單元進行測試，使用上面已測試的單元做驅動模塊。依此類推直到測試完所有基本單元。
優點：在集成測試前提供早期的集成途徑。在執行上和詳細設計的順序一致。不需要開發驅動模塊。
缺點：隨着測試的進行，測試過程越來越復雜，開發和維護成本增加。
總結：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
2. 自底向上的單元測試策略
方法：先對最底層的基本單元進行測試，模擬調用該單元的單元做驅動模塊。然后再對上面一層進行測試，用下面已被測試過的單元做樁模塊。依此類推，直到測試完所有單元。
優點：在集成測試前提供系統早期的集成途徑。不需要開發樁模塊。
缺點：隨着測試的進行，測試過程越來越復雜。
總結：比較合理的單元測試策略，但測試周期較長。
3. 孤立單元測試策略
方法：不考慮每個單元與其它單元之間的關系，為每個單元設計樁模塊或驅動模塊。每個模塊進行獨立的單元測試。
優點：簡單、容易操作，可達到高的結構覆蓋率。
缺點：不提供一種系統早期的集成途徑。
總結：最好的單元測試策略。
3. 集成測試的測試策略：
1. 大爆炸集成
優點：可以迅速完成集成測試；並且只要極少數的驅動和樁模塊；用例也是最少的；簡單；資源利用率高
缺點：一次試運行成功的可能性不大，問題定位和修改比較困難，許多接口錯誤很容易躲過測試。
適應於一個維護型項目或被測試系統較小
2. 自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
3. 自底向上集成
優點：對底層組件行為較早驗證；工作最初可以並行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
4. 三明治集成
優點：集合了自頂向下和自底向上兩種策略的優點
缺點：中間層測試不充分
適應於大部分軟件開發項目
5. 基干集成
優點：具有三明治集成的優點，更適合於大型復雜項目的集成。
缺點：必須對系統的結構和相互依存性進行仔細的分析；驅動和樁開發量大；局部采用了大爆炸的策略，有些接口可能測試不充分。
嵌入式系統中常用
6. 分層集成
適應於有明顯層次關系的系統
7. 基於功能的集成
優點：優先驗證關鍵功能的正確性；減少驅動的開發；進度要快。
缺點：對接口測試不充分；有較大的冗余測試。
8. 基於消息的集成
優點：優先驗證關鍵消息的正確性；減少驅動的開發；進度要快。
缺點：對接口測試不充分；有較大的冗余測試。
9. 基於風險的集成
優點：最具有風險的組件最早進地驗證，有助於系統的快速穩定。
缺點：需要對各組件的風險有一個清晰的分析。
10. 基於進度的集成
優點：具有較高的並行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。
4. 系統測試的測試策略：
1. 數據和數據庫完整性測試
2. 功能測試
3. 用戶界面測試
4. 性能評測
5. 負載測試
6. 強度測試
7. 容量測試
8. 安全性和訪問控制測試
9. 故障轉移和恢復測試
10. 配置測試
11. 安裝測試
12. 加密測試
13. 可用性測試
14. 版本驗證測試
15. 文檔測試
3. 答案如下：
1. Berard提出了一些測試用例的設計方法，主要原則包括:
1. 每個測試用例應當給予特殊的標識，並且還應當與測試的類有明確的聯系。
2. 測試目的應當明確。
3. 應當為每個測試用例開發一個測試步驟列表。這個列表應包含以下一些內容：
1. 列出所要測試對象的專門說明。
2. 列出將要作為測試結果運行的消息和操作。
3. 列出測試對象可能發生的例外情況。
4. 列出外部條件（即為了正確對軟件進行測試所必須有的外部環境的變化）。
5. 列出為了幫助理解和實現測試所需要的附加信息。
2. 主要方法：
1. 基於故障的測試
基於故障測試也可以用於組裝測試，組裝測試可以發現消息聯系中”可能的故障”。
“可能的故障”一般為意料之外的結果、錯誤地使用了操作/消息、不正確引用等。為了確定由操作（功能）引起的可能故障必須檢查操作的行為。
這種方法除用於操作測試外，還可用於屬性測試，用以確定其對於不同類型的對象行為是否賦予了正確的屬性值。因為一個對象的”屬性”是由其賦予屬性的值定義的。
2. 基於腳本的測試
基於腳本的測試主要關注用戶需要做什么，而不是產品能做什么，即從用戶任務（使用用例）中找出用戶要做什么及去執行。
這種基於腳本的測試有助於在一個單元測試情況下檢查多重系統。所以基於腳本測試用例測試比基於故障測試不僅更實際（接近用戶），而且更復雜一點。
3. OO類的隨機測試
如果一個類有多個操作（功能），這些操作（功能）序列有多種排列。而這種不變化的操作序列可隨機產生，用這種可隨機排列的序列來檢查不同類實例的生存史，就叫隨機測試。
4. 類層次的分割測試
這種測試可以減少用完全相同的方式檢查類測試用例的數目。這很像傳統軟件測試中的等價類划分測試。分割測試又可分三種。
1. 基於狀態的分割。按類操作是否改變類的狀態來分割（歸類）。
2. 基於屬性的分割。按類操作所用到的屬性來分割（歸類）。
3. 基於類型的分割。按完成的功能分割（歸類）。
5. 由行為模型（狀態、活動、順序和合作圖）導出的測試
狀態轉換圖（STD）可以用來幫助導出類的動態行為的測試序列，以及這些類與之合作的類的動態行為測試序列。
4. 答案如下：
1. 單元測試階段。各獨立單元模塊在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告，提交缺陷報告。
2. 集成測試階段。集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。
3. 系統測試階段。將通過確認測試的軟件，作為整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。
1.
判斷題
1.
軟件測試就是為了驗證軟件功能實現的是否正確，是否完成既定目標的活動，所以軟件測試在軟件工程的后期才開始具體的工作。
2.
發現錯誤多的模塊，可能殘留在模塊中的錯誤也多。
3.
測試人員在測試過程中發現一處問題，如果問題影響不大，而自己又可以修改，應立即將此問題正確修改，以加快、提高開發的進程。
4.
單元測試通常應該先進行”代碼走查”，再以白盒法為主，輔以黑盒法進行動態測試。
5.
功能測試是系統測試的主要內容，檢查系統的功能、性能是否與需求規格說明相同。
6.
軟件質量管理即QM由QA和QC構成，軟件測試屬於QC的核心工作內容。
7.
軟件測試只能發現錯誤，但不能保證測試后的軟件沒有錯誤。
8.
軟件就是程序。
9.
測試只要做到語句覆蓋和分支覆蓋，就可以發現程序中的所有錯誤。
10.
I18N測試是指對產品做出具有國際化，而L10N測試則是指對軟件做出符合本地化需求更改工作。
2.
選擇題
1.
進行軟件質量管理的重要性有：（）
A、維護降低成本 B、法律上的要求 C、市場競爭的需要
D、質量標准化的趨勢 E、軟件工程的需要 F、CMM過程的一部分
G、方便與客戶進一步溝通為后期的實施打好基礎
2.
以測試的形態分測試可以分為：（）
A、建構性測試 B、系統測試 C、專項測試
D、單元測試 E、組件測試 F、集成測試
3.
選出屬於黑盒測試方法的選項（）
A、測試用例覆蓋 B、輸入覆蓋 C、輸出覆蓋
D、分支覆蓋 E、語句覆蓋 F、條件覆蓋
4.
編寫測試計划的目的是：（）
A、使測試工作順利進行 B、使項目參與人員溝通更舒暢 C、使測試工作更加系統化
D、軟件工程以及軟件過程的需要 E、軟件過程規范化的要求 F、控制軟件質量
5.
依存關系有4種分別是：（）
A、開始－結束 B、開始－開始 C、結束－開始
D、結束－結束 E、開始－實施－結束 F、結束－審核－開始
6.
軟件質量管理（QM）應有質量保證（QA）和質量控制（QC）組成，下面的選項屬於QC的是：（）
A、測試 B、跟蹤 C、監督
D、制定計划 E、需求審查 F、程序代碼審查
7.
實施缺陷跟蹤的目的是：（）
A、軟件質量無法控制 B、問題無法量化 C、重復問題接連產生
D、解決問題的知識無法保留 E、確保缺陷得到解決
F、使問題形成完整的閉環處理
8.
使用軟件測試工具的目的：（）
A、幫助測試尋找問題 B、協助問題的診斷 C、節省測試時間
D、提高Bug的發現率 E、更好的控制缺陷提高軟件質量
F、更好的協助開發人員
9.
典型的瀑布模型的四個階段是：（）
A、分析 B、設計 C、編碼
D、測試 E、需求調研 F、實施
10.
PSP是指個人軟件過程 ，是一種可用於（）、（）和（）個人軟件工作方式的自我改善過程。
A、控制 B、管理 C、改進
D、高效 E、充分 F、適宜
3.
問答題
1.
測試人員在軟件開發過程中的任務是什么？
2.
在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
3.
黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！
四、 設計題
1.
如何測試一個紙杯？
2.
測試notepad的文件保存功能，就是file/save彈出對話框的功能，從那幾個方面寫測試用例。
參考答案：
1.
答案如下
1.
錯
2.
對
3.
錯
4.
對
5.
對
6.
對
7.
對
8.
錯
9.
錯
10.
對
2.
答案如下
1.
ABCDEFG
2.
ABC
3.
ABC
4.
ABC
5.
ABCD
6.
ABC
7.
ABCD
8.
ABC
9.
ABCD
10.
ABC
3.
答案如下
1.
1、尋找Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關注用戶的需求。
總的目標是：確保軟件的質量。
2.
一條Bug記錄最基本應包含：編號、Bug所屬模塊、Bug描述、Bug級別、發現日期、發現人、修改日期、修改人、修改方法、回歸結果等等；要有效的發現Bug需參考需求以及詳細設計等前期文檔設計出高效的測試用例，然后嚴格執行測試用例，對發現的問題要充分確認肯定，然后再向外發布如此才能提高提交Bug的質量。
3.
黑盒測試的優點有：
1.
比較簡單，不需要了解程序內部的代碼及實現；
2.
與軟件的內部實現無關；
3.
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
4.
基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
5.
在做軟件自動化測試時較為方便。
黑盒測試的缺點有：
1.
不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；
2.
自動化測試的復用性較低。
白盒測試的優點有：
1.
幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。
白盒測試的缺點有：
1.
程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
2.
測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
3.
系統龐大時，測試開銷會非常大。
4.
答案如下
1.
答案如下：
1.
功能度：用水杯裝水看漏不漏；水能不能被喝到
2.
安全性：杯子有沒有毒或細菌
3.
可靠性：杯子從不同高度落下的損壞程度
4.
可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用
5.
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
6.
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
7.
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
8.
疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
9.
壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透
2.
答案如下：
1.
對文件名長度進行上下邊界的測試
2.
對文件名進行等價類划分，測試文件名合法和非法的情況，測試文件名里包含有保留字的情況。
3.
測試文件保存的兩種類型。
4.
測試文件名和文件保存類型組合的情況。
5.
根據文件系統的軟件故障模型，設計測試用例。
6.
測試File菜單是否存在界面問題。(保存對話框調用的系統對話框，此處無需檢查)
7.
熱鍵和快捷鍵