• 驗證

• 現(xiàn)場反饋bug，需要由測試接口人統(tǒng)一接收，并驗證，驗證通過后登記bug，指派給開發(fā)

• 登錄（測試）

• 進入測試主頁面，使用頁面中的“+提bug”按鈕創(chuàng)建新bug。

• 在登記bug前，請先搜索一下禪道中是否已經(jīng)有人登記了相同的問題，如有則不要再重復登記；

• **bug**輸入項說明及填寫規(guī)范：

• 輸入項：所屬迭代填寫規(guī)范：必填，否則bug統(tǒng)計時會有問題

• 輸入項：影響版本 填寫規(guī)范：版本測試填寫對應的版本號；熱修復填寫熱修復的版本號；

• 輸入項：當前指派填寫規(guī)范：將bug指派給開發(fā)組長，由開發(fā)組長安排bug修復計劃；

• 輸入項：bug類型填寫規(guī)范：選擇對應的問題類型

• bug的類型

• 模板：

• 輸入項：bug標題

• 填寫規(guī)范：

• l 版本測試和熱修復測試問題：bug所在子功能名-完整的問題描述（不要寫需求描述）

• l 所有bug在提交時，均需要進行是否低級bug（只需要分析一步，沒有任何轉折or只要最基本的自測就能發(fā)現(xiàn)的bug）的認定，認定為低級bug時，**在標題開頭增加：*******

• l 產(chǎn)品經(jīng)理/項目經(jīng)理驗收過程中發(fā)現(xiàn)的問題，在標題前打標記：UAT-

• l 產(chǎn)品上線后非用戶發(fā)現(xiàn)反饋提交的問題，在標題前打標記：PRD-

• 產(chǎn)品上線后外部反饋提交的問題，是測試階段已提交的bug，在標題前打標記：ZPRD

• 維護測試中專項測試的bug，根據(jù)實際情況在bug，在標題前打標記：清理測試/按鈕防抖

• l 回歸測試中明顯上一版正常，這一版不正常的bug，在標題后打標記：（修復引入）

• l 測試中遇到的隨機bug，在標題后打標記：（隨機）

• l 產(chǎn)品經(jīng)理提出讓測試登記的需求變更bug，在標題前標記：需求變更-需求描述；填寫規(guī)范：l 版本測試開始前，先與產(chǎn)品經(jīng)理/項目經(jīng)理確認好當前版本上線時間、和下個版本預計上線時間；

• l 熱修復版本發(fā)現(xiàn)的bug，截止日期填寫當天；l 測試填寫的截止日期作為參考值，截止日期的最終值由項目經(jīng)理確認。填寫規(guī)范：問題的詳細描述，或貼問題截圖說明；步驟、結果、期望的順序不能改；
  

• 輸入項：嚴重程度填寫規(guī)范：其中1級重大、2級嚴重、3級普通、4級輕微，詳細如下：1級：核心功能無法使用、系統(tǒng)崩潰（含404）、數(shù)據(jù)丟失、導致冒煙測試無法通過的問題 2級：主要功能問題，關聯(lián)影響其他功能使用，數(shù)據(jù)錯誤 3級：次要功能問題，不影響模塊中其他功能。4級：各種細節(jié)建議、文字描述（錯別字、歧義、詞不達意）、易用性、界面布局、風格統(tǒng)一等PS*：核心、主要、次要功能中符合4級定義的bug，均選擇4級；*性能、兼容性問題屬于bug類型，不影響嚴重程度的判斷；

• 輸入項：優(yōu)先級填寫規(guī)范：1級最高，4級最低，詳細如下：1級：核心業(yè)務、主要業(yè)務、主要功能阻塞，特殊性能要求未達到的問題；2級：核心業(yè)務、主要業(yè)務問題，不影響業(yè)務正常進行的問題；3級：主要功能的問題；4級：非核心業(yè)務、主要業(yè)務、主要功能的問題。**PS**：緊急程度使用優(yōu)先級進行標記，請結合功能點清單中標記的核心業(yè)務、主要業(yè)務、主要功能來判斷問題的優(yōu)先級。特殊情況可請產(chǎn)品經(jīng)理調整優(yōu)先級。

• 輸入項：截止日期
  

bug的截止時間

• 輸入項：重現(xiàn)步驟
  

分配

• 開發(fā)組長將問題指派給開發(fā)人員，給出解決時間和優(yōu)先級

• 如果選擇外部原因、延期處理的bug，請先報告在指派給測試

• 測試人員激活bug，開發(fā)組長了解原因后在指派給開發(fā)

  
  

• 分配時核對項
  

• 輸入項：優(yōu)先級填寫規(guī)范：1級最高，4級最低，詳細如下：1級：需要立即解決的問題；2級：需要在指定時間內解決的問題；3級：項目開發(fā)計劃內解決的問題；4級：為資源充沛時解決的問題。
  

修復

• 開發(fā)在指定時間修復bug并填寫解決方案，將bug提交給測試驗證

  
  

• 在禪道中打開某個bug，使用“解決”功能，進入該bug的解決頁面，填寫相應“解決方案、指派給、備注”
  

• 輸入項：解決方案填寫規(guī)范：正確填寫

• 輸入項：解決版本填寫規(guī)范：填寫正確的解決版本號輸入項：解決方案、備注、指派給填寫規(guī)范：l 設計如此、不是bug、不予解決三類bug，和產(chǎn)品及測試人員溝通后，再指派給測試。l 外部原因、延期處理兩類bug在注釋中寫明原因，指派給開發(fā)組長，開發(fā)組長審核通過后指派給測試。l 研發(fā)人員正常修復bug后，需在注釋中填寫問題產(chǎn)生原因，及解決方法。填寫此信息可以幫助統(tǒng)計研究每個人的編碼習慣、薄弱環(huán)節(jié)、同時利于提升測試人員的理解，便于以后更效率的發(fā)現(xiàn)問題。l 代碼

回歸（測試）

• 測試人員根據(jù)發(fā)布版本要求對bug進行統(tǒng)一回歸測試，避免自己在測試環(huán)境上進行無效的測試。

激活（測試）

• 回歸測試中發(fā)現(xiàn)未修復成功的bug，激活后統(tǒng)一指派給開發(fā)組長。激活bug時，不能刪除影響版本中原有的版本號，同時必須新增一個激活時的版本號；

關閉 （測試）

• 對已解決的bug在有效的回歸測試后關閉。對不是bug、不予解決、無法重現(xiàn)、外部原因等bug在備注中填寫測試人員的理解后關閉。對其他類型bug在驗證后關閉，定期統(tǒng)計分析。

版本號管理（測試）

在禪道的迭代-版本中創(chuàng)建版本號；

• 在新功能提測時，創(chuàng)建版本號：x.x.x.01修復.00版本測試過程中，每次發(fā)版動作開始后，將X.X.X.01修復.00，修改為：X.X.X.0100.00，同時新增版本號：X.X.X.01修復.00；版本測試過程中，每進行一次發(fā)版動作，必須增加一個版本號，并記錄該版本發(fā)版原因；版本測試過程中，遇到阻礙測試進行必須馬上修復發(fā)版的bug時，新增版本號：X.X.X.XX緊急修復.00，然后告知開發(fā)修復該bug后要馬上發(fā)版，該bug的解決版本號需要選緊急修復版本號；當版本測試完成后，版本中會遺留一個：X.X.X.XX修復.00版本號，在下一次提測前，所有遺留bug修復后都會進入這個版本號，在下個版本提測時，需要將該版本號修改為：X.X.X.XX00.00，再新增一個X.X.X.XX修復.00當版本測試需要分批次修復遺留bug、或完成新功能時，提前在版本中創(chuàng)建好每個批次需要使用的版本號，如：X.X.X.XX第一批次修復.00、X.X.X.XX第二批次修復.00……對已解決的bug在有效的回歸測試后關閉。對不是bug、不予解決、無法重現(xiàn)、外部原因等bug在備注中填寫測試人員的理解后關閉。對其他類型bug在驗證后關閉，定期統(tǒng)計分析。

總結：

• 聽從組長的bug分配任務，按時按量的完成的bug的修復

• 安裝文檔來編寫bug的說明（比如嚴重程度、優(yōu)先級、截止時間、重現(xiàn)步驟.....）

• 在禪道軟件上點擊bug，填寫相應：解決方案、指派給、備注”

• 版本號：每次提交版主在后面疊加

? ? ? ? ? ? ? ? ? ??