本測試報告的具體編寫目的，指出預期的讀者范圍。
實例：本測試報告為XXX項目的測試報告，目的在於總結測試階段的測試情況以及分析測試結果，描述系統是否符合需求（或達到XXX功能目標）並對測試質量進行分析。作為測試質量參考文檔提供給用戶、測試人員、開發人員、項目管理者、其他質量管理人員和需要閱讀本報告的高層經理閱讀。
（注意：通常，用戶對測試結論部分感興趣，開發人員希望從缺陷結果以及分析得到產品開發質量的信息，項目管理者對測試執行中成本、資源和時間予與重視，而高層經理希望能夠閱讀到簡單的圖表並且能夠與其他項目進行同向比較。）
列出本計划中使用的專用術語及其定義
列出本計划中使用的全部縮略語全稱及其定義
|
縮寫詞或術語
|
英文解釋
|
中文解釋
|
|
|
|
|
|
|
|
|
列出本計划各處參考的
經過核准的全部文檔和主要文獻。
對測試項目進行簡要的說明。
對項目目的進行簡要說明。必要時包括簡史，這部分不需要腦力勞動，直接從需求或者招標文件中拷貝即可。
對測試項目的測試目的進行簡要的說明，主要描述測試的要點、測試范圍和測試目的。
簡要說明測試開始時間與發布時間。
列出項目參與人員的職務、姓名、E-mail 和電話。
|
職務
|
姓名
|
E-Mail
|
電話
|
|
開發工程師
|
|
|
|
|
CVS Builder
|
|
|
|
|
開發經理
|
|
|
|
|
測試負責人
|
|
|
|
|
測試人員
|
|
|
|
對系統的結構進行簡要描述。參考系統白皮書，使用必要的框架圖和網絡拓撲圖能更加直觀。
簡要介紹測試用例的設計方法，使得開發或測試經理等人員閱讀的時候容易對測試用例的設計有個整體的印象，特別是一些異常的設計方法或關鍵測試技術，需要在這里進行說明。
描述建立測試環境所需要的設備、用途及軟件部署計划。
“
機型（配置）”：此處說明所需設備的機型要求以及內存、CPU、硬盤大小的最低要求。
“
用途及特殊說明”：此設備的用途，如數據庫服務器，web服務器，后台開發等；如有特殊約束，如開放外部端口，封閉某端口，進行性能測試等，也寫在此列；
“
軟件及版本”：詳細說明每台設備上部署的自開發和第三方軟件的名稱和版本號，以便系統管理員按照此計划分配測試資源；
“
預計空間”：說明第三方軟件和應用程序的預計空間；
“
環境約束說明”：建立此環境時的特殊約束。如需要開發外部訪問端口，需要進行性能測試等。
|
機型（配置）
|
操作系統
|
軟件及版本
|
SUN450
|
|
oracle8.1.2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平台2
：IBM
|
|||||
|
機型
|
IP
地址
|
操作系統
|
用途
|
第三方軟件及版本
|
預計空間
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
軟件需求
|
用途
|
|
|
|
此項目將列出測試使用的工具以及用途：
|
測試工具
|
用途
|
|
自動測試工具
|
|
簡要介紹測試中采用的方法和測試技術。主要是黑盒測試，測試方法可以寫上測試的重點和采用的測試模式，這樣可以一目了然的知道是否遺漏了重要的測試點和關鍵塊。
這是測試報告的核心，主要匯總測試各種數據並進行度量，度量包括對測試過程的度量和能力評估、對軟件產品的質量度量和產品評估。
需求覆蓋率是指經過測試的需求/功能和需求規格說明書中所有需求/功能的比值，通常情況下要達到100％的目標。
|
需求/功能（或編號）
|
測試點描述
|
是否測試
|
重要等級
|
是否通過
|
備注
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
根據測試結果，按編號給出每一測試需求的通過與否結論。
需求覆蓋率=測試通過需求點/需求總數×100％
測試覆蓋是指根據經過測試的測試用例和設計測試用例的比值，通過這個指標獲得測試情況的數據。
|
需求/功能（或編號）
|
測試用例數
|
執行數
|
未執行數
|
通過數
|
失敗數
|
備注
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
測試覆蓋率=執行數/用例總數×100％
測試通過率=通過數/執行數×100％
對測試過程中產生的缺陷進行統計和分析。
這部分主要列出測試過程中的所有bug，並對其進行描述。
|
序號
|
BUGID
|
描述
|
等級
|
模塊
|
測試人員
|
開發人員
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.1.2 重要解決bug列表
這部分主要列出測試過程中產生關鍵的並且解決了的bug，對於重要的bug，需要對其產生的原因和解決方法進行分析說明。
|
序號
|
BUGID
|
描述
|
等級
|
模塊
|
測試人員
|
開發人員
|
Bug
分析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.1.3 遺留bug列表
這部分主要列出已經發現尚未被解決的bug，並對其進行描述，對於未解決的問題，需要在測試報告中詳細分析產生的原因和避免的方法。
|
序號
|
BUGID
|
描述
|
等級
|
模塊
|
測試人員
|
開發人員
|
Bug
分析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本部分對上述缺陷和其他收集數據進行綜合分析
4.2.2.1 缺陷綜合分析
缺陷發現效率 ＝ 缺陷總數/執行測試用時
可到具體人員得出平均指標
用例質量 ＝ 缺陷總數/測試用例總數 ×100％
缺陷密度 ＝ 缺陷總數/功能點總數
缺陷密度可以得出系統各功能或各需求的缺陷分布情況，開發人員可以在此分析基礎上得出那部分功能/需求缺陷最多，從而在今后開發注意避免並注意在實施時予與關注，測試經驗表明，測試缺陷越多的部分，其隱藏的缺陷也越多。
4.2.2.2 測試曲線圖
描繪被測系統每工作日/周缺陷數情況，得出缺陷走勢和趨向。比如：
這部分簡要地列出性能測試結果，並對測試結果進行分析說明，以說明是否符合軟件需求。該部分也可以在性能測試報告中進行說明。
記錄測試輸出結果，將測試結果的數據表格，圖表如實的反映到測試結果中。用於數據分析。例如：
|
短信數目
（萬條）
|
時間
(秒)
|
平均速度
(條/秒)
|
最高速度
(條/秒)
|
最低速度
（條/秒）
|
IDLE占用率
(平均，%)
|
MEM使用率
(平均，%))
|
CPU使用率
(平均，%)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
記錄測試輸出結果。用於數據分析。例如：
在分別處理1萬條神州行和全球通的MO短信的情況下，短信處理速度為400條/秒。
測試結果對比：IAGW1.1短信最大處理能力為330個條/秒，本次release的IAGW1.1性能略有提高。
各模塊運行穩定。
這部分主要是軟件質量量度的一個尺度總表，主要是對上述分析的一個總結。
|
項目
|
結果
|
描述
|
|
測試執行時間跨度
|
|
|
|
測試執行總天數
|
|
|
|
測試准備時間
|
|
|
|
測試總時間
|
|
|
|
軟件Build次數
|
|
|
|
測試人力資源
|
|
|
|
測試硬件資源
|
|
|
|
測試項目總數
|
|
|
|
自動測試項目總數
|
|
|
|
推遲測試項目總數
|
|
|
|
未測試項目總數
|
|
|
|
測試案例總數
|
|
|
|
自動測試案例總數
|
|
|
|
成功測試案例總數
|
|
|
|
發現錯誤總數
|
|
|
|
修正錯誤總數
|
|
|
|
已知錯誤總數
|
|
|
|
測試執行時間細分
Accecpt Test
Smoke Test
Build First
Regress Test First
Build Second
Regress Test Second
Release Check
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
這部分是測試報告中最關注的內容，主要是對測試過程產生的測試結果進行分析之后，得出測試的結論和建議。這部分為測試經理、項目經理和高層領導最關心的部分，因此需要准確、清晰、扼要地對測試結果進行總結。
說明該軟件的開發是否達到了預期的目標，能否交付使用。
說明測試后可能存在的風險，對系統存在問題的說明，描述測試所揭露的軟件缺陷和不足，以及可能給軟件實施和運行帶來的影響。
對測試計划執行情況以及測試結果進行總結，包括：
1．測試計划執行是否充分（可以增加對安全性、可靠性、可維護性和功能性描述）
2．對測試風險的控制措施和成效
3．測試目標是否完成
4．測試是否通過
5．是否可以進入下一階段項目目標
對軟件的各項缺陷所提出的改進建議，如：各項修改的方法、工作量和負責人、各項修改的緊迫程度、后續改進工作的建議、對產品修改和設計的建議、對過程管理方面的建議等