前言

此文章爲本人利用課餘時間進行的ISTQB初級認證知識和考點的總結。總結過程主要參考了“ISTQB測試人員認證初級大綱（2011版）”，由於作者能力與精力有限，此篇文章可能會存在紕漏，望見諒並及時指出。謝謝！

ISTQB思維腦圖

上圖中紅色字體部分爲重要考點和易錯點。

ISTQB（初級）知識和考點總結

軟件測試基礎(1)

爲什麼需要測試(1.1)

缺陷帶來的危害(1.1.1)
- 資金受損
- 時間受損
- 信譽受損
- 人員傷亡
測試基本術語(1.1.2)
- 【人爲】錯誤（Error, Mistake）
- 【內在】缺陷（Defect，Bug，Fault）
- 【外部】失效（Failure）
  - 當存在缺陷的代碼被執行時引發缺陷（即發現缺陷必須要運行軟件）
  - 失效也可能是由於環境條件引起的
測試和調試的區別
調試和測試是兩個不同的概念。動態測試可以發現由於軟件缺陷引起的失效。而調試是一種發現，分析，清除引起失效原因的開發活動，隨後由測試員進行的再測試是爲了確認修改的代碼已經解決了失效問題。每個活動的職責是截然不同的，即測試員進行測試，開發人員進行調試。
- 調試（Debug）
  - 調試是一種開發活動；
  - 調試爲了發現、分析並消除缺陷；
  - 調試一邊修改代碼一邊進行驗證；
  - 調試由開發人員執行；
  注意：調試的對象只能是代碼，不能是文檔；
- 測試（Test）
  - 動態測試可以發現缺陷引起的失效；
  - 再測試（Verify）是爲了驗證代碼修改已經解決了失效；
  - 測試由測試人員執行；
  注意：測試的對象不僅限於代碼，還可以包括文檔；
外部和內部質量特性(1.1.4)
軟件滿足規定或潛在客戶需求特性的程度（ISO9126）
- 功能性
  - 適合性
  - 準確性
  - 互操作性
  - 保密安全性
  - 功能依從性
- 可靠性
  - 成熟性
  - 容錯性
  - 可靠依從性
- 易用性
  - 易理解性
  - 易學性
  - 易操作性
  - 吸引性
  - 易用依從性
- 效率
  - 時間特性
  - 資源利用性
  - 效率依從性
- 維護性
  - 易分析性
  - 易改變性
  - 穩定性
  - 易測試性
  - 維護依從性
- 可移植性
  - 適應性
  - 易安裝性
  - 共存性
  - 易替換性
  - 可移植依從性
測試和質量的關係(1.1.4)
軟件測試是對軟件質量的度量和評估，提供軟件質量的信息，不能僅靠軟件測試保證質量。
- 度量及評估軟件質量特性
  可以根據測試中所發現的缺陷，對軟件功能和非功能性需求以及特性(例如:可靠性、可用性、效率、可維護性和可移植性)進行度量，從而評估軟件質量。
- 樹立對於軟件質量的信心
  當測試發現很少或者沒有發現缺陷的時候，測試就會幫助樹立對於軟件質量的信心。
- 改進軟件開發過程
  通過分析在其他項目中發現的缺陷和引起缺陷的根本原因，可以改進軟件開發過程。
- 質量保證工作的一部分
  測試應該作爲開發過程中質量保證工作的不可或缺的一部分(與開發標準、培訓和缺陷分析一樣)。
測試的充分性(1.1.5)
- 風險
  - 技術風險
  - 商業產品風險
  - 項目風險
- 時間限制
- 預算限制

測試總體目標(1.2)

【早期階段】預防缺陷
- 靜態測試
【開發階段】發現缺陷
- 組件測試
- 集成測試
- 系統測試
【驗收階段】增加對質量的信心
- 驗收測試
【運行階段】爲決策提供信息
- 維護測試

測試的基本原則(1.3)

原則 1 - 測試顯示存在缺陷
測試可以顯示存在缺陷，但不能證明系統不存在缺陷。測試可以減少軟件中存在未被發現缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟件或系統是完全正確的。
原則 2 - 窮盡測試是不可行的
除了小型項目，進行完全(各種輸入和前提條件的組合)的測試是不可行的。通過運用風險分析和不同系統功能的測試優先級，來確定測試的關注點，從而替代窮盡測試。

助記：
不要追求完美，考慮測試的充分性。
原則 3 - 測試儘早介入
爲了儘早發現缺陷，在軟件或系統開發生命週期中，測試活動應該儘可能早的介入，並且應該將關注點放在已經定義的測試目標上。

助記：
越早發現缺陷影響越小
原則 4 - 缺陷集羣性
測試工作的分配比例應該與預期的和後期觀察到的缺陷分佈模塊相適應。少數模塊通常包含大部分在測試版本中發現的缺陷或失效。

助記：
缺陷多的模塊要着重測試
原則 5 - 殺蟲劑悖論
採用同樣的測試用例多次重複進行測試，最後將不再能夠發現新的缺陷。爲了克服這種“殺蟲劑悖論”，測試用例需要進行定期評審和修改，同時需要不斷增加新的不同的測試用例來測試軟件或系統的不同部分，從而發現潛在的更多的缺陷。

助記：
要儘量測新版本；隨時更新測試用例、環境、工具和計劃。
原則 6 - 測試活動依賴於測試背景
針對不同的測試背景，進行不同的的測試活動。比如，對安全關鍵的軟件進行測試，與對一般的電子商務軟件的測試是不一樣的。

助記：
測試人員要有行業背景和行業知識！
原則 7 - 不存在缺陷(就是有用系統)的謬論
假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的。

基本的測試過程(1.4)

1. 測試計劃和控制
  測試計劃的主要活動是:識別測試任務、定義測試目標以及爲了實現測試目標和任務確定必要的測試活動。
測試控制是持續進行的活動:通過對測試實際進度和測試計劃之間的比較，報告測試的狀態，包括與計劃之間存在的偏差。測試控制包括在必要的時候採取必要的措施來滿足測試的任務和目標。需要在項目的整個生命週期中對測試活動進行監督，以達到控制測試過程的目的。同時，測試計劃的制定也需要考慮測試監控活動的反饋信息。

測試計劃和控制階段的任務將在第五章講述。
1. 測試分析和設計
  測試分析和設計是將概括的測試目標轉化爲具體的測試條件和測試用例的一系列活動。
主要任務:
 評審測試依據(比如需求、軟件完整性級別1(風險等級)、風險分析報告、系統架構、設計和接口說明);
 評估測試依據和測試對象的可測性;
 通過對測試項、規格說明、測試對象行爲和結構的分析，識別測試條件並確定其優先級;
 設計測試用例並確定優先級;
 確定測試條件和測試用例所需要的測試數據;
 規劃測試環境的搭建和確定測試需要的基礎設施和工具;
 創建測試依據和測試用例間的雙向可追溯性。
1. 測試實現和執行
  通過特定的順序組織測試用例來完成測試規程和腳本的設計，並且包括測試執行所需的其他任何信息，以及測試環境的搭建和運行測試。
主要任務:
 測試用例的開發、實現並確定它們的優先級。(包括識別測試數據);
 開發測試規程並確定優先級，創建測試數據，同時也可以準備測試用具和設計自動化測試腳本;
 根據測試規程創建測試套件，以提高測試執行的效率;
 確認已經正確搭建了測試環境;
 確認並更新測試依據和測試用例間的雙向可追溯性;
 根據計劃的執行順序，通過手工或使用測試執行工具來執行測試規程;
 記錄測試執行的結果，以及被測軟件、測試工具和測試件的標識和版本;
 將實際結果和預期結果進行比較;
 對實際結果和預期結果之間的差異，作爲事件上報，並且進行分析以確定引起差異的原因(例如:代碼缺陷、具體測試數據缺陷、測試文檔缺陷、或測試執行的方法有誤等);
 缺陷修正後，重新進行測試活動。比如通過再次執行上次執行失敗的用例來確認缺陷是否已經被修正(確認測試)。執行修正後的測試用例或執行一些測試用例來確保缺陷的修正沒有對軟件未修改的部分造成不良影響或對於缺陷的修正沒有引發其他的缺陷(迴歸測試)。
1. 評估出口準則和報告
  評估出口準則是將測試的執行結果和已經定義的測試目標進行比較的活動。這個活動在各個測試級別上都需要進行。(參見章節 2.2)
主要任務:
 按照測試計劃中定義的測試出口準則檢查測試日誌;
 評估是否需要進行更多的測試，或是否需要更改測試的出口準則;
 爲利益相關者提供一個測試總結報告。
1. 測試結束活動
  測試結束活動就是從已完成的測試活動中收集和整合有用的數據，這些數據可以是測試經驗、測試件、影響測試的因素和其他數據。
  在以下幾種情況下需要執行測試結束活動，例如:當軟件系統正式發佈、當一個測試項目完成(或取消)、當達到一個里程碑或當一個維護版本完成時。
主要任務:
 檢查提交了哪些計劃的可交付產品;
 事件報告是否關閉、或對未關閉的事件報告提交變更需求;
 記錄系統的驗收;
 記錄和歸檔測試件、測試環境和測試基礎設備，以便以後的重複使用; 移交測試件到維護部門;
 分析和記錄所獲得的經驗教訓，用於以後的項目和測試成熟度改進;
 使用爲測試成熟度的提高所收集的信息。

測試的獨立性級別(1.5)

由開發者本人執行
測試由軟件本身編寫的人員來執行(最低級別的獨立)
由其他開發人員執行
測試由一個其他開發人員(如來自同一開發小組)來執行
由獨立的測試小組或專家執行
測試由組織內的一個或多個其他小組成員(如獨立的測試小組)或測試專家(如可用性或性能測試專家)來執行
由外包或其他外部組織執行
測試由來自其他組織或其他公司的成員來執行(如測試外包或其他外部組織的鑑定，最高級別的獨立)

軟件測試與開發如何相處(1.5)

溝通方面的問題經常會發生，特別是當測試員只是被視爲不受歡迎的缺陷消息的傳遞者的時候。然而可以使用下面的一些方法來改善測試員和其他小組成員之間的溝通和相互關係:
 以合作而不是爭鬥的方式開始項目，時時提醒項目的每位成員:共同目標是追求高質量的產品;
 對產品中發現的問題以中性的和以事實爲依據的方式來溝通，而不要指責引入這個問題的小組成員或個人。比如，客觀而實際地編寫缺陷報告和評審發現的問題;
 儘量理解其他成員的感受，以及他們爲什麼會有這種反應;
 確信其他成員已經理解你的描述，反之亦然。

職業道德(1.6)

公共 - 認證測試工程師應當以公衆利益爲目標。
客戶和僱主 - 在保持與公衆利益一致的原則下，認證測試工程師應注意滿足客戶和僱主的最高利益。
產品 - 認證測試工程師應當確保他們提供的(在產品和系統中由他們測試的)發佈版本符合最高的專業標準。
判斷 - 認證測試工程師應當維護他們職業判斷的完整性和獨立性。
認證軟件測試管理人員和測試領導人員應贊成和促進對軟件測試合乎道德規範的管理。
專業 - 在與公衆利益一致的原則下，認證測試工程師應當推進其專業的完整性和聲譽。
同事 - 認證測試工程師對其同事應持平等和互助和支持的態度，並促進與軟件開發人員的合作。
自我 - 認證測試工程師應當參與終生職業實踐的學習，並促進合乎道德的職業實踐方法。

軟件生命週期中的測試(2)

軟件開發模型(2.1)

軟件開發模型是指軟件開發所依據的方式和過程。

如何選擇開發模型？

根據項目的內容
根據產品的特徵
V模型（順序開發模型）(2.1.1)
“V模型”也稱“順序開發模型”，它適合需求明確且不常改變的場景。

用戶需求 <———— 驗收測試
系統設計 <——— 系統測試
概要設計 <—— 集成測試
詳細設計 <— 組件測試
編碼/實現

備註：
箭頭表示驗證關係
- 組件測試
- 集成測試
- 系統測試
- 驗收測試
迭代-增量開發模型(2.1.2)
迭代-增量開發模型由需求建立、設計、構建和測試等一系列相對較短的開發週期構成。

在每次迭代過程中, 對迭代產生的系統可能需要在不同的測試級別上進行測試。通過將增量模塊加入到以前開發的模塊中，形成一個逐漸增大的系統，這個系統同樣需要進行測試。在完成第一次迭代後，對所有的迭代進行迴歸測試會變得越來越重要。驗證和確認可以在每個增量模塊中進行。
- 原型開發
- 快速應用開發(RAD)
- 統一軟件開發過程(RUP)
- 敏捷開發(Agile)
  “敏捷開發模型”適合需求快速變化的場景。

測試級別(2.2)

“V模型”也稱“順序開發模型”，它適合需求明確且不常改變的場景。

用戶需求 <———— 驗收測試
系統設計 <——— 系統測試
概要設計 <—— 集成測試
詳細設計 <— 組件測試
編碼/實現

備註：
箭頭表示驗證關係

組件測試(2.2.1)
- 也稱“單元測試”或“模塊測試”；
- 在軟件編碼完成後，對每個程序模塊進行測試；
- 通常由開發人員進行，測試人員輔助；
  - 概述
    在獨立可測試的軟件中(模塊、程序、對象和類等),可以通過組件測試發現缺陷，以及驗證軟件功能。根據開發生命週期和系統的背景，組件測試可以和系統的其他部分分開，單獨進行測試。在組件測試過程中，會使用到樁、驅動器和模擬器。
    
    組件測試可能包括功能測試和特定的非功能特徵測試，比如資源行爲測試(如內存泄漏)或健壯性測試和結構測試(比如分支覆蓋)。根據工作產品，例如組件規格說明、軟件設計或數據模型等設計測試用例。
    
    通常，通過開發環境的支持，比如組件測試框架或調試工具，組件測試會深入到代碼中，而且實際上設計代碼的開發人員通常也會參與其中。在這種情況下，一旦發現缺陷，就可以立即進行修改，而不需要正式的缺陷管理過程。
  - 測試依據
    - 組件需求說明
    - 詳細設計文檔
    - 代碼
  - 測試對象
    - 組件
    - 程序
    - 數據轉換/移植程序
    - 數據庫模型
集成測試(2.2.2)
- 也稱“組裝測試”或“聯合測試”；
- 關注模塊之間的配合，用以發現接口上的缺陷；
- 集成應當是漸進的，可以“自頂向下”也可以“自底向上”集成；
  - 概述
    集成測試是對組件之間的接口進行測試，以及測試一個系統內不同部分的相互作用，比如操作系統、文件系統、硬件或系統之間的接口。
    
    集成的規模越大，就越難在某一特定的組件或系統中定位缺陷，從而增加了風險並會花費額外的更多時間去發現和修理這些故障。
    系統化集成的策略可以根據系統結構(例如自頂向下或自底向上)、功能任務集、事務處理順序或系統和組件的其他方面等來制定。爲了能方便快速地隔離故障和定位缺陷，集成程度應該逐步增加，而不是採用“大爆炸”式的集成。
    
    測試特定的非功能特徵(比如性能)也可以包含在系統集成測試中。
    在集成的每個階段，測試員只是把精力集中在集成本身。舉例來說，假如集成模塊 A 和模塊 B，測試人員是應該關注兩個模塊之間的交互，而不是每個模塊的功能。功能測試和結構測試方法都可以應用在集成測試。
  - 測試依據
    - 軟件和系統設計文檔
    - 系統架構
    - 工具流
    - 用例
  - 測試對象
    - 子系統
    - 數據庫實現
    - 基礎結構
    - 接口
    - 系統配置和配置數據
系統測試(2.2.3)
- 將整個程序安裝到運行環境中，對硬件、網絡、操作系統及支撐平臺構成的整體系統進行測試。
- 通常由獨立的測試團隊進行。
  - 概述
    系統測試關注的是在開發項目或程序中定義的一個完整的系統/產品的行爲。
    
    在系統測試中，測試環境應該儘量和最終的目標或生產環境相一致，從而減少不能發現和環境相關的失效的風險。
    
    系統測試可能包含基於不同方面的測試:基於風險評估的、基於需求規格說明的、基於業務過程的、基於用例的、或基於其他對系統行爲的更高級別描述或模型的、基於與操作系統的相互作用的、基於系統資源等的測試。
    
    針對功能需求的系統測試開始時可以選擇最適合的基於規格說明的測試即黑盒技術來對系統進行測試。比如:可以根據業務準則描述的因果組合來生成決策表。基於結構的技術即白盒測試技術，可以評估測試的覆蓋率，可以基於評估覆蓋一個結構元素，如菜單結構或者頁面的導航等的完整性。
    
    系統測試通常由獨立的測試團隊進行。
  - 測試依據
    - 系統和軟件需求規格說明
    - 用例
    - 功能規格說明
    - 風險分析報告
  - 測試對象
    - 系統、用戶手冊和操作手冊
    - 系統配置和配置數據
驗收測試(2.2.4)
- 也稱“交付測試”或“確認測試”；
- 在交付軟件前，需要檢測與證實軟件是否滿足了需求說明書中規定的要求。
  - 概述
    通常是由使用系統的用戶或客戶來進行，同時系統的其他利益相關者也可能參與其中。
    
    驗收測試的目的是建立對系統、系統的某部分或特定的系統非功能特徵建立信心。發現缺陷不是驗收測試的主要目標。驗收測試可以用來評估系統對於部署和使用的準備情況，但是驗收測試不一定是最後級別的測試。
    
    驗收測試可以在多個測試級別上進行。
  - 測試依據
    - 用戶需求
    - 系統需求
    - 用例
    - 業務流程
    - 風險分析報告
  - 測試對象
    - 基於完全集成系統的業務流程
    - 用戶處理過程
    - 結構
    - 報告
    - 配置數據
  - 典型類型
    - 用戶驗收測試
      最終操作人員參與
    - 操作（驗收）測試
      由系統管理員來進行，測試內容主要包括:
       系統備份/恢復測試;
       災難恢復測試;
       用戶管理測試;
       維護任務測試;
       數據加載和移植活動;
       安全漏洞階段性檢查。
    - 合同和法規性驗收測試
      合同性：根據合同中規定的驗收準則進行測試；
      法規性：根據法律法規進行測試，如政府、法律和安全方面的法律法規。
    - Alpha和Beta（或現場）測試
      Alpha 測試通常在開發組織現場進行，但測試並非由開發團隊執行。Beta 測試或實地測試，是在客戶或潛在客戶現場進行並由他們執行。

測試類型(2.3)

功能性測試(2.3.1)
可以採用基於規格說明的技術，根據軟件或系統的功能來設計測試條件和測試用例(參見第 4 章)。功能測試主要是考慮軟件的外部表現行爲(黑盒測試)。

安全性測試是功能測試的一種，它會對安全性相關的功能(比如防火牆)進行測試，從而檢測系統和數據是否能抵禦外部惡意的威脅，如病毒等。互操作性測試是另一種功能性測試，評估軟件產品與其他一個或多個組件或系統交互的能力。

注意：
安全性和互操作性測試是功能性測試。
非功能性測試(2.3.2)
非功能測試包括但不限於:性能測試、負載測試、壓力測試、可用性測試、可維護性測試、可靠性測試和可移植性測試。非功能性測試就是測試系統運行的表現如何。
結構測試(2.3.3)
可以在任何測試級別上進行結構測試(白盒測試)。

結構測試技術最好在進行基於規格說明的測試之後使用，以便通過評估結構類型的覆蓋來測量測試的完整性。

覆蓋是指結構通過測試套件檢驗的程度，以項被覆蓋的百分比來表示。假如覆蓋率不是 100%，可能需要設計更多的測試用例，來測試被遺漏的項，從而提高測試的覆蓋。有關覆蓋技術參見第 4 章。

在所有的測試級別，特別是在組件測試和組件集成測試中，可以利用工具來測量代碼內某些元素的覆蓋率，比如語句覆蓋和判定覆蓋。結構測試也可以基於系統的結構，比如調用層次結構。

結構測試方法也同樣可以運用到系統、系統集成或驗收測試級別(比如業務模型或菜單結構)。
再測試和迴歸測試(2.3.4)
當發現和修改了一個缺陷後，應進行再測試以確定已經成功的修改了原來的缺陷，這稱之爲確認。調試(定位並修復缺陷)是一種開發活動，不是一種測試活動。

迴歸測試是對已被測過的程序在修改缺陷後進行的重複測試，以發現在這些變更後是否有新的缺陷引入或被屏蔽。

當軟件發生變更或者應用軟件的環境發生變化時，需要進行迴歸測試。迴歸測試的規模可以根據在以前正常運行的軟件中發現新的缺陷的風險大小來決定。

迴歸測試可以在所有的測試級別上進行，同時適用於功能測試、非功能測試和結構測試。迴歸測試套件一般都會執行多次，而且通常很少有變動，因此將回歸測試自動化是很好的選擇。

維護測試(2.4)

維護測試是在一個現有的運行系統上進行，且一旦對軟件或系統進行修改、移植或退役處理時，就需要進行維護測試。

當數據從另一個應用程序移植到正在維護的系統時，需要移植測試(轉換測試)。

爲系統退役而進行的維護測試應該包括數據移植測試，或當數據要長時間的保存時還須存檔測試。

維護測試根據變更情況的不同，可以在某一測試級別或所有測試級別和測試類型上進行。確定變更如何影響現有系統的過程，稱之爲影響分析，它有助於決定實施迴歸測試的廣度和深度。

如果規格說明遺失、過時或測試人員沒有具備領域知識，進行維護測試將是一件困難的事情。

軟件靜態測試技術(3)

靜態測試分類

評審
- 非正式評審
- 正式評審
  - 走查(Walk through)
  - 技術評審(Technical Review)
  - 正規審查(Inspection)
基於工具的靜態分析
- 詞法和語法分析
- 靜態錯誤分析

靜態技術和測試過程(3.1)

概述
靜態測試技術通過手工檢查(評審)或自動化分析(靜態分析)的方式對代碼或者其他的項目文檔進行檢查。

評審是對軟件工作產品(包括代碼)進行測試的一種方式，可以在動態測試執行之前進行。
在生命週期早期的評審過程中發現並修改缺陷(例如發現需求中的缺陷)的成本會比在動態測試中才發現並修改這些缺陷的成本低的多。
目標
評審、靜態分析和動態測試具有共同的目標是識別缺陷。
它們之間是互補的，不同的技術可以有效和高效地發現不同類型的缺陷。
特點
- 不需要運行代碼；
- 直接發現缺陷本身；
- 檢查對象不僅是代碼還可以是文檔；
- 可以在早期發現缺陷，大幅降低成本；
- 相對動態測試而言，靜態測試成本低效率高；

評審過程(3.2)

正式評審的階段(3.2.1)
- 1. 計劃階段
     定義評審標準;
     選擇人員;
     分配角色;
     爲更加正式的評審類型(比如審查)制定入口和出口準則;
     選擇需要進行評審的文檔的內容;
     覈對入口準則(針對更正式的評審類型)。
- 1. 預備會階段
     分發文檔;
     向評審參與者解釋評審的目標、過程和文檔。
- 1. 個人準備階段
     先行評審文檔，爲評審會議做準備;
     標註可能的缺陷、問題和建議;
- 1. 評審會議階段
     討論和記錄，並留下文檔化的結果或會議紀要(針對更正式的評審類型);
     標註缺陷、提出處理缺陷的建議、對缺陷作出決策;
     在任何形式的會議期間或跟蹤任何類型的電子通信期間檢查/評價和記錄問題。
- 1. 返工階段
     修改發現的缺陷(通常由作者來進行);
     記錄缺陷更新的狀態(在正式評審中)。
- 1. 跟蹤結果階段
     檢查缺陷是否已得到解決;
     收集度量數據;
     覈對出口準則(針對更正式的評審類型)。
角色和職責(3.2.2)
- 經理
  經理:決定是否需要進行評審，在項目計劃中分派時間，判斷是否已達到評審的目標。
  
  注意：
  經理未必出席評審會議。
- 主持人
  主持人:主持文檔或文檔集的評審活動，包括策劃評審、召開會議和會議後的跟蹤。假如需要，主持人可能還需要進行不同觀點之間的協調。主持人通常是評審成功與否的關鍵。
  
  注意：
  主持人是評審成敗的關鍵。
- 作者
  作者:待評審文檔的作者或主要責任人。
- 評審員
  評審員:具有專門技術或業務背景的人員(也稱爲檢查員(checker)或審查員(inspector))，他們在必要的準備後，標識和描述被評審產品存在的問題(如缺陷)。所選擇的評審員應該
  在評審過程中代表不同的觀點和角色，並且應該參與各種評審會議。
- 記錄員
  記錄員:記錄所有的事件、問題，以及在會議過程中識別的未解決的問題。
  
  注意：
  記錄員可以是其他角色兼職負責，例如主持人，但不能是作者本人。
評審類型(3.2.3)
非正式評審：
- 評審對象是正在進行中的工作產品；
- 不需要明確定義的過程，可以沒有書面指導性材料。
正式評審：
- 評審對象是已經確認完成的工作產品；
- 需要遵循明確定義的過程，參與人員有明確的職責劃分，有明確定義的入口和出口準則，以及規範化的書面材料。
  - 非正式評審
    主要目的:以較低的成本獲得收益。
  - 走查(Walk through)
    主要目的:學習、增加理解、發現缺陷。
    
    在實際情況中可以是非常正式的，也可能是非常不正式的;
  - 技術評審(Technical Review)
    主要目的:討論、作決策、評估候選方案、發現缺陷、解決技術問題、檢查與規格及標準的符合程度。
    
    在實際情況中可以是在不正式的和非常正式的之間;
  - 正規審查(Inspection)
    主要目的:發現缺陷。
技術評審的注意事項
1. 評審應針對材料而非作者；
2. 評審會議不宜超過兩個小時：當被審覈材料多時，應該拆分成若干部分進行評審；
3. 限制爭辯的時間：當無法取得一致認同時，先記錄問題，可另行安排時間進行討論；
4. 闡明問題而不試圖解決問題：評審會上不要解決問題，應記錄問題，會後再解決問題；

靜態分析的工具支持(3.3)

概述
靜態分析的目的是發現軟件源代碼和軟件模型中的缺陷。靜態分析的執行並不需要使用工具去實際運行被測軟件。而動態測試是真正運行軟件的代碼。靜態分析可以定位那些在測試過程很難發現的缺陷。與評審一樣，靜態分析通常發現的是缺陷而不是失效。靜態分析工具能夠分析程序代碼 (比如控制流和數據流)，以及產生如 HTML 和 XML 的輸出。
靜態分析的好處
靜態分析的好處:
 在測試執行之前儘早發現缺陷;
 通過度量的計算(比如高複雜性測量)，早期警示代碼和設計可能存在問題的方面;
 可以發現在動態測試過程不容易發現的一些缺陷;
 可以發現軟件模塊之間的相互依賴性和不一致性，例如鏈接;
 改進代碼和設計的可維護性;
 在開發過程中學習經驗教訓，從而預防缺陷。
靜態分析策略
開發人員通常在組件測試和集成測試之前或期間，或當代碼簽入到配置管理工具時使用靜態分析工具(按照預先定義的規則或編程規範進行檢查)。

設計人員在軟件建模期間也使用靜態分析工具。

靜態分析工具會產生大量的警告信息，需要很好的管理這些信息，從而可以有效地使用靜態分析工具。

編譯器也可以爲靜態分析提供一些幫助，包括度量的計算。
工具能夠發現的典型缺陷
通過靜態分析工具能夠發現的典型缺陷如下:
 引用一個沒有定義值的變量;
 模塊和組件之間接口不一致;
 從未使用的變量;
 不可達代碼或死代碼;
 邏輯上的遺漏與錯誤(潛在的無限循環);
 過於複雜的結構;
 違背編程規則;
 安全漏洞;
 代碼和軟件模型的語法錯誤。

測試設計技術(4)

測試開發過程(4.1)

測試分析階段
在測試分析階段，要對測試基礎文檔進行分析，從而決定測試什麼，也就是明確測試的條件。將測試條件定義爲能通過一個或多個測試用例進行驗證的一個條目或事件(比如功能、事務處理、質量特徵或結構元素等)。
建立從測試條件到需求的可追溯性，有助於需求變更時的影響分析和測試用例集的需求覆蓋率分析。在測試分析階段，除了考慮一些其它的因素，基於已經識別的風險，實施具體的測試方法從而選擇要採用的測試技術(有關風險分析的更多的內容請參見第 5 章)。
測試設計階段
在測試設計階段，要定義和記錄測試用例和測試數據。測試用例由:一組輸入值、執行的前提條件、預期結果和執行的後置條件等元素組成，以覆蓋一定的產生目標或測試條件。測試設計規格說明(包含測試條件)和測試用例規格說明的內容在“軟件測試文檔標準(IEEE Std 829-1998)” 中有具體的描述。
預期的測試結果應該作爲測試用例規格說明的一部分，同時包含輸出、數據和狀態的變化，以及其他的測試結果。假如沒有明確預期結果，則一個看似合理卻錯誤的結果可能被視爲正確的結果。理想情況下預期結果應該在測試執行之前明確定義。
測試實現階段
在測試實現階段，測試用例的開發、實現、確定優先級和組織都應該包含在測試規程規格說明中(IEEE STD 829-1998)。測試規程(或者手工測試腳本)描述了測試用例執行的順序。如果使用測試執行工具進行測試，這種測試的動作順序將在測試腳本中描述(自動化的測試規程)。
不同的測試規程和自動化測試腳本要體現在測試執行進度表中，該計劃定義了不同測試規程和可能的自動化測試腳本的執行順序、執行的時間和執行者。測試執行進度表同時考慮了其他的因素，比如迴歸測試、測試優先級以及技術和邏輯的依賴等。

測試設計技術的種類(4.2)

基於規格說明/黑盒(4.3)
基於規格說明的測試技術具有以下共同特點:
 使用正式或非正式的模型來描述需要解決的問題、軟件或其組件等;  根據這些模型，可以系統地導出測試用例。
- 等價類
  有效等價類
  無效等價類
- 邊界值
  臨界值
  剛好超出臨界值
  剛好小於臨界值
- 決策表
  因果圖與判定表：
  複雜條件構成因果圖
  根據因果圖生成判定表
- 狀態轉換
  根據軟件的狀態、狀態間的轉換、觸發狀態變化(轉換)的輸入或事件以及從狀態轉換導致的可能的行動來進行測試。
- 用例
  描述了參與者(用戶或系統)之間的相互作用，並從這些交互產生一個從系統用戶或客戶的角度所期望和能觀察到的結果。
  
  用例非常有助於設計用戶/客戶參與的驗收測試; 也可以幫助發現由於不同組件之間的相互作用和相互影響而產生的集成缺陷，這是在單個的組件測試中是無法發現的。
  
  備註：用例指的是用戶如何使用軟件，即“Use Case”。
基於結構/白盒(4.4)
基於結構的技術的共同特點:
 根據軟件的結構信息設計測試用例，比如軟件代碼和詳細設計信息;
 可以通過已有的測試用例測量軟件的測試覆蓋率，並通過系統化的導出設計用例來提高覆蓋率。
- 語句覆蓋
  在組件測試中，語句覆蓋是指評價一個測試用例套件中已經執行的可執行語句的百分比。
- 判定覆蓋
  判定覆蓋，和分支測試相關，是指評價在一個測試用例套中已經執行的判定(例如 if 語句的 true 和 false 選項)輸出的百分比。
  
  備註：“判定覆蓋”比“語句覆蓋”更全面，100%的“判定覆蓋”可以保證 100%的“語句覆蓋”，反之則不行。
基於經驗(4.5)
基於經驗的方法具有以下共同特點:
 測試用例根據參與人員的經驗和知識來編寫;
 測試人員、開發人員、用戶和其他的利益相關者對軟件、軟件使用和環境等方面所掌握的知識作爲信息來源之一;
 對可能存在的缺陷及其分佈情況的瞭解作爲另一個信息來源。

注意：這種技術依據測試員的經驗，所以產生的效果會有極大的不同。
- 探索性測試
  探索性測試是指依據包含測試目標的測試章程來同時進行測試設計、測試執行、測試記錄和學習，並且是在規定時間內進行的。
  這種方法在規格說明較少或不完備且時間壓力大的情況下使用更有幫助，或者作爲對其他更爲正式的測試的增加或補充。
  它可以作爲測試過程中的檢查，以有助於確保能發現最爲嚴重的缺陷。
- 錯誤推測法
  錯誤推測法的一個結構化方法是列舉可能的錯誤，並設計測試來攻擊這些錯誤，這種系統的方法稱之爲缺陷攻擊。

測試管理(5)

測試組織(5.1)

測試組織的獨立性
獨立測試的優點:
 獨立的測試員是公正的，可以發現一些其他不同的缺陷。;
 一個獨立的測試員可以驗證在系統規格說明和實現階段所做的一些假設。
獨立測試的缺點:
 與開發小組脫離(如果完全獨立);
 開發人員可能喪失對軟件質量的責任感;
 獨立的測試員可能被視爲瓶頸或者成爲延時發佈而被責備的對象。
測試組織模式
- 基於技能的組織模式
- 基於項目的組織模式
測試角色及職責
- 測試組長
  測試組長可能的主要任務包括:
   與項目經理以及其他人共同協調測試策略和測試計劃;
   制定或評審項目的測試策略和組織的測試方針;
   將測試的安排合併到其他項目活動中，比如集成計劃;
   制定測試計劃(要考慮背景，瞭解測試目標和風險)，包括選擇測試方法，估算測試的時間、工作量和成本，獲取資源，定義測試級別、測試周期並規劃事件管理;
   啓動測試規格說明、測試準備、測試實施和測試執行，監督測試結果並檢查出口準則;
   根據測試結果和測試過程(有時記錄在狀態報告中)調整測試計劃，並採取任何必要措施對存在的問題進行補救;
   對測試件進行配置管理，保證測試件的可追溯性;
   引入合適的度量項以測量測試進度，評估測試和產品的質量;
   決定什麼應該自動化，自動化的程度，以及如何實現;
   選擇測試工具支持測試，併爲測試員組織測試工具使用的培訓;
   決定關於測試環境實施的問題;
   根據在測試過程中收集的信息編寫測試總結報告。
- 測試員
  測試員可能的主要任務包括:
   評審和參與測試計劃的制定;
   分析、評審和評估用戶需求、規格說明書及模型的可測試性;
   創建測試規格說明;
   建立測試環境(通常需要系統管理員，網絡管理員協同完成);
   準備和獲取測試數據;
   進行所有級別的測試，執行並記錄測試日誌，評估測試結果，記錄和預期結果之間的偏差。
   根據需要使用測試管理工具和測試監控工具;
   實施自動化測試(可能需要開發人員或測試自動化專家的支持);
   在可行的情況下，測量組件和系統的性能;
   對他人的測試進行評審。

測試計劃和估算(5.2)

測試計劃(5.2.1)
1. 測試計劃受到很多因素的影響:組織的測試方針、測試範圍、測試目標、風險、約束、關鍵程度、可測試性和資源的可用性等。
2. 隨着項目和測試計劃的不斷推進，將有更多的信息和具體細節包含在計劃中。
3. 測試計劃是個持續的活動，需要在整個生命週期過程和活動中進行。
4. 從測試中得到的反饋信息可以識別變化的風險，從而對計劃作相應的調整。
測試計劃活動(5.2.2)
對整個系統或部分系統可能的測試計劃活動包括:
 確定測試的範圍和風險，明確測試的目標;
 決定總體測試方法，包括測試級別、入口和出口準則的界定;
 把測試活動整合和協調到整個軟件生命週期活動中去(採購、供應、開發和運維);
 決定測試什麼?測試由什麼角色來執行?如何進行測試?如何評估測試結果?
 爲測試分析和設計活動安排時間進度;
 爲測試實現、執行和評估安排時間進度;
 爲已定義的不同測試活動分配資源;
 定義測試文檔的數量、詳細程度、結構和模板;
 爲監控測試準備和執行、缺陷解決和風險問題選擇度量項;
 確定測試規程的詳細程度，以提供足夠的信息支持可複用的測試準備和執行。
入口準則(5.2.3)
入口準則定義了什麼時候可以開始測試，如某個測試級別的開始，或什麼時候一組測試準備就緒可以執行。

入口準則主要包含:
 測試環境已經準備就緒並可用;
 測試工具在測試環境中已經準備就緒;
 可測的代碼可用;
 測試數據可用。
出口準則(5.2.4)
測試出口準則(exit criteria)的目的是:定義什麼時候可以停止測試，比如某個測試級別的結束，或者當測試達到了規定的目標。

出口準則主要包含:
 完整性測量，比如代碼、功能或風險的覆蓋率;
 對缺陷密度或可靠性度量的估算;
 成本;
 遺留風險，例如沒有被修改的缺陷或在某些部分測試覆蓋不足;  進度表，例如基於交付到市場的時間。
測試估算(5.2.5)
- 測試工作量
  測試工作量的內容：
  1. 測試用例設計；
  2. 測試環境設置；
  3. 測試用例執行；
  4. 測試缺陷報告；
  一旦估算了測試工作量，就可以識別資源和制定時間進度表。
- 決策因素
  測試的工作量可能取決於多種因素，包括:
   產品的特點:規格說明和用於測試模型的其它信息(即測試依據)的質量，產品的規模，問題域的複雜度，可靠性、安全性的需求和文檔的需求;
   開發過程的特點:組織的穩定性、使用的工具、測試過程、參與者的技能水平和時間緊迫程度等;
   測試的輸出:缺陷的數量和需要返工的工作量。
- 估算方法
  兩種估算測試工作量的方法:
   基於度量的方法:根據以前或相似項目的度量值來進行測試工作量的估算，或者根據典型的數據來進行估算;
   基於專家的方法:由任務的責任人或專家來進行測試任務工作量的估算。
測試方法(5.2.6)
- 測試策略與方法
  測試方法是測試策略的具體實現。
  
  僅做了解：
  測試策略（Testing Strategy）通常是描述如何測試軟件的總體方法和目標。它是關於如何測試系統的正式描述，需要確定針對所有測試級別的測試策略。包括確定測試環境、階段、類型、方法和技術。描述測試包含多少個測試級別（如組件測試、集成測試、系統測試等）以及每個階段內進行的測試種類（如功能測試、性能測試、壓力測試等）。
  【從2010版大綱開始：爲保持測試方法(test approach)與術語表中的定義一致。術語“測試策略(test strategy)” 將不再作爲術語要求了。】
- 典型的測試方法
  典型的測試方法包括:
   分析的方法，比如基於風險的測試，直接針對風險最高的部分進行測試;
   基於模型的方法，比如隨機測試利用失效率(如:可靠性增長模型)或使用率(如:運行概況)的統計信息;
   系統的方法，比如基於失效的方法(包括錯誤推測和故障攻擊)，基於檢查表的方法和基於質量特徵的方法; 基於與過程或符合標準的方法，比如在行業標準中規定的方法或各類敏捷的方法;
   動態和啓發式的方法，類似於探索性測試，測試很大程度上依賴於事件而非提前計劃，而且執行和評估幾乎是同時進行的;
   諮詢式的方法，比如測試覆蓋率主要是根據測試小組以外的業務領域和/或技術領域專家的建議和指導來推動的;
   可重用的方法，比如重用已有的測試材料，廣泛的功能迴歸測試的自動化，標準測試套件等。
  
  可以結合使用不同的測試方法，比如基於風險的動態方法。

測試過程的監控(5.3)

測試監控的目的
測試監控的目的是：
1. 提供關於測試活動的反饋信息，使測試活動保持可視性。監控的信息可以通過手工或自動的方式進行收集，同時可以用來衡量出口準則，比如測試覆蓋率。
2. 也可以用度量數據對照原計劃的時間進度和預算來評估測試的進度。
常用的測試度量項目
常用的測試度量項有:
 測試用例準備工作完成的百分比(或按計劃已編寫的測試用例的百分比);
 測試環境準備工作完成的百分比;
 測試用例執行情況(例如:執行/沒有執行的測試用例數，通過/失敗的測試用例數);
 缺陷信息(例如:缺陷密度、發現並修改的缺陷、失效率、重新測試的結果);
 需求、風險或代碼的測試覆蓋率;
 測試員對產品的主觀信心;
 測試里程碑的日期;
 測試成本，包括尋找下一個缺陷或執行下一輪測試所需成本與收益的比較。
測試報告
測試報告是對測試工作和活動等相關信息的總結，主要包括:
 在測試周期內發生了什麼?比如達到測試出口準則的日期;
 通過分析相關信息和度量可以對下一步的活動提供建議和做出決策，比如對遺留缺陷的評估、繼續進行測試的經濟效益、未解決的風險以及被測試軟件的置信度等。

測試總結報告的大綱可以參考“軟件測試文檔標準”(IEEE Std 829-1998)。

需要在測試級別的過程中和完成時收集度量信息，來評估:
 該測試級別的測試目標實現的充分性;
 採用的測試方法的適當性;
 針對測試目標的測試的有效性。

注意：
“軟件測試文檔標準”(IEEE Std 829-1998)的內容在考題中會有體現，建議瞭解。
測試控制
測試控制描述了根據收集和報告的測試信息和度量而採取的指導或糾正措施。措施可能包括任何測試活動，也可能影響其它軟件生命週期中的活動或任務。

測試控制措施的例子:
 基於測試監控信息來做決策;
 如果一個已識別的風險發生(如軟件交付延期)，重新確定測試優先級;
 根據測試環境可用性，改變測試的時間進度表;
 設定入口準則:規定修改後的缺陷必須經過開發人員再測試(確認測試)後才能將它們集成到版本中去。

配置管理(5.4)

配置管理的目的是在整個項目和產品的生命週期內，建立和維護軟件或系統產品(組件、數據和文檔)的完整性。

對測試而言，採用配置管理可以確保:
 測試件的所有相關項都已經被識別，版本受控，相互之間有關聯以及和開發項(測試對象)之間有關聯的變更可跟蹤，從而保證可追溯性;
 在測試文檔中，所有被標識的文檔和軟件項能被清晰明確的引用。

對於測試員來說，配置管理可以幫助他們唯一地標識(並且複製)測試項、測試文檔、測試用例和測試用具。

在測試計劃階段，應該選擇配置管理的規程和基礎設施(工具)，將其文檔化並予以實施。

風險和測試(5.5)

項目風險(5.5.1)
項目風險是圍繞項目按目標交付的能力的一系列風險，比如:
 組織因素:
 技能、培訓和人員的不足;
 個人問題;
 政策因素，比如:
 與測試員進行需求和測試結果溝通方面存在的問題;
 測試和評審中發現的信息未能得到進一步跟蹤(如未改進開發和測試實踐);
 對測試的態度或預期不合理(如:沒有意識到在測試中發現缺陷的價值)。
 技術因素:
 不能定義正確的需求;
 給定現有限制的情況下，沒能滿足需求的程度;
 測試環境沒有及時準備好;
 數據轉換、遷移計劃，開發和測試數據轉換/遷移工具造成的延遲;
 低質量的設計、編碼、配置數據、測試數據和測試。
 供應商因素:
 第三方存在的問題;
 合同方面的問題。

在分析、管理和緩解這些風險的時候，測試經理需要遵循完善的項目管理原則。“軟件測試文檔標準”(IEEE Std 829-1998)中指出，測試計劃需要陳述風險和應急措施。
產品風險(5.5.2)
在軟件或系統中的潛在失效部分(即將來可能發生不利事件或危險)稱之爲產品風險，因爲它們對產品質量而言是一個風險，包括:
 故障頻發的軟件交付使用;
 軟件/硬件對個人或公司造成潛在損害的可能性;
 劣質的軟件特性(比如功能性、可靠性、易用性和性能等);
 低劣的數據完整性和質量(例如:數據遷移問題、數據轉換問題、數據傳輸問題、違反數據標準問題);
 軟件沒有實現既定的功能。
基於風險的測試方法
風險通常可以用來決定從什麼地方開始測試，什麼地方需要更多的測試。測試可以用來降低風險或可以減少負面事件的影響。

在項目初期階段，使用基於風險的方法進行測試，有利於降低產品風險的級別。

在基於風險的測試方法中，識別出的風險可以用於:
 決定採用的測試技術;
 決定要進行測試的範圍;
 確定測試的優先級，嘗試儘早的發現嚴重缺陷;
 決定是否可以通過一些非測試的活動來降低風險(比如對缺乏經驗的設計者進行相應的培訓)。

風險管理活動提供了一些系統化的方法:
 評估(並定期重新評估)可能出現的錯誤(風險);
 決定哪些風險是重要的需要處理的;
 處理風險的具體措施。

事件管理(5.6)

事件報告的主要目標
事件報告的主要目標如下:
 爲開發人員和其他人員提供問題反饋，在需要的時候可以進行識別、隔離和糾正;
 爲測試組長提供一種有效跟蹤被測系統質量和測試進度的方法;
 爲測試過程改進提供資料。
事件報告的具體內容
事件報告的具體內容主要包括:
 提交事件的時間，提交的組織和作者;
 預期和實際的結果;
 識別測試項(配置項)和環境;
 發現事件時軟件或系統所處的生命週期階段;
 爲了能確保重現和解決事件需要描述事件(包括日誌、數據庫備份或截屏);
 對利益相關者的影響範圍和程度;
 對系統影響的嚴重程度;
 修復的緊迫性/優先級;
 事件狀態(例如:打開的、延期的、重複的、待修復的、修復後待重測的或關閉的等);
 結論、建議和批准;
 全局的影響，比如事件引起的變更可能會對系統的其他部分產生影響;
 變更歷史記錄，比如針對事件的隔離、修改和已修改的確認，項目組成員所採取的行動順序;
 參考，包括髮現問題所用的測試用例規格說明的標識號。

事件報告的大綱也可以參考“軟件測試文檔標準”(IEEE Std 829-1998)。

軟件測試工具(6)

測試工具的類型(6.1)

測試工具大體上可分爲三類：

功能測試工具
性能測試工具
測試管理工具

測試管理(6.1.3)
- 測試管理工具
- 需求管理工具
- 事件管理工具
- 配置管理工具
靜態測試(6.1.4)
- 評審工具
- 靜態分析工具
- 建模工具
測試規格說明(6.1.5)
- 測試設計工具
- 測試數據準備工具
測試執行和記錄(6.1.6)
- 測試執行工具
- 測試用具/單元測試框架工具
- 測試比較器
- 覆蓋率測量工具
- 安全性測試工具
性能和監控(6.1.7)
- 動態分析工具
- 性能/負載/壓力測試工具
- 監控工具
特定應用領域(6.1.8)
- 數據質量評估

有效使用工具(6.2)

潛在的收益與風險(6.2.1)
- 潛在收益
  使用工具的潛在收益包括:
   減少重複性的工作(比如，執行迴歸測試，重新輸入相同測試數據，代碼規則檢查);
   更好的一致性和可重複性(比如，用工具按照相同的順序和頻率執行測試，從需求生成測試);
   客觀的評估(比如，靜態測量、覆蓋率);
   容易得到測試和測試的相關信息(比如，關於測試進展的統計和圖表，事件發生率和性能)。
- 潛在風險
  使用工具存在的風險:
   對工具抱有不切實際的期望(包括功能性和易用性);
   低估首次引入工具所需的時間、成本和工作量(包括培訓和額外的專業知識);
   低估從工具中獲得較大和持續性收益需要付出的時間和工作量(包括使用工具的方式需要更改測試過程，並不斷改進);
   低估了對工具生成的結果進行維護所需的工作量;
   對工具過分依賴(替代測試設計或者對一些更適合手工測試的方面卻使用自動測試工具);
   忽視了在工具中對測試對象的版本控制;
   忽視了多個重要工具之間的關聯和互操作性，例如:需求管理工具、版本控制工具、事件管理工具、缺陷跟蹤工具和其他從不同供應商獲得的工具;
   工具供應商破產、停止維護工具或將工具賣給其他供應商的風險;
   供應商對工具的支持、升級和缺陷修復反應不力;
   開源/免費工具項目中止的風險;
   其他不可預知的風險，例如不能支持新平臺。
工具類型的特殊考慮(6.2.2)
- 測試執行工具
  注意：
  1. 所有的測試方法都需要腳本語言方面的技術專家(或測試員或測試自動化專家)。
  2. 無論使用什麼腳本技術，都需要儲存每次測試的預期結果，便於後續比較。
  - 自動化測試
    正確認識自動化測試：
    1. 爲了獲得可觀收益，經常需要爲這類工具投入很多工作量。
    2. 通過記錄測試員手動操作的捕捉過程往往開始看起來似乎很吸引人，但是這種方法不適合大量的自動化測試。捕獲的腳本只是用特定數據和動作來線性表示每個腳本的一部分。當發生意外事件時，這類腳本是不穩定的。
  - 數據驅動技術
    1. 數據驅動的方法是將測試輸入(數據)與測試用例分離，並將測試輸入存放在一個電子表格中，這樣可以使用不同的數據進行相同的測試。
    2. 不熟悉腳本語言的測試員可以從一個表格內輸入測試數據並執行事先定義好的測試腳本。
    注意：此方法需要腳本語言方面的技術專家。
  - 關鍵字驅動技術
    1. 在關鍵字驅動的測試方法中，電子表格含有描述系統要採取的行爲的關鍵字(也稱爲行爲字)和測試數據。
    2. 測試員(即使不熟悉腳本語言)也能針對被測應用，使用這些關鍵字來定義測試。
    注意：此方法需要腳本語言方面的技術專家。
- 靜態分析工具
  警告信息不阻礙代碼轉換成可執行程序，但理想情況是應予以處理，以便將來更容易進行代碼的維護。
  在開始就有計劃的逐步使用分析工具來過濾一些警告信息是一種有效的方法。
- 測試管理工具
  測試管理工具需要有與其他工具和表格有接口，以便產生符合組織所需格式的有用信息。

組織內引入工具(6.3)

需要考慮的關鍵點
爲組織選擇工具所需要考慮的關鍵點有:
 評估組織的成熟度、分析引入工具的優點和缺點和認識引入工具能改善測試過程的可能性;
 根據清晰的需求和客觀的準則進行評估;
 概念驗證，在評估階段要確認在現有的情況下使用工具對被測軟件是否有足夠效果，或爲了有效使用工具，目前的基礎設施需要如何改變;
 評估供應商(包括培訓、提供的支持及其他商業方面考量)，如果是非商業性工具要評估提供服務的供應商;
 爲了在工具使用方面得到更好的指導和培訓，需要先收集內部需求;
 評估培訓需求時需要考慮現有測試團隊的自動化測試技能;
 根據實際的情況估算成本-收益比。
試點項目的目的
將選擇的工具引入組織要從一個試點項目開始，試點項目有以下目的:
 對工具有更多的認識;
 評估工具與現有的過程以及實踐的配合程度，確定哪些方面需要作修改;
 定義一套標準的方法來使用、管理、儲存和維護工具及測試資產(比如，定義文件和測試的命名規則、創建庫和定義模塊化測試套件);
 評估在付出合理的成本後能否得到預期的收益。
成功部署的因素
在組織內成功部署工具的因素包括:
 逐步在組織的其餘部分將工具推廣到測試中;
 調整並改進過程來配合工具的使用;
 爲新使用者提供培訓和指導;
 定義使用指南;
 實施一種在實際運用中收集工具使用情況的方法;
 監控工具的使用和收益情況;
 爲測試團隊使用工具提供支持;
 在所有團隊內收集經驗和教訓。

ISTQB初級認證-知識點及腦圖總結

前言