填空題
- 邏輯驅動覆蓋測試是最傳統最經典的白盒測試技術。
- 軟件測試的目的是發現軟件錯誤，不是證明軟件正確。
- 白盒測試法是通過分析程序的內部邏輯來設計測試用例的。
- 黑盒測試法是根據程序的功能來設計測試用例的。
- 測試的關鍵問題是如何選擇測試用例。
- 軟件測試用例主要由輸入數據和預期輸出結果兩部分組成。
- 成功的測試是指運行測試用例後發現了程序錯誤，而不是證明了程序的正確或改正了程序的錯誤。
- 查錯能力最強的邏輯覆蓋標準是條件組合覆蓋，不是條件覆蓋。覆蓋準則最強的是路徑覆蓋。發現錯誤能力最弱的是語句覆蓋。實際的邏輯覆蓋測試中，一般以條件組合覆蓋爲主設計測試用例，然後再補充部分用例，以達到路徑覆蓋測試標準。
- 在黑盒測試中，着重檢查輸入條件組合的方法是因果圖法。
- 軟件測試過程中的集成測試主要是爲了發現概要設計階段的錯誤。
- 軟件測試過程中的系統測試主要是爲了發現需求分析階段的錯誤。
- 軟件測試過程中的單元測試主要是爲了發現詳細設計階段的錯誤。
- 集成測試時，能較早發現高層模塊接口錯誤的測試方法是自頂向下漸增式測試。
- 確認測試以需求規格說明書文檔作爲測試的基礎。
- 使用白盒測試方法時，確定測試數據應根據程序內部邏輯和指定的覆蓋標準。
- 軟件調試的目的是找出錯誤所在並改正。
- 超出軟件工程範圍的測試是系統測試。
- 軟件測試需要了解軟件設計的功能、內部結構和處理過程，不需要了解軟件設計的條件。
- 集成測試方法需要考察模塊間的接口和各模塊之間的聯繫。
- 調試應該由編制該源程序的程序員完成。
- 測試階段的基本任務是根據軟件開發各階段的文檔資料和程序的內部結構，精心設計一組測試用例，利用這些實例執行程序，找出軟件中潛在的各種錯誤和缺陷。
- 軟件測試方法一般分爲兩大類：動態測試方法和靜態測試方法。動態測試通過運行程序發現錯誤，根據測試用例的設計方法不同，動態測試又分爲黑盒測試和白盒測試兩類。靜態測試採用人工檢測和計算機輔助靜態分析的手段對程序進行檢測。
- 黑盒法只在軟件的接口處進行測試，依據需求規格說明書，檢查程序是否滿足功能要求。
- 白盒法必須考慮程序的內部結構和處理過程，以檢查處理過程的細節爲基礎，對程序中儘可能多的邏輯路徑進行測試。
- 白盒測試是透明盒測試、結構測試、邏輯驅動測試或基於程序的測試，被測對象是源程序，以程序的內部邏輯爲基礎設計測試用例。
- 黑盒測試是功能測試或基於規格說明的測試，用黑盒技術設計測試用例有四種方法：等價類劃分法、邊界值分析法、因果圖法、決策表法。
- 白盒測試進行的是單元測試和集成測試，黑盒測試進行的是集成測試和系統測試。
- 邏輯覆蓋是對程序內部有判定存在的邏輯結構設計測試用例，根據程序內部的邏輯覆蓋程度又可分爲：語句覆蓋、分支覆蓋（判定覆蓋）、路徑覆蓋、原子謂詞覆蓋（條件覆蓋）、分支謂詞覆蓋（判定條件覆蓋）、複合謂詞覆蓋（條件組合覆蓋）六種覆蓋技術。
- 等價類劃分從程序的功能說明，找出一個輸入條件，然後將每個輸入條件劃分成兩個或多個等價類。
- 邊界值分析是將測試邊界情況作爲重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。如果輸入域是一個有序集合，則應選取集合中的第一個元素和最後一個元素作爲測試用例。
- 在測試程序時，根據經驗或直覺推測程序中可能存在的各種錯誤，稱爲故障猜測法。
- 測試的綜合策略是在測試中，聯合使用各種測試方法。通常先用黑盒測試法設計基本的測試用例，再用白盒測試法補充一些必要的測試用例。
- 軟件測試一般經過四個測試：單元測試、集成測試、確認測試、系統測試。
- 單元測試是指對源程序中每一個程序單元進行測試，檢查各模塊是否正確實現規定的功能，從而發現模塊在編碼中或算法中的錯誤，它涉及編碼和詳細設計的文檔。
- 在單元測試中，需要爲被測模塊設計驅動模塊和樁模塊。驅動模塊用來模擬被測模塊的上級調用模塊，樁模塊用來代替被測模塊所調用的模塊。
- 集成測試是指在單元測試基礎上，將所有模塊按照設計要求組裝成一個完成的系統進行的測試。也稱組裝測試、聯合測試、子系統測試、部件測試。
- 集成測試的方法有兩種：非漸增式測試和漸增式測試。
- 自頂向下漸增式測試不需要編寫驅動模塊。只需要編寫樁模塊，其步驟是從模塊開始，沿着被測程序的頂層的控制路徑逐步向下測試，它有兩種組合策略：軟件結構圖和深度優先策略、寬度優先策略。
- 自底向上漸增式測試不需要編寫樁模塊，只需要編寫驅動模塊。
- 被測程序不在機器上運行，而是採用人工檢測和計算機輔助分析檢測的手段稱爲靜態測試。
- 用等價類劃分法設計一個測試用例時，使其覆蓋儘可能多的尚未被覆蓋的有效等價類，或使其覆蓋有且一個無效等價類。
- 軟件測試是爲了發現錯誤而執行程序的過程。
- 運行被測程序的方法稱爲動態測試。
- 動態測試中，主要測試軟件功能的方法稱爲黑盒測試法。
- 選擇測試用例，使得被測程序中每個判定的分支至少執行一次，這種邏輯覆蓋標準稱爲分支覆蓋。
- 用等價類劃分法設計測試用例時，如果被測程序的某個輸入條件規定了取值範圍，則可確定一個有效等價類和兩個無效等價類。
- 在所有的黑盒測試方法中，最嚴格的，最具有邏輯性的測試方法是決策表法。
- 對於一個 n 變量的程序，邊界值分析測試會產生 4n+1 個測試用例；健壯性邊界值測試將產生 6n+1 個測試用例。
- 等價類劃分法和邊界值分析法都是着重考慮輸入條件，如果程序輸入之間沒有什麼聯繫，採用等價類劃分和邊界值分析是一種比較有效的方法。如果輸入之間有關係，則應該採用因果圖法和決策表法。
- 軟件測試過程 V 模型非常明確地表明瞭測試的不同級別，清晰地展示了軟件測試與開發之間的關係。W 模型形象地說明了軟件測試與開發的並行關係，體現了測試貫穿於整個開發過程的思想。在 H 模型中，軟件測試的活動過程完全獨立，形成了一個完全獨立的流程，貫穿於整個產品的週期，與其他流程併發進行。X 模型提出針對單獨的程序片段進行相互分離的編碼和測試，通過頻繁的交接，最終集成爲可執行的程序。
- 白盒測試的策略有：桌前檢查、同行評審、代碼走查、靜態分析、單元測試。
- 白盒測試中邏輯驅動覆蓋測試的原子謂詞覆蓋準則不包含語句覆蓋或分支覆蓋。
- 代碼審查和代碼走查都是軟件靜態測試方法。
- 模塊分析是集成測試的第一步，也是最重要的工作之一。集成測試一般將模塊劃分爲3個等級：高危模塊、一般模塊和低危模塊，高危模塊應該優先測試。
- 集成測試的漸增式集成策略可以同時完成單元測試的集成測試。
- 目前在進行集成測試時普遍採用漸增式集成方法。
- 性能測試方法包括基準法和性能下降曲線分析法，其中基準法大體包括響應時間、併發用戶、吞吐量、性能計數器。
- 壓力測試的方法有重複、併發、量級增加、隨機。
- 系統測試的任務是檢測開發出的軟件與系統其它部分能否協調地工作，實際上是針對系統中各個組成部分進行的綜合性檢驗
- 性能測試是檢驗軟件是否達到需求說明書中規定的各類性能指標，並滿足一些性能相關的約束和限制條件。性能測試的目的是通過測試，確認軟件是否滿足產品的性能需求，同時發現系統中存在的性能瓶頸，並對系統進行優化。
- 壓力測試（Stress Testing）是指模擬巨大的工作負荷，以查看系統在峯值使用情況下是否可以正常運行。壓力測試是通過逐步增加系統負載來測試系統性能的變化，並最終確定在什麼負載條件下系統性能處於失效狀態，一次來獲得系統性能提供的最大服務級別的測試。
- 健壯性測試（Robustness Testing）主要用於測試系統抵禦錯誤的能力。這裏的錯誤通常是指由於設計缺陷而帶來的系統錯誤。測試的重點爲當出現故障時，是否能夠自動恢復或忽略故障自動運行。
- 健壯性有兩層含義：一是高可靠性，二是從錯誤中恢復的能力。可靠性體現了軟件系統的質量，需要根據符合規格說明的數據選擇測試用例，用於檢測在正常情況下系統輸出的正確性。從錯誤中恢復的能力體現了軟件系統的適應性，需要在異常數據中選擇測試用例，檢測非正常情況下的系統行爲。
- 安全性測試是檢查系統對非法侵入的防範能力，其目的是爲了發現軟件系統中是否存在安全漏洞。軟件安全性是指在非正常條件下不發生安全事故的能力。系統安全設計的準則是使非法侵入的代價超過被保護的信息的價值，從而令非法侵入者無利可圖。
- 安全性測試的方法有：功能驗證、漏洞掃描、模擬攻擊、偵聽技術。
- 軟件可靠性測試是測試在規定時間、規定的運行剖面上運行規定的軟件，測試其是否能夠正常執行的能力。其基本參數有：故障率、維修率、平均無故障時間、平均維護時間、有效度、殘留的缺陷數目、可靠性。
- 恢復性測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啓動系統。恢復測試首先要採用各種方法強迫系統失敗，然後驗證系統是否能儘快恢復。
- 備份測試是恢復性測試的一個補充，也是恢復性測試的一個部分。備份測試的目的是驗證系統在軟件或者硬件失敗時備份數據的能力。
- 兼容性測試是指檢查軟件之間是否能夠正確地進行交互和共享信息。
- 軟件運行的第一件事就是安裝（嵌入式軟件除外），安裝測試是軟件測試首先需要解決的問題。安裝測試需要不僅要考慮在不同的操作系統上運行，還要考慮與現有軟件系統的配合使用問題。
- 可用性測試（Usability Testing）是對於用戶友好型的測試，是指在設計過程中被用來改善易用性的一系列方法。
- 配置測試（Configuration Testing）是驗證系統在不同的系統配置下能否正確工作。配置測試的目的是促進被測軟件在儘可能多的硬件平臺上運行。有時經常會與兼容性測試或安裝測試一起進行。
簡答題
- 什麼是軟件測試？軟件測試的目的是什麼？
軟件測試是使用人工或自動手段來運行或測定某個系統的過程，其目的在於檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。
軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，並利用這些測試用例去執行程序，以發現軟件故障的過程。
軟件測試是一種軟件質量保證活動，其動機是通過一些經濟有效的方法，發現軟件中存在的缺陷，從而保證軟件質量。
軟件測試的目的是發現錯誤，但不能保證沒有錯誤。
- 簡述軟件測試的過程。
- 單元測試：檢測程序模塊中有無故障存在。
- 集成測試：發現與接口有關的模塊之間的問題。
- 確認測試：對軟件產品進行評估以確定其是否滿足軟件需求的過程。
- 系統測試：針對系統中各個組成部分進行的綜合性檢驗，證明系統的性能。
- 驗收測試：向用戶表明所開發的軟件系統能夠像用戶所預定的那樣工作。
- 簡述軟件測試與軟件開發的關係。
- 項目規劃階段：負責整個測試階段的規劃。
- 需求分析階段：確定測試需求分析，制定系統測試計劃。測試需求分析是指產品生存週期中測試所需的資源、配置、各階段評審通過的標準等。
- 概要設計和詳細設計階段：制定集成測試計劃和單元測試計劃。
- 編碼階段：開發相應的測試代碼或測試腳本。
- 測試階段：實施測試，並提交相應的測試報告。
軟件測試應貫穿於軟件開發的整個期間。
軟件開發經過制定計劃、需求分析、設計階段之後，才能進入編寫程序階段。但是，表現在程序中的故障，並不一定是編碼所引起的，很可能是詳細設計、概要設計階段，甚至是需求分析階段的問題引起的。即使針對源程序進行測試，所發現故障的根源也可能在開發前期的各個階段。解決問題、排除故障也必須追溯到前期的工作。因此，軟件測試應貫穿於軟件定義與開發的整個期間。
- 如何搭建軟件測試環境？
測試環境是指用來運行軟件的環境。測試環境 = 硬件+軟件+網絡+數據準備+測試工具
- 硬件環境：主要是指PC機、筆記本電腦、服務器、各種PDA終端等。
- 軟件環境：主要是軟件運行的操作系統。還有Java虛擬機，MySQL等。
- 網絡環境：主要指的是C/S結構還是B/S結構。
- 數據準備：主要指的是測試數據的準備。測試數據應考慮數據量和真實性，即儘可能獲得大量的真實的數據，包括正確和錯誤的數據。當無法取得真實數據時應儘可能模擬出大量的數據。
- 測試工具：靜態測試工具、動態測試工具、黑盒測試工具、白盒測試工具、測試執行評估工具、測試管理工具等。
搭建軟件測試環境還應注意：
- 儘量模擬用戶的真實使用環境；
- 測試環境中儘量不要安裝其它與被測軟件無關的軟件，但最好安裝殺毒軟件，以確保系統中沒有病毒；
- 測試環境應與開發環境獨立。
總之，搭建的軟件測試環境應與軟件生產運行環境一致，但還要從軟件開發環境中獨立出來。
- 軟件測試應遵循的原則有哪些？
- 儘早地和不斷地進行軟件測試：缺陷存在放大趨勢。問題發現越早，解決問題的代價就越小，這是軟件開發過程中的黃金法則。
- 不可能完全的測試：
- 不可能測試程序對所有可能輸入的響應。
- 不可能測試到程序每一條可能的執行路徑。
- 無法找出所有的設計錯誤。
- 不能採用邏輯來證明程序的正確性。
- 增量測試，由小到大：單元測試 → 集成測試 → 系統測試。
- 避免測試自己的程序。
- 注意錯誤集中的現象。
- 確認BUG的有效性：有時候測試人員提交的BUG並不是真正的BUG。一般由A測試人員發現的BUG，一定要由另外一個B測試人員來進行確認。
- 合理安排測試計劃：嚴謹、準確。
- 缺陷的定義和種類。
按照缺陷的來源，軟件缺陷分爲文檔缺陷、代碼缺陷、測試缺陷、過程缺陷。
缺陷的種類有：輸入/輸出缺陷、邏輯缺陷、計算缺陷、接口缺陷、數據缺陷。
- 缺陷的生命週期和基本流程。
生命週期：
- 評估：評估(Review)是缺陷處理的核心。由項目經理或者委員會組決定缺陷如何處理。
- 開放：缺陷一旦被發現並且記錄下來 就處於開放(Open)狀態。
- 解決：經過評估，決定是否解決，由誰來解決。
- 關閉：找到解決方案的軟件缺陷 (Resolved)，必須經過評估和測試驗證，才能最終關閉 (Closed)。
基本流程：
- 未經確認（Unconfirmed）
- 活躍（Active/Open）
- 已分配（Assigned）
- 已解決（Resolved）
- 已驗證（Verified）
- 關閉（Close）
- 黑盒測試與白盒測試的區別與聯繫。
區別：白盒測試需要源代碼；黑盒測試則不需要，只需要可執行文件。黑盒測試從用戶的角度出發，不考慮內部實現，只關注程序外在功能，白盒測試則是從開發人員的角度，對程序的邏輯結構進行測試。白盒測試在編碼、集成測試階段進行，黑盒測試在系統測試、確認測試階段進行。
聯繫：白盒測試和黑盒測試都是軟件測試的一個方面；兩者有時結合起來同時進行測試，稱爲“灰盒測試”。
- 四種黑盒測試的方法與原理。
等價類劃分法：完全不考慮程序的內部結構，只根據程序規格說明書對輸入範圍進行劃分，把所有可能的輸入數據，即程序輸入域劃分爲若干個互不相交的子集，稱爲等價類，然後從每個等價類中選取少數具有代表性的數據構成測試用例，然後進行測試。
邊界值分析法：在等價類劃分基礎上進行邊界值分析測試的基本思想是：選取正好等於、剛剛大於或剛剛小於等價類邊界的值作爲測試數據，而不是選取等價類中的典型值或任意值作爲測試數據。
因果圖法：如果輸入之間有關係，例如，約束關係、組合關係，這種關係用等價類劃分的邊界值分析是很難描述的，因此必須考慮使用一種適合於描述對於多種條件的組合，產生多個相應動作的測試方法。首先確定軟件規格中的原因和結果，然後確定原因和結果之間的邏輯關係，根據這些關係畫出因果圖，再確定因果圖中的各個約束，在因果圖上用一些記號表明約束或限制條件，最後把因果圖轉換爲決策表，並根據決策表設計測試用例。
決策表法：決策表是把作爲條件的所有輸入的各種組合值以及對應輸出值都羅列出來而形成的表格。它能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。決策表通常由條件樁、條件項、動作樁和動作項四部分組成。動作項和條件項緊密相關，指出在條件項的各組取值情況下應該採取的動作。
- 黑盒測試的兩個顯著優點。
- 黑盒測試與軟件具體實現無關，所以如果軟件實現發生了變化，測試用例仍然可以使用。
- 設計黑盒測試用例可以和軟件實現同時進行，因此可以壓縮項目總的開發時間。
- 簡述等價類劃分法中測試用例的設計。
- 確定輸入需求及輸入項。
- 爲每個等價類規定一個唯一的編號。
- 設計一個新的測試用例，儘可能多地覆蓋尚未被覆蓋的有效等價類，直到測試用例覆蓋了所有的有效等價類（包括輸出域）。
- 設計一個新的測試用例，使其覆蓋並且只覆蓋一個還沒有被覆蓋的無效等價類，直到測試用例覆蓋了所有的無效等價類。
- 從測試工作量和測試有效性兩方面進行黑盒測試方法的比較與選擇。
- 測試工作量
- 測試用例數量（邊界值分析>等價類劃分>決策表）
- 邊界值分析：不考慮數據或邏輯依賴關係，機械地根據各邊界生成測試用例。但會生成大量測試用例，機器執行時間長。
- 等價類劃分：則關注數據依賴關係和函數本身，考慮如何劃分等價類，隨後也是機械地生成測試用例。
- 決策表技術：最精細，既要考慮數據，又要考慮邏輯依賴關係。但生成的測試用例少，機器執行時間短。
- 設計測試用例的工作量（邊界值分析<等價類劃分<決策表）
- 決策表：測試用例生成所需的工作最大。但生成的測試用例少，機器執行時間短。
- 邊界值分析：測試方法使用簡單，但會生成大量測試用例，機器執行時間長。
- 測試用例數量（邊界值分析>等價類劃分>決策表）
- 測試有效性
- 如果變量引用的是物理量，可採用邊界值分析測試和等價類測試。
- 如果變量是獨立的，可採用邊界值分析測試和等價類測試。
- 如果變量不是獨立的，可採用決策表測試。
- 如果可保證是單缺陷假設，可採用邊界值分析和健壯性測試。
- 如果程序包含大量例外處理，可採用健壯性測試和決策表測試。
- 如果變量引用的是邏輯量，可採用等價類測試和決策表測試。
- 簡述白盒測試中邏輯驅動覆蓋測試的控制流覆蓋準則。
- 語句覆蓋準則
- 語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。
- 分支覆蓋準則
- 設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
- 謂詞覆蓋準則
- 原子謂詞覆蓋準則
- 設計足夠多的測試用例，運行所測程序，使程序中每個複合謂詞所包含的每一個原子謂詞都至少獲得一次“真”值和一次“假”值。
- 分支——謂詞覆蓋準則
- 設計足夠多的測試用例，運行所測程序，使程序中不僅每個複合謂詞所包含的每一個原子謂詞都至少獲得一次“真”值和一次“假”值，而且每個複合謂詞本身也至少獲得一次“真”值和一次“假”值。
- 複合謂詞覆蓋準則
- 設計足夠多的測試用例，運行所測程序，使程序中每個謂詞中條件的各種可能都至少出現一次。
- 原子謂詞覆蓋準則
- 路徑覆蓋準則
- 設計足夠多的測試用例，覆蓋被測試對象中的所有可能路徑。
- 各種覆蓋準則間的關係。
- 簡述代碼審查和代碼走查的區別。
代碼審查：軟件開發人員詳細向測試人員講解代碼實現情況，並採用靜態分析工具進行分析。
代碼走查：由測試人員組成小組，準備一批有代表性的測試用例，集體扮演計算機的角色，沿程序的邏輯，逐步運行測試用例，查找被測軟件缺陷。
- 什麼是缺陷模式？基於缺陷模式的軟件測試有何技術特點？
缺陷模式：是指程序中經常發生的錯誤或缺陷所呈現的語法及語義特徵。通常由具有領域程序設計經驗的程序員或者測試人員總結出來。不同的編程語言，往往對應於不同的缺陷模式集。
基於缺陷模式的軟件測試技術特點：針對性強；往往能發現其他測試技術難以發現的故障；工具自動化程度高以及測試效率高；缺陷定位準確。
- 簡述缺陷模式的種類及實例。
以缺陷產生後果的嚴重性高低爲評判標準，從程序的源代碼形式着眼，對缺陷模式進行分類：
- 故障模式：一經產生，會導致系統異常或出錯。如。存儲泄露，數組越界。
- 安全漏洞模式：此類缺陷會給系統留下安全隱患，爲攻擊該系統開了綠燈。如，緩衝區溢出，未驗證輸入。
- 疑問代碼模式：此類問題未必會造成系統的錯誤，可能是誤操作造成的，或者是由工程師不熟悉開發程序造成的，起到提示作用。如，低性能：低效代碼或函數；爭議代碼：讓人費解的代碼。
- 規則模式：聲明定義，分支控制，版面書寫等。
- 簡述集成測試與系統測試的區別。
集成測試在開發過程中的概要設計階段相對應，在開發過程中並行進行；系統測試則在開發完成時進行。集成測試採用黑白盒結合的測試方法；而系統測試則採用黑盒測試方法。集成測試的測試內容是各模塊之間的接口，以及集成後的功能，目的是找出接口上的錯誤；系統測試的測試內容是整個系統的功能，目的是找出與需求不一致的部分。集成測試是面向開發者的測試；系統測試是面向用戶的測試。
- 簡述集成測試的層次。
- 傳統軟件按集成粒度不同：
- 模塊內集成測試
- 模塊間集成測試
- 子系統內集成測試
- 子系統間集成測試
- 面向對象的應用系統按集成粒度不同：
- 類內集成測試
- 類間集成測試
- 簡述集成測試策略。
- 非漸增式集成：首先對每個子模塊進行測試（單元測試），然後將所有模塊全部集成起來一次性進行集成測試。
- 漸增式集成：把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，然後再把下一個待測試的模塊結合起來進行測試。
- 自頂向下集成：從主控制模塊開始，沿着程序的控制層次向下移動，逐漸把各個模塊結合起來。
- 自底向上集成：從“原子”模塊（即最底層的模塊）開始組裝和測試。
- 三明治集成：混合增量測試策略，綜合了自頂向下和自底向上兩種集成方法的優點。
- 簡述三種漸增式集成測試策略的步驟。
- 自頂向下集成
- 對主控制模塊進行測試，測試時用樁模塊代替所有直接附屬於主控制模塊的模塊。
- 根據選定的結合策略（深度優先或寬度優先），每次用一個實際模塊替換一個樁模塊（新結合進來的模塊往往又需要新的樁模塊）。
- 爲了保證加入的模塊沒有引入新的錯誤，可能需要進行迴歸測試（即，全部或部分地重複以前做過的測試）。
- 自底向上集成
- 把底層模塊組合成實現某個特定的軟件子功能的族。
- 寫一個驅動程序（用於測試的控制程序），協調測試數據的輸入和輸出。
- 對由模塊組成的子功能族進行測試。
- 去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能組。
- 三明治集成
- 確定以哪一層爲界來進行集成，如 B 模塊。
- 對模塊 B 及其所在層下面的各層使用自底向上的集成策略。
- 對模塊 B 所在層上面的層次使用自頂向下的集成策略。
- 對模塊 B 所在層各模塊同相應的下層集成。
- 對系統進行整體測試。
- 簡述性能測試和壓力測試的聯繫與區別。
- 壓力測試用來保證產品發佈後系統能否滿足用戶需求，關注的重點是系統整體；
- 性能測試可以發生在各個測試階段，即使是在單元層，一個單獨模塊的性能也可以進行評估。
- 壓力測試是通過確定一個系統的瓶頸，來獲得系統能提供的最大服務級別的測試，是極端情況下的系統能力的表現；
- 性能測試是檢測系統在一定負荷下的表現，是正常能力的表現。