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

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

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

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

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

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

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

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

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

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

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

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

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