測試過程管理之發(fā)布申請流程

接上節(jié)內(nèi)容項目測試的周邊文檔，今日分享發(fā)布申請清單與缺陷跟蹤管理表。

對于小型項目來講，發(fā)布申請清單由項目經(jīng)理填寫并審核，然后交付部署人員直接發(fā)布了。但在嚴謹?shù)捻椖恳?guī)范里，這種方法并不可行，尤其是大型項目，如果是涉及到外部客戶的項目，發(fā)布申請清單更是需要經(jīng)過層層審核，通過后方可執(zhí)行發(fā)布動作。

發(fā)布申請清單

發(fā)布申請清單首先，我們先了解下項目中發(fā)布的整個流程，很多傳統(tǒng)的測試人員一般只跟蹤到測試交付，或是產(chǎn)品驗收結(jié)束階段。對于發(fā)布流程不清晰 ，或是等到發(fā)布后會由項目經(jīng)理通知需要線上測試。以此類推，測試人員一直處于被動的工作階段。對于項目的整體規(guī)范，發(fā)布流程如下：測試團隊系統(tǒng)測試交付通過->UAT測試團隊預發(fā)布測試通過->產(chǎn)品經(jīng)理驗收通過->研發(fā)經(jīng)理填寫發(fā)布申請清單->交由所屬項目經(jīng)理&QA經(jīng)理簽字確認->研發(fā)經(jīng)理發(fā)送申請發(fā)布郵件->職能部門負責人同意后方可執(zhí)行發(fā)布動作，否則會給出拒絕發(fā)布的原因。

一般情況下，發(fā)布申請清單主要包含以下內(nèi)容：

• 項目名稱

• 當前版本

• 發(fā)布版本

• 申請人

• 申請日期

• 版本描述

• 測試情況

• 回退機制

• 備注

• 相關(guān)審核人員

當前版本填寫當前的應(yīng)用版本號，申請人為申請發(fā)布的第一責任人，也是填寫發(fā)布清單的人員，版本描述即目前即將要上線的內(nèi)容，可以分為新增和刪除，優(yōu)化功能；測試情況填寫申請發(fā)布版本的測試結(jié)果 ，如SIT/UAT測試通過，XXX產(chǎn)品團隊驗收通過等；備注與相關(guān)審核人員可根據(jù)公司需要配置；一般由項目經(jīng)理及QA經(jīng)理、職能部門負責人審核；回退機制根據(jù)項目性質(zhì)及公司要求來，回退機制與風險識別同等重要，一旦發(fā)布異常，需要做好容災(zāi)測試的建議方案。以下舉個例子：

試運行：2天；

試運行期間，內(nèi)部用戶進行系統(tǒng)功能驗收及測試團隊線上常規(guī)測試；若發(fā)現(xiàn)問題且問題數(shù)量較多（超過XX個）或出現(xiàn)嚴重程度高的問題則進行回退，回退版本至上一個版本；回退需要在XX確認前進行并馬上進行問題修復；若發(fā)現(xiàn)問題數(shù)量較少且嚴重級別較低，則后續(xù)安排逐步修復。

即使我們現(xiàn)在工作中并不需要測試人員去接觸到發(fā)布相關(guān)的工作，也需要主動學習以使我們?nèi)谌脒M整個項目中，而非單純地“執(zhí)行測試”。

缺陷跟蹤管理表

缺陷跟蹤管理表在工作中還是比較常見的，缺陷報告一般使用缺陷管理工具來維護與跟蹤。這里的缺陷跟蹤管理表一般用于項目后期與測試收尾階段，對于遺留缺陷的跟蹤與維護，缺陷跟蹤管理表會在測試報告、發(fā)布申請清單、客戶項目周例會會議中使用到。每個項目中都難免會存在一些需要耗費時間精力的問題，特別是性能測試問題，平均修復周期在1周左右。但按照測試計劃測試交付時間已結(jié)束時，需要測試人員整理出遺留問題并以跟蹤管理表的形式來維護。

缺陷跟蹤管理表主要包含以下內(nèi)容：

• 缺陷編號

• 缺陷類別

• 緊急程度

• 用例編號

• 問題描述

• 解決方案

• 提出人

• 處理人

• 解決時間

以上，也可以從缺陷管理平臺中過濾導出，需要注意的是用例編號是對應(yīng)缺陷的測試用例編號，如果是在探索性測試或是內(nèi)部用戶發(fā)現(xiàn)的，且并無對應(yīng)用例路徑 ，則需要在所屬用例中增加該用例，并更新到用例庫中，也是日后學習與要注意的地方。解決方案可以靈活填寫，但要交付出去時解決方案不能為空。處理人可以有多個。缺陷跟蹤管理表一般會放在協(xié)同文檔。