1、測試順序：測試計劃和控制、測試分析和設計、測試實現和執行、評估出口準則和報告、測試結束活動。測試手段：靜態測試、動態測試測試目標：發現缺陷、增加對質量的信心、為決策提供信息、預防缺陷獨立測試可以應用于任何測試級別。獨立級別由低到高：測試由軟件本身編寫的人員來執行測試由一個其他開發人員（如來自同一個開發小組）來執行測試由組織內的一個或多個其他小組成員（如獨立的測試小組）或測試專家（如可用性或性能測試專家）來執行測試由來自其他組織或其他公司的成員來執行（如測試外包或其他外部組織的鑒定）軟件開發模型1. V 模型（順序開發模型）相對開發的四種測試級別：組件/ 單元測試、集成測試、系統測試、驗收測試2

2、. 迭代-增量開發模型生命周期模型中的測試應具備以下特點：每個開發活動都有相應的測試活動每個測試級別都有其特有的測試目標對于每個測試級別，需要在相應的開發活動過程中進行相應的測試分析和設計在開發生命周期中，測試員在文檔初稿階段就應該參與文檔的評審每個測試級別都需要明確的內容：測試的總體目標、測試用例設計需要參考的工作產品（及測試依據）、 測試對象、發現的典型缺陷和失效、對測試用具的需求、測試工具的支持、專門的方法和職責。一、測試級別? 組件 / 單元測試測試依據：組件需求說明、詳細設計文檔、代碼典型測試對象：組件、程序、數據轉換/移植程序? 集成測試測試依據：軟件和系統設計文檔、系統架構、工作

3、流、用例典型測試對象：子系統、數據庫實現、基礎結構、接口、系統配置和配置數據? 系統測試測試依據：系統和軟件需求規格說明、用例、功能規格說明、風險分析報告典型測試對象：系統、用戶手冊和操作手冊、系統配置和配置數據系統測試可能包含基于不同方面的測試：基于風險評估的、基于需求規格說明的、基于業務過程的、基于用例的、基于其他對系統行為的更高級別描述或模型的、基于與操作系統的相互作用的、基于系統資源等的。系統測試通常由獨立的測試團隊進行。? 驗收測試測試依據：用戶需求、系統需求、用例、業務流程、風險分析報告 典型測試對象：基于完全集成系統的業務流程、操作與維護流程、用戶處理過程、結構、報 告、配置數據

4、。同時系統的其他利益相關者也可能參與驗收測試通常由使用系統的用戶后客戶來進行，其中。二、測試類型? 功能測試（黑盒測試）安全測試時功能測試的一種。互操作性是另一種功能性測試，評估軟件產品與其他一個或多個組件或系統交互的能力。? 非公能測試主要包括：性能測試、負載測試、壓力測試、可用性測試、可維護性測試、可靠性測試、可移植性測試，非公能性測試就是測試系統運行的表現如何。? 軟件結構/ 架構測試（結構測試）（白盒測試）最好在進行基于規格說明的測試之后使用，以便通過評估結構類型的覆蓋來測量測試的完整性。? 與變更相關的測試（再測試和回歸測試）? 維護測試對軟件或系統修改、移植、退役處理而進行的維護測

5、試。三、靜態技術評審、 靜態分析和動態測試具有共同的目標：識別缺陷。靜態技術發現的是軟件失效的原因（缺陷） ，而不是失效本身。通過評審更容易發現如下典型缺陷：與標準直接的偏差、需求內的錯誤、設計錯誤、可維護性不足和錯誤的接口規格說明等。? 評審過程正式評審的階段：計劃階段、預備會階段、個人準備階段、檢查/ 評價 /記錄結果（評審會議階段） 、返工階段、跟蹤結果階段。? 角色和職責經理、主持人、作者、評審員、記錄員。? 評審類型非正式評審（以較低的成本獲得收益）；走查（學習、增加理解、發現缺陷）；技術評審（需要包含同行和技術專家，討論、作決策、評估候選方案、返現缺陷、解決技術問題、檢查與規格及標

6、準的符合程度）審查（通常是同行檢查，引入了度量，主要目的是發現缺陷）走查、技術評審和審查可以是在同行們-即由同一組織級別內的同事們內舉行，這種評審類型稱為同行評審。? 靜態分析的工具支持靜態分析的目的是發現軟件源代碼和軟件模型中的缺陷。與評審一樣，靜態分析通常發現的是缺陷而不是失效。開發人員通常在組件測試和集成測試之前或期間，或當代碼簽入到配置管理工具時使用靜態分析工具，設計人員在軟件建模期間也使用靜態分析工具。四、測試設計技術? 測試開發過程測試分析階段（對測試基礎文檔進行分析，明確測試什么。要建立測試條件到需求的可追溯性） ；測試設計階段（要定義和記錄測試用例和測試數據，預期的測試結果應該

7、作為測試用例規格說明的一部分）；測試實現階段；? 測試設計技術種類使用測試設計技術的目的是為了識別測試條件和開發測試用例。黑盒測試設計技術（也稱為基于規格說明的測試技術） 是依據分析測試基礎文檔來選擇測試 條件、測試用例或測試數據的技術； 白盒測試設計技術 （也稱為結構化或基于結構的測試技 術）是基于分析被測組件或系統的結構的測試技術?；谝幐裾f明的測試技術具有以下共同特點：使用正式或非正式的模型來描述需要解決的問題、軟件或其組件等；根據這些模型，可以系統地導出測試用例。基于結構的技術的共同特點：根據軟件的結構信息設計測試用例，比如軟件代碼和詳細設計信息；可以通過已有的測試用例測量軟件的測試覆

8、蓋率，并通過系統化的導出設計用例來提高覆蓋率。基于經驗的方法具有以下共同特點：測試用例根據參與人員的經驗和知識來編寫；測試人員、開發人員、用戶和其他的利益相關者對軟件、軟件使用和環境等方面所掌握的知識作為信息來源之一；對可能存在的缺陷及其分布情況的了解作為另一個信息來源。? 基于規格說明或黑盒測試技術等價類劃分分為有效數據和無效數據。也可以基于輸出、內部值、事件相關的值（如事件之前或之后）以及接口參數（在集成測試階段）邊界值分析詳細的規格說明對邊界值分析很有幫助。決策表測試這種方法可以用來記錄一個系統要實施的復雜的業務規則。決策表測試的優點是可以生成測試條件的各種組合，而這些組合可能利用其它方

9、法會無法被測試到。 適用于軟件的行為由一 些邏輯決策所決定的情況。狀態轉換測試普遍較多的使用在嵌入式軟件行業和自動化行業，但同樣適用于特定狀態業務對象的建模或測試具有對話框狀態轉換流的系統。用例測試? 基于結構的或白盒技術組件級別：軟件組件的結構，比如：語句、判定、分支或每個不同的路徑；集成級別：結構可能是調用樹（模塊調用關系圖）；系統級別：結構可能是菜單結構、業務過程或web頁面結構。語句覆蓋和覆蓋率語句覆蓋率取決于被（設計或執行）測試用例覆蓋的可執行語句數量除以被測代碼中所有可 執行語句數量。判定覆蓋和覆蓋率判定覆蓋，和分支測試相關，是指評價在一個測試用例套中已經執行的判定輸出的百分比。判

10、定覆蓋率取決于被（設計或執行）的測試用例覆蓋的所有判定出口數目除以被測代碼中所 有可能的判定出口數目。其他的基于結構的技術條件覆蓋、多重條件覆蓋、模塊覆蓋、組件覆蓋、類的覆蓋。? 基于經驗的技術錯誤推測法，測試人員靠經驗來預測缺陷。錯誤推測法的一個結構化方法是列舉可能的錯誤，并設計測試來攻擊這些錯誤，這種系統的方法稱之為缺陷攻擊。探索性測試是指依據包含測試目標的測試章程來同時進行測試設計、測試執行、測試記錄和學習，并且是在規定時間內進行的。? 選擇測試技術測試技術的選擇基于下面幾個因素：系統類型、法律法規標準、客戶或合同的需求、風險的級別、風險的類型、測試目標、文檔的可用性、測試員的技能水平、

11、時間和成本預算、開發生命周期、用例模型和以前發現各類缺陷的經驗。五、測試管理? 測試組織測試組織和測試獨立性：a. 不獨立的測試成員、開發人員測試自己的代碼；b. 開發團隊內獨立的測試員；c. 組織內獨立的測試小組或團隊，向項目經理或執行經理匯報；d. 來自業務組織、用戶團體內的獨立測試人員；e. 針對特定測試類型的獨立測試專家，例如： 可用性測試員、安全性測試員、認證測試員；f. 外包或組織外的獨立測試人員。測試組長和測試員執行的活動和任務是由項目和產品的背景、人員的角色和組織結構來決定的。? 測試計劃和估算入口準則定義了什么時候可以開始測試，如某個測試級別的開始，或什么時候一組測試準備就緒

12、可以執行。出口準則的目的是定義什么時候可以停止測試，比如某個測試級別的結束，或者當測試達到了規定的目標。兩種估算測試工作量的方法：基于度量的方法（根據以前或相似）、基于專家的方法。測試策略，測試方法：在特定項目中，測試方法是測試策略的具體實現。典型的測試方法：分析的方法、基于模型的方法、系統的方法、基于與過程或符合標準的方法、動態和啟發式的方法、咨詢式的方法、可重用的方法? 測試過程的監控測試監控的目的是提供關于測試活動的反饋信息，使測試活動保持可視性。測試控制描述了根據收集和報告的測試信息和度量而采取的指導或糾正措施。? 配置管理配置管理的目的是在整個項目和產品的生命周期內，建立和維護軟件或

13、系統產品（組件、數據和文檔）的完整性。? 風險和測試項目風險項目風險是圍繞項目按目標交付的能力的一系列風險。產品風險在軟件或系統中的潛在失效部分（即將來可能發生不利事件或危險）稱之為產品風險?；陲L險的測試需要借助于項目利益相關者的集體知識和智慧，從而識別風險以及為了應對這些風險需要采用的測試級別。? 事件管理測試的目的之一是發現缺陷，所以實際結果和預期結果之間的差異需要作為一個事件被記錄。事件必須進行調查，并且有可能最終被證明是一個缺陷。六、軟件測試工具? 測試工具的類型測試管理的工具支持：測試管理工具、需求管理工具、事件管理工具（缺陷跟蹤工具）、配置管理工具。靜態測試的工具支持：靜態測試工具提供了一種在開發過程的早期發現盡可能多的缺陷的高性價比的方法。評審工