2023年12月12日發(作者：親愛的同學)
?ISTQB軟件測試人員認證
高級大綱
測試經理
2012 版
國際軟件測試認證委員會
中文版的翻譯編輯和出版統一由ISTQB?授權的CSTQB?負責
測試人員認證
高級大綱 -- 測試經理
英文版權聲明
如果此文檔的來源是公認的，則可以拷貝此完整的文檔或部分。
版權標志 ? International Software Testing Qualifications Board（以下稱為ISTQB）
高級測試經理工作組：Rex Black（主席）、Judy McKay（副主席）、Graham Bath、Debra
Friedenberg、Kenji Onishi、Mike Smith、Geoff Thompson、Tsuyoshi Yumoto; 2010-2012。
?
中文版權聲明
未經許可，不得復制或抄錄本文檔內容。
?版權標志 ?中國軟件測試認證委員會（以下簡稱“CSTQB”）.
2012 版
? International Software Testing Qualifications Board
第 2 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
版本歷史
版本
ISEB v1.1
?ISTQB 1.2E
V2007
D100626
D101227
D2011
Alpha 2012
Beta 2012
Beta 2012
Beta 2012
Beta 2012
RC 2012
GA 2012
中文發布版
日期
2001年9月4日
2003年9月
2007年10月12日
2010年6月26日
說明
ISEB 從業人員大綱
?ISTQB 高級大綱（EOQ-SG）
認證高級測試工程師大綱2007版
納入2009年同意的修改，把每章的內容分至每個單獨的模塊。
2010年12月27日 接受不影響語句含義的格式變化和修正。
2011年10月31日 拆分大綱，修改學習目標和相應的文字。增加BO。
2012年2月09日 納入了所有成員委員會對10月發布版本的意見。
2012年3月26日 納入了所有成員委員會對Alpha版本的意見。
2012年4月7日 Beta 版提交GA
2012年6月8日 正文編輯版發布給各成員委員會。
2012年6月27日 加入EWG 和術語意見
2012年8月15日 候選發布版 – 最終包括成員委員會的編輯
2012年10月19日 最終編輯和整理版提交成員大會（GA）
?
2013年6月30日 最終編輯和整理提交CSTQB2012 版
? International Software Testing Qualifications Board
第 3 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
目錄
版本歷史 .................................................................................................................................................. 3
目錄 .......................................................................................................................................................... 4
0. 課程大綱引言 ...................................................................................................................................... 7
0.1 目的 ............................................................................................................................................... 7
0.2概述 ............................................................................................................................................... 7
0.3預期學習目標 ................................................................................................................................. 7
1.
測試過程 –– 420 分鐘. .................................................................................................................... 8
1.1 簡介 ............................................................................................................................................... 9
1.2 測試計劃、監督和控制 .................................................................................................................. 9
1.2.1測試計劃 ................................................................................................................................. 9
1.2.2 測試監督和控制 .................................................................................................................... 10
1.3 測試分析 ...................................................................................................................................... 11
1.4 測試設計 ...................................................................................................................................... 12
1.5 測試實施 ...................................................................................................................................... 12
1.6 測試執行 ...................................................................................................................................... 13
1.7 評估出口準則和報告 .................................................................................................................... 13
1.8 測試結束活動 ............................................................................................................................... 14
2. 測試管理 – 750 分鐘. ......................................................................................................................... 15
2.1 簡介 ............................................................................................................................................. 17
2.2 一定條件下的測試管理 ................................................................................................................ 17
2.2.1 了解測試干系人 .................................................................................................................... 17
2.2.2其它的軟件開發生命周期活動及工作產品 ............................................................................ 18
2.2.3測試活動和其它生命周期活動的整合 ................................................................................... 18
2.2.4 管理非功能測試 .................................................................................................................... 20
2.2.5管理基于經驗的測試 ............................................................................................................. 20
2.3基于風險的測試和其它測試優先級設定和工作量分配的方法 ...................................................... 21
2.3.1基于風險的測試 .................................................................................................................... 21
2.3.2基于風險的測試技術 ............................................................................................................. 25
2.3.3選擇其它測試技術 ................................................................................................................ 27
2.3.4測試過程中的測試優先級設定和工作量分配 ........................................................................ 28
2.4測試文檔和其它工作產品 ............................................................................................................. 28
2.4.1測試方針 ............................................................................................................................... 29
2.4.2測試策略 ............................................................................................................................... 29
2.4.3主測試計劃 ........................................................................................................................... 31
2.4.4級別測試計劃........................................................................................................................ 31
2.4.5項目風險管理........................................................................................................................ 32
2.4.6其它的測試工作產品 ............................................................................................................. 32
2.5測試估算 ...................................................................................................................................... 33
2.6定義和使用測試度量 .................................................................................................................... 34
2.7測試的商業價值 ........................................................................................................................... 38
2.8分布式測試、外包測試以及內包測試 ........................................................................................... 39
2.9 管理行業標準的使用 .................................................................................................................... 39
3. 評審 – 180 分鐘. ................................................................................................................................ 41
2012 版
? International Software Testing Qualifications Board
第 4 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
3.1 簡介 ............................................................................................................................................. 42
3.2管理評審和審計 ........................................................................................................................... 43
3.3對評審進行管理 ........................................................................................................................... 43
3.4評審度量 ...................................................................................................................................... 45
3.5管理正式評審 ............................................................................................................................... 45
4. 缺陷管理 – 150 分鐘. ......................................................................................................................... 47
4.1 簡介 ............................................................................................................................................. 48
4.2缺陷生命周期和軟件開發生命周期 .............................................................................................. 48
4.2.1缺陷工作流程和狀態 ............................................................................................................. 48
4.2.2管理無效和重復缺陷 ............................................................................................................. 49
4.2.3跨職能缺陷管理 .................................................................................................................... 49
4.3缺陷報告信息 ............................................................................................................................... 49
4.4使用缺陷報告信息評估過程能力 .................................................................................................. 51
5. 改進測試過程 – 135 分鐘. .................................................................................................................. 52
5.1 簡介 ............................................................................................................................................. 53
5.2測試改進過程 ............................................................................................................................... 53
5.2.1過程改進的介紹 .................................................................................................................... 53
5.2.2過程改進的類型 .................................................................................................................... 53
5.3改進測試過程 ............................................................................................................................... 54
5.4使用TMMi改進測試過程 ............................................................................................................. 55
5.5使用TPI Next改進測試過程 ........................................................................................................ 55
5.6使用CTP改進測試過程 ............................................................................................................... 56
5.7 使用 STEP改進測試過程 ............................................................................................................ 56
6. 測試工具及自動化 – 135 分鐘 ........................................................................................................... 57
6.1 簡介 ............................................................................................................................................. 58
6.2選擇工具 ...................................................................................................................................... 58
6.2.1開源工具 ............................................................................................................................... 58
6.2.2定制工具 ............................................................................................................................... 58
6.2.3投資回報（ROI） ................................................................................................................. 59
6.2.4選擇流程 ............................................................................................................................... 60
6.3工具生命周期 ............................................................................................................................... 61
6.4工具度量 ...................................................................................................................................... 62
7. 人員技能 – 團隊構成 – 210 分鐘. ...................................................................................................... 63
7.1 簡介 ............................................................................................................................................. 64
7.2個人技能 ...................................................................................................................................... 64
7.3測試團隊動力 ............................................................................................................................... 65
7.4使測試適合組織 ........................................................................................................................... 66
7.5激勵 ............................................................................................................................................. 67
7.6溝通 ............................................................................................................................................. 68
8. 參考資料 ............................................................................................................................................ 69
8.1 標準 ............................................................................................................................................. 69
?8.2 ISTQB 文檔 ................................................................................................................................ 69
8.3 商標 ............................................................................................................................................. 70
8.4 書籍 ............................................................................................................................................. 70
8.5 其它引用 ...................................................................................................................................... 71
9. 索引 .................................................................................................................................................... 72
2012 版
? International Software Testing Qualifications Board
第 5 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
致謝
本文件由國際軟件測試認證委員會負責高級測試經理模塊的高級子工作組的核心團隊于2010至2012年間編制,他們包括: Rex Black （主席）、Judy McKay（副主席）、Graham Bath、Debra
Friedenberg、Bernard Homès、Paul Jorgenn、Kenji Onishi、Mike Smith、Geoff Thompson、
Tsuyoshi Yumoto。
核心團隊向評審團隊和所有測試委員會成員提出的建議和幫助表示感謝。
直至高級課程大綱截稿時，其工作組成員如下（按姓氏字母排序）:
Graham Bath、Rex Black、Maria Clara Choucair、Debra Friedenberg、Bernard Homès（副主席）、Paul Jorgenn、Judy McKay、Jamie Mitchell、Thomas Mueller、Klaus Oln、Kenji Onishi、Meile
Posthuma、Eric Riou du Cosquer、Jan Sabak、Hans Schaefer、Mike Smith （主席）、Geoff
Thompson、Erik van Veenendaal、Tsuyoshi Yumoto。
下列成員參與了評審、評論和大綱表決工作:
Chris van Bael、Graham Bath、Kimmo Hakala、Rob Hendriks、Marcel Kwakernaak、Rik Marlis、Don Mills、Gary Mogyorodi、Thomas Mueller、Ingvar Nordstrom、Katja Piroué、Miele Posthuma、Nathalie Rooboom de Vries、Geoff Thompson、Jamil Wahbeh 和 Hans Weiberg
?本文由 ISTQB大會于2012年10月19日正式發布。
參加本大綱前期翻譯的有（按姓氏拼音排序）：李雪、凌勁鋒、王華、文燕、熊文杰、鄭丹丹等。
?參加本大綱最終翻譯的CSTQB專家有（按姓氏拼音排序）：柴阿峰、陳耿、李碩、王軼、徐文葉、周震漪（組長）等。
2012 版
? International Software Testing Qualifications Board
第 6 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
0. 課程大綱引言
0.1 目的
本大綱根據國際軟件測試認證委員會對高級大綱（測試經理）的要求進行編寫，ISTQB提供此大綱的主要目的：
1. 國家認證委員會需將大綱翻譯成當地語言并分發給培訓機構，并可根據特定語言對大綱進行適度潤色、修改，以保證語句通順可讀。
2. 考試委員會可根據特定語言，按照高級大綱（測試經理）的學習目標設計考題。
3. 培訓機構需根據高級大綱（測試經理）準備課程并選擇最適宜的教學方法。
4. 需要認證的考生，根據高級大綱準備考試（作為培訓課程的一部分或獨立使用）。
5. 國際軟件和系統工程領域，應以此大綱為基礎，推進軟件和系統測試蓬勃發展。并以此為基礎著書和出文章。
?國際軟件測試認證委員會ISTQB允許其它組織、機構在獲得書面授權后使用此大綱內容。
?0.2概述
高級大綱由以下3個單獨的部分組成：
? 測試經理
? 測試分析師
? 技術測試分析師
?高級大綱的概述文檔 [ISTQB_AL_OVIEW] 包括以下信息：
? 每個大綱的學習成果
? 每個大綱摘要
? 各大綱之間的關系
? 認知程度描述 （K級別）
? 附錄
0.3預期學習目標
預期學習目標是學習成果的前提保證，同時也被作為高級測試經理認證考試題目編寫的基礎。被標記為K1級的知識點，需要考生牢記、回憶、識別和認知。K2，K3，K4級的知識點會在之后相關章節出現。
2012 版
? International Software Testing Qualifications Board
第 7 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
1. 測試過程 –– 420 分鐘.
關鍵詞
出口準則（exit criteria）, 測試用例（test ca）, 測試結束（test closure）, 測試條件（test
condition）, 測試控制（test control）, 測試設計（test design）, 測試執行（test execution）, 測試實施（test implementation）, 測試日志（test log）, 測試計劃（test planning）, 測試規程（test
procedure）, 測試腳本（test script）, 測試總結報告（test summary report）
測試過程的學習目標
1.2 測試計劃、監督和控制
TM-1.2.1
TM-1.3.1
TM-1.3.2
TM-1.4.1
TM-1.5.1
(K4) 為了計劃測試活動和工作產品來實現測試目標，必須對一個系統的測試需求進行分析
1.3 測試分析
(K3) 使用可追溯性來檢查與測試目標、測試策略和測試計劃相關的已定義測試條件的完整性和一致性
(K2) 解釋可能影響所規定測試條件詳細程度的因素，以及詳細規定測試條件的優點和缺點
1.4 測試設計
(K3) 使用可追溯性來檢查與已定義測試條件相關的所設計測試用例的完整性和一致性
1.5 Test Implementation
(K3) 使用風險、優先級、測試環境和數據依賴以及限制條件來制定測試執行的進度，該進度針對測試目標、測試策略和測試計劃是完整和一致的
1.6 Test Execution
TM-1.6.1
TM-1.7.1
(K3) 使用可追溯性來監督測試進展與測試目標、測試策略和測試計劃的一致性和完整性
1.7 Evaluating Exit Criteria and Reporting
(K2) 解釋在測試過程中準確和及時信息收集的重要性，以便支持準確的報告和對照出口準則進行評價
1.8 Test Closure Activities
TM-1.8.1
TM-1.8.2
(K2) 總結四組測試結束活動
(K3) 實現項目回顧以評價過程和發現改進領域
2012 版
? International Software Testing Qualifications Board
第 8 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
1.1 簡介
在ISTQB? 軟件測試基礎級認證大綱中已描述了基本的測試過程包括以下活動：
? 計劃和控制
? 分析和設計
? 實施和執行
? 評估出口準則和報告
? 測試結束活動
基礎級大綱認同這些活動雖然有邏輯順序，但過程中的某些活動可能重疊，或并行進行。
對于高級大綱，為了讓該過程更為精練和優化、更適合軟件開發生命周期以及促進有效的監督和控制，某些活動被視為獨立的。所考慮的活動如下：
? 計劃、監督和控制
? 分析
? 設計
? 實施
? 執行
? 評估出口準則和報告
? 測試結束活動
1.2 測試計劃、監督和控制
本節將著重討論測試計劃、監督和控制過程。如基礎級大綱所述，這些活動是測試管理的職責。
1.2.1測試計劃
每個測試級別的測試計劃在這一級別的測試過程的初始階段開始，并貫穿整個項目，直至這一級別的測試結束活動完成。計劃包括識別滿足測試策略中定義的任務和目標所需的活動和資源。測試計劃也包括識別、收集和跟蹤度量項的方法，這些度量項將用于指導項目、確定與計劃的符合程度以及評價達成目標的情況。通過在計劃階段確定有用的度量項，可以有效的幫助選擇工具、安排培訓和建立文件指南。
為測試項目所選擇的一個或多個策略有助于確定在計劃階段應進行的任務。例如當采用基于風險的測試策略（見第2章）時，使用風險分析可以指導測試計劃過程中的風險緩解活動、可以降低識別出的產品風險、可以幫助制定風險的應急措施。如果發現多個可能的并且嚴重的與安全性相關的潛在缺陷，則應該花費大量精力開發和執行安全性測試。同樣，如果發現設計規格說明有嚴重缺陷，則在測試計劃過程中可安排對設計規格說明進行額外的靜態測試（評審）。
也可以使用風險信息來確定不同測試活動的優先級。例如，當系統性能的風險較高，可在獲得已集成的代碼后盡快進行性能測試。類似的，如果采用了應對式測試策略，計劃創建測試章程和動態測試技術（如探索性測試）的工具是必需的。
測試經理在測試計劃階段應清楚的定義測試方法，包括要采用的測試級別、每個級別的目標以及每個級別使用的測試技術。例如針對某一航空系統進行基于風險的測試時，風險評估規定了需要哪個級別的代碼覆蓋，及應采用的測試技術。
2012 版
? International Software Testing Qualifications Board
第 9 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
在測試依據（例如，特殊需求或風險）、測試條件和覆蓋測試條件的測試之間可能存在復雜的關系，在這些工作產品之間也常常存在多對多的關聯。需要理解這些關聯，才能有效地進行測試計劃、監督和控制。對于工具的決策可能也依賴于對工作產品之間關聯的理解。
開發組和測試組生成的工作產品之間可能也存在關聯。例如，可追溯性矩陣需要跟蹤系統設計人員的詳細設計規格說明的內容、業務分析員的商務需求以及測試組定義的測試工作產品之間的關系。如果要設計和使用詳細測試用例，可在計劃階段規定以下要求：在開始生成測試用例前，開發組的詳細設計文檔要得到批準。在遵循敏捷的生命周期時，可以在測試開始之前采用非正式的信息傳遞來交流信息。
測試計劃中還可能列出在此計劃測試范圍內的具體軟件特征（適宜時基于風險分析），同時也確切地說明不在其測試范圍內的特征。根據形式化程度的高低以及文檔與項目的關聯度，每個在范圍內的特征都能關聯到一個對應的測試設計規格說明。
在這個階段，也可以要求測試經理與項目架構師共同來確定初始的測試環境規格說明、驗證所需資源的可獲取性，以確保要配置環境的人員有義務做這些工作，并且了解成本／交付時間表以及完成和交付測試環境所需的工作。
最后，應該識別所有的外部依賴關系和相關的服務級別協議（Service Level Agreements，SLA），如果需要，應與相關方進行初步接觸。所謂的依賴關系包括對外部組織的資源請求、與其它項目的依賴關系（如果是在一個程序內的工作）、與外部供應商或合作開發伙伴的依賴關系、與其它部署團隊以及數據庫管理員的依賴關系。
1.2.2 測試監督和控制
為了讓測試經理進行高效的測試控制，需要建立測試進度計劃和監督框架以便對照計劃跟蹤測試工作產品和資源。此框架應該包括將測試工作產品的狀態和活動與計劃和戰略目標相關聯所需的詳細的度量項和目標。
對于小型且不太復雜的項目，將測試工作產品和測試活動關聯到測試計劃和戰略目標相對容易，但總體而言，為了達到這些目標，必須對目標進行詳細定義，這包括為了滿足測試目的和測試依據覆蓋的措施和目標。
以可理解的并與項目和業務干系人相關的方式，將測試工作產品的狀態和活動與測試依據關聯起來是非常重要的。定義目標以及對測試條件和測試條件集進展的測量可以作為一種方法，通過測試條件實現其它測試工作產品與測試依據的關聯。正確配置的可追溯性，包括通過可追溯性報告狀態的能力，使得開發工作產品、測試依據和測試工作產品間存在的復雜關系更為透明和容易理解。
干系人要求監督的詳細度量項和目標有時與系統功能或規格說明不直接相關，特別是沒有正式文檔或只有少量文檔的時候。例如，即使是按系統功能定義了規格說明，業務干系人也許仍對按照運行業務周期建立的覆蓋更感興趣。業務干系人在項目早期的參與有助于確定這些度量項和目標，這不僅可在項目期間幫助提供更好的控制，還可在整個項目過程中幫助推動和影響測試活動。例如，干系人度量項和目標可影響測試設計的架構和測試實施工作產品和／或測試執行進度計劃，以便按照這些度量項準確地監督測試進展。
測試控制是一個持續的行為，包括實際進度與測試計劃之間的比較，在需要時實施糾正措施。測試控制引導測試工作來滿足任務、策略和目標，包括在需要時再次進行的測試計劃活動。對控制數據的相應反應依賴于詳細計劃的信息。
2012 版
? International Software Testing Qualifications Board
第 10 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
測試計劃文檔和測試控制活動的內容將在第2章中闡述。
1.3 測試分析
基礎級大綱中對測試分析和設計合在一起進行了描述，而高級大綱雖然認同它們可以作為并行、整合或互動的活動來實現，以推動測試設計工作產品的生成，但在高級大綱中還是分別作為獨立的活動來考慮。
測試分析是以測試條件的形式來確定要測試“什么”的活動。可通過分析測試依據、測試目標和產品風險來識別測試條件。它們（測試條件）可被視為詳細的度量項和成功目標（如作為出口準則的一部分），應該可追溯到測試依據和規定戰略目標，包括測試目標和其它項目或干系人成功的準則。測試條件應該隨著測試設計和其它測試工作產品的生成而可以向前追溯。
在某個給定測試級別的測試依據一旦建立就可盡快進行該級別的測試分析。可采用正式的測試技術和其它通用分析技術（如基于風險的分析策略和基于需求的分析策略）來識別測試條件。測試條件可以取決于測試級別、在進行分析時可獲得的信息以及所選擇的詳細程度（即文檔編寫的粒度）規定也可以不規定值或變量。
在決定描述測試條件的詳細程度時，有以下一些因素要考慮：
? 測試級別
? 測試依據的詳細程度和質量
? 系統／軟件復雜度
? 項目和產品風險
? 測試依據間的關系，哪些是要測試的，以及如何進行測試
? 所使用的軟件開發生命周期
? 采用的測試管理工具
? 對測試設計和其它測試工作產品進行說明和文檔化的程度
? 測試分析人員所掌握的技術和知識
? 測試過程和組織自身的成熟度（注意更高的成熟度可能要求的詳細程度更高，也可能接受低一些的詳細程度）
? 能提供咨詢的其它項目干系人的可用性
采用詳細說明的測試條件可能會造成測試條件的數目較多。例如，你可能有一個概要測試條件，測試一個電子商務應用的“退出登錄”。但在一份詳細測試條件文檔中，這個條件可能被分成多個測試條件，一個針對每一種受支持的付款方式，一個針對每個可能的目的地國家，等等。
詳細說明測試條件的優點包括：
? 有助于增加將其它測試工作產品（如測試用例）與測試依據和測試目標相聯系的靈活性，以便為測試經理提供更好和更詳細的監督和控制
? 如基礎級大綱所述，在一個較高級別的測試項目的早期，只要測試依據存在，并在系統架構和詳細設計可用之前對測試條件進行詳細說明有助于預防缺陷
? 以干系人能夠理解的方式向其解釋測試工作產品（測試用例和其它測試工作產品對于業務干系人而言常常毫無意義，簡單的度量數據，如已執行的測試用例數對于干系人的覆蓋要求而言也毫無意義）
? 有助于影響和指導其它測試活動，以及開發活動
? 能夠更有效覆蓋詳細的度量項和目標，使得測試設計、實施和執行以及相應工作產品得到優化
? 為在某一測試級別內更清晰的橫向可追溯性提供依據
2012 版
? International Software Testing Qualifications Board
第 11 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
詳細說明測試條件的缺點包括：
? 有可能花費大量時間
? 在變更的環境中可維護性變得困難
? 流于形式并需要整個團隊來定義和實施
在以下情況中詳細定義測試條件會特別有效：
? 為了適應開發生命周期、成本和／或時間限制或其它因素，采用少量測試設計文檔方法，例如檢查表
? 沒有或只有很少的正式需求或其它開發工作產品作為測試依據
? 項目的規模大、復雜且風險高，需要一定的監督和控制，而這樣的監督和控制不能簡單地通過將測試用例和開發工作產品相關聯來實現
當測試依據可以容易且直接與測試設計工作產品相關聯時，可用較少的細節來描述測試條件，如下列情況：
? 組件級別測試
? 較不復雜的項目，要測什么和如何測試之間存在簡單的層次關系
? 可借助于用例來定義測試的驗收測試
1.4 測試設計
測試設計是定義“如何”測試的活動。測試設計包括使用測試策略和／或測試計劃中確認的測試技術，通過逐步闡述已識別的測試條件或測試依據來生成測試用例。
根據測試監督、控制和追溯的方法，可以將測試用例直接（或通過測試條件間接）與測試依據和規定的目標相關聯。這些目標包括戰略目標、測試目標和其它項目或干系人的成功準則。
按照規定的方法進行測試設計，在識別出測試條件和有足夠信息后通過給定測試級別的測試設計來生成詳細或概要測試用例。對于更高級別的測試，測試設計更象是在早期測試分析之后的一個單獨活動，而對于低級別的測試，測試分析和設計很可能作為一個整合的活動來進行。
測試實施活動中某些任務也可能用迭代的方法與測試設計過程整合，以構建執行所需的測試，如測試數據的生成。事實上，這個方法在過程中可以優化測試條件的覆蓋，生成詳細或概要測試用例。
1.5 測試實施
測試實施是由測試分析師組織測試和設置測試優先次序的活動。在之前已經形成正式文檔的情況下，測試實施是將測試設計實施為具體的測試用例、測試規程和測試數據的活動。某些遵循IEEE829標準的組織在測試用例規格說明中定義輸入和相應的預期結果，在測試規程規格說明里定義測試步驟。更常見的情況是，每個測試的輸入、預期結果和測試步驟都寫在一起。測試實施還包括建立已存儲的測試數據（如在平面文件或數據庫表格中）。
測試實施還涉及進行最終的檢查以確保測試組已準備好執行測試。檢查可以包括確保提供所需的測試環境、測試數據和代碼（可能運行某個測試環境和／或代碼驗收測試），所有測試用例已寫好、經過評審、可以運行。還可能包括對照涉及的級別（見1.7章節）檢查顯性和隱形的入口準則。測試實施可能還涉及到測試環境和測試數據的詳細描述。
2012 版
? International Software Testing Qualifications Board
第 12 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
在測試實施時所完成工作的詳細程度和相關復雜性可能受到測試工作產品（如測試用例和測試條件）詳細程度的影響。某些情況下，尤其是那些可以長期復用的回歸測試，需要詳細描述執行測試所需的步驟，以確保無論哪個測試人員都能可靠、一致地執行測試。如果法律法規需要，測試應該提供符合適用標準的證據。（見2.9章節）
在測試實施期間，測試執行進度計劃內應該包括手動測試和自動化測試的順序。測試經理應該仔細檢查可能要求按特別順序或在特別設備上運行測試的限制條件，包括風險和優先級，還必須了解和檢查對測試環境或測試數據的依賴關系。
早期測試實施可能會有一些缺點。例如，如果使用敏捷生命周期，每次迭代的代碼可能發生巨大的變化，造成大量的實施工作被浪費。即使不是敏捷這樣易于變更的生命周期，任何迭代或增量生命周期都可能導致迭代之間發生重大變化，使腳本測試不可靠或有更高的維護需求。即使是順序型生命周期，如果管理不當，需求頻繁變更，甚至在項目晚期也出現需求變更，情況也會如此。在進行廣泛測試實施工作之前，了解軟件開發生命周期和可供測試的軟件功能的可預測性是明智的。
早期測試實施可能也有一些優勢。比如，具體的測試提供了一些工作例子，用來說明如果按測試依據所編寫的內容，軟件應該有何種行為。業務領域專家可能會發現，驗證具體的測試比驗證抽象的業務規則更容易，并可能由此進一步地發現軟件規格說明中的不足。這樣驗證后的測試可能會為軟件設計人員和開發人員對軟件必須有的行為提供有啟發性的說明。
1.6 測試執行
一旦提交了測試對象并且滿足了測試執行的入口準則，就可以開始測試執行。測試應該在測試執行之前進行設計或至少進行定義。應該使用工具，特別是用于測試管理、缺陷跟蹤和（如果適用）測試自動化執行工具。應該進行測試結果跟蹤，包括度量項跟蹤，所有組員都應該理解跟蹤的數據，提供并公布測試日志和缺陷報告的標準模板。確保在測試執行之前就完成這些事項，就可以高效地開展測試執行活動。
應該按照測試用例執行測試，不過測試經理應該考慮允許測試人員有一定的自由度，以便測試人員在測試執行中能確保覆蓋額外有趣的測試場景和觀察有趣的行為。當使用的測試策略，至少是部分的使用應對性策略時，應該保留一些時間用于基于經驗和基于缺陷的技術進行測試。當然，在這種不使用腳本測試的情況下，發現的任何失效必須描述再現失效所必需的測試用例，而這些新描述的測試用例往往會與已經現有的文檔化測試用例有所不同。自動化測試完全是腳本化的測試，會毫無偏離地遵循規定好的指示。
在測試執行期間測試經理的主要職責是按照測試計劃監督進展，如有需要，啟動和執行控制措施以引導測試的任務、目標和策略朝著成功的方向發展。為了這樣，測試經理可以使用從測試結果回到測試條件、測試依據和最終測試目標的追溯性，以及從測試目標向前到測試結果的追溯性。此過程在2.6章節中有詳細描述。
1.7 評估出口準則和報告
2.6章節詳細討論了測試進展監督和控制的文檔和報告。
從測試過程角度來看，重要的是確保具備有效的過程來提供評價出口準則和報告所需的源信息。
2012 版
? International Software Testing Qualifications Board
第 13 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
所需信息和收集方法的定義是屬于測試計劃、監督和控制的一部分。在測試分析、測試設計、測試實施和測試執行的過程中，測試經理應該確保負責這些活動的測試組的成員準確和及時地提供所需的信息，以便推動有效的評價和報告。
報告的詳細程度和頻繁程度（次數）取決于項目和組織。這應該在測試計劃階段進行協商，包括與相關項目干系人溝通。
1.8 測試結束活動
當確定測試執行完成后，應當收集關鍵輸出成果并且交給相應的人員或歸檔。這些活動統稱為測試結束活動。測試結束活動分為4大類別：
1. 檢查測試是否完成——確保所有的測試工作已經實際結束。例如，所有計劃執行的測試應該已經被執行，或者被有意跳過不執行，所有已知的缺陷應該已經修復并經過確認測試、或被推遲到下一個發布版本、或接受作為系統的永久局限。
2. 交付測試工作產品——向需要軟件產品的人員交付有價值的工作產品。例如，對于已經推遲或接受的已知缺陷，應該告知使用者并對他們使用系統進行支持。測試及測試環境應該轉交給負責維護測試的人員。回歸測試集（無論自動還是手動的）應該形成相應文件并轉交給維護團隊。
3. 總結經驗教訓——主持或參與回顧會議，會議中可記錄（來自測試項目和整個軟件開發生命周期中的）重要經驗教訓。在這些會議中，建立計劃以確保能保持良好實踐并避免不良實踐，或者如果問題無法解決，則在項目計劃中予以適應。待考慮的方面包括：
a. 參加質量風險分析討論會中的用戶代表的范圍是否足夠廣泛？例如，由于較晚才發現不曾預料的缺陷集群，在未來的項目中可以讓更廣泛的用戶代表來參加項目的質量風險分析會。
b. 估算是否準確？比如，實際開銷與估算可能有嚴重誤差，因而未來的估算活動需要考慮此問題及其根本原因，例如，是測試效率低還是估算結果確實低于應有的開銷。
c. 缺陷的趨勢以及缺陷原因和影響分析的結果如何？例如，評估是否在后期與分析和開發的質量相關聯的變更請求導致或看似一個不良實踐的趨勢。又例如跳過某一個測試級別，而這一測試級別本可以更早、以性價比更高、更節約時間的方式發現缺陷。檢查缺陷趨勢是否與新技術、人員變化和技能不足等因素有關。
d. 是否有潛在的過程改進機會？
e. 是否有未預期的與計劃之間的偏差應該在今后的計劃中予以調整？
4. 在配置管理系統中歸檔所有的結果、記錄、報告和其它文檔及工作產品。例如，測試計劃和項目計劃應該保存到計劃的目錄下，并明確指明這些文檔對應的系統及版本。
以上這些任務非常重要但經常被疏忽。應該在測試計劃中明確包括這些任務。
遺漏這些任務中的一項或多項是常見的事，通常是因為過早的重新分配或辭退項目成員、因為下一個項目的資源或進度的壓力、因為團隊疲勞等等。對于按照合同開展的項目，例如客戶定制開發，合同中應該明確這些需要的任務。
2012 版
? International Software Testing Qualifications Board
第 14 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2. 測試管理 – 750 分鐘.
關鍵詞
級別測試計劃（level test plan）、主測試計劃（master test plan）、產品風險（product risk）、項目風險（project risk）、質量風險（quality risk）、風險（risk）、風險分析（risk analysis）、風險評估（risk asssment）、風險識別（risk identification）、風險級別（risk level）、風險管理（risk
management）、風險緩解（risk mitigation）、基于風險的測試（risk-bad testing）、測試方法（test approach）、測試條件（test conditions）、測試控制（test control）、測試總監（test
director）、測試估算（test estimation）、測試組長（test leader）、測試級別（test level）、測試管理（test management）、測試監督（test monitoring）、測試計劃（test plan）、測試方針（test
policy）、測試策略（test strategy）、寬帶德爾菲法（Wide Band Delphi）
測試管理的學習目標
2.2一定條件下的測試管理
TM-2.2.1
TM-2.2.2
TM-2.2.3
TM-2.3.1
TM-2.3.2
TM-2.3.3
TM-2.3.2
TM-2.3.3
TM-2.3.4
TM-2.3.5
(K4) 分析軟件項目或程序的干系人、環境、需求，包括軟件開發生命周期模型，并識別最佳測試活動
(K2) 理解軟件開發生命周期中的活動和工作產品如何影響測試，以及測試如何影響軟件開發生命周期中的活動和工作產品
(K2) 解釋在基于經驗的測試和非功能性測試中對測試管理問題進行處置的方法。
2.3基于風險的測試及其它測試優先級設定和工作量分配的方法
(K2) 基于風險的測試及其它測試優先級設定和工作量分配的方法
(K2) 舉例說明產品風險分析的不同技術
(K4) 分析、識別和評估產品質量風險，從關鍵項目干系人的角度總結風險及評估的風險級別
(K2) 舉例說明產品風險分析的不同技術
(K4) 分析、識別和評估產品質量風險，從關鍵項目干系人的角度
(K2) 描述在生命周期和測試過程中，怎樣根據評估的風險級別，適當地緩解和管理識別的產品質量風險
(K2) 舉例說明測試選擇、優先級設定和分工的不同方案
2.4 測試文檔和其它工作產品
TM-2.4.1
TM-2.4.2
TM-2.4.3
TM-2.4.4
(K4) 分析給出的測試方針和測試策略，建立主測試計劃、級別測試計劃和其它與這些文檔相補充和相一致的測試工作產品
(K4) 針對給定的項目，分析項目風險并選擇適當的風險管理方案（如緩解、應急、轉移和／或接受）
(K2) 描述并舉例說明測試策略如何影響測試活動
(K3) 制定適合組織、生命周期以及項目需要的測試工作產品的文檔規范和模版，適時裁剪標準的主體部分，生成可用模版
2.5 測試估算
TM-2.5.1
TM-2.5.2
(K3) 針對給定的項目，使用所有適當的估算技術創建整個測試過程活動的估算
(K2) 理解可能影響測試估算的因素，并舉例說明
2012 版
? International Software Testing Qualifications Board
第 15 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.6 定義及使用測試度量
TM-2.6.1
TM-2.6.2
TM-2.6.3
(K2) 描述并比較典型的測試相關度量
(K2) 比較不同層面的測試進度監控
(K4) 分析和匯報測試結果，主要包括遺留風險、缺陷狀態、測試執行狀態、測試覆蓋狀態以及信心來提供見解和建議，幫助項目干系人做出發布決策
2.7 測試的商業價值
TM-2.7.1
TM-2.7.2
(K2) 分別給出決定質量成本四種類別的例子
(K3) 基于質量成本，以及其它定性和定量的考慮，估算測試的價值，并將其告知測試干系人
2.8 分布式、外包及內部測試
TM-2.8.1 (K2) 理解如何成功運用不同人員策略構建團隊：是利用分布式團隊、外包團隊還是內包試團隊
2.9 管理行業標準的應用
TM-2.9.1 (K2) 總結軟件測試標準的來源及使用
2012 版
? International Software Testing Qualifications Board
第 16 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.1 簡介
在高級大綱中，測試從業人員開始劃分專業方向。本章主要關注測試職業人員在晉升為測試組長、測試經理及測試總監時所需的知識領域。盡管不同的組織對這些職位和擔任這些職位的人員的職責等級有不同界定，但在本大綱中，我們將所有這些專業測試人員統稱為測試經理。
2.2 一定條件下的測試管理
作為一名經理，最主要的職責是獲取和利用資源（人力，軟件，硬件，基礎設施等）去開展能帶來附加值的工作。對于軟件和IT經理而言，這個過程通常是項目或程序中旨在（對內部用戶或對外部用戶）交付軟件或系統的部分。對于測試經理而言，這個過程與測試相關，具體而言就是基礎級大綱和本大綱第1章中描述的基礎測試過程。由于測試過程的附加值只能通過整個項目或程序的成功（或通過防止更嚴重的失效發生）來體現，因此，測試經理必須相應地計劃和控制測試過程。換句話說，測試經理必須根據其它干系人的需求、環境、干系人的活動（如進行測試的軟件開發生命周期）、干系人的工作產品（如需求規格說明），適當地安排測試過程，包括相關活動及工作產品。
2.2.1 了解測試干系人
測試干系人是指與測試活動、測試工作產品、最終系統或交付物的質量有利益關系的人。干系人的利益可能是直接或間接地介入測試活動、直接或間接地接受測試工作產品，或者直接或間接地受到項目生產的交付物的質量的影響。
測試的干系人取決于項目、產品、組織或其它因素，可能包含以下角色：
? 開發人員、開發組長和開發經理：這些干系人需要部署待測的軟件，獲取測試結果，通常還必須根據測試結果采取一定行動（如修復報告的缺陷）
? 數據庫架構師、系統架構師和設計師：這些干系人設計軟件，獲取測試結果，通常也必須根據測試結果采取一定行動
? 市場和業務分析師：這些干系人決定軟件必須呈現的特性，以及這些特性固有的質量水平。他們通常還參與確定測試覆蓋范圍，評審測試結果，根據測試結果做出決策
? 高層管理人員、產品經理和項目發起人：這些干系人通常參與確定測試覆蓋范圍，評審測試結果，并根據測試結果做出決策
? 項目經理：這些干系人負責管理項目，使其取得成功，這就要求在質量、進度、特性和預算之間取得平衡。他們通常負責獲取測試活動所需的資源，并協同測試經理進行測試計劃和控制
? 技術支持、客戶支持和幫助臺人員：這些干系人支持用戶和客戶，同時也是已交付軟件的特征與質量的受益人
? 直接和間接用戶。這些干系人直接使用軟件（即最終用戶），或者接受由該軟件生產或支持的輸出或服務
更多關于測試干系人的信息可參見參考書籍 [Goucher09] 第2章。
以上的干系人列表并不全面。測試經理必須為自己的項目或程序識別具體的測試干系人。測試經理還必須理解干系人與測試關系的確切本質，以及測試團隊怎樣服務于這些干系人的需求。除了識別如上所述的測試干系人，測試經理還應識別其它影響測試和／或被測試影響的軟件開發生命周期活動與工作產品。否則的話，測試過程可能無法達到最佳的效果和效率（見2.2.3節）。
2012 版
? International Software Testing Qualifications Board
第 17 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.2.2其它的軟件開發生命周期活動及工作產品
軟件測試評價的是非測試活動產生的一個或多個工作產品的質量，因此，測試通常存在于一套軟件開發生命周期活動的大背景下。測試經理必須在了解這些其它的活動及其工作產品怎樣影響測試（如基礎級大綱所述），并了解測試怎樣影響這些其它的活動及其工作產品的情況下，計劃和指導測試活動。
例如，在使用敏捷開發實踐的組織，開發人員執行測試驅動的開發（TDD），生成自動化的單元測試，然后不斷將代碼（以及針對這些代碼的測試）集成到配置管理系統中。測試經理應與開發經理一起確保將測試人員集成到了這些活動中，并與這些活動保持一致。測試人員可以通過評審單元測試，為提高覆蓋率和測試活動的有效性給出建議，同時深入了解該軟件及其實施情況。測試人員也可以評估將他們自己創建的自動化測試，尤其是功能回歸測試集成到配置管理系統中的方式。[Crispin09]
盡管測試活動、其它測試干系人、軟件開發生命周期活動和工作產品之間的具體關系取決于項目、選定的軟件開發生命周期和許多其它的因素，但測試和以下活動相互關聯密不可分：
? 需求工程和管理。在確定測試工作的范圍和進行估算時，測試經理需要考慮到需求，并且對需求的變更保持高度的警惕性，在出現變更時，采取測試控制活動以適應這些變更。技術測試分析師和測試分析師應參與需求評審
? 項目管理。在測試分析師和技術測試分析師的協助下，測試經理必須將進度和資源需求提供給項目經理。測試經理必須與項目經理一起去理解項目計劃的變更，并采取測試控制活動以適應這些變更
? 配置和變更管理。測試經理必須與測試團隊一起確定測試對象交付流程和機制，并將這些記錄在測試計劃中。測試經理可以要求測試分析師和技術測試分析師生成版本驗證測試，并在測試執行過程中確保版本控制
? 軟件開發和維護。測試經理應與開發經理一起協調測試對象的交付，包括每次測試發布內容與發布日期，以及參與到缺陷管理中（見第4章）
? 技術支持。測試經理應與技術支持經理一起確保在測試結束時測試結果能順利交付，以便讓在產品發布后參與產品支持的人員知道產品有哪些失效以及為這些失效的變通方法，另外，測試經理應該與技術支持經理共同對產生的失效進行分析，以實施測試過程改進
? 編寫技術文檔。測試經理應與技術文檔經理一起確保測試文檔能按時交付，且這些文檔中體現了對缺陷的管理
除了識別如上所述的測試干系人，測試經理還必須識別其它影響測試和／或被測試影響的軟件開發生命周期活動與工作產品。否則的話，測試過程可能無法達到最佳的效果和效率。
2.2.3測試活動和其它生命周期活動的整合
無論項目使用的是哪個軟件開發模型，測試都應是項目的一個主要部分。軟件開發模型包括：
? 順序模型，如瀑布模型、V模型、W模型：在順序模型中，各階段（如需求、設計、實施、單元測試、集成測試、系統測試和驗收測試）的所有工作產品和活動都在下個階段開始前完成。測試計劃、測試分析、測試設計和測試實施與項目計劃、業務／需求分析、軟件和數據庫設計、編程重疊進行，具體如何重疊則取決于該測試的級別。測試執行按照基礎級大綱和本大綱中討論的測試級別的順序進行
? 迭代或增量模型，如快速應用開發（RAD）和統一開發過程（RUP）：在迭代或增量模型中，對待實現的特性進行分組（如根據業務優先級或風險），各項目階段，包括其工作產品和活動，存在的目的就是實現各組特性。各階段可能按順序進行，也可能重疊進行，而迭代本身也可能是有序的或重疊的。項目啟動期間，在項目計劃和業務／需求分析的同時進行粗略的測試計劃和測試分析。詳細的測試計劃、測試分析、測試設計和測試實施發生在每次迭代之初，重2012 版
? International Software Testing Qualifications Board
第 18 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
疊進行。測試執行通常包括重疊的測試級別。每個測試級別都盡早開始，在后續更高級別的測試開始后也可能會繼續
? 敏捷，如SCRUM和極限編程（XP）：這些屬于迭代生命周期模型，但迭代的周期很短（通常為二到四周）。每次迭代的活動和產品在下次迭代開始之前完成（如迭代是順序性的）。測試進行的方式與迭代模型類似，但各種測試活動與開發活動之間都有很大程度的重疊，包括測試執行（各級別的）與開發活動之間。在一次迭代中的所有活動，包括測試，都應在下一次迭代開始之前完成。在敏捷項目中，測試經理的角色通常從直接的管理者轉變成了技術權威／咨詢顧問
? 螺旋：在螺旋模型中，項目早期使用原型來確認項目的可行性，試驗設計和實施決策，根據業務優先級和技術風險選擇原型試驗開展的順序。對這些原型進行測試以確認技術問題的哪些方面仍然沒有解決。一旦解決了主要的技術問題，就可以按照順序模型或迭代模型開展項目
為了能將測試活動適當地整合到生命周期內，測試經理必須對于組織使用的生命周期模型有詳細的了?解。例如，在V模型中，應用于系統測試級別的ISTQB基礎測試過程可以按照下列方式整合：
? 系統測試計劃活動與項目計劃同時進行，測試控制一直持續到系統測試執行和測試結束工作完成
? 系統測試分析和設計與需求規格說明、系統和架構（概要）設計說明和組件（詳細）設計說明的編寫同時進行
? 系統測試實施活動可在系統設計期間開始，但大部分都是與編碼和組件測試同時進行。系統測試相關的部署工作通常會延續到系統測試執行開始前的幾天
? 當所有的系統測試入口準則被滿足（或免除）時開始系統測試執行活動，系統測試入口準則一般是指至少完成了組件測試，通常還包括完成組件集成測試。系統測試會被持續執行直到系統測試出口準則被滿足為止
? 整個系統測試執行期間都在評價系統測試出口準則和匯報系統測試結果，一般來說，當項目即將到達最后期限時評價和匯報的頻率更高，也更緊迫
? 在滿足了系統測試出口準則和正式宣布系統測試執行工作完成之后，進行系統測試結束活動，結束活動有時可以推遲到驗收測試結束或所有項目活動完成后進行
在迭代或增量的生命周期模型中，必須開展同樣的任務，但任務開展的時間以及程度可以不同。例如，與其在項目初期就部署整個測試環境，不如只部署本次迭代所需的部分可能更有效率。無論是迭代還是增量生命周期模型，計劃得越深入，基礎測試過程延伸的范圍就越廣。
除了項目的計劃階段，測試的執行和匯報也可能受到團隊使用的生命周期的影響。例如，迭代生命周期中，在下一次迭代開始之前撰寫完整的報告和進行迭代后評審會議可能是有效的。通過將每次迭代看作一個小型項目，項目組有機會根據上一次迭代中發生的事件做出糾正和調整。由于迭代周期可能很短，受到時間限制，縮短花在報告和評估上的時間是可以理解的，而任務的開展都應作為跟蹤整個測試進展和盡可能快地識別問題區域的一種方式。如果沒有采取糾正措施，在某次迭代中發生的問題很容易影響下一次迭代，甚至在下一次迭代中重現。
還有一些與如何將測試和其它生命周期活動整合的信息可能記錄在測試策略章節中（見2.4.2節）。測試經理應在測試計劃和／或項目計劃期間，對各測試級別和選定的生命周期模型與測試過程的組合進行項目特定的整合。
根據組織、項目和產品的需求，可能需要補充基礎級大綱未定義的測試級別，如：
? 硬件-軟件集成測試
? 系統集成測試
? 特性交互測試
2012 版
? International Software Testing Qualifications Board
第 19 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
? 客戶產品集成測試
各測試級別都應明確定義以下要素：
? 測試目標，可實現的目的
? 測試范圍和測試項
? 測試依據，以及衡量該測試依據覆蓋率的方式（如可追溯性）
? 入口和出口準則
? 測試交付物，包括結果匯報
? 適用的測試技術，以及與這些技術相應的確保覆蓋度的方式
? 與測試目標、入口和出口準則以及結果匯報相關的度量和度量標準（包括覆蓋率的度量）
? 針對具體的測試任務應用的測試工具（適用時）
? 資源（如測試環境）
? 測試團隊內外部負責的個人和群體
? 符合組織、法規或其它規范（適用時）
最好的做法是在各測試級別對上述要素進行一致定義，以免不同級別的類似測試之間出現不必要的差距，造成危險和資源浪費。在本章后面部分還會繼續討論。
2.2.4 管理非功能測試
非功能測試計劃失敗會導致發布后發現嚴重的，有時是災難性的系統質量問題。然而，很多非功能測試都是昂貴的，因此，測試經理必須依據風險選擇需要執行的非功能測試。另外，非功能測試有許多類型，并非每一種測試類型都適用于給定的應用程序。
測試經理可能并沒有充足的專業能力去處理各種計劃的相關因素，因此，他們需要將非功能測試活動的部分測試計劃責任委派給技術測試分析師（某些情況下是測試分析師）。測試經理應要求分析師考慮到以下一般因素：
? 干系人需求
? 所需的工具
? 測試環境
? 組織因素
? 安全性
?更多內容參見高級技術測試分析師大綱第4章 [ISTQB ATTA SYL]。
測試經理需要考慮的另一個重要因素就是怎樣將非功能測試集成到軟件開發生命周期。常見的錯誤是一直等到所有的功能測試都完成以后才開始進行非功能測試，這樣做會導致太晚發現關鍵的非功能缺陷。相反，應該優先安排非功能測試，并根據風險對測試進行排序。通常在早期的測試級別，甚至是在開發期間，可以通過多種途徑緩解非功能風險。例如，系統設計期間的用戶界面原型的易用性評審對于識別重大的易用性缺陷十分有效，如果直到系統測試結束時才發現這些缺陷，則會嚴重影響項目進度。
在迭代生命周期中，變更和迭代的速度會讓人難以關注需要構建復雜框架的非功能測試。那些比單次迭代周期花費的時間更長的測試設計和實施活動應單獨安排成迭代之外的工作活動。
2.2.5管理基于經驗的測試
基于經驗的測試能高效地找出其它測試技術可能遺漏的缺陷，正因為這個好處，它被用來檢查其它測試技術的完整性，但這種技術也為測試管理帶來了一些挑戰。測試經理在知道基于經驗的測試，尤其是探索性測試帶來的好處的同時，也應該意識到其帶來的挑戰。由于一般采用輕量化文檔，且通常測試事前2012 版
? International Software Testing Qualifications Board
第 20 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
準備得很少，因此很難評估這種測試技術達到的覆蓋率。管理層需要特別留意測試結果的可重復性，尤其是當有多個測試人員參與測試時。
管理基于經驗的測試，尤其是探索性測試的一種方式是將測試工作分解成小到30-120分鐘的時間段，這些時間段有時被稱為測試會話。這種時間段界定該會話中要做的工作，在此期間只關注這些工作，并且提供一定程度的監控和調度。每個測試會話覆蓋既定的測試章程，此測試章程由測試經理以書面或口頭的方式傳達給測試人員。測試章程給出了測試會話中應覆蓋的一個或多個測試條件，進一步幫助測試人員集中精力，避免在多人同時開展探索性測試時出現工作的重疊。
管理基于經驗的測試另一種的方式是將自主和自發測試集成到更為傳統的預先設計好的測試會話中。例如，測試人員獲準（或被分配了時間）在他們預定義測試的明確步驟、輸入和期待結果以外進行探索。測試人員可能還會被安排在運行一天的預定義測試之前、期間或之后，進行自主測試會話，作為每日測試的一個部分。如果測試會話發現了缺陷或值得進行后續測試的領域，可能會對提前編寫的測試進行更新。
在每次探索性會話之初，測試人員確認并執行必要的測試啟動任務。在會話期間，測試人員根據采用的測試技術設計和執行測試，查找缺陷，并將測試結果記錄在日志中。（如果要求測試必須是可重復的，測試人員應該記錄測試輸入、操作及事件。）會話結束后，可能會有一個情況匯報，為后續測試會話確立方向。
2.3基于風險的測試和其它測試優先級設定和工作量分配的方法
測試管理中普遍存在的一個挑戰是測試的選擇、分配和優先級設定，即測試團隊必須在實際上無限的可覆蓋的測試條件和測試條件的組合中選擇一組有限的測試條件，確定適當的分工以確保各項條件都被測試用例覆蓋，然后將生成的測試用例按照優先級排序，推動測試工作有效、高效地開展。測試經理可以通過識別和分析風險以及其它因素，來幫助解決這個問題，但由于許多限制和其它變量的相互影響，可能導致折衷的解決方案。
2.3.1基于風險的測試
風險是指負面或不希望發生的后果或事件發生的可能性。當引起客戶、用戶、參與者或干系人對產品質量或項目成功的信心減弱的問題可能發生時，風險就存在。當潛在問題主要影響的是產品質量時，它們被稱為質量風險、產品風險或產品質量風險。而當潛在問題主要影響的是項目成功時，它們則被稱為項目風險或計劃風險。
在基于風險的測試中，在干系人參與的產品質量風險分析的過程中對質量風險進行識別和評估。測試團隊設計、實施和執行測試來緩解質量風險。質量包括影響客戶、用戶和干系人滿意度的全部功能、行為、特征和屬性。因此，質量風險是產品可能存在質量問題的情況。系統質量風險的例子包括報告中的錯誤計算（與準確度相關的功能風險），用戶輸入響應慢（與效率和響應時間相關的非功能風險），界面和字段難以理解（與易用性和易理解性相關的非功能風險）。當測試找出了缺陷時，通過讓他人意識到這些缺陷，并在發布前有機會處理這些缺陷，測試緩解了質量風險。當測試不再發現缺陷時，通過確保在測試條件下，系統可以正常運作，測試也緩解了質量風險。
基于風險的測試使用產品質量風險來選擇測試條件，為這些條件分配測試工作，并為生成的測試用例設定優先級。基于風險的測試有各種各樣的技術，這些技術在采集的文檔的類型和級別，以及運用的形式方面大相徑庭。基于風險的測試明確指出的或隱含的目的就是用測試來降低整體的質量風險水平，具體而言是把風險水平降低到可接受的范圍。
2012 版
? International Software Testing Qualifications Board
第 21 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
基于風險的測試包含四個主要活動：
? 風險識別
? 風險評估
? 風險緩解
? 風險管理
這些活動之間部分重疊。后面的幾節會討論到每個活動。
要想取得最佳的效果，風險識別和評估小組應包括所有項目和產品干系人的代表，不過有時項目的實際情況導致某些干系人代理其它干系人。例如，在大眾市場的軟件開發中，可能抽樣一小部分潛在客戶，要求他們幫助識別潛在的嚴重影響他們使用軟件的缺陷；在這個例子中，抽樣的小部分潛在客戶就是作為所有最終客戶群的代理人。由于測試人員在產品質量風險和失效方面的專長，他們應該積極參與風險識別和評估過程。
2.3.1.1風險識別
干系人可通過下列的一項或多項技術來識別風險：
? 專家咨詢
? 獨立評估
? 使用風險模版
? 項目回顧
? 風險研討會
? 頭腦風暴
? 檢查表
? 參考過去的經驗
對參與風險識別的干系人的抽樣越廣泛，風險識別過程就越有可能識別出越多的嚴重產品質量風險。
風險識別通常會產生一些副產品，例如，識別出并非產品質量風險的問題。例子包括有關產品或項目的一般疑問或問題，或參考的文檔，如需求和設計說明中的問題。質量風險識別的另一副產品是識別出項目風險，不過項目風險并不是基于風險的測試關注的焦點。然而，項目風險管理對于包括基于風險測試在內的所有測試方法都是很重要的，這一點在2.4節中會進一步討論。
2.3.1.2 風險評估
識別了風險后，就開始風險評估，即研究識別出的這些風險。具體而言，風險評估包括對每個風險進行分類，確定風險發生的概率和影響。風險評估還可能涉及評價或分配每個風險的其它屬性，如風險責任人。
風險的分類就是將每個風險劃分到適當的類型中，例如性能、可靠性、功能性等等。有些組織使用ISO
9126（ISO 9126標準正在被ISO 25000標準所取代）的質量特征進行分類，但大多數組織采用的都是其它的分類方案。風險分類時使用的檢查表通常與風險識別使用的相同。有通用的質量風險檢查表，許多企業都根據自己的需要定制這些檢查表。如果使用檢查表作為風險識別的基礎，在風險識別時通常就進行了風險的分類。
確定風險的級別通常包括評估每條風險發生的可能性，以及發生之后的影響。發生的可能性是指被測系統存在潛在問題的概率。換句話說，可能性是對技術風險的級別的評估。影響產品和項目風險發生的可能性的因素包括：
2012 版
? International Software Testing Qualifications Board
第 22 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
?
?
?
?
?
?
?
?
?
?
?
技術和團隊的復雜性
業務分析師、設計師和程序員的人員和培訓問題
團隊內部的沖突
與供應商的合同問題
異地工作的團隊隊員
舊方法與新方法對立
工具和技術
管理或技術領導不力
時間、資源、預算和管理壓力
缺乏前期的質量保證活動
高變更率
早期的高缺陷率
接口和集成問題
風險發生的影響是指風險發生對用戶、客戶或其它干系人的影響的嚴重程度。換句話說，影響來自于業務風險。影響項目和產品風險的影響程度的因素包括：
? 使用受影響的特性的頻率
? 該特性對于實現業務目標的關鍵程度
? 聲譽的損害
? 商業損失
? 潛在的財務、生態、社會損失或法律責任
? 民事或刑事法律制裁
? 吊銷執照
? 缺乏合理的變通
? 明顯的失效導致負面聲譽
? 安全性
風險的級別既可定性也可定量地評估。如果確定了可能性和影響的量化數據，可以將這兩個值相乘，計算出定量的風險優先級數值。不過通常風險的級別只能通過定性的方式確認。也就是說，我們可以將可能性形容成很高、高、中、低或很低，但無法用精確的百分比表達出來；同樣地，我們可以將影響形容成很高、高、中、低或很低，但也不能完整或精確地表達財務上的影響。不應該認為定性的方法比定量的方法差；實際上，如果風險級別的定量評估使用不當的話，會誤導干系人對風險程度的理解和管理。風險級別的定性評估通常通過乘法或加法相結合，得到一個風險總分。這個風險總分可能被稱為風險優先數，但確切來說，它應是定性的、有序的相對評級。
另外，除非風險分析基于廣泛的、有效統計的風險數據，風險分析應該更多基于干系人對于可能性和影響的主觀感知。通常，項目經理、編程人員、用戶、業務分析師、架構師和測試人員的感知各不相同，因此針對各項風險的風險級別可能有不同的意見。風險分析過程應包括達成共識，或者即使在最糟的情況下，也要有確立都同意的風險級別的方式（如通過管理層下達命令或通過取該風險級別的平均值，中間值或眾數值）。此外，還應檢查風險級別的分布情況，確保風險的評分對于測試排序、優先級設定和分工能起到實際的指導作用。否則，將無法使用風險級別來指導風險緩解活動。
2.3.1.3風險緩解
基于風險的測試從質量風險分析（識別和評估產品質量風險）開始。質量風險分析是主測試計劃和其它測試計劃的基礎。正如計劃中所述，測試的設計、實施和執行是為了覆蓋風險。開發和執行測試的工作量與風險的級別成一定比例，也就是說風險的級別越高，使用的測試技術就越細致（如結對測試），風險的級別越低，使用的測試技術就越不細致（如等價類劃分或有時限的探索性測試）。此外，開發和執2012 版
? International Software Testing Qualifications Board
第 23 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
行測試的優先級也是依據風險級別而設定。有些安全規范（如FAA DO-178B/ED 12B,IEC 61508）規定了基于風險級別的測試技術和覆蓋率。另外，風險的級別還應影響到一些決策，例如使用項目工作產品（包括測試）的評審，獨立的級別，測試人員的經驗水平，確認測試（再測試）和回歸測試的程度。
在項目開展期間，測試團隊仍應對改變質量風險集和／或已知質量風險的風險級別的補充信息保持了解。應該定期調整質量風險分析，至少在項目的主要里程碑到來時（進行這種調整），以此來指導對測試的調整。調整包括識別新風險，重新評估現有風險的級別和評價風險緩解活動的有效性。例如，如果在需求階段，基于需求規格說明進行了一次風險識別和評估，那么當設計規格說明定案后，就應對已有的需求規格風險重新進行評價。再如，如果在測試中發現某個組件包含的缺陷要遠比預期的缺陷數多，則可得出在此區域缺陷的可能性比預期的要高的結論，并將風險的可能性和整體風險級別上調，根據調整結果就應增加該組件測試的工作量。
在測試執行開始之前也可以緩解產品質量風險。例如，如果在風險識別時發現了需求的問題，項目組就可以通過實施全面的需求規格說明評審來緩解這一風險。這樣做可以降低風險的級別，可能意味著緩解殘余質量風險所需的測試數目減少。
2.3.1.4生命周期中的風險管理
理想情況下，在整個生命周期期間都在進行風險管理。如果組織有測試方針文檔和／或測試策略文檔，這些文檔中應當描述測試中管理產品風險和項目風險的一般過程，以及風險管理怎樣集成到測試的各個階段中，并使其發揮作用。
一個成熟的組織，風險意識應遍及整個項目組，在這樣的組織中，風險管理并非僅僅發生在測試中，而是發生在各個方面。重要的風險不僅在特定測試級別的前期就得到處理，而且在早期的測試級別中也得到了處理。例如，如果性能被識別為一個關鍵質量風險區域，性能測試在系統測試的前期就會開始進行，而且在單元測試和集成測試時也會運行性能測試。成熟的組織不僅識別風險，還識別風險的來源和風險一旦發生將帶來的后果。對于那些確實發生的風險，使用根本原因分析來深入理解風險的來源和實施過程改進，防范于未然。風險緩解貫穿于整個軟件開發生命周期。風險分析獲得了充足的信息，考慮到了相關的工作活動、系統行為分析、基于成本的風險評估、產品風險分析、最終用戶風險分析和責任風險分析。當測試團隊參與并對整個程序范圍的風險分析產生影響的情況下，風險分析超越了測試的范疇。
大多數基于風險的測試方法還包括用風險級別來對測試進行排序和優先級設定的技術，以此確保測試執行時盡早覆蓋最多的重要區域，發現最多的重要缺陷。某些情況下，所有的高級別風險的測試都是在較低級別風險測試之前進行的，且測試的運行嚴格按照風險排序（通常稱為“深度優先” ）；其它情況下，測試優先級根據抽樣方法來制定。抽樣方法就是選擇一個測試樣本，該測試樣本可以覆蓋到所有已識別的風險。用風險覆蓋率評估選出的測試樣本，確保每條風險至少被覆蓋到一次（通常稱為“廣度優先” ）。
無論基于風險的測試是深度優先還是廣度優先，分配給測試的時間都有可能不足。基于風險的測試使得測試人員能以剩余風險級別的方式向管理層報告當前測試狀態，讓管理層決定是否要增加測試時間或將剩余的風險轉移給用戶／客戶、服務／技術支持人員和／或運營人員。
在測試執行期間，最先進的基于風險的測試技術（并不一定是最正式或重量級的技術）讓項目參與人、項目和產品經理、高層行政管理人員和項目干系人根據剩余風險級別監控軟件開發生命周期，包括做出是否發布的決策。這就要求測試經理在匯報有關風險的測試結果時，要確保所有干系人都能理解。
2012 版
? International Software Testing Qualifications Board
第 24 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.3.2基于風險的測試技術
基于風險的測試技術有很多，其中有一些很不正式，例如測試人員在探索性測試期間分析質量風險的方法 [Whittaker09]。盡管這種方法能有助于指導測試，但會導致過分關注缺陷的可能性，而不是關注缺陷的影響，也沒有引入跨職能干系人的輸入。這些方法還很主觀，依賴于單個測試人員的能力、經驗和偏好。正因如此，這些方法很少可以取得基于風險的測試的全部收益。
為了嘗試以最小的成本獲得基于風險的測試的收益，許多人采用了輕量級的基于風險的方法。這種方法融合了非正式方法的響應能力和靈活性以及正式方法的力度和一致性。輕量級方法的例子包括：實用風險分析與管理（PRAM）[Black09]、系統的軟件測試（SST）[Craig02]和產品風險管理（PRisMa）[vanVeenendaal12]。除了基于風險的測試的常見屬性外，這些技術通常還有以下屬性：
? 從基于風險的測試行業經驗中逐漸演變而來，特別是那些效率至關重要的行業
? 取決于跨職能組的，代表業務類和技術類觀點的干系人，在初期風險識別和評估中的廣泛參與
? 在一個項目的最初階段引入緩解質量風險時效果最佳，風險分析的主要工作產品和副產品有助于影響產品的規格說明和實施，從而最大程度地減少風險
? 使用生成的輸出結果（風險矩陣或風險分析表）作為測試計劃和測試條件，以及所有后續測試管理和分析活動的基礎
? 支持將關于剩余風險的測試結果匯報給各級別的測試干系人
這類技術中有些（如SST）要求將需求規格說明作為風險分析的輸入，而且只有在提供了需求規格說明后才能使用。其它技術（如PRisMa和PRAM）鼓勵使用將基于風險與基于需求混合的策略，使用需求規格說明和／或其它規格說明作為風險分析的輸入，但功能可以完全基于干系人的輸入。將需求作為輸入可以幫助確保對需求的高覆蓋率，但測試經理務必要確保不漏測在需求中沒有提到的重要風險，尤其是非功能領域的風險。如果得到的輸入是好的并設定了優先級的需求，通常我們可以看到風險級別和需求優先級之間的密切關聯。
這些技術中有許多都鼓勵將風險識別和評估過程作為干系人之間就測試方法達成共識的一種方式。這會帶來巨大的好處，但同時也需要占用干系人的時間去參與小組的頭腦風暴會議或是一對一的訪談。干系人參與的不足會導致風險分析中的差距。當然，干系人并不一定對每個風險級別意見一致，所以主持質量風險分析工作的人必須積極且有創造性地與干系人一起達到可能的最大程度的一致。一個專門主持評審會議的主持人具有的所有技能都適用于主持質量風險分析的人員。
與正式技術一樣，輕量級的技術允許對可能性和影響因素進行加權，以強調業務或技術風險（如取決于測試級別）。與正式技術不一樣的輕量級技術：
? 僅使用兩個因素，可能性和影響程度；并且
? 使用簡單的，定性的判斷和尺度
這些方法的輕量性質在諸多領域帶來了靈活性和可用性，以及適合整個團隊的各種經驗和技能水平的人員（甚至是非技術人員和新人）。
在正式的，重量級的那一端，測試經理有許多可用的選項：
? 危害分析，延伸至整個分析過程的上游，嘗試識別每個風險背后隱藏的危害
? 暴露的成本，對每個質量風險，風險評估過程包括三個因素：1）與該風險項相關的失效的可能性（用百分比表示）；2）一旦生產期間發生與該風險項相關的典型失效將造成的失效成本（用金融數量表示）；3）這些失效的測試成本
? 失效模式和影響分析（FMEA）和其變體 [Stamatis03]，識別質量風險，風險的潛在原因和可能造成的影響，然后確定嚴重程度，分配優先級和檢測等級
2012 版
? International Software Testing Qualifications Board
第 25 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
質量功能展開（QFD），一種影響測試的質量風險管理技術，具體而言，關注的是對客戶或用戶需求的理解不當或不充分引起的質量風險
故障樹分析（FTA），對各種實際發現的失效（從測試或生產中）或潛在失效（質量風險）進行根本原因分析，首先分析會導致失效的缺陷，其次是會導致這些缺陷的（認為）錯誤或（其它）缺陷，一直繼續直到找出根本原因
基于風險的測試采用的具體技術和怎樣采用該技術取決于項目、過程和產品。例如，類似Whittaker的探索性技術的非正式方法可能適用于補丁或是快速修復。在敏捷項目中，質量風險分析被完全集成到每個沖刺（Sprint）的初期，風險的文檔也融入了用戶故事跟蹤。綜合系統要求不僅對單個系統，對整個綜合系統也有風險分析。安全關鍵系統和關鍵任務項目要求的正式程度和文檔的級別相對較高。
基于風險的測試的輸入、過程和輸出取決于選定的測試技術。常見的輸入包括干系人見解、規格說明和歷史數據。常見的過程包括風險識別、風險評估和風險控制。常見的輸出包括質量風險列表（附帶各風險的風險級別和建議的測試工作量分配）、規格說明等輸入文檔中發現的缺陷、關系到風險項的疑問或問題，以及影響測試或項目整體的項目風險。
通常，影響基于風險的測試成功與否的最關鍵因素是有正確的干系人參與風險識別和評估。干系人對于產品質量由什么構成都有各自的理解，而且他們都有著自己的一套風險的優先級和關注點。但他們還是傾向于分成兩大類：業務干系人和技術干系人。
業務干系人包括客戶、用戶、運營人員、幫助臺和技術支持人員。這些干系人了解客戶和用戶，因此可以從業務的角度識別風險和評估影響。
技術干系人包括開發人員、架構師、數據庫管理員和網絡管理員。這些干系人知道潛在的軟件失效方式，因此可以從技術層面識別風險和評估可能性。
某些干系人既代表業務角度的觀點也代表技術角度的觀點。比如說，擔任測試分析或業務分析角色的專題事務專家，由于其在技術和業務領域的專業知識，一般會有更廣闊的視角。
識別風險項的過程就是生成一張充實的風險列表的過程。干系人沒有必要爭論風險項的內容，只要有一個干系人認為是系統質量的風險，那么它就是風險項。重要的是干系人必須對風險級別的評定達成共識。例如，在使用可能性和影響程度作為評定因素的輕量級方法中，過程必須包括找到對于可能性和影響程度的通用的分級方案。包括測試組在內的所有干系人必須使用同樣的尺度，且必須能覆蓋每個質量風險項的可能性和影響。
另外，如果要長期使用基于風險的測試，那么測試經理必須要成功地向干系人倡導基于風險的測試。要想持續使用這個技術，跨職能組必須要看到風險分析的價值。這就要求測試經理理解干系人的需要、期望和參與過程的可用時間。
干系人適當參與質量風險分析過程能讓測試經理獲益匪淺。對于需求缺失或描述不明確的項目，干系人仍然可以在合適的檢查表的指引下識別風險。在實施了基于風險的測試后，當測試團隊的缺陷檢測效率提高時，我們就可以看到干系人參與所帶來的收益。之所以這樣，是由于使用了更全面的測試依據，此處是使用了質量風險項列表。
在結束基于風險的測試時，測試團隊應衡量他們的效益。許多情況下，這關系到回答以下需要通過度量和與團隊咨詢的部分或全部4個問題：
? 測試團隊發現的重要缺陷是否比次要缺陷要多？
? 大部分的重要缺陷是否是測試團隊在測試執行的初期發現的？
2012 版
? International Software Testing Qualifications Board
第 26 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
測試團隊能否就風險向干系人解釋測試結果？
測試團隊跳過的測試（如果有的話）是否比執行的測試的相關風險級別要低？
大多數情況下，基于風險的測試只要成功，以上四個問題答案都是肯定的。長期來看，測試經理應該為這些度量標準設定過程改進目標，并積極提升質量風險分析過程的效率。當然，其它的度量標準和成功標準也可以用于基于風險的測試，測試經理應仔細考慮這些度量標準之間的關系，測試團隊奮斗的戰略目標，以及管理這些特定度量標準和成功標準集的使用需要的行為。
2.3.3選擇其它測試技術
在許多測試經理使用基于風險的測試作為他們測試策略的一個要素的同時，許多測試經理還選擇了包括其它技術。
其中一種最流行的開發測試條件并設定優先級的替代技術就是基于需求的測試。基于需求的測試可以使用多種技術，如歧義評審、測試條件分析和因果圖。歧義評審識別和消除需求文檔（作為測試依據）中的歧義，通常是通過使用常見需求缺陷的檢查表（參見 [Weigers03]）。
如 [Craig02] 中所述，分析測試條件包括仔細閱讀需求規格說明，以識別需要覆蓋的測試條件。如果需求事先已經被分配了優先級，就可以被用來分配工作和設定測試用例優先級。如果沒有，又不把基于需求的測試融入基于風險的測試的話，就難以確定適當的工作分配和測試的先后順序。
在高級測試分析師模塊中，談到覆蓋測試條件的組合作為測試分析的一部分時，講到了因果圖。因果圖其實有更廣泛的用途，它可以將極大的測試問題歸納為可控數目的測試用例，并且仍然能保證測試依據的功能覆蓋達到100%。因果圖還可以在設計測試用例時識別出測試依據中的分歧，如果在需求草案階段就開始設計測試，就可以在軟件開發生命周期的早期發現缺陷。采用因果圖的一大難題是畫圖的復雜度。因果圖太過復雜，很難人工完成，現在有許多工具可以代勞。
基于需求的測試的一個普遍障礙是需求規格說明模糊不清、可測試性差、不完整或根本不存在。并非所有的組織都會積極解決這些問題，如果面臨這種情況，測試人員必須另選測試策略。
有時另一種方法也會用到現有需求，那就是通過基于模型的方法，創建使用概況或運行概況，綜合使用測試用例、用戶（有時稱作人物角色）、輸入和輸出，以準確地展現該系統在現實中的應用。這么做不僅測試了功能性，同時還測試了易用性、互操作性、可靠性、安全性和性能。
在測試分析與計劃期間，測試團隊識別使用概況并嘗試用測試用例覆蓋這些概況。使用概況是一種基于可用信息，對軟件現實應用的估計。也就是說，和基于風險的測試一樣，使用概況可能無法完全展現最終的真實情況。不過，如果有充足的信息和干系人輸入的話，那么展現的情況就是恰當的（參見
[Musa04]）。
有些測試經理還會采用檢查表等有條理的方法來決定要測試什么，測試多少，以怎樣的順序測試。在產品非常穩定的情況下，一張列出了所有待測的主要功能和非功能區域的檢查表，加上現有的測試用例積累便足夠了。檢查表通常以發生變更的類型和數量為基礎，對測試分工和測試排序有啟發作用。但這種方法只在測試小變更時比較有效。
最后，另一種常用的方法就是應對型方法。在應對型方法中，測試執行之前做的測試工作很少。測試團隊關注的是應對實際交付的產品。當發現了缺陷群時，缺陷群就成了后續測試的焦點。測試優先級設定2012 版
? International Software Testing Qualifications Board
第 27 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
和分工不斷變化。應對型方法可以作為其它方法的補充，但如果單獨使用的話，它往往會漏掉程序中的一些至關重要的區域，僅僅因為（在這些區域中）沒有發現大量的缺陷。
2.3.4測試過程中的測試優先級設定和工作量分配
無論測試經理采用的是哪種技術——或者，更好的做法，混合使用一些技術——測試經理都必須將該技術融入項目及測試過程中。例如，在順序生命周期（如V模型）中，測試團隊在需求階段選擇測試、分配測試工作量，并開始設定測試的優先級，然后再進行定期調整，但迭代或敏捷生命周期則要求逐次迭代的方法。測試計劃和控制必須考慮到風險、需求、使用概況、以及做出相應反應的程度。
在測試分析、設計和實施期間，必須采用在測試計劃階段做的測試分工和設定的優先級。僅僅因為沒有使用該信息來指導后續的測試過程，會造成測試過程中的細致分析和／或建模的普遍障礙。這個障礙通常發生在設計和實施階段。
在執行測試時，還是應該使用在計劃階段設定的優先級，不過有一點很重要，在計劃制定后要根據獲取的信息定期更新優先級。在評估和匯報測試結果和出口準則狀態時，測試經理也必須從風險、需求、使用概況、檢查表和其它用于測試選擇和優先級設定的指導這些方面評估和匯報。必要時，需根據測試優先級方案對測試進行分類。
作為結果匯報和出口準則評估的一部分，測試經理可以衡量測試完成的程度，應包括將測試用例和發現的缺陷追溯到相關的測試依據。例如，在基于風險的測試中，隨著測試運行發現缺陷，測試人員可以檢測殘留的、剩余風險級別。這么做可以在使用基于風險的測試時知道發布的正確時機。測試匯報應提到覆蓋到的，仍未關閉的風險，以及已獲得或還未獲得的收益。基于風險覆蓋匯報測試結果的例子，參見[Black03]。
最后，在測試結束期間，測試經理應評估與所有測試干系人，包括客戶和用戶的質量方面的需求和期待相關的度量標準和成功準則。只有在測試滿足了這些需求和期待時，測試團隊才可以稱得上是真正有效的團隊。
2.4測試文檔和其它工作產品
文檔編制通常是測試管理活動的一部分。在不同的組織和項目中盡管測試管理文檔的具體名稱和每個文檔的范圍往往不一致，但組織和項目中常用的測試管理文檔有以下類型：
? 測試方針：描述組織的測試目標和目的
? 測試策略：描述組織中通用的、不按項目而變化的測試方法
? 主測試計劃（或項目測試計劃）：描述一個特定項目中測試策略的實施情況
? 級別測試計劃（或階段測試計劃）：描述在每個測試級別中所要進行的特定活動
這些類型的文檔的物理存在形式在不同的環境下可能不同。在某些組織和項目中可能合并成一個文檔，有時可能分成多個文檔，而有時則可能宣稱這些文檔中的某些內容是憑直覺去撰寫的、某些內容可能被忽略、或者將未修改的傳統測試方法寫入文檔。較大、較正式的組織和項目傾向于撰寫上述所有類型的文檔，并將其作為書面的工作產品予以保存，而較小、不太規范的組織和項目通常只會撰寫其中的一部分。雖然使用何種類型的文檔取決于組織和項目，但是本大綱將分別描述每一個文檔類型。
2012 版
? International Software Testing Qualifications Board
第 28 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.4.1測試方針
測試方針描述了組織為什么要進行測試。它定義了組織期望達到的總體測試目標。測試方針應由組織中的高級測試管理人員，在測試干系人組的高層經理的協助下制定。
在某些情況下，測試方針是更廣泛的質量方針的一部分或補充。質量方針描述質量管理的整體價值和目標。
測試方針可能是一份簡短的、概要的文檔：
? 總結組織驅動測試的價值
? 定義測試目標，如建立對軟件的信心，檢測軟件的缺陷，降低質量風險的級別（參見2.3.1節）
? 描述如何評估測試滿足這些目標的有效性和效率
?? 列出典型的測試過程，可能用ISTQB基礎測試過程作為基礎
? 說明組織將如何改進其測試過程（參見第5章）
測試方針應可針對新開發項目的測試活動，同時也針對維護項目的測試活動。測試方針也可以指定整個組織要使用的測試術語和測試工作產品的內部和／或外部參考規范。
2.4.2測試策略
測試策略文檔描述組織的通用測試方法，包括用測試管理產品和項目風險、測試級別的劃分和與測試相關的概要活動的方式。（同一個組織在不同情況下可能有不同的策略，例如不同的軟件開發生命周期，不同的風險級別，或不同的規定要求。）測試策略及其描述的測試過程和測試活動應與測試方針一致。它應該為組織或一個或多個項目提供通用測試入口和出口準則。
如上所述，測試策略描述一般測試方法，通常包括：
? 分析型策略，如基于風險的測試。在這種情況下，測試團隊分析測試依據，以識別要覆蓋的測試條件。例如，在基于需求的測試中，通過測試分析從需求中導出測試條件，再設計和實施測試來覆蓋這些條件。然后執行測試，通常用每個測試覆蓋的需求的優先級來決定測試運行的順序。從需求狀態方面匯報測試結果，如通過了測試的需求，測試了需求但未通過，還未完全測試需求，需求測試受阻，等等
? 基于模型的策略，如基于運行概況測試。在這種情況下，測試團隊開發一個模型，該模型展現了系統存在的環境（基于實際或期望的情況），系統應該接受的輸入和系統運行的條件，以及系統應如何運行。例如，在針對高速發展的移動設備應用程序的基于模型的性能測試中，基于當前的使用情況和項目隨著時間推移的發展情況，可能會開發出展現往來的網絡通信量、活躍和不活躍的用戶以及造成的處理負載的模型。另外，也可能開發出當前生產環境的硬件、軟件、數據容量、網絡和基礎設施的模型。還可能開發出理想的、預期的和最小的吞吐率、響應時間和資源分配的模型
? 基于方法的策略，如基于質量特征的測試。在這種情況下，測試團隊使用既定的一套測試條件，如測試規范（如ISO 9126）（ISO 9126標準正在被ISO 25000標準所取代），有關特定領域、應用或測試類型（如安全性測試）的一般化的邏輯測試條件的檢查表或集合，每個迭代或每次發布期間使用這一套測試條件。例如，在對一個簡單的，穩定的電子商務網站進行維護測試時，測試人員可能會用檢查表來識別每一頁的關鍵功能、屬性和環節。測試人員會在每次修改該網站時都會覆蓋檢查表上的相關要素
? 符合過程或標準的策略，如受制于美國食品藥品管理局（US FDA）標準的醫療系統的測試。在這種情況下，測試團隊遵循一系列由標準委員會或其它專家組制定的過程，這些過程使用文檔2012 版
? International Software Testing Qualifications Board
第 29 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
?
描述了，如何適當的識別和使用測試依據和測試基準，以及組建測試團隊。例如，在遵循敏捷管理技術的項目中，每次迭代期間測試人員分析描述特定特性的用戶故事，作為該迭代的計劃過程的一部分，估算測試每個特性所需的工作量，識別每個用戶故事的測試條件（通常稱為“驗收準則”），執行覆蓋這些條件的測試，執行測試時，將每個用戶故事的狀態（未測試、測試失敗或測試通過）匯報給團隊組長（通常稱為“Scrum Master”）
應對型策略，如缺陷攻擊測試。在這種情況下，測試團隊等到收到了軟件后才開始設計和實施測試，對待測的實際系統作出反應。例如，在對基于菜單的個人電腦應用程序進行探索性測試時，可能會開發出一套與特性、菜單選擇和屏幕對應的測試章程。每個測試人員都分到了一套測試章程，然后使用這些章程來組織探索性測試的會話。測試人員定期向測試經理匯報測試會話的結果，測試經理再根據發現的結果修改測試章程
咨詢式策略，如用戶導向的測試。在這種情況下，測試團隊根據一個或多個關鍵干系人的輸入決定要覆蓋的測試條件。例如，在對基于網站的應用程序進行外包兼容測試時，公司可能會提供外包的測試服務供應商一份瀏覽器版本、反病毒軟件、操作系統、連接類型和其它配置項的優先級清單，他們想要根據這份清單對照自己的應用軟件進行評估。然后測試服務供應商就可以用諸如結對測試（針對高優先級項）的測試技術和等價類劃分（針對低優先級項）來生成測試
反回歸測試策略，如廣泛采用自動化來進行測試。在這種情況下，測試團隊使用各種技術來管理回歸風險，尤其是一個或多級別的功能和／或非功能回歸測試自動化。例如，如果對一個基于網站的應用程序進行回歸測試，測試人員可以使用基于GUI的測試自動化工具來自動化該應用的一般和特殊用例。然后在每次修改該應用程序時執行這些測試
不同的測試策略可以相互組合。所選的測試策略應符合組織的需要和方法，并可根據其特定的業務或項目進行修改。
測試策略可描述要執行的測試級別。在這種情況下，應給出制定每個測試級別的入口準則和出口準則的概要指導以及這些測試級別之間的關系（例如，不同的測試級別對應不同的測試覆蓋目標）。
測試策略也可包括如下方面的內容：
? 集成規程
? 測試規約說明技術
? 測試獨立性（可根據不同的測試級別而有所變化）
? 必需的和可選的應遵守的標準
? 測試環境
? 測試自動化
? 測試工具
? 軟件工作產品和測試工作產品的可重用性。
? 確認測試（再測試）和回歸測試
? 測試控制和測試匯報
? 測試度量和度量標準
? 缺陷管理
? 測試件的配置管理方法
? 角色和職責
長期和短期的測試策略可能有必要區分開來。不同的測試策略適合不同的組織和項目。例如，對于安全關鍵的應用，應使用比其它應用更精確詳細的測試策略。此外，測試策略還因開發模型不同而異。
2012 版
? International Software Testing Qualifications Board
第 30 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.4.3主測試計劃
主測試計劃描述如何在特定的項目中所有待進行的測試工作，包括要執行哪幾個測試級別，以及這些級別之間的關系和測試級別與對應的開發活動之間的關系。主測試計劃應說明測試人員如何在這個項目中實施測試策略（即如何選擇測試方法）。主測試計劃應與測試方針和測試策略相一致，若有不一致，則應解釋為何會出現偏差和例外，以及該偏差可能導致的潛在影響。例如，如果組織的測試策略是在一個不變的系統即將發布之前進行一次完全通過的回歸測試，但當前的項目沒有回歸測試，那么它的測試計劃就應說明這么做的原因和將采取哪些行動緩解由與常用策略的偏差帶來的風險。測試計劃還應說明預期的由該偏差導致的影響。例如，跳過回歸測試可能要求在項目初次發布一個月后安排一次維護發布。主測試計劃描述了較大項目或業務中的測試工作，所以它應作為項目計劃或業務指南的補充。
主測試計劃的內容和結構根據組織、組織的文檔標準、項目形式的不同而變化，通常都會有以下部分：
? 測試項和不測試項
? 測試的質量屬性和不測試的質量屬性
? 測試進度安排和預算（應根據項目預算或組織運營預算調整）
? 測試執行周期及其與軟件發布計劃的關系
? 測試團隊與其它人或部門之間的關系和交付內容
? 對于每個測試級別定義要測試項和不測試項
? 每個測試級別的明確的入口準則、延續（暫停／繼續）準則和出口準則，以及這些測試級別之間的關系
? 測試項目的風險
? 測試工作的整體治理
? 執行每個測試級別的職責
? 每個測試級別的輸入和輸出
在一些較小的項目或業務中，若只設定一個正式的測試級別，那么可將主測試計劃和該級別的測試計劃合并成一個文檔。例如，如果系統測試作為唯一的正式測試級別，非正式的組件測試和集成測試由開發人員執行，非正式的驗收測試將作為 Beta 測試的一部分由客戶執行。在這種情況下，該系統測試計劃可包含本節中提到的內容。
另外，測試通常依賴于項目中的其它活動。若這些活動在其文檔中未充分定義，尤其是它們與測試的關系和對測試的影響，那么在主測試計劃（或相應的級別測試計劃）中應包含這些內容。例如，若沒有定義配置管理過程，則在測試計劃中應說明如何將測試對象交付給測試團隊。
2.4.4級別測試計劃
級別測試計劃描述在每個測試級別中所要進行的特定活動或測試類型。級別測試計劃拓展了主測試計劃中的特定級別或類型。它包含了進度安排、任務和里程碑等在主測試計劃中不一定包含的細節。另外，它還應包括該級別的測試規格說明應遵守的標準和使用的模板。
在不那么正式的項目或業務中，通常只有一份級別測試計劃作為測試管理文檔。在這種情況下，該級別測試計劃可包含本節前面所提到的要素。
對于敏捷項目，Sprint測試計劃或迭代測試計劃可以替代級別測試計劃。
2012 版
? International Software Testing Qualifications Board
第 31 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.4.5項目風險管理
適當的項目計劃的一個重要部分就是處理風險。項目風險的識別可以使用2.3節中所述的類似的過程。當識別出風險后，就應該告知項目經理，再由項目經理制定對策。這種風險的緩解并不總是測試組織力所能及的。然而，有些風險是可以而且應該由測試經理成功緩解的，如：
? 測試環境和工具的就緒
? 測試人員的可用性和能力
? 缺乏測試工作的標準、規則和技術
管理項目風險的方法包括盡早準備測試件、預測試的測試環境，預測試產品的早期版本，使用更嚴格的測試入口準則，加強需求的可測性、參與項目早期工作產品的評審、參與對變更的管理、以及監控項目的進展和質量。
在識別和分析了項目風險后，管理風險有以下四種方案：
1. 緩解風險，通過預防性措施降低風險的可能性和／或影響
2. 制定應急計劃，降低風險成為事實后的影響
3. 將風險轉移給其它方來處理
4. 忽略或接受風險
最佳方案的選擇取決于各方案帶來的利益和機會，需花費的成本，以及和它們相關的潛在的任何額外風險。如果為某個項目風險確定了應急計劃，最佳實踐是同時確定應急計劃的觸發時間（以此確定觸發應急計劃的時機和方式）和所有者（開展應急計劃的人）。
2.4.6其它的測試工作產品
測試會生成許多其它的工作產品，如缺陷報告、測試用例規格說明和測試日志。其中大部分都是由測試分析師和技術測試分析師編制。在測試分析師大綱中，討論了生成工作產品和編制相關文檔的考慮因素。測試經理應該確保這些工作產品在下列活動中的一致性與質量：
? 建立并度量，以監控這些工作產品的質量，如被拒絕的缺陷報告的比例
? 和測試分析師、技術測試分析師一起選擇和（根據需要）定制工作產品的適當模版
? 與測試分析師、技術測試分析師一起建立工作產品的標準，如測試、日志和報告需要詳細到什么程度
? 選擇適當的參與人和干系人并使用適當的技術對工作產品進行評審
測試文檔的范圍、類型和特性主要取決于選定的軟件開發生命周期、可用的標準和法規和開發的特定系統的產品質量和項目風險。
測試工作產品的模版有許多來源，如IEEE 829。測試經理要記住IEEE 829標準適用于任何行業。因此，該模版中包括了很多非常詳細的內容，其中有一些可能并不適用于特定組織。最佳實踐是對IEEE
829進行裁剪，為特定的組織創建自己的標準模版。模版的一致應用會減少培訓需求并且幫助組織內部統一過程。
測試還會生成測試結果報告，這些報告通常由測試經理編制，本章稍后將介紹測試結果報告。
2012 版
? International Software Testing Qualifications Board
第 32 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
2.5測試估算
作為一種管理活動，估算是為了得到特定業務或項目中各種活動的成本和完成日期的近似目標。最好的估算：
? 代表有經驗的實際工作者的集體智慧，并能得到相關參與人員的支持
? 提供具體詳盡的，關于資金、資源、任務和相關人員的清單
? 指出每個被估算活動的最可能的成本、工作量和周期
盡管為估算建立了項目管理最佳實踐，但軟件工程和系統工程的估算依舊充滿了困難，包括技術上的和政治上的困難。估算是就是將最佳實踐應用到與項目或業務有關的測試活動中。
測試估算應包含第一章所描述的測試過程中的所有活動。由于測試執行通常在項目的關鍵路徑上，所以管理人員會對測試執行的成本、工作量、特別是測試執行持續時間的估算值非常感興趣。然而，當軟件的整體質量很差或未知時，對測試執行進行估算往往會比較困難，并且估算的結果也不可靠。此外，對系統的熟悉程度和經驗水平也很可能影響估算的質量。常用的做法是估算需要執行的測試用例數，但這僅僅適用于當可以假定待測軟件中的缺陷較少時。在估算過程中所作的假定應記錄在估算的文檔中。
測試估算應考慮影響測試活動的成本、工作量和持續時間等所有因素。這些因素包括（但不僅限于此）：
? 系統質量所要求的級別
? 待測系統的規模
? 以前測試項目的歷史數據，也可包括行業數據或其它組織的基準數據
? 過程因素，包括測試策略、開發或維護生命周期和過程成熟度，以及項目估算的準確度
? 物質因素，包括測試自動化和工具、測試環境、測試數據、開發環境、項目文檔（如需求文檔、設計文檔等）、以及可復用的測試工作產品
? 人員因素，包括經理和技術組長、高級行政管理人員的承諾和期望、項目團隊的技能、經驗和態度、項目團隊的穩定性、團隊成員之間的關系、測試和調試環境的支持、是否有熟練的承包商和顧問、以及相關領域的知識
? 過程、技術和組織的復雜度、測試干系人的人數、子團隊的組成和位置
? 項目啟動、培訓和定向需求
? 新工具、技術、定制硬件、大量測試件的熟悉和開發
? 非常詳細的測試規約說明的要求，特別是要符合不熟悉的文檔標準
? 難以確定的組件交付時間，特別是對于集成測試和測試開發而言
? 敏感的測試數據（如對時間敏感的數據）
交付的待測軟件的質量也是測試經理在估算時應該考慮的一個主要方面。例如，如果開發人員已經采用了最佳實踐，如自動化的單元測試和持續集成，那么在將代碼交付給測試團隊之前，多達50%的缺陷就已經被清除了（關于這些實踐的缺陷清除有效性的更多內容，參見 [Jones11] ）。一些報道稱使用敏捷方法，包括測試驅動開發，交付的待測件質量較高。
估算可以自底向上進行，也可以自頂向下進行。在測試估算中可以單獨或組合使用的技術有下列幾種：
? 直覺、猜測和以往經驗
? 工作分解結構（WBS）
? 團隊估算會議（如寬帶德爾菲法）
? 公司標準和規范
? 測試占整個項目工作量的百分比或人員編制（例如，測試人員與開發人員的比例）
2012 版
? International Software Testing Qualifications Board
第 33 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
組織的歷史和度量，包括基于度量的模型，該模型用于估算缺陷數、測試周期數、測試用例數、每個測試的平均工作量以及回歸周期的數目
工業平均值和預估模型，例如功能點、代碼行數、估計的開發工作量或其它項目參數（如參見[Pol01] ）
大多數情況下，得出估算值后，需要提交給管理人員，并說明理由（請參見 3.7 節）。通常，隨后進行協商，協商的結果常常是需要重新進行估算。理想情況下，最終的測試估算代表了組織和項目目標在質量、進度安排、預算以及特性方面的最佳平衡。
要記住任何估算結果都是基于進行估算時可用的信息。項目早期信息可能比較有限，而且在項目早期已經可用的信息后面也可能發生變化。為了保持準確性，應該更新估算結果來反映新的信息和變更過后的信息。
2.6定義和使用測試度量
管理上有這樣一句名言，進行度量的工作才會得到有效的執行。反之，因為很容易忽略那些不進行度量的工作，所以不進行度量的工作通常不會得到有效的執行。因此，對于包括測試在內的任何活動，建立適當的度量都是很重要的。
測試度量可以劃分到以下的一種或多種類型中：
? 項目度量，對照既定的項目出口準則，如測試用例執行率、通過率和失敗率，度量項目進展
? 產品度量，度量產品的某些屬性，如測試程度和缺陷密度
? 過程度量，度量測試或開發過程的能力，如通過測試發現的缺陷百分比
? 人員度量，度量個人或小組的能力，如在給定的時間內測試用例的實施情況
任何給定的度量都屬于以上的兩種、三種、甚至四種類型。例如，體現每日缺陷發現率的趨勢圖可以與以下內容都相關：出口準則（連續一周都未發現新缺陷）、產品質量（測試無法再找出產品的缺陷）、和測試過程的能力（在執行測試的前期發現了大量缺陷）。
人員度量尤為敏感。測試經理有時會把過程度量誤認為是人員度量，導致大家為了讓該度量對他們更有利而采取一些行動，產生災難性的后果。本大綱第7章和專業測試經理大綱中討論了對測試人員的適當激勵和評估。
在高級大綱中，我們主要關注的是使用度量來衡量測試工作的進展，如項目度量。某些用于衡量測試進展的項目度量也關系到產品和過程。在專業測試經理大綱中描述了更多關于管理產品和過程度量的使用的內容。在改進測試過程的專家級大綱中描述了更多關于使用過程度量的內容。
度量的使用可以讓測試人員在匯報結果時保持一致，而且可以連貫地跟蹤測試進展。測試經理通常被要求在各種會議上展示度量數據，這些會議的參與人可能包括從技術人員到執行管理層的各級別的用戶。因為有時確定一個項目整體成功與否也會用到這些度量數據，在決定需要跟蹤什么內容，匯報的頻率和呈現這些信息的方式時都需要特別留意。需要強調的是，測試經理必須考慮以下內容：
? 度量的定義：應定義一組有限的有用度量。度量的定義依據項目、過程和／或產品的具體目標。定義度量時應考慮到平衡，因為單個的度量可能會誤導對狀態或趨勢的印象。對這些定義的度量的解讀必須得到所有干系人的認可，避免討論這些度量時產生混亂。經常發生定義了過多的度量而沒有關注那些最相關的度量的情況
2012 版
? International Software Testing Qualifications Board
第 34 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
?
度量的追蹤：應該盡可能自動化度量報告和匯總，以縮短采集和處理度量數據的時間。隨時間的推移，特定的度量數據可能會反映出和度量定義階段約定的解讀不同的信息。測試經理應做好準備，仔細分析這些度量數據和期待可能出現哪些偏差，以及造成偏差的原因
度量的匯報：目的是幫助管理層迅速理解所獲得的信息。應呈現對某段時間度量的“快照”或度量隨時間推移的變化，這樣才能進行趨勢分析
度量的有效性：測試經理還必須驗證匯報的信息。為某個度量收集的數據可能無法反應項目的真實情況或可能傳達了過于樂觀或過于悲觀的趨勢。在呈現數據前，測試經理必須就數據的準確度和可能傳達的信息兩方面對數據進行評審
監控測試進展主要就以下五個方面：
? 產品（質量）風險
? 缺陷
? 測試
? 覆蓋率
? 信心
在項目和業務中，產品風險、缺陷、測試和覆蓋率可以，且通常有特定的方式進行度量和匯報。如果這些度量數據和測試計劃中定義的出口準則相關，他們可以作為判斷測試工作是否完成的客觀標準。信心的度量可以通過調查或使用覆蓋率作為替代度量，不過通常還會以主觀的方式匯報信心。
與產品風險相關的度量包括：
? 通過了測試的完全覆蓋的風險的百分比
? 測試失敗的風險的百分比
? 還未完全測試的風險的百分比
? 按風險類別劃分的覆蓋的風險百分比
? 在初次質量風險分析后識別的風險的百分比
與缺陷相關的度量包括：
? 已報告（發現）的缺陷總數對比已解決（修復）的缺陷總數
? 失效的平均時間間隔和失效出現率
? 按下列分類統計的缺陷數或百分比
o 特定的測試項或組件
o 根本原因
o 缺陷來源（如需求規格說明、新特征、回歸等）
o 測試發布
o 引入、發現和移除缺陷的階段
o 優先級／嚴重程度
o 拒絕或重復的報告
? 從報告缺陷到修復缺陷所花的時間趨勢
? 引入了新缺陷（有時也稱子缺陷）的缺陷修復數
和測試相關的度量包括：
? 已計劃的、已詳細說明（已實施）的、已運行、通過的、失敗的、無法執行的和跳過不執行的測試總數
? 回歸測試和確認測試的狀態，包括趨勢和未通過的回歸測試總數及未通過的確認測試總數
? 計劃的每日測試時長對比實際的每日測試時長
2012 版
? International Software Testing Qualifications Board
第 35 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
? 測試環境的可用性（準備測試團隊可用的測試環境占計劃測試時長的百分比）
和測試覆蓋率相關的度量包括：
? 需求和設計要素的覆蓋率
? 風險覆蓋率
? 環境／配置覆蓋率
? 代碼覆蓋率
重要的是測試經理要知道怎樣去解讀和使用覆蓋率的度量，以便理解和報告測試狀態。對于級別較高的測試，如系統測試、系統集成測試和驗收測試，主要的測試依據通常是需求規格說明、設計規格說明、用例、用戶故事、產品風險、支持環境和支持配置等工作產品。結構化的代碼覆蓋率度量更適用于級別較低的測試，如單元測試（如語句和分支覆蓋）和組件集成測試（如接口覆蓋）。測試經理可能使用代碼覆蓋的度量數據來衡量測試覆蓋待測系統的程度，但在匯報較高級別的測試結果時，通常不會提到代碼覆蓋的度量。此外，測試經理應該知道即便單元測試和組件集成測試達到了結構覆蓋目標的100%，缺陷和質量風險仍有待較高級別的測試來處理。
度量也可以連系到基本測試過程中的活動（在基礎級大綱和本大綱中有描述）。這樣一來，在整個測試過程中，就可以對照項目目標和測試過程本身，使用度量數據來監督測試過程本身以及達成項目目標的進展。
和監控測試計劃和控制活動相關的度量包括：
? 風險、需求和其它測試依據要素的覆蓋率
? 缺陷發現情況
? 計劃開發測試件和執行測試用例的時長對比實際的時長
和監控測試分析活動相關的度量包括：
? 識別的測試條件數
? 測試分析中發現的缺陷數（如通過使用測試依據識別風險或其它測試條件）
和監控測試設計活動相關的度量包括：
? 測試用例覆蓋的測試條件百分比
? 測試設計中發現的缺陷數（如通過對照測試依據開發測試）
和監控測試實施活動相關的度量包括：
? 測試環境配置的百分比
? 測試數據記錄加載的百分比
? 測試用例自動化的百分比
和監控測試執行活動相關的度量包括：
? 執行、通過和失敗的測試占已計劃的測試的百分比
? 執行（和／或通過）的測試用例覆蓋的測試條件的百分比
? 計劃與實際的報告／解決的缺陷對比
? 計劃與實際達到的覆蓋率的對比
2012 版
? International Software Testing Qualifications Board
第 36 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
監控測試進展和測試完成活動的度量包括里程碑、入口準則和出口準則（測試計劃中定義和批準的）的映射，其中可能包括以下內容：
? 計劃的測試條件、測試用例或測試規約說明的數目和按測試是否通過分別統計的執行的測試條件、測試用例或測試規約說明的數目
? 總缺陷數，通常按嚴重程度、優先級、目前狀態、受影響的子系統或其它分類統計（見第4章）
? 要求的、接受的、開展的和測試過的變更數
? 計劃成本對比實際成本
? 計劃工期對比實際工期
? 測試里程碑的計劃日期對比實際日期
? 有關測試的項目里程碑（如代碼凍結）的計劃日期對比實際日期
? 產品（質量）風險狀態、通常按已緩解與未緩解的風險，主要的風險區域、測試分析后發現的新風險等分類統計
? 由于阻塞事件或計劃的變更導致的測試工作量、成本或時間損失的百分比
? 確認和回歸測試狀態
和監控測試結束活動相關的度量包括：
? 測試執行期間已執行的、通過的、失敗的、無法執行的和跳過不執行的測試用例的百分比
? 納入可復用的測試用例庫的測試用例的百分比
? 自動化的測試用例的百分比或計劃的與實際的自動化的測試用例百分比對比
? 并入回歸測試的測試用例的百分比
? 已解決／未解決的顯著缺陷報告的百分比
? 識別和歸檔的測試工作產品的百分比
另外，標準的項目管理技術，如工作分解結構，通常被用來監控測試過程。在敏捷團隊中，測試是燃盡圖上用戶故事進展的一部分。使用精益管理技術時，通常是通過將用戶故事卡從看板圖上穿過一列來監控以逐次故事為基礎的測試過程。
在給定了一組度量標準后，度量數據可以通過口頭陳述、在表格中以數值的形式，或用圖形來進行匯報。度量數據可以有很多用途，包括：
? 分析，找出可從測試結果中觀察到的趨勢和原因
? 匯報，將測試結果告知感興趣的項目參與人和項目干系人
? 控制，改變整個測試或項目的過程和監控過程糾正的結果
收集、分析和報告這些測試度量數據的適當方式取決于具體的信息需要、目標和使用這些度量數據的個人能力。另外，測試報告的具體內容也應該根據不同的讀者而變化。
為了測試控制的需要，有一點很重要，整個測試過程（測試計劃完成后）的度量數據要提供測試經理指導測試工作成功地完成測試使命，測試策略和實現測試目標所需的信息。因此計劃時一定要考慮到信息需要，監控時一定要包括收集任何需要的工作產品度量。需要的信息量和采集信息需要的工作量取決于各種項目因素，包括項目規模、復雜度和風險。
測試控制一定要回應測試產生的信息和項目或活動存在的不斷變化的環境。例如，如果動態測試在某些認為不可能有很多缺陷的區域發現了缺陷群，又如由于測試開始時間延遲導致測試執行周期縮短，則必2012 版
? International Software Testing Qualifications Board
第 37 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
須對風險分析和計劃作出修改。這么做可能需要對測試優先級重新設定和對剩余的測試執行工作重新進行分配。
如果通過測試進展報告發現與測試計劃出現了偏差，則應執行測試控制。測試控制的目的是為項目和／或測試重新定向到更可能取得成功的方向。當根據測試結果影響和衡量項目中的控制工作時，需要考慮以下內容：
? 修改質量風險分析、測試優先級和／或測試計劃
? 增加資源或增加項目或測試工作量
? 推遲發布日期
? 放松或加強測試出口準則
? 改變項目的范圍（功能或非功能）
實施這些內容通常需要項目或業務干系人之間達成共識，并且取得項目或業務經理的同意。
測試報告中發布的信息應該大部分取決于目標讀者，如項目管理人員或業務管理人員的信息需要。項目經理最可能感興趣的是關于缺陷的詳細信息，而業務經理最關注的可能是產品風險的狀態。
2.7測試的商業價值
測試經理必須努力優化測試，以確保發揮好的商業價值。過量測試無法發揮好的商業價值，因為測試強加的不合理的延時和成本要比通過測試節約的時間和成本更高。測試不足也無法發揮好的商業價值，因為交付給用戶太多的缺陷。最佳的方案介于兩者之間。測試經理一定要幫助測試干系人理解這個最佳方案和測試發揮的價值。
雖然大多數組織認為測試在某種意義上是有價值的，但很少有管理人員，包括測試經理，可以量化、描述或明確界定測試的價值。另外，許多測試經理、測試組長和測試人員關注測試戰術上的細節（測試任務或測試級別方面），卻忽略了與測試相關的更大的戰略上（更高級別）的問題，而這些問題恰恰是其它項目參與者，尤其是管理人員關注的部分。
測試為組織、項目和／或業務帶來了定量和定性的價值：
? 定量的價值，包括發現缺陷并在產品發布前預防或修復這些缺陷、發現缺陷并了解在產品發布前依舊存在的缺陷（未修復但有相關文檔記錄，且可能采取了變通方法）、通過運行測試減少風險并發布了有關項目、過程和產品狀態的信息
? 定性的價值，包括提高產品質量的聲譽、使發布更順利和更可預測、增加對產品的信心、降低產品功能失效甚至造成人員傷亡的可能性，避免承擔法律責任
測試經理應知道哪些價值對他們的組織、項目和／業務有意義，并能在溝通測試情況時將測試與這些價值聯系起來。
一種用于度量測試的定量價值和效率的成熟方法稱為質量成本（或有時稱為不良質量成本）。質量成本方法將項目和運行的成本分成與產品缺陷成本相關的四個類別：
? 缺陷預防成本，例如培訓開發人員，提高他們編寫的代碼的可維護性和安全性
? 缺陷檢測成本，例如編寫測試用例，配置測試環境和評審需求
? 內部失效成本，例如在發布之前，測試或評審期間，修復發現的缺陷
? 外部失效成本，例如將有缺陷的軟件發布給客戶導致的支持成本
2012 版
? International Software Testing Qualifications Board
第 38 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
部分測試預算是用于支付缺陷檢測成本（即便在測試人員沒有找到缺陷的情況下也會花費的成本，比如開發測試花費的錢），而剩余的用于支付內部失效成本（與找到的缺陷相關的實際成本）。缺陷檢測成本和內部失效成本的總和通常會比外部失效成本低很多，而這正是測試的價值所在。測試經理可通過列出這四類成本來作一個有說服力的商業用例，以說明測試的價值。
更多關于測試的商業價值，包括質量成本的內容參見 [Black03]。
2.8分布式測試、外包測試以及內包測試
很多時候，有些，甚至可能所有的測試工作都是由身處異地的人員完成的，這些人為不同的公司工作，或完全獨立于項目團隊之外。如果測試工作分散在不同地點，則被稱為分布式測試。如果承擔測試工作的人員與開發團隊不同屬一個公司，同時測試工作又是在非開發地點進行的，則被稱為外包測試。若測試工作由其它與項目團隊在同一地點的非同公司成員承擔，則被稱為內包測試。
對于上述所有類型的測試，需要明確團隊之間的溝通方式，并明確定義關于使命、任務和交付內容的期待。項目團隊必須減少對非正式交流渠道的依賴，如在走廊上的對話或同事之間的私人交流。定義應有的溝通方式是很重要的，定義的范圍應該包括處理問題升級等內容，通過交流要傳達的信息類型和溝通的方式。團隊各方干系人都必須清楚知道自己以及他人的角色和職責，避免產生誤解或不切實際的期待。地點、時區、文化和語言的差異使得這些工作變得更加重要。
對于上述所有類型的測試，另一個共同點是各個團隊要使用一致的方法。盡管在任何項目中都可能發生方法不一致的情況，但在分布式和／或由其它公司執行測試時，這種情況發生的可能性更高。如果測試小組之間或測試小組、開發小組、管理人員之間使用各自不同的方法，那么可能造成嚴重的問題，尤其是在測試執行期間。 例如，如果客戶使用敏捷開發，而測試服務供應商預先定義的測試方法是假設使用順序生命周期，那么測試件交付給供應商的時間以及性質就會成為雙方爭論的焦點。
對于分布式測試，不同工作地點之間的測試分工必須要明確、合理。如果不這么做的話，可能導致把測試工作分配給不具備相應能力的測試小組。另外，如果每個小組不知道自己負責哪部分工作的話，那他們可能就不會做他們本該做的事。對于各小組的期待必須要傳達清楚。如果缺乏細致的管理，整個測試工作可能遭受差距（增加產品發布的殘余質量風險）和重復（導致降低效率）的困擾。
最后，對于各種類型的測試，整個項目團隊建立并維持對測試團隊的信任非常重要。要相信各個測試團隊雖然在組織、文化、語言和地理位置上有所不同，但他們依舊能很好地履行他們的職責。缺少信任會導致低效和延遲。缺少信任會引起驗證彼此的活動、相互追究問題的責任以及上演組織政治斗爭這類問題，進而造成低效和延期。
2.9 管理行業標準的使用
在基礎大綱和高級大綱中，都參考了許多標準。這些參考標準涉及到軟件開發生命周期、軟件測試、軟件質量特征、評審和缺陷管理。測試經理應該知道這些標準，所在組織對使用這些標準的方針，以及他們是否必須或有必要使用這些標準，或使用標準是否有幫助。
標準可以有不同的來源，例如：
? 國際標準或具有國際性目標的標準
? 國家標準，如國際標準在某個國家的國內版
? 專業領域特定的標準，如對國際標準或國家標準進行裁剪，以應用到特定的領域，或是為某個專門的領域開發的國際或國家標準
2012 版
? International Software Testing Qualifications Board
第 39 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
國際標準機構包括ISO和IEEE。ISO是國際標準組織，又稱IOS，國際標準化組織。國際標準化組織是由各國標準化團體（ISO成員團體）組成的世界性的聯合會，它們為軟件測試人員提供了許多有用的標準，例如ISO 9126（將被ISO 25000取代）、ISO 12207和ISO 15504。
IEEE是電氣與電子工程師協會，它是一家被一百多個國家承認的美國專業組織。該組織同樣為軟件測試人員提供了許多有用的標準，例如IEEE 829和IEEE 1028。
許多國家都有自己的國家標準，其中的某些標準可用于軟件測試。例如英國的BS-7925-2:1998，該標準提供了很多關于在高級測試分析師和高級技術測試分析師大綱中描述的測試設計技術的信息。
有些標準是專門用于特定行業領域的，其中的某些標準可用于軟件測試、軟件質量和軟件開發。例如，在航空電子領域，美國聯邦航空管理局的標準DO-178B（等同于歐盟的ED 12B）適用于民用飛機中使用的所有軟件。該標準規定了根據待測軟件的關鍵程度的不同，相應級別的結構化覆蓋標準。
另一個領域特定標準的例子是醫療體系中的美國食品與藥品管理局的第820章21條的內容。該標準引?薦了一系列結構化測試技術和功能測試技術，同時還引薦了一系列與ISTQB大綱相一致的測試策略和原則。
有些時候，標準和方法并不專注與測試領域，但它們對于測試所處的軟件開發上下文影響卻十分重大。?
這里有個例子，CMMI軟件過程改進框架，其中包含了兩個重要的過程域，驗證和確認。對驗證和確認的解讀通常是他們指的是測試的不同級別（如系統測試和驗收測試）。驗證和確認還涉及到測試策略，通常被解讀成要求在測試策略中納入分析型基于需求的測試。
? ?還有幾個重要的例子，PMI的PMBOK、PRINCE2和ITIL。PMI和PRINCE 2是北美和歐洲使用較?
廣泛的項目管理框架。ITIL是用于確保IT團隊能向其所在的組織交付有價值的服務的一個框架。在這?些框架中提到的術語和活動與ISTQB大綱和術語表中提到的有很大區別。如果所在的組織使用PMI的?PMBOK、PRINCE2和／或ITIL，測試經理必須充分了解選定的框架、框架的實施和相關術語，以便在該組織中能有效地工作。
無論采用的是什么標準或方法，記住這些方法和標準都是由一組專業人員制定的。標準體現了這些專業人員的集體的經驗和智慧，但也體現了他們的不足。測試經理應該了解他們所處的環境和背景中采用的標準，無論是正式標準（國際標準、國家標準或行業特定標準）或是組織自身的標準和推薦實踐。
在考慮使用多個標準時，記住某些標準可能和其它標準不一致，或甚至出現定義上的沖突。測試經理應該決定不同標準在測試所處的上下文中的用處。某個標準中闡述的信息可能會對項目有正向作用，也可能會起到反作用。然而，通過這些標準，可以參考已證實的最佳實踐，并且提供組織測試過程的基礎。
有些時候，符合標準是強制性的，而且也涉及到測試。測試經理必須知道與標準符合情況相關的所有要求，確保維持適當的符合度。
2012 版
? International Software Testing Qualifications Board
第 40 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
3. 評審 – 180 分鐘.
關鍵詞
審計（audit）、非正式評審（informal review）、審查（inspection）、管理評審（management
review）、主持人（moderator）、評審（review）、評審計劃（review plan）、評審員（reviewer）、技術評審（technical review）、走查（walkthrough）
評審學習目標
3.2管理評審和審計
TM-3.2.1 (K2) 了解管理評審和審計的關鍵特性
3.3對評審的管理
TM-3.3.1 (K4) 分析項目，選擇適宜的評審類型并定義開展評審的計劃，確保評審得到適當的實施、跟進，和確定責任
TM-3.3.2 (K2) 了解參與評審需要的因素，技能和時間
3.4評審的度量
TM-3.4.1 (K3) 定義評審使用的過程和產品度量
3.5管理正式評審
TM-3.5.1 (K2) 舉例說明正式評審的特點
2012 版
? International Software Testing Qualifications Board
第 41 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
3.1 簡介
ISTQB基礎級大綱把評審作為對產品的靜態測試活動引入。審計和管理評審更關注測試過程而不是軟件工作產品。
評審作為一種靜態測試，測試經理可能要對其成功實施負責，尤其是在涉及測試件產品的時候。然而，從更廣的軟件項目的角度來說，這項責任應該屬于組織方針。由于不管在有軟件項目之前還是軟件項目當中，正式評審都可能在各個領域廣泛應用，責任方可能是測試經理、質量保證經理或經過培訓的評審協調員。在本大綱中，責任方（無論是誰）被稱為評審組長。
評審組長應該確保現實條件與ITSQB基礎大綱里定義的、保證測試成功實施的因素相符合。另外，評審組長還應編制度量計劃以確保評審帶來成效。
因為測試人員對軟件系統的操作行為和軟件系統必須具備的特性有深入的了解，所以他們的參與對評審過程是非常重要的。
評審的參與人員應該接受評審的培訓，了解在評審過程中各自的角色。所有的評審參與人都必須盡力實現一個好的評審應帶來的效益。
評審如果進行得當，對整體交付的質量來說，是性價比最高的質量保證方法。因此，評審組長能夠在其項目中實施有效的評審并證明這些評審的收益尤為重要。
項目可能進行的評審有：
? 合同評審，項目開始啟動和項目主要里程碑點
? 需求評審，在需求可以被評審時發起，最好同時覆蓋功能和非功能需求
? 概要設計評審，在整體架構設計可被評審時發起
? 詳細設計評審，在詳細設計可被評審時發起，一般在編碼工作開始之前
? 代碼評審，在單個軟件模塊生成時進行，可能包括單元測試及其結果以及代碼本身
? 測試工作產品評審，可能覆蓋測試計劃、測試條件、質量風險分析結果、測試、測試數據、測試環境和測試結果
? 每個測試級別的測試入口（測試準備性）評審和測試出口評審，分別在測試執行開始前檢查測試入口準則，和結束測試前檢查測試出口準則
? 驗收評審，用于獲取客戶或干系人對系統的批準
?
在對產品實施多種評審的基礎上，評審組長需謹記雖然通過評審可以識別缺陷，但也要在實施評審的同時，結合其它的靜態測試（如靜態分析）和代碼的動態測試。通過結合這些測試技術能提高測試覆蓋率，并將識別出更多的缺陷。
不同的技術有不同的側重點，例如，評審可以在編碼前就消除需求的問題，避免將該問題引入到代碼中。靜態分析可以協助編碼規范的執行，并識別出通過檢查工作產品難以識別的問題。審查不僅能發現和移除缺陷，還能訓練作者如何避免在其工作產品中生產缺陷。
?ISTQB基礎大綱介紹了以下幾種評審：
? 非正式評審
? 走查
? 技術評審
? 審查
2012 版
? International Software Testing Qualifications Board
第 42 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
除上述評審之外，測試經理也可能參與：
? 管理評審
? 審計
3.2管理評審和審計
管理評審用于監督進度，評估狀態和對未來活動做決策。此類評審支持項目未來的決策，如調整資源等級，實施糾正措施或改變項目范圍。
管理評審的關鍵特性如下：
? 由或為直接負責項目或系統的經理組織
? 由或為某個干系人或決策者組織，例如更高級別的經理或主管
? 檢查計劃之間的一致性與偏差
? 檢查管理規程的充分性
? 評估項目風險
? 評估行動的影響和衡量影響的方法
? 提供行動，待解決問題和決策的清單
過程的管理評審，如項目回顧（例如，經驗教訓），是過程改進活動的組成部分。
測試經理應該參與還可以發起針對測試進度的管理評審。
審計一般用來展現對既定準則，如適用的標準，規章限制，或者合同義務的符合性。也就是說，審計的目的是獨立評估過程、規章、標準的符合性。審計的關鍵特性如下：
? 由一位審計組長組織和主持
? 通過訪談、見證和檢查文檔收集符合性的證據
? 記錄的結果包括觀察結果、建議、糾正措施和通過／不通過的評價
3.3對評審進行管理
評審應該安排在軟件項目的自然轉換點或里程碑。一般來說，應該在定義了需求和設計后舉行相關的評審。評審以商業目標為起點，到設計的不可再分的級別，自上而下地進行。管理評審應該在項目的主要里程碑點進行，一般作為測試執行和其它主要項目階段之前、過程中、之后的驗證活動的一部分。評審策略必須與測試方針和總體測試策略一致。
在制定項目的總體評審計劃前，評審組長（有可能是測試經理）應考慮：
? 評審的對象（產品和過程）
? 評審的參與人
? 需要覆蓋的相關風險因素
在項目計劃階段初期，評審組長應該識別評審的對象，選擇適當的評審類型（非正式評審、走查、技術評審或審查，或兩、三種類型的混合），以及正式程度。在此，建議提供額外的評審培訓。在確定上述內容后，測試經理可以分配評審過程的預算（時間和資源）。決定預算時應考慮到風險的評估和投資回報的計算。
2012 版
? International Software Testing Qualifications Board
第 43 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
評審的投資回報是進行評審的成本和不進行評審在項目后期才應對相同的缺陷（或完全遺漏這些缺陷）的成本之間的差別，所節省的成本和時間進行計算。這里可以使用2.7節所述的質量成本計算方法來確定這個數值。
執行評審的最佳時機的確定取決于以下方面：
? 待評審項是否有足夠確定的版本可用
? 合格的評審參與人的是否有時間參與
? 最終版的評審對象應該到位的時間
? 特定評審對象的評審過程所需時間
評審組長應在計劃測試時充分定義用以評估評審的度量。如果使用審查，應該在文檔組成部分完成時（如單個需求或章節）按作者的要求進行簡要審查。
在計劃測試期間，必須定義評審過程的目標，包括有效和高效地開展評審，以及就評審反饋達成共識。
項目評審多數針對整個系統進行，但對于子系統甚至單個軟件要素也可能是必要的。應該根據項目規模和復雜度以及產品風險決定評審的次數、評審的類型、評審組織以及涉及的人員。
為了保證效率，評審參與人必須有足夠的技術和規程方面的知識，除了這些，為了讓評審有效，還需要參與人有其它的一些技能，如嚴謹和關注細節。好的評審意見必須足夠清晰且按照恰當的優先級排列。對規程知識的需要可能意味著有必要進行一些培訓，確保評審人員了解他們在評審過程中的角色和職責。
評審計劃應該考慮到與進行評審時的技術、組織和人員相關的評審風險。是否有足夠技術知識的評審人員的參與對評審成功與否是非常關鍵的。項目中所有的團隊都應該參與評審計劃的制定，以確保所有團隊都對評審過程的成功做出承諾。計劃時必須確保每個組織為評審人員分配了足夠的準備和參與時間，他們能按照項目進度安排的評審節點參與評審。同時，也應該為評審人員安排接受所需的技術和過程培訓的時間。測試經理還必須識別關鍵評審人員的后備人選，以防關鍵評審人員因為個人原因或工作原因無法參與評審。
在實際執行正式評審時，評審組長必須確保：
? 參與人提供的度量數據足以評估評審效率
? 編制了檢查表，檢查表也得到了維護以改進以后的評審
? 針對評審發現的缺陷定義了缺陷嚴重程度和優先級評估，用于缺陷管理（見第4章）
每次評審后，評審組長應該：
? 收集評審度量和確保識別的問題得到了充分的解決，符合評審特定的測試目標
? 使用評審度量作為確定最終的評審投資回報率（ROI）的輸入
? 向相關干系人提供反饋信息
? 向評審參與人提供反饋
為了評價評審的有效性，測試經理可以把后續測試（即評審之后）的實際結果與評審報告上的結果進行比較。對于經過評審批準的工作產品，如果后面發現缺陷較多，評審組長應該考慮評審過程中可能會讓缺陷遺漏的地方。可能的原因包括評審過程的問題（如入口／出口準則不當）、評審組組成不當、評審工具（檢查表等）不充分、評審員培訓和經驗不足以及評審準備和會議時間太短。
遺漏缺陷（尤其是嚴重缺陷）的模式在若干項目重復出現，說明評審的開展有嚴重問題。這種情況下，評審組長需要檢查過程并采取適當的措施。也有可能因為各種原因，經過了一段時間后，評審不再有2012 版
? International Software Testing Qualifications Board
第 44 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
效。這種情況在項目回顧中會得到揭示，當評審發現的缺陷的百分比降低時。這時評審組長也必須調查原因并予以解決。無論在什么情況下，評審度量數據都不應該用于懲罰或者獎勵單個評審員或者文檔作者，而應該關注于評審過程本身。
3.4評審度量
評審組長（前面說過可能是測試經理）必須確保有可用的度量來：
? 評估評審對象的質量水平
? 評估進行評審的成本
? 評估進行評審后的下游收益
評審組長可以使用度量數據來確定評審的投資回報和效率。這些度量也可以用于報告和過程改進活動。
對于每個評審過的工作產品，都可以測量和報告下列度量，用于評估產品：
? 工作-產品規模（文檔頁數，代碼行等）
? 準備時間（評審前）
? 舉行評審的時間
? 修復缺陷的返工時間
? 評審過程的持續時間
? 發現的缺陷數和缺陷嚴重程度
? 識別工作產品中的缺陷集群（即缺陷密度較高的領域）
? 評審類型（非正式評審、走查、技術評審或審查）
? 平均缺陷密度（如每頁或每千行代碼的缺陷）
? 估計的遺留缺陷數（或遺留缺陷密度）
每個評審都可以測量和報告下列度量，用于評估過程：
? 缺陷發現百分比（包括在生命周期的更晚期發現的缺陷）
? 評審過程工作量和時間的改進
? 計劃評審的工作產品的覆蓋率百分比
? 發現的缺陷類型和嚴重程度
? 參與人對評審過程有效性和效率的反饋
? 評審缺陷和動態測試缺陷以及產品缺陷的質量成本度量
? 評審有效性的相互關系（評審類型與缺陷發現有效性）
? 評審員的數目
? 每花一個小時發現的缺陷數
? 估計節省的項目時間
? 缺陷評估工作量（即總的發現和修復時間除以缺陷數量）
此外，上面提到的用于評估產品的度量也能用于過程評估。
3.5管理正式評審
ISTQB基礎級大綱描述了正式評審的不同階段：計劃，啟動，個人準備，評審會議，返工和跟進。要想正確實施一個正式評審，評審組長需要確保遵循了評審過程的所有步驟。
2012 版
? International Software Testing Qualifications Board
?第 45 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
正式評審有許多特性，例如：
? 定義了入口和出口準則
? 評審人員使用檢查表
? 交付物包括報告、評價表或其它評審總結表等
? 用于報告評審有效性、效率和進展的度量
在發起正式評審前，應該由評審組長確認滿足了評審的先決條件（定義在規程或者入口準則清單上），并得到評審組長的同意。
如果沒有滿足評審的先決條件，評審組長可以向評審決策者提議以下任一項：
? 修改目標重新定義評審
? 為了使評審繼續，進行必要的修正活動
? 推遲評審
最后，作為控制正式評審的一部分，這些評審在整體（更高級）項目的環境下得到監督，并與項目質量保證活動相關。正式評審的控制包括根據產品和過程度量提出反饋信息。
2012 版
? International Software Testing Qualifications Board
第 46 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
4. 缺陷管理 – 150 分鐘.
關鍵詞
異常（anomaly）、缺陷（defect）、缺陷分類委員會（defect triage committee）、失效（failure）、假負面結果（fal-negative）、假正面結果（fal-positive）、階段遏制（pha containment）、優先級（priority ）、根本原因（root cau）、嚴重程度（verity）
缺陷管理學習目標
4.2 缺陷生命周期和軟件開發生命周期
TM-4.2.1
TM-4.2.2
TM-4.3.1
(K3) 為測試組織開發缺陷管理過程，包括缺陷報告流程，用于在測試生命周期中監控項目缺陷
(K2) 說明有效的缺陷管理必需的過程和參與者
4.3缺陷報告信息
(K3) 定義在缺陷管理過程中應該收集的數據和分類信息
4.4使用缺陷報告信息評估過程能力
TM-4.4.1
(K2) 解釋缺陷報告信息怎樣用于評估測試和軟件開發過程的過程能力Explain
2012 版
? International Software Testing Qualifications Board
第 47 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
4.1 簡介
組織的缺陷管理過程和工具對于測試組和參與軟件開發的各組來說都是非常關鍵的。有效的缺陷管理收集的信息可以幫助測試經理和其它項目干系人深入了解項目在整個開發生命周期中的狀態，通過持續收集和分析數據，還可以幫助識別測試和開發過程的改進機會。
除了了解整個缺陷生命周期和如何使用它來監控測試和軟件開發過程外，測試經理還必須熟悉哪些數據是亟需收集的，而且必須提倡過程和缺陷管理工具的適當用法。
4.2缺陷生命周期和軟件開發生命周期
在基礎級大綱里提到，工作產品在產生過程中由于人為錯誤引入了缺陷。這些工作產品可能是需求規格說明、用戶故事、技術文檔、測試用例、程序代碼或者其它任何在軟件開發或維護過程中產生的工作產品。
在軟件開發生命周期中任何時間點和相關工作產品中都可能引入缺陷。因此，軟件開發周期的每個階段都要包括發現和移除潛在缺陷的活動。例如，在設計規格說明，需求規格說明，代碼交付給下一階段的工作前可以使用靜態測試技術（即評審和靜態分析）。越早識別并移除缺陷，系統整體的質量成本越低；在缺陷引入階段解決該缺陷，是質量成本最低的做法（如當軟件過程有效實現階段抑制時）。另外，在基礎大綱里提過，靜態分析直接找到缺陷而不是發現失效，因此，由于不需要通過調試活動將缺陷隔離，移除缺陷的成本得以降低。
在單元測試、集成測試和系統測試等動態測試過程中，缺陷是通過其引起的失效來揭示，即實際測試結果與預期結果不符（即異常）。在某些情況下，測試人員會因為沒有觀察到異常而發生假負面結果。如果測試人員觀察到了異常，就意味著需要做進一步的調查。以填寫缺陷報告作為調查的開始。
在測試驅動開發時，自動單元測試被用作為一種可執行的設計規格說明。產品代碼在開發后立即執行這些測試。只要部分或全部測試沒被通過，此單元的開發就不能算完成。因此，這類測試的失效不構成缺陷（報告），而且一般不會被跟蹤。
4.2.1缺陷工作流程和狀態
大部分的測試組織在缺陷生命周期中使用工具管理缺陷報告。缺陷報告通常在工作流中得到處理，在整個缺陷生命周期會歷經一系列狀態。在大多數狀態下，缺陷生命周期的唯一一個參與者擁有該缺陷報告，他負責執行某個任務，該任務完成時會讓缺陷進入下一個狀態（分配給下一個責任人）。在最終狀態下，如當缺陷報告被關閉（通常意味著該報告指出的缺陷已被修復，修復的結果已經通過確認測試驗證），被取消（通常意味著該缺陷報告無效），無法重現（通常意味著再也無法觀察到該異常），或延期時（通常意味著該異常與一個實際存在的缺陷相關，但該缺陷在項目中無法得到修復），缺陷報告將不再有所有者，因為將不再需要采取進一步行動。
對于測試人員在測試中發現的缺陷，有三種狀態需要測試團隊采取相應行動：
? 初始狀態
o 在這個狀態下，一名或者多名測試人員為負責解決缺陷的人員收集必要的信息，用以重現異常（詳見下面缺陷報告的內容）
o 還可能被稱為 “打開”或“新”的狀態
2012 版
? International Software Testing Qualifications Board
第 48 頁/ 共 74頁
2012年10月19日 測試人員認證
高級大綱 -- 測試經理
?
?
退回狀態
o 在這個狀態下，報告接收人拒絕接收報告或者向測試人員詢問進一步的信息。這個狀態表明初始狀態的信息收集過程或者測試本身存在不足，測試經理應該監控以免出現過高的退回率。在這狀態測試人員必須提供補充信息，或確認該報告應該被拒絕
o 還可能被稱為“拒絕”或“澄清”狀態
確認測試狀態
o 在這個狀態下，測試人員會運行確認測試（一般按照缺陷報告中重現失效的步驟），判斷修復是否解決了問題。如果確認測試表明缺陷已被修復，測試人員應關閉缺陷報告。如果確認測試顯示缺陷沒有被修復，測試人員應該再次打開缺陷報告，讓之前安排的缺陷負責人繼續修復缺陷
o 還可能被稱為 “解決”或“驗證”狀態
4.2.2管理無效和重復缺陷
某些情況下，異常的出現不是因為缺陷，而是因為測試環境、測試數據測試件的其它要素，或者測試人員自己的誤解。如果測試人員建立缺陷報告后發現其內容和測試的工作產品缺陷無關的話，則被稱為假負面結果。這類報告一般會被取消或者作為無效缺陷報告被關閉。另外，在某些情況下，一個缺陷會表現出在測試人員看來完全無關的不同癥狀。如果事后發現兩個或以上缺陷報告是由相同的根本原因引起的，通常只保留其中一個缺陷報告，其它的將視為重復缺陷報告被關閉。
盡管無效缺陷報告和重復缺陷報告代表了一定程度的低效率，但一定數量的此類報告是不可避免的，而且應該被測試經理所接受。當測試經理試圖消除所有的無效和重復缺陷報告時，漏檢測的數量往往會增加，這是因為測試人員擔心出錯而不敢填寫缺陷報告，這降低了測試組織的缺陷發現有效性，而缺陷發現有效性往往和測試組織的關鍵目標密切相關。
4.2.3跨職能缺陷管理
雖然測試組織和測試經理是整個缺陷管理過程和缺陷管理工具的所有者，但是一般會有跨職能的小組負責管理整個項目所報告的缺陷。除了測試經理、缺陷管理委員會（或缺陷分類委員會）的成員外一般還可包括開發、項目管理、產品管理和其它軟件開發的利益干系人。
當發現缺陷并記錄在缺陷管理工具中后，缺陷管理委員會需要判斷缺陷的有效性和是否要修復或延期。在做決策時要求缺陷管理委員會考慮修復缺陷與否的效益、風險和成本。如果要修復缺陷，小組要把此任務和其它項目任務做比較確定修復該缺陷的優先級。測試經理和測試團隊可能會被問到某個缺陷的重要性并需要提供其它有效的客觀信息。
缺陷跟蹤工具不應替代溝通交流，缺陷管理委員會的會議也不應替代缺陷跟蹤工具。溝通交流、充分的工具支持、定義明確的缺陷生命周期和缺陷管理委員會的充分參與對有效和高效的缺陷管理來說，都是不可或缺的。
4.3缺陷報告信息
當識別出一個缺陷（通過靜態測試）或者觀察到一個失效（通過動態測試）時，相關人員應該收集相應數據并記錄在缺陷報告中。
這些信息需要滿足三個目的：
2012 版
? International Software Testing Qualifications Board
第 49 頁/ 共 74頁
2012年10月19日
本文發布于:2023-12-12 17:59:39，感謝您對本站的認可！
本文鏈接：http://www.newhan.cn/zhishi/a/1702375180244330.html
版權聲明：本站內容均來自互聯網，僅供演示用，請勿用于商業和其他非法用途。如果侵犯了您的權益請與我們聯系，我們將在24小時內刪除。
本文word下載地址：istqb高級測試經理-2012-TM(無水印版).doc
本文 PDF 下載地址：istqb高級測試經理-2012-TM(無水印版).pdf
| 留言與評論（共有 0 條評論） |
