測試人員在完成一項測試項目以后，最應該做的就是去編寫測試總結報告，這樣有利於尋找自己的不足，同時在下一次測試的過程中能更快的找到自己對測試的認識，在測試完成-測試總結-測試繼續-測試完成-測試總結，這樣一個循環的過程中，才能不斷的成長和完善自己的不足。也就是我們簡單的說 執行-總結-反思-執行-總結-反思......無限循環的過程中，才能讓自己不停的往前推進，不然只是流水線似的的工作，每到年底總結感覺自己又過去了一年，撒變化都沒有，也不知道自己有哪些進步，但是卻在一步一步的憂慮中，又長了一歲...離35歲又進了一步。
一、測試報告與測試總結的區別？
一直糾結到底什么是測試報告和測試總結，一度把他們混為一談了，總想去總結點撒，但是每次一去總結的時候，發現哪里不對。
測試報告：把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟件存在的質量問題提供依據，同時為軟件驗收和交付打下基礎。一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據采集及對最終測試結果的分析。測試報告僅僅是測試總結的一部分，是對測試過程的描述和測試結果信息的匯總，並根據過程數據做分析給出測試結論評估。
測試總結：測試總結的是問題，是風險，是經驗，是如何改進，是分析測試過程中的問題，並針對項目進行分析從而找出解決方案。也可以說用於分析並總結這些缺陷，將總結出來的經驗用於指導下一次的測試用例設計。在每個版本測試完畢后，要進行測試總結，做一些比例的總結、缺陷嚴重級別及比例的總結，人員工作效率的總結，還有最重要的是風險的平復，對下一測試版本的建議等。
我所理解的測試報告是對外的，需要正式提交的一份文檔，它是一份有規則、有結構的正式文檔，需要涵蓋我們的目的、背景、測試概要（測試環境和配置、測試方法和工作、測試概要分析表）、各模塊的完整測試情況（功能測試、性能測試、可靠性測試、兼容性測試、安全性測試、易用性測試、兼容性測試）。
請參考博文：https://www.cnblogs.com/wendyw/p/13375975.html
而所謂的測試總結是對內的，對我們內部在自己測試過程中的問題、難點進行整理以吸取教訓和經驗，在下一次測試開始前能更好的進行改進的一個反思的過程。它所涵蓋的應該是一些分析數據，比如測試用例分析、缺陷分析、質量優勢、質量問題總結。
二、測試總結思路
大綱：引言+測試概要+測試結果及缺陷分析+測試結論及建議
- 1.引言
- 2.測試概要
- 3.測試結果及缺陷分析（核心）
- 4.測試結論及建議
做任何測試總結，我們處於互聯網行業，一定首先要想到的是如何使用工具來幫助我們達到目的，而不是通過人工去實現。我們目前通過使用工具EXCEL工具的宏功能和結合禪道測試-BUG、用例，進行定制編寫相應的代碼，進行定制化缺陷分析。
1.測試結果及缺陷分析結果工具：分析工具+數據來源【Excdel宏功能+禪道-測試-對應項目導出來的數據】。
2.測試用例結果分析展示數據：測試用例的開始測試時間、計划完成時間、計划進度、實際進度、通過率、測試狀態、測試用例總數、測試用例的通過、失敗、阻塞、未執行、延期、無效。
在測試用例分析的時候，涉及到的幾個公式：
- 通過率=通過/(通過+失敗)；
- 測試狀態：實際進度VS計划進度；
- 實際進度=(通過+失敗)/(通過+失敗+阻塞+未執行)
3.BUG結果分析展示數據：總的用例BUG-統計與分析、BUG趨勢、BUG-遺留-嚴重程度和優先級、BUG-遺留-開發-嚴重程度和優先級、BUG-遺留-類型分布、開發分布、激活天數、BUG-本周創建-嚴重程度、BUG-本周關閉、BUG-累計情況-嚴重程度-狀態。
具體實例，根據某個項目進行詳細分析。
三、測試總結
測試總結
1引言
1.1編寫目的
本測試總結了具體編寫目的，指出預期的讀者范圍。
本測試總結為XXX項目的測試總結，目的在於總結測試階段的測試及分析測試結果，描述系統是否符合需求（或達到XX功能目標）。預期參考人員包括用戶、測試人員、開發人員、項目管理者、其他質量管理人員和需要閱讀本總結的高層經理。
1.2項目背景
對項目目標和目的進行簡要說明。
1.3系統簡介
設計說明書中必要的框架圖和網絡拓撲圖。
1.4術語和縮寫詞
1.5參考資料
2測試概要
包括測試的一些聲明、測試范圍、測試目的等，主要是測試情況簡介。
2.1測試用例設計
2.2測試環境和配置
2.3測試方法和工具
3測試結果及缺陷分析
匯總各種數據並進行度量，度量包括對測試過程的度量和能力評估、對軟件產品的質量度量和產品評估。
3.1測試用例分析
需求覆蓋：
需求覆蓋是指經過測試的需求/功能和需求規格說明書中所有需求/功能的比值，通過情況下要達到100%的目標。
- 需求/功能（或編號）：需求覆蓋率=(Y項數量/需求總數)*100%
- 已覆蓋需求數量
- 未覆蓋需求數量
- 測試類型
- 是否通過：[Y][N][P][N/A],P表示部分通過，Y表示通過，N表示不通過，N/A表示不可測試或者用例不適用。
測試覆蓋：
- 需求/功能（或編號）：測試覆蓋率=(執行數/用例總數)*100%
- 用例個數
- 執行總數
- 未執行
- 未/漏測分析和原因
3.2缺陷分析與統計
- 缺陷發現效率=缺陷總數(bug)/執行測試用時
- 用例質量=(缺陷總數bug/測試用例總數)*100%
- 缺陷密度=缺陷總數/功能點總數
缺陷密度：系統各功能或各需求的缺陷分析情況，開發人員可以在此分析基礎上得出哪部分功能/需求缺陷最多，從而在今后開發中注意避免並在實施時予以關注，測試經驗表明，測試缺陷越多的部分隱藏的缺陷也越多。
3.2.1BUG趨勢
BUG趨勢圖預期結果展示：
- 各嚴重程度累計趨勢圖：
- 各曲線應呈緩慢增長趨勢。
- 嚴重程度1的曲線應處於其他嚴重程度之下（少於其他嚴重程度）。
- 累計總數趨勢圖：應呈緩慢增長趨勢。
- 累計遺留趨勢圖：前期應呈平緩趨勢，后期應呈下降趨勢且最后歸於0
- 當期新增趨勢圖：前期應呈平緩趨勢，后期應呈下降趨勢且最后歸於0
- 當期關閉趨勢圖：前期應呈平緩趨勢，后期應呈下降趨勢
BUG趨勢圖實際結果展示，若與預期不一致，解釋原因，比如：
- 大多數功能提測時間集中，未細分階段進行提測
- 某模塊開發質量差
- 開發未及時修復BUG
- 需求變更未評審導致開發未按變更后需求實現
3.2.2BUG遺留
缺陷趨勢分析是缺陷的縱向分析，在時間上對缺陷進行分析，有助於進度控制和測試過程的管理。
缺陷趨勢分析是考察缺陷隨時間變化的趨勢，如將各種狀態（活動的、修正的、關閉的）的缺陷計數作為時間的函數來顯示，缺陷趨勢分析報告可以是實時的(如每日缺陷數、每周缺陷數隨時間的變化曲線)，也可以是累計的（如新報告的缺陷累計數和關閉的缺陷累計數比較曲線）
缺陷趨勢預期：
生命周期的初期，缺陷增長率高。在達到頂峰后，缺陷會隨時間以較低的速率下降。可以根據這一趨勢付復審項目時間表來檢查進展情況。
激活狀態BUG - 嚴重程度與優先級：
- 嚴重程度與優先級為1的遺留數量：應為0
- 嚴重程度與優先級為2的遺留數量：應為0
- 嚴重程度與優先級為3和4遺留數量：應為0
遺留數量 > 0原因：
延期修復BUG - 嚴重程度與優先級：
- 延期的嚴重程度與優先級為1的遺留數量：應為0
- 延期的嚴重程度與優先級為2的遺留數量：應為0
- 延期的嚴重程度與優先級為3和4遺留數量：應該控制在閾值范圍以內
1和2延期數量 > 0 原因：
3和4延期數量 > threshold原因：
3.2.3BUG累計情況 – 嚴重程度
模塊VS嚴重程度（分析BUG數量TOP2的模塊）
各程度占比（分析嚴重程度為1和2過多的原因）
3.2.4BUG累計情況 – 類型分布
BUG產生原因分析：分析數量TOP2的類型
3.2.5BUG累計情況 – 解決方案
BUG解決方案分析：分析無效BUG數量過多的原因（已解決、延期處理為有效BUG）
3.2.6BUG累計情況 – 激活次數
BUG激活次數：分析各位開發人員解決BUG的效率及質量
3.2.7BUG累計情況 – 由誰產生
BUG由誰產生：BUG制造者分布
3.2.8BUG累計情況 – 發現階段
BUG發現階段：應 組件測試 > 集成測試 > 系統測試 > 驗收測試 > 試運行
分析驗收測試、試運行BUG過多原因
3.2.9BUG累計情況 – 由誰發現
BUG由誰發現：分析測試效率、質量
3.2.10BUG累計情況 – 由誰發現
BUG由誰發現：分析測試效率、質量
4測試結論與建議
對過程、缺陷分析之后下結論。
4.1測試結論
- 測試執行是否充分
- 對測試風險的控制措施和成效
- 測試目標是否完成
- 測試是否通過
- 是否可以進入下一階段項目目標
4.2測試建議
- 對系統存在問題的說明，描述測試所揭露的軟件缺陷和不足，以及可能給軟件實施和運行帶來的影響
- 可能存在的潛在缺陷和后續工作
- 對缺陷修改和產品設計的建議
- 對過程改進方面的建議
4.3測試優化
優化：根據項目實施過程中的問題做總結分析，針對問題找到解決方法，進而改進項目實施中的缺陷，提升項目實施質量。按照軟件生命周期分為3類：最終產品質量度量、過程中質量度量、維護質量度量。
（1）產品質量度量：缺陷密度、用戶報告的問題和用戶滿意度等。
（2）過程中質量度量：測試進度偏差、案例執行率、測試案例有效性、測試案例覆蓋率、基於輪次的缺陷發現率等。
（3）維護質量度量：逃逸缺陷密度、修復響應時間、逾期修復百分數和有效缺陷修復率等。
如果有更好的想法，歡迎大家留言討論，本文只代表個人的不成熟想法，請指教！