最近參與了幾次面試，面試者的簡歷中都會提及：需求或者版本測試結束后會進行版本總結，而不僅僅是提供一份測試報告。
於是特意追問了一下，總結中都包含什么內容，答復上基本都是圍繞此次測試過程中發現的BUG數量以及修復情況進行分析總結，其它方面的延伸比較少。
自己也思考了一些，在這里與大家交流，歡迎大家爭相討論。
一、何為測試總結
區別與測試報告一般是針對開發完成編碼后對開發質量的一個總結。
測試總結站的角度，更多是在整個軟件研發過程中所有問題的總結。
包含需求搜集階段的問題、產品需求分析設計階段的問題、開發設計編輯階段的問題、產品測試階段的問題、項目上線后反饋的問題的總結。
二、何時進行
1.需求測試或者版本發布測試結束后
此時進行總結更具有時效性，但缺少使用者對此版本的直接反饋，只能算是內部總結。
2.產品上線應用一段時間之后
增加了客戶使用后的反饋，更有利於從第三方視角反饋發布版本的質量情況及用戶視角暴露的問題。
三、誰來組織/誰要參與
組織者：一般由測試經理或者對應項目的測試主管組織。
參與者：項目總監、產品經理、開發經理、測試經理及其它相關開發測試工程師。
四、總結形式/載體
1.召開總結會議（載體：word、excel、ppt、視頻等），常用ppt。
2.郵件溝通反饋
3.視頻會議等
具體形式因團隊而已，重點要關注效果，總結后要形成可落地的改進計划。
五、總結內容
版本總結中應該包含哪些內容？那些量化的數據可以分析？
這兩日讀了Vincent的軟件質量報告模板-產品質量度量，針對研發及測試階段的分析說明已經很到位。
涉及到開發、測試計划偏離度的分析，缺陷類型、優先級、分布、質量趨勢的分析，建議大家可以仔細拜讀下。
里面涉及的內容這里就不再次說明，其他方面的內容這里做下補充，大家可以整合一份適用於自己公司的一套標准。
前邊我們提到，要總結需求搜集階段的問題、產品需求分析設計階段的問題、開發設計編碼階段的問題、產品測試階段的問題、項目上線后反饋的問題等。
1.需求搜集階段-客戶/項目
針對需求提交是否及時、是否提交符合規范、描述是否清晰、業務場景是否完備等進行統計分析。
如圖中V1.0版本需求按時提交率只有75%，很有可能造成版本規划延期或者版本發布時間壓縮。
根據相關數據及測試過程中產生的影響，針對需求搜集放提出相應建議，並要求需求搜集放給出相應的保障措施及計划。
2.需求分析及設計-產品側
針對需求，產品是否按時審批、按時提交相關設計、組織相關需求評審溝通會議、插入需求占比等相等 
此處插入需求占比，也可根據插入需求工時與版本規划工時進行對比統計。
3.開發設計編碼-開發側
針對開發設計提交及時性、開發計划按時完成情況、缺陷數量、缺陷密度、缺陷修復周期、缺陷分類、缺陷修復情況分析Vincent文章中已經說明。
下面我們從另外一個角度，工時投入情況去分析。
從上述看，我們能夠發現開發在自測與設計階段的投入較少，從而造成大部分精力都在修復BUG。
建議開發：定期進行設計Review、代碼Review，要求開發做單元測試，寫自測報告。
4.產品測試階段-測試側
針對測試用例、測試報告提交的及時性、版本發布內容提交的完備性、計划按時完成情況、缺陷遺留情況、客戶，項目反饋問題情況進行分析。
下面我們從另外一個角度，工時投入情況去分析。
從上述看，測試在BUG與產品設計優化上的投入將近占了測試工作的一半，說明開發質量與產品設計存在一定的問題。
5.項目上線后問題反饋
針對項目/客戶反饋問題進行分析總結，類似缺陷分析，重點總結遺漏的原因及后需的規避措施。
上述看，場景遺漏導致的問題較多，測試側應該在用例設計及評審上做重點改進。
六、匯總整理各部門總結並發布
基於測試總結過程中的數據分析，我們提出了對部門的建議。
針對提出的建議，各部門要配合梳理可落地的改進措施，匯總到測試部門，測試部門負責整理發布，並監督改進的落地。
以保障在下個版本測試過程中，相關問題能夠得到有效的規避，從而提升工作的效率與質量。
針對上述各個階段的分析總結，除了一些具體的數據以外，可以增加一些具體的案例，這樣在分析總結是大家才能切身體會。
數據的背后不是吐槽那個階段，那個部門的不好，目的是透過數據看本質，不斷完善我們的工作流程，達到高效協作，高質輸出的目標。