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

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

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

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

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

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

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

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

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

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

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

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

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