[注：以下提供的模板用于 Rational Unified Process。其中包括用方括號括起來并以藍色斜體（樣式=InfoBlue）顯示的文本，它們用于向作者提供指導，在發布此文檔之前應該將其刪除。按此樣式輸入的段落將被自動設置為普通樣式（樣式=Body Text）。]
[要定制 Microsoft Word 中的自動字段（選中時顯示灰色背景），請選擇 File >Properties，然后將 Title、Subject 和 Company 等字段替換為此文檔的相應信息。關閉該對話框后，通過選擇 Edit> Select All（或 Ctrl-A）并按 F9，或只是在字段上單擊并按 F9，可以在整個文檔中更新自動字段。對于頁眉和頁腳，這一操作必須單獨進行。按 Alt-F9，將在顯示字段名稱和字段內容之間切換。有關字段處理的詳細信息，請參見 Word 幫助。]
修訂歷史記錄
|
日期 |
版本 |
說明 |
作者 |
|
<日/月/年> |
<x.x> |
<詳細信息> |
<姓名> |
目錄
1. 簡介 4
1.1 目的 4
1.2 范圍 4
1.3 定義、首字母縮寫詞和縮略語 4
1.3.1 術語 4
1.3.2 縮寫語 4
1.4 參考資料 4
1.5 概述 4
2. 測試目標 4
3. 測試標準 4
4. 測試數據 5
5. 主要評測方法 5
6. 測試完成標準 5
7. 缺陷管理指南 5
8. 變更管理標準 5
測試指南
1. 簡介
[測試指南的簡介應提供整個文檔的概述。它應包括此測試指南的目的、范圍、定義、首字母縮寫詞、縮略語、參考資料和概述。]
1.1 目的
[闡明此測試指南的目的。]
[說明此測試指南的書寫目地是什么？ 讀者對象是誰？ 以及讀者應該具備哪方面知識？]
1.2 范圍
[簡要說明此測試指南的范圍：它的相關項目，以及受到此文檔影響的任何其他事物。]
[測試指南相關聯的項目簡要描述，與測試指南相關的其他模塊，文檔等等。比如軟件規范，軟件設計以及描述本測試應該測試哪些？而不應該測試哪些？]
1.3 定義、首字母縮寫詞和縮略語
[本小節應提供正確理解此測試指南所需的全部術語、首字母縮寫詞和縮略語的定義。這些信息可以通過引用項目詞匯表來提供。]
1.3.1 術語
術語：解釋
1.3.2 縮寫語
縮寫語：全名，（中文名稱，解釋）
1.4 參考資料
[本小節應完整地列出此測試指南中其他部分所引用的任何文檔。每個文檔應標有標題、報告號（如果適用）、日期和出版單位。列出可從中獲取這些參考資料的來源。這些信息可以通過引用附錄或其他文檔來提供。]
[格式：作者，版本，出版日期，[出版社名]，”文件名稱”，比如：
廖洪濤， V1.0， 2005/10/11，“媒體烽火臺系統-數字電視機頂盒設計需求參考規范” ]
1.5 概述
[本小節應說明此測試指南中其他部分所包含的內容，并解釋文檔的組織方式。]
[1.1-1.4應該描述而沒有描述的部分]
2. 測試目標
[陳述組織執行和使用測試的原因。][測試應該達到那種目標？ 為什么要進行該測試？]
3. 測試標準
[本節確定并說明將在計劃、設計、實施、執行和評估等活動中使用的所有指南和標準。這些指南和標準包括：[測試指南的主體部分]
· 測試用例標準：確定應該為測試而開發的測試用例的類型，例如有效測試用例、無效測試用例、邊界測試用例等。[比如java API測試中應該包括功能性測試，完整性測試，監聽測試以及穩定性測試，并且簡單描述每項測試的功能]
· 命名約定：說明應該如何給各種實體（如測試用例和測試過程）命名。[測試用例編號應該按照何種規則命名？ UI中的名稱應該用啥符號引起來? …]
· 設計指南：說明測試過程和腳本模塊化在復用和維護方面的目標。[如果測試需要書寫測試腳本，對測試腳本進行架構設計，可用圖及文字進行描述，注明模塊與模塊之間的關聯和依賴關系，必要的時候加上數據流向說明。
測試用例的設計大綱，以及哪些測試用例可以被其他模塊復用，比如軟件啟動功能測試用例是其他功能測試用例的前提條件；時間輸入檢驗測試用例可以在EPG時間設定，系統設計時間設定測試用例中復用。
如果需要有測試腳本支持，如何使用測試軟件，即測試腳本的界面設計？可以引見附錄]
4. 測試數據
說明如何為支持測試而選擇（或創建）和恢復數據。] [完成該測試需要何種測試數據？ 測試數據信息是什么？ 應該如何配置這些測試數據？ 可以引見附錄]
5. 主要評測方法
[指定將采用何種評測方法來確定測試活動的進展，例如將要使用哪種缺陷計數，如何評測已成功執行的測試用例等。]
[比如通過查看測試代碼運行后的測試報告文件來判斷測試用例是否通過。通過按照測試用例的步驟進行操作是否達到預期效果來評定測試用例是否通過等]
6. 測試完成標準
[說明推薦使用的完成及評估標準。]
[什么條件算測試完成？ 比如每一條測試用例測試結果與測試計劃中描述的希望結果一致。測試結束產品發布的標準是什么：比如>99.995%的測試用例通過測試；所有重要的缺陷得到解決，總的測試缺陷控制在百分之多少以內？]
7. 缺陷管理指南
[說明將如何管理缺陷。]
[測試中發現的缺陷應該如何進行管理？比如通過Bugzilla, 還是書寫測試報告單。發現缺陷后開發人員與測試人員應該如何進行交流，什么級別的缺陷應該盡可能在多長時間解決。本版本不解決的缺陷應該如何控制？]
8. 變更管理標準
[確定將如何管理和維護測試工件。]
[描述如何管理此文檔的變更及其發生變更應該告訴那些人員以及如何告知？
比如：文檔變更應該在頭部歷史記錄中詳細注明變更內容，并且將變更文字變更為紅色，另外重新建立文件，文件格式為:文件名+YYYYMMDD.doc。通過Email告訴測試計劃設計師，測試開發人員。同時也應該告訴測試部門經理，技術總監,以及文檔版本管理人員]
文章來源于領測軟件測試網 http://www.kjueaiud.com/