Bug追蹤管理系統(tǒng)(Mantis)的培訓PPT課件

1 Bug追蹤管理系統(tǒng) Mantis 的培訓 Bug追蹤管理綜述Bug追蹤管理的流程Mantis操作簡述 主要內容 3 Bug追蹤管理概述 Bug追蹤管理的重要性保證Bug能夠得到及時的發(fā)現(xiàn)和解決解決bug的過程細節(jié)能夠得到完整的記錄和存檔隨時了解當前項目中的bug的處理狀況和整體情況Bug追蹤管理中的主要角色項目經理 PM主要職責 確認問題 分派任務 協(xié)調任務 重新打開問題開發(fā)人員 DEV主要職責 解決問題 申請協(xié)調測試人員 報告人員 RP主要職責 報告問題 測試并確認問題解決 Bug追蹤管理綜述Bug追蹤管理的流程Mantis操作簡述 主要內容 5 Bug追蹤管理的狀態(tài) 已關閉 已解決 已分派 提請協(xié)調 新建 已確認 打回 6 Bug追蹤管理的流程 已關閉 已解決 已分派 提請協(xié)調 新建 已確認 打回 報告問題 分派任務 認為問題描述不合格 重新說明問題 認為分派有誤或者需要幫助 重新分派 接受任務開始工作 已解決完畢 已完成自己的部分需要其他人再處理 確認問題解決 重新打開該問題 認為問題沒有解決 需要協(xié)調 重新解決問題 重新分派 7 Bug追蹤管理的狀態(tài)轉移矩陣 新建 該矩陣表示從當前狀態(tài)可以到達哪些下一狀態(tài) 8 流程示例 角色定義PM great mantis帳號 RP chijxDEV zhangb liangyb問題背景 媽媽愛問部分內容塊的ie和firefox下有兼容性的顯示問題需要美工zhangb和程序員liangyb共同配合完成 但首先是美工的工作 9 流程示例 續(xù)1 1Chijx提交bug 問題進入 新建狀態(tài) 2great認為描述不當 出現(xiàn)頻率和問題說明不清楚 因此打回 問題進入 打回狀態(tài) 此時不應對問題進行分派 否則流程會有問題 3 1chijx在 我的視圖 中發(fā)現(xiàn)自己報告的問題被打回 于是進行修改 重新提交3 2chijx將問題狀態(tài)改為 新建 10 流程示例 續(xù)2 4great發(fā)現(xiàn)重新修改的問題之后 如果認為描述得當 則將問題分派給開發(fā)人員 問題進入 已分派 狀態(tài) 由于問題牽涉到界面顯示 所以分派給美工zhangb 5zhangb在 我的視圖 中看到 查看問題 并且任務分配沒有異議 否則可以申請協(xié)調 則將問題的狀態(tài)改為 已確認 表示接受任務 開始工作 11 流程示例 續(xù)3 確認問題的時候 需要填入對于問題的注釋 如對于問題的大致分析 解決方案等等 12 流程示例 續(xù)4 6如zhangb完成修改 認為解決問題可以將狀態(tài)改為 已解決 如果覺得這個問題自己已經做好能做的部分 需要其他人再繼續(xù)修改 則 并且填寫申請協(xié)調的理由 問題進入 申請協(xié)調狀態(tài) 7Great發(fā)現(xiàn)了需要協(xié)調的問題 經過討論之后 將問題重新分派給liangyb 即由程序員做必要的調整 8Liangyb確認工作 問題進入 已確認 狀態(tài) 13 流程示例 續(xù)5 9liangyb解決了問題 將問題的狀態(tài)置為 已解決 并添加解決問題的說明 如解決的方法 是否還有注意事項 或者這是重復問題 或者不是問題 而是設計的考慮 10 1chijx在我的視圖發(fā)現(xiàn)該問題已解決 需要對此進行確認是否真正解決 14 流程示例 續(xù)6 10 2Chijx認為該問題沒有解決 因此打回11liangyb發(fā)現(xiàn)被打回的問題 如重新解決問題之后 再次提交解決 如認為該問題無法解決則申請協(xié)調 15 流程示例 續(xù)7 12chijx最終確認問題的解決 這樣一個典型的bug解決的周期才算是正式結束了 該問題會在我的視圖中的 已解決的 出現(xiàn) 對于解決的方式進行說明 16 流程示例的總結 從問題歷史我們可以看到整個流程的各個步驟 哪些人做了哪些操作 Bug追蹤管理綜述Bug追蹤管理的流程Mantis操作簡述 主要內容 18 我的視圖頁面 在這個頁面上可以看到項目的bug追蹤情況看到自己負責的問題的狀態(tài) 在本頁面的最底端用顏色標示了問題的狀態(tài) 點擊視圖的標題可以進入該視圖的所有問題的列表頁面 點擊我的視圖可以顯示所有的問題視圖 19 我的視圖頁面 開發(fā)人員應重點關注的視圖測試人員應重點關注的視圖 點擊視圖的標題可以進入該視圖的所有問題的列表頁面 20 查看問題的頁面 搜索的過濾條件 問題列表 21 報告問題 22 報告問題的注意事項 對于分類 出現(xiàn)頻率 嚴重性這三個選項認真選擇 摘要 力求簡明扼要 一針見血說明 報告問題時必須清楚 翔實 確保程序員不要花太多時間重現(xiàn)問題 要做到完整報告如下幾點 1 發(fā)生問題時的登錄用戶 頁面URL 及瀏覽器地址欄中的地址 2 輸入是什么 說明操作步驟 3 在什么操作下發(fā)生了問題 該操作能否重現(xiàn) 說明清楚問題的具體表現(xiàn) 錯誤的提示信息 4 為清楚說明問題 必要的時候應該截圖 作為問題的附件5 不光是問題 如果是一些合理化建議和觀點 也可以作為問題報告 可以在 嚴重性 那里作為 新特性 來提交 23 修改個人信息 登錄之后 請盡快修改默認的密碼和常用email 24 其他注意事項 誤區(qū)開發(fā)人員把問題置為 已解決 就是把事情做完了 只有測試人員確認并關閉了才算是真正解決了問題測試是測試人員的事情 開發(fā)人員同樣應該主動發(fā)現(xiàn)和報告問題 而且有些測試只有開發(fā)人員才能做好測試人員把問題報告了 就是測試工作完成了 在程序員解決問題之后 還要確認問題是否解決了并最終關閉問題 解決問題是程序員的事情 測試人員同樣應該了解問題的本質 問題的解決方法 并積極提供解決建議問題關閉之后 就肯定沒問題了 定期要進行回歸測試 即把已經測試關閉之后的問題重新進行測試 因為后面的問題的修改可能會影響到前面的問題 原來正確的地方反而出錯了 25 其他注意事項 測試的基本原則是換位思考 如果我是程序員 別人這么報告問題 我能否很快知道問題是什么 優(yōu)先級項目經理PM在分派任務的時候應該標注問題的優(yōu)先級 或在問題注釋中說明問題解決的進度開發(fā)人員應該根據(jù)優(yōu)先級和問題注釋選擇解決問題的先后次序盡量減少使用 申請協(xié)調 對于問題需要協(xié)作完成的情況 如果能簡單溝通協(xié)調解決 就不需要提出 申請協(xié)調 雙方自行解決 否則增加問題的解決的周期 防止無休止循環(huán) 對于確實需要分階段