複製鏈接
請複製以下鏈接發送給好友

測試報告

鎖定
測試報告是指把測試的過程和結果寫成文檔,對發現的問題和缺陷進行分析,為糾正軟件的存在的質量問題提供依據,同時為軟件驗收和交付打下基礎。
中文名
測試報告
外文名
test report
硬    盤
可用空間大小
編    號
BUG號
缺陷概要
該缺陷描述的事實

目錄

測試報告基本介紹

測試報告是測試階段最後的文檔產出物。優秀的測試經理或測試人員應該具備良好的文檔編寫能力;
一份詳細的測試報告包含足夠的信息,包括產品質量和測試過程的評價,測試報告基於測試中的數據採集以及對最終的測試結果分析。

測試報告內容

測試報告的內容
測試報告的內容可以總結為以下目錄:
  • 首頁
  • 引言(目的、背景、縮略語、參考文獻)
  • 測試概要(測試方法、範圍、測試環境、工具)
  • 測試結果與缺陷分析(功能、性能)
  • 測試結論與建議(項目概況、測試時間 測試情況、結論性能彙總)
  • 附錄(缺陷統計)
各部分的格式與內容
1、首頁
·· 報告名稱(軟件名稱+版本號+用户端類型(android,iphone,後台管理等等)+測試範圍(單元,集成,系統,模塊等等)+測試報告)
·· 報告委託方,報告責任方,報告日期等
·· 版本變化歷史
·· 密級
2、引言
2.1編寫目的
本測試報告的具體編寫目的,指出預期的讀者範圍。
實例:本測試報告為XXX項目的測試報告,目的在於總結測試階段的測試以及分析測試結果,描述系統是否符合需求(或達到XXX功能目標)。預期參考人員包括用户、測試人員、、開發人員、項目管理者、其他質量管理人員和需要閲讀本報告的高層經理。
2.2 項目背景
項目目標和目的進行簡要説明。必要時包括簡史,這部分不需要腦力勞動,直接從需求或者招標文件中拷貝即可。
2.3 系統簡介
如果設計説明書有此部分,照抄。注意必要的框架圖和網絡拓撲圖能吸引眼球。
2.4 術語和縮略語
列出設計本系統/項目的專用術語和縮寫語約定。對於技術相關的名詞和與多義詞一定要註明清楚,以便閲讀時不會產生歧義。
2.5 參考資料
1. 需求、設計、測試用例、手冊以及其他項目文檔都是範圍內可參考的東西。
2. 測試使用的國家標準、行業指標、公司規範和質量手冊等等。
3、測試概要
測試的概要介紹,包括測試的一些聲明、測試範圍、測試目的等等,主要是測試情況簡介。(其他測試經理和質量人員關注部分)
3.1測試方法(和工具)
簡要介紹測試中採用的方法(和工具)。
提示:主要是黑盒測試,測試方法可以寫上測試的重點和採用的測試模式,這樣可以一目瞭然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項,當使用到測試工具和相關工具時,要説明。注意要註明是自產還是廠商,版本號多少,在測試報告發布後要避免大多工具的版權問題。
3.2測試範圍(測試用例設計
簡要介紹測試用例的設計方法。例如:等價類劃分、邊界值、因果圖,以及用這類方法(3-4句)。
提示:如果能夠具體對設計進行説明,在其他開發人員、測試經理閲讀的時候就容易對你的用例設計有個整體的概念,順便説一句,在這裏寫上一些非常規的設計方法也是有利的,至少在沒有看到測試結論之前就可以瞭解到測試經理的設計技術,重點測試部分一定要保證有兩種以上不同的用例設計方法。
3.3測試環境與配置
簡要介紹測試環境及其配置。
提示:清單如下,如果系統/項目比較大,則用表格方式列出
CPU
內存:
硬盤:可用空間大小
操作系統:
應用軟件:
機器網絡名:
局域網地址:
…….
客户端配置
…….
對於網絡設備和要求也可以使用相應的表格,對於三層架構的,可以根據網絡拓撲圖列出相關配置。
4、測試結果與缺陷分析
整個測試報告中這是最激動人心的部分,這部分主要彙總各種數據並進行度量,度量包括對測試過程的度量和能力評估、對軟件產品質量度量和產品評估。對於不需要過程度量或者相對較小的項目,例如用於驗收時提交用户的測試報告、小型項目的測試報告,可省略過程方面的度量部分;而採用了CMM/ISO或者其他工程標準過程的,需要提供過程改進建議和參考的測試報告-主要用於公司內部測試改進和缺陷預防機制-則過程度量需要列出。
4.1測試執行情況與記錄
描述測試資源消耗情況,記錄實際數據。(測試、項目經理關注部分)
4.1.1測試組織
可列出簡單的測試組架構圖,包括:
測試組架構 (如存在分組、用户參與等情況)
測試經理(領導人員)
主要測試人員
參與測試人員
4.1.2測試時間
列出測試的跨度和工作量,最好區分測試文檔和活動的時間。數據可供過程度量使用。
例如 XXX子系統/子功能
實際開始時間-實際結束時間
總工時/總工作日
任務 開始時間 結束時間 總計
合計
對於大系統/項目來説最終要統計資源的總投入,必要時要增加成本一欄,以便管理者清楚的知道究竟花費了多少人力去完成測試。
測試類型 人員成本 工具設備 其他費用
總計
在數據彙總時可以統計個人的平均投入時間和總體時間、整體投入平均時間和總體時間,還可以算出每一個功能點所花費的時/人。
用時人員 編寫用例 執行測試 總計
合計
這部分用於過程度量的數據包括文檔生產率和測試執行率。
生產率人員 用例/編寫時間 用例/執行時間 平均
合計
4.1.3測試版本
給出測試的版本,如果是最終報告,可能要報告測試次數迴歸測試多少次。列出表格清單則便於知道那個子系統/子模塊的測試頻度,對於多次迴歸的子系統/子模塊將引起開發者關注。
4.2覆蓋分析
4.2.1需求覆蓋
需求覆蓋率是指經過測試的需求/功能和需求規格説明書中所有需求/功能的比值,通常情況下要達到100%的目標。
需求/功能(或編號) 測試類型 是否通過 備註
[Y][P][N][N/A]
根據測試結果 ,按編號給出每一測試需求的通過與否結論。P表示部分通過,N/A表示不可測試或者用例不適用。實際上,需求跟蹤矩陣列出了一一對應的用例情況以避免遺漏,此表作用為傳達需求的測試信息以供檢查和審核。
需求覆蓋率計算 Y項/需求總數 ×100%
需求/功能(或編號) 用例個數 執行總數 未執行 未/漏測分析和原因
實際上,測試用例已經記載了預期結果數據,測試缺陷上説明了實測結果數據和與預期結果數據的偏差;因此沒有必要對每個編號在此包含更詳細的説明的缺陷記錄與偏差,列表的目的僅在於更好的查看測試結果。
測試覆蓋率計算 執行數/用例總數 ×100%
4.3缺陷的統計與分析
缺陷統計主要涉及到被測系統的質量,因此,這部分成為開發人員、質量人員重點關注的部分。
4.3.1缺陷彙總
被測系統 系統測試 迴歸測試 總計
合計
按嚴重程度
嚴重 一般 微小
按缺陷類型
用户界面 一致性 功能 算法 接口 文檔 用户界面 其他
按功能分佈
功能一 功能二 功能三 功能四 功能五 功能六 功能七
最好給出缺陷的餅狀圖和柱狀圖以便直觀查看。俗話説一圖勝千言,圖標能夠使閲讀者迅速獲得信息,尤其是各層面管理人員沒有時間去逐項閲讀文章。
圖例
4.3.2缺陷分析
本部分對上述缺陷和其他收集數據進行綜合分析
缺陷綜合分析
缺陷發現效率 = 缺陷總數/執行測試用時
可到具體人員得出平均指標
用例質量 = 缺陷總數/測試用例總數 ×100%
缺陷密度 = 缺陷總數/功能點總數
缺陷密度可以得出系統各功能或各需求的缺陷分佈情況,開發人員可以在此分析基礎上得出那部分功能/需求缺陷最多,從而在今後開發注意避免並注意在實施時予與關注,測試經驗表明,測試缺陷越多的部分,其隱藏的缺陷也越多。
測試曲線圖
描繪被測系統每工作日/周缺陷數情況,得出缺陷走勢和趨向
缺陷編號 簡要描述 分析結果 備註
4.3.3殘留缺陷與未解決問題
殘留缺陷
編號:BUG號
缺陷概要:該缺陷描述的事實
原因分析:如何引起缺陷,缺陷的後果,描述造成軟件侷限性和其他限制性的原因
預防和改進措施:彌補手段和長期策略
未解決問題
功能/測試類型:
測試結果:與預期結果的偏差
缺陷:具體描述
評價:對這些問題的看法,也就是這些問題如果發出去了會造成什麼樣的影響
5、測試結論與建議
5.1 測試結論
1. 測試執行是否充分(可以增加對安全性、可靠性、可維護性和功能性描述)
2. 對測試風險的控制措施和成效
3. 測試目標是否完成
4. 測試是否通過
5. 是否可以進入下一階段項目目標
[1] 
5.2 建議
1.對系統存在問題的説明,描述測試所揭露的軟件缺陷和不足,以及可能給軟件實施和運行帶來的影響
2.可能存在的潛在缺陷和後續工作
3.對缺陷修改和產品設計的建議
4.對過程改進方面的建議
6、附錄
· 缺陷列表
· 缺陷等級定義標準
· 測試通過標準

測試報告範本

XXX公司
XXX(產品或軟件)/XXX(模塊) 測試報告
1.概述
測試目的 簡述本次測試的目的,如:驗證某模塊是否符合設計
項目背景 簡述測試所在項目的背景,如:進入什麼階段,以及其他信息
硬件環境 僅針對測試對象的硬件環境及其版本信息加以説明
軟件環境 僅針對測試對象的軟件環境及其版本信息加以説明
3.測試人員
人員
角色
4.實際進度
佔用時間 描述整個測試過程的時間跨度,如:xxxx-xx-xx至xxxx-xx-xx
進度情況 原因 如果測試提前或延後完成,請説明具體原因
5.測試參考文檔
《XXX測試計劃》
《XXX測試用例》
《文檔三》
《文檔四》
版本信息 V1.0
測試數據
測試項總數 0
PASS 0 PASS率 #DIV/0!
FAIL 0 FAIL率 #DIV/0!
嚴重度——高 0 其中:高-- #DIV/0!
嚴重度——中 0 中-- #DIV/0!
嚴重度——低 0 低-- #DIV/0!
測試項編號 測試項 通過與否 問題描述 問題嚴重度
注: 問題嚴重度的界定:
高——導致系統死機或後續部分測試項功能不能實現,影響後續測試;
中——影響該部分的測試功能的完整性且急需解決;
低——僅屬於系統中的小bug,或根據測試過程發現的需要調整的部分,但並非急需解決。
7.項目的總結 對整個測試項目進行總結性闡述,如:測試是否通過,導致FAIL的主要原因。
8.意見和建議 針對本次測試工作,提出自己的意見或建議。沒有可填“無”。
參考資料