測試報告模板

測試報告模板1.簡介

1.1編寫目的

本文檔用于記錄測試過程，總結各輪次的測試情況，分析測試數(shù)據(jù)，歸納測試工作進行過程中暴露的問題與遺留的風險，給出相應的測試建議以供后續(xù)項目參考。

1.2項目背景

xx需要一個擁有真實用戶的社區(qū)化產品，通過真實高信任度用戶關系的建立，提高用戶粘性，提升活躍會員數(shù)，帶來長效的增長。在此背景下，以真實用戶為基礎的社區(qū)應運而生。主要具有以下5點意義：

1.提高社區(qū)活躍會員數(shù)

2.提高用戶粘度

3.建立真實（和用戶的社區(qū)身份相一致）的多維用戶信息

4.建立高信任度的用戶關系

5.達到真實可信用戶關系中的用戶之間的傳播效應

1.3定義、首字母縮寫詞和縮略語

無

1.4參考資料

各輪系統(tǒng)測試階段總結

2.測試概要

整個xx項目的測試經歷了xx-1.0與xx-1.1兩個階段，共經歷了1輪集成測試、6輪冒煙測試和7輪系統(tǒng)測試和1輪上線跟蹤測試。整個測試過程中累計執(zhí)行用例8100條，發(fā)現(xiàn)缺陷1026個。截至xx-1.1第四系統(tǒng)測試結束，所發(fā)現(xiàn)的高權重問題已得到修復和驗證。

2.1測試時間

整個xx項目的測試時間從xx年2月18日開始，到xx年3月27日上線止，期間各階段工作情況如下：

2.2測試范圍

本次測試覆蓋的范圍包括：功能測試、兼容性測試、接口測試、數(shù)據(jù)遷移測試、性能測試、安全性測試和品質監(jiān)控。以下分別對功能測試、兼容性測試、接口測試、數(shù)據(jù)遷移測試、性能測試和安全性測試進行說明。

功能測試

xx-1.1在xx-1.0基礎上更新的主要功能如下：

數(shù)據(jù)遷移測試

接口測試

兼容性測試

性能測試

參見SVN中的性能測試報告。

安全性測試

整個xx測試過程中先后進行了三輪安全性測試，發(fā)現(xiàn)了2個影響較嚴重的安全性問題，且都已得到修復和驗證。

2.3測試版本

下表顯示了各輪次測試版本和對應測試范圍的分配情況：

2.4測試用例

根據(jù)需求文檔，測試人員編寫和內審了測試用例，為xx項目共計編寫用例3558條，累計執(zhí)行用例8100條。

2.5測試策略

xx-1.0測試策略

1.測試類型：按階段劃分定義為集成測試和系統(tǒng)測試。

2.集成測試階段進行了一輪集成測試，主要以需求挖掘、分析、確認和尋找實現(xiàn)與需求不一致為主要目標

3.系統(tǒng)測試階段分三輪進行，基本策略如下：

第一輪為覆蓋性測試，測試范圍覆蓋以上描述的所有范圍，關注所有級別的bug；

第二輪對權重為A、B的模塊進行功能測試、兼容性測試，權重為C的模塊進行冒煙測試，回歸測試所有已修復的bug；

第三輪對權重為A的模塊進行功能測試、兼容性測試，對權重為B、C的模塊進行冒煙測試，回歸測試所有待解決的bug，及已關閉的高優(yōu)先級bug。

每輪測試開始前都進行快速的冒煙測試，通過冒煙確信系統(tǒng)可測時進入下一輪系統(tǒng)測試。

數(shù)據(jù)遷移測試、接口測試只在第一輪進行。

4.缺陷評估：每輪測試結束后都組織開發(fā)工程師、測試工程師、產品工程師等共同評估產品缺陷，評估內容包括缺陷解決方案、是否涉及需求變更、下一輪開始時間及是否可以結束測試等。

xx-1.1測試策略

1).測試類型：按階段劃分定義為系統(tǒng)測試。

2).系統(tǒng)測試分四個輪次進行，基本策略如下：

第一輪為覆蓋性測試，測試范圍覆蓋以上描述的所有范圍，關注所有級別的bug；

第二輪對權重為A、B的模塊進行功能測試、兼容性測試，權重為C的模塊進行冒煙測試，回歸測試所有已修復的bug；對系統(tǒng)進行性能測試。

第三、四輪對權重為A的模塊進行功能測試、兼容性測試，對權重為B、C的模塊進行冒煙測試，回歸測試所有待解決的bug，及已關閉的高優(yōu)先級bug；

每輪測試開始前都進行快速的冒煙測試，通過冒煙確信系統(tǒng)可測時進入下一輪系統(tǒng)測試。

數(shù)據(jù)遷移測試、接口測試只在第一輪進行。

3).缺陷評估：每輪測試結束后都組織開發(fā)工程師、測試工程師、產品工程師、QA等共同評估產品缺陷，評估內容包括缺陷解決方案、是否涉及需求變更、下一輪開始時間及是否可以結束測試等。

3.結果分析

整個xx測試過程中累計發(fā)現(xiàn)有效缺陷1026個，其中A級缺陷3個，B級21個，C級800個，D級169個，E級33個。經項目組成員評估，到xx-1.1發(fā)布止遺留缺陷51個，其余975個缺陷均已修復且全部驗證通過。下面分別從xx-1.0和xx-1.1兩個階段、從不同角度對缺陷進行分析。

3.1缺陷趨勢

xx-1.0

整個測試過程中累計發(fā)現(xiàn)缺陷734個，各輪次缺陷分布情況如下表。

下圖顯示了xx-1.0測試過程中缺陷的發(fā)展趨勢：

xx-1.1

整個測試過程中累計發(fā)現(xiàn)缺陷292個，各輪次缺陷分布情況如下表。

下圖顯示了xx-1.1測試過程中缺陷的發(fā)展趨勢：

從缺陷趨勢圖中可以看出，xx-1.0和xx-1.1兩個測試階段，缺陷均隨著測試過程的推進呈現(xiàn)收斂趨勢，這符合測試缺陷的發(fā)展規(guī)律，證明測試計劃和策略是可靠有效的。

3.2缺陷優(yōu)先級分布

xx-1.0

每輪次各級別缺陷分布情況如下：

xx-1.1

每輪次各級別缺陷分布情況如下：

整個xx項目測試過程種中發(fā)現(xiàn)的C級以上（包括C級）缺陷824個，占總缺陷數(shù)的80.31%，這說明系統(tǒng)在測試過程中處于不穩(wěn)定狀態(tài)，存在大量較為嚴重的問題，但隨著測試過程的推進，高優(yōu)先級問題又逐漸減少，整個系統(tǒng)趨于穩(wěn)定。

3.3缺陷按模塊分布

下表顯示了整個xx測試過程中發(fā)現(xiàn)缺陷在各模塊中的分布情況

從下圖中可以看出各模塊缺陷的分布趨勢：

從以上缺陷分布情況看，所有缺陷中有近30%是和產品需求相關的，諸如需求定義欠明確、需求描述有歧義、需求沒有定義、實現(xiàn)和需求不一致等。

3.4重開缺陷情況

從上表可以看出整個Space測試過程中，各輪驗證缺陷的重開比率都偏高，這是我們后續(xù)項目中需要關注和提高的地方。

3.5遺留缺陷情況

到xx-1.1發(fā)布止，整個Space項目遺留缺陷51個，且這些缺陷均通過PDT相關成員評估后確信可以遺留，待后續(xù)版本規(guī)劃處理。具體缺陷信息此處略去。

3.6上線跟蹤測試結果

xx-1.1于3月27日7:00上線后，我們在當日的7:00-12:00進行了集中跟蹤測試，且在此之后安排有2名測試工程師，每天用一些時間跟蹤上線情況、客服反饋問題的最新動態(tài)。截止4月2日上午11:00上線跟蹤測試結果是：累計缺陷40個，且都是C級以下。其中屬需求相關問題5個，因上線后環(huán)境差異導致問題35個，開放中缺陷4個，已關閉缺陷16個，已解決待驗證缺陷20個。

4.結論&問題&建議

4.1測試結論

1.經過前后兩個階段的多輪測試，雖遺留了一些缺陷沒有解決，但系統(tǒng)功能已趨于穩(wěn)定，且項目確定的范圍、策略和計劃均已實現(xiàn)，項目測試可以結束、xx-1.1可以上線。

2.通過測試覺得產品在用戶體驗方面有待后續(xù)版本進一步改進，不排除用戶在使用該產品時有“暈”的感覺。

4.2呈現(xiàn)的問題

1.需求問題。特別是xx-1.0項目需求，雖然陸續(xù)看到了好多需求文檔，但這些文檔給人的感覺是：需求分析不完整、需求描述不清晰，需求文檔的邏輯性、可讀性、可實現(xiàn)性、可測試性比較差，需求的歧義性較大。從而感覺在整個xx-1.0測試過程中不斷地在挖掘需求、確認需求、變更需求和評審需求。xx-1.1的項目需求有了很大改觀，xx本身需求經過和收集、分析、確認和評審的過程，但對各接口產品的需求仍然沒有進行統(tǒng)一的分析、確認和評審，這部分需求的歧義性較大且變更較多，整個需求文檔的可讀性、可測試性、完整性和清晰性仍然較差。

2.變更控制問題。這在xx-1.0的測試過程中體現(xiàn)的比較明顯，如項目需求的變更、項目責任人的變更、項目計劃的變更等。xx-1.0整個測試過程中一直在確認和變更需求，且需求變更的機制沒有規(guī)約，一個會議、一封mail或是一個口頭傳達就可能變更需求。xx-1.1測試過程中這一問題得到了較好的改進，但變更控制規(guī)約的實施欠佳。所有的需求變更均沒有及時很好的更新至需求文檔，xx-1.0體現(xiàn)的更為明顯。

3.版本控制問題。xx-1.0測試過程中沒能進行版本管理；xx-1.1測試過程中對xx本身的代碼進行了版本管理，各接口產品的代碼均由各技術負責人進行管理，在這期間出現(xiàn)過代碼覆蓋的情況、代碼忘記上傳或遺漏部署的情況。難以保證每輪測試版本的清晰、和發(fā)布版本與測試版本的一致性。

4.測試環(huán)境問題。xx-1.1測試期間測試環(huán)境和開發(fā)環(huán)境沒能很好的分離，導致測試和開發(fā)修復缺陷不能并行；測試期間有開發(fā)工程師直接在測試環(huán)境上修復缺陷和修改測試環(huán)境的情況；測試環(huán)境不穩(wěn)定，如hosts設置不正確等。

5.項目計劃欠明確、人員職責欠清晰。

4.3測試建議

1.遺留缺陷。建議在xx-1.1上線后以patch方式，或在后續(xù)版本中解決遺留缺陷，以提升產品的穩(wěn)定性和用戶體驗。

2.需求建議。不論是xx本身還是各接口產品，建議進一步加強需求收集、分析、確認和評審過程，進一步提升需求文檔的質量：減少需求的歧義性，提升需求的完整性、描述的清晰性、一致性、可讀性、可實現(xiàn)性和可測試性。同時建議在后續(xù)項目中能對設計文檔（如UI/UE等）進行評審，以增強產品的使用性、提升用戶體驗。

3.變更控制。建議在后續(xù)項目中進一步加強變更控制策略和規(guī)約制定，并強化變更控制規(guī)約的執(zhí)行。不怕變更，關鍵要控制好變更的時機和策略。

4.版本控制。加強xx本身，特別是各接口產品的版本控制策略，以保證測試版本的清晰性、發(fā)布/上線版本和最終測試版本的一致性。

5.測試環(huán)境。期望在后續(xù)項目中xx及各接口產品的測試環(huán)境和開發(fā)環(huán)境完全分開，或階段性完全獨立，且各部分環(huán)境有專門的接口人負責，在測試期間