眾所周知，在軟件的生命周期中，只要軟件不被淘汰，測試的工作就要一直進行。很多時候一旦項目版本發(fā)布，大部分測試人員都會認為工作終于結束了，能夠休息幾天，做一些與發(fā)布版本無關的事情。

事實上，在版本發(fā)布之后，測試人員還有很多事情要做，比如總結、復盤、反思、整理測試的過程。像版本測試過程中遇到了哪些問題，在版本測試中發(fā)現(xiàn)了哪些缺陷，版本發(fā)布后用戶的反饋是什么等等。

在版本測試過程中，很多時候都是安排的任務多，但是給的時間少，所以測試中更多的是記錄發(fā)現(xiàn)的問題BUG，測試過程也只是大概記錄，沒有系統(tǒng)完整的文檔。測試人員應該在發(fā)布后使用相對大量的時間來總結、記錄和共享他們測試過程中碰到的問題，以及測試過程中缺陷的分布情況。

測試用例需求覆蓋分析，需求的覆蓋率有沒有達到100%;測試的覆蓋率和測試的通過率情況如何?？梢园凑詹煌哪K，來分析測試用例數(shù)、需求覆蓋率、執(zhí)行的情況、測試覆蓋率、通過率。

缺陷的分析與統(tǒng)計，通過缺陷的統(tǒng)計可以反映出被測軟件的質量?？梢园驯据啘y試中發(fā)現(xiàn)的所有缺陷進行整合，找到的缺陷可以按照功能模塊，嚴重程度，優(yōu)先級，缺陷類型分布來進行分類匯總，比如像以下這種方式：

其次可以從軟件【已發(fā)布的版本】來進行分析缺陷，通過折線圖的形式，來體現(xiàn)出每個版本中缺陷的數(shù)量

也可以從【缺陷類型(BUG引入的原因)】角度來分析缺陷，通過餅狀圖的形式，根據(jù)缺陷類型來體現(xiàn)缺陷數(shù)量分布，比如：功能錯誤缺陷占比數(shù)據(jù)，UI設計缺陷占比數(shù)據(jù)，文檔缺陷占比數(shù)據(jù).....

還可以從缺陷的嚴重程度來分析缺陷：通過柱形圖的形式，按照嚴重程度來體現(xiàn)缺陷數(shù)量，比如：本輪測試中，致命、嚴重、一般、較小各自的缺陷總數(shù)量

(上述圖片均來自于網(wǎng)絡)

通過分析總結測試過程，還要考慮是否存在漏測，有沒有考慮風險分析與評估，版本發(fā)布后用戶的反饋，測試人員的測試分析點是否考慮不全面，對被測系統(tǒng)的核心業(yè)務模塊理解不徹底，導致引發(fā)測試漏洞，測試人員的經(jīng)驗是否不足，測試經(jīng)理在工作組織安排上是否存在疏忽等。

最重要的還是要收集好用戶的反饋，整個系統(tǒng)應該為用戶提供一個反饋入口，比如像用戶體驗計劃，客服等功能。

當用戶在使用軟件的過程中發(fā)現(xiàn)問題時，用戶會將問題進行提交，客服人員會跟進用戶的反饋問題。測試人員拿到用戶反饋問題后，要及時進行復盤與跟蹤，看導致該問題出現(xiàn)的原因是什么，后期進行深入回歸測試等。

總之項目產(chǎn)品版本升級后，測試人員還要持續(xù)進行測試工作的開展，保證測試過程的高質量性。小伙伴們可以及時關注公眾號，滿滿的技術干貨指導大家測試工作的進行。