XX項目測試報告版本信息日期版本狀態簡要描繪編寫審查贊同2018-07-18初次成立項目測試報告（標準版）模板XXX注：狀態能夠為 N-新建、A-增添、M-改正、D-刪除目錄編寫目的 錯誤!不決義書簽。測試參照文檔 錯誤!不決義書簽。

項目信息 錯誤!不決義書簽。測試概括錯誤!不決義書簽。基本信息 錯誤!不決義書簽。測試過程 錯誤!不決義書簽測試范圍5測試范圍5測試過程評估錯誤!不決義書簽。錯誤!不決義書簽測試設計 錯誤!不決義書簽。測試用例 錯誤!不決義書簽。測試方法 錯誤測試設計 錯誤!不決義書簽。測試用例 錯誤!不決義書簽。測試方法 錯誤!不決義書簽。測試履行 錯誤!不決義書簽。測試用例覆蓋總結錯誤!不決義書簽測試用例履行總結 錯誤!不決義書簽。缺點統計與剖析錯誤!不決義書簽。缺點統計錯誤!不決義書簽。缺點剖析錯誤!不決義書簽缺點散布--按嚴重等級區分錯誤!不決義書簽。缺點散布--按功能模塊區分錯誤!不決義書簽。缺點散布--按缺點種類區分錯誤!不決義書簽。缺點趨向--新增缺點錯誤!不決義書簽。缺點趨向--從頭翻開缺點 錯誤!不決義書簽。缺點趨向--改正缺點 錯誤!不決義書簽。缺點趨向--缺點趨向--封閉缺點錯誤!不決義書簽。版本需求改正剖析錯誤版本需求改正剖析錯誤!不決義書簽。需求改正描繪 錯誤需求改正描繪 錯誤!不決義書簽。需求改正統計 錯誤!不決義書簽版本演進軌跡錯誤版本演進軌跡錯誤!不決義書簽。測試總結錯誤!不決義書簽。測試結論錯誤!不決義書簽。測試建議 錯誤!不決義書簽。遺留問題列表 錯誤!不決義書簽風險剖析 錯誤!不決義書簽。編寫目的本測試報告為【XX】項目的測試報告，目的在于總結測試階段的測試狀況以及剖析測試結果,描繪系統能否切合需求并對測試質量進行剖析。本報告作為測試質量參照文檔供應給用戶、測試人員、開發人員、項目管理者、其余質量管理人員和需要閱讀本報告的高層經理閱讀。測試參照文檔《用戶需求說明書》《軟件需求規格說明書》《軟件開發計劃》《軟件測試計劃》《軟件測試方案》《軟件測試策略》《軟件測試用例》《缺點分類指南》《功能及UI測試標準》項目信息項目名稱XX項目編號XXX.項目周期2018/1/19?2018/2/26項目性質嶄新產品/大版本升級/小版本升級（只好選擇一個）項目版本號項目經理XXX測試經理XXX測試工程師XXX開發工程師XXX測試概括基本信息本次測試的基本信息以下:測試時間2018/1/19?2018/2/26測試環境硬件辦理器：InterCorei5，內存：8GB操作系統：Windows10軟件NavicatPremium、xshell、IE,FireFox，CoogleChrome等閱讀器測試站點

無無無無編寫測試策略編與測試方案編寫測試用例評審測試用例測試環境準備測試數據準備—測試腳本準備 1-測試履行系統測試 回歸測試測試結束編寫測試報告編寫用戶手冊項目實行培訓項目部署測試范圍任務測試覆蓋功能點一級功能二級功能三級功能歷史新增及改正測試過程評估測試設計測試用例測試用例的設計方法采納等價類區分、界限值、因果圖、錯誤推斷法等。依照需求文檔和原型圖設計測試用例，測試用例覆蓋所有需求功能點，在評審通事后履行測試。測試方法依據系統需求規格說明書的描繪， 明確指出了系統應當擁有的功能。 在完好不考慮程序內部構造和內部特征的狀況下，測試者只要檢查程序功能能否依照系統需求規格說明書的規定正常使用，能否能在輸入適合的數鋸下產生正確的輸出信息， 而且能保持外面信息（如數據庫或文件）的完好性。所以采納了著眼于程序外面構造、不考慮內部邏輯構造、針對軟件界面和軟件功能進行測試的測試方法：黑盒測試。本次測試的要點集中在基本數據錄入、業務流程和各功能模塊間的接口。測試履行測試用例覆蓋總結履行的測試用例數覆蓋了所有的功能點模塊名稱用例數（條）覆蓋狀況履行狀況客戶管理94系統測試2輪，查收測試2輪履行94條，未經過1條用例經過率：%測試用例履行總結測試履行統計表測試用例版本號工作量投入（人天）測試用例規模總用例數新增用例數履行結果統計表計劃履行的用例數實質履行的用例數經過的用例數履行率覆蓋率經過率發現缺點數履行率=實質履行的用例數*計劃履行的用例數覆蓋率=實質履行的用例數*總用例數經過率=經過的用例數三實質履行的用例數發現缺點數=本次版本一共提交了多少個BUG單＜事例總數與計劃履行事例數不一致，請說明原由。（指本次測試總事例數與本次測試總的計劃履行事例數），與本文最后一個章節的風險相對應。＞＜計劃履行事例數與實質履行事例數不一致，請說明原由。（指本次測試總的計劃履行事例數與本次履行總的實質履行事例數），與本文最后一個章節的風險相對應。＞缺點統計與剖析缺點統計缺點總計：28個;翻開：17個；辦理中：2個；從頭翻開：3個；已解決：5個；已封閉：1個

缺陷統計已關ifl缺點剖析缺點散布--按嚴重等級區分缺點嚴重等級共計已封閉未解決已封閉所占百分比稍微-Trivial般-Minor重要-Major嚴重-Critical堵塞-Blocker缺陷分布■按嚴重程度劃分缺點散布--按功能模塊區分模塊名稱共計已封閉未解決已封閉所占百分比

缺陷分布-按功能模塊劃分25■豐解決 t 3■已矢誦 14 S缺點散布--按缺點種類區分缺點種類共計已封閉未解決已封閉所占百分比需求問題41325%代碼問題31233%設計問題62433%配置問題42250%環境問題43175%兼容問題94544%安全問題31233%性能問題330100%腳本問題31233%數據問題43175%其余74357%非缺點51420%

缺陷分布-按缺陷類型劃分1Q-aj■未解決■已關閉■■未解決■已關閉需求代碼設計翅羞環境議等安全性能腳本數褊耳百i訥題冋題問題問題冋題冋題問題問ii冋題問題館陷1■未解決3425li|_|■La1i斗■已關例L]2341315mJ"a1缺點趨向--新增缺點缺點趨向--從頭翻開缺點缺點趨向--改正缺點缺點趨向--封閉缺點版本需求改正剖析需求改正描繪本次版本測試共收到35個需求改正：此中14個為測試過程中已有項目的需求改正，主要集中在準時裝項目、國外購二期項目、在線支付異樣同步商家需求等需求中； 4個技術優化,17個為新增的需求改正。本次版本需求改正數目仍舊許多，需求改正方面的控制還需增強，版本的改正對版實質量的影響很大，本次版本公布風險較高。需求改正統計新增需求：12個改正需求：1個需求優化：23個

需求變更統訂■新增零液■靈更需求■諄求優化版本演進軌跡排列本項目內的所有分支及各個分支歸并后的回歸測試版本號公布時間能否歸并回歸測試結果否經過測試總結測試結論＜對測試的過程和結果進行簡要剖析，給出測試結論和建議 ＞＜測試結論要明確，即經過或許不經過，不可以附加任何條件。關于有條件經過的需求，需要在后續“風險剖析”章節進行描繪＞，有條件經過是依據準出條件有部分條件不經過，詳細準則以下：經過----達到準出條件，如：測試事例履行率達到95%、堵塞和致命的缺點所有修復且測試經過、嚴重缺點修復率超出95%、一般缺點修復率已超出85%、提示缺點修復率超出75%；不經過----未達到準出條件，如：測試事例履行率低于 95%、堵塞和致命缺點未所有修復或復測未經過、嚴重缺點修復率未達到95%、一般缺點修復率未達到85%，提示缺點修復率未達到75%;有條件經過----指未達到準出條件但項目責任人確認有關風險，或風險能夠獲得辦理，在此條件下贊同測試有條件經過。經過對本系統的兩輪測試工作，將系統所存在的缺點所有裸露并交予開發人員進行 bug修復，再經過回歸測試保證了所有功能及模塊已經實現，而且知足客戶需求。本系統的測試充足有效，主要業務模塊的測試覆蓋達到 100%，缺點解決率達到100%。當前的測試工作基本達到了預約目標，即達成除原有的系統功能外的所有功能及模塊功能的功能測試，測試任務已全面達成。依據測試結果、BUG的修復率和測試計劃中的測試經過標準得出該項目功能測試經過，能夠交托使用。測試建議從測試的整個過程來看， 比較常有的問題是：編寫框中數據輸入過長不可以正確辦理或許頁面變形，頁面款式不一致（翻頁、提示語等） ，數據增添成功，上傳附件不顯示，查問冗余數據等。開發人員在編碼過程中，系統在實現基本功能的前提下需要注意頁面款式的一致性和操作界面友善性等非功能的方面。在此次測試過程中， 提出建議：測試人員在提交bug時，需要詳盡描繪：版本號、操作步驟、希望結果、實質結果，以便開發人員讀懂并能重現 bug，防止將bug直接打回，延伸bug的存在周期。同時開發人員一定將打回bug以前需賜予問題解答的簡單描繪， 以利于回歸測試。在本次測試中因沒有依照標準履行， 致使有些bug在回歸幾次后才有效解決， 所以一定在以后的測試項目中測試人員和開發人員嚴格依照標準履行。在本次測試過程中存在一個問題多次改正的狀況。 造成此問題出現的最主要原由是開發人員在提交新版本時未進行單元測試。 所以，我們建議開發人員將程序包提交給測試人員以前先對程序代碼進行檢查，這樣能有效地縮短 BUG的生計周期，提升測試人員和開發人員的工作效率。遺留問題列表＜給出遺留的影響到系統上線或許進入下一個環節的問題，比方，狀態為“致命”的測試缺點，或許需要要點關注的狀態為“嚴重”的測試缺點。關于其余需要需求負責人、開發負責人、版本負責人等加以關注或許加以改良的問題，也需要在此處列出缺點編號缺點描繪嚴重級別重現概率影響說明遺留原由—致命100%致使系統崩潰需求改正，待確認需求后一致改正嚴重100%致使數據丟失數據庫遷徙，待遷徙后修復風險剖析＜對系統上線或許進入下一