Mantis使用及提單細則

1、邵勇新Mantis功能使用Bug跟蹤流程提單規(guī)范細則注冊注冊1.賬號請輸入姓名的拼音.2.輸入正確的Email.3.通過Email郵件激活Mantis賬號.4.設(shè)置登錄密碼.5.檢查賬號密碼是否可以正常登錄.搜索過濾功能搜索過濾功能1.可以通過條件進行搜索.2.將條件都關(guān)閉，可以通過問題 單號進行單條問題搜索.提單前提單前1.當右上角選擇為“所有項目”.2.點擊提交問題，出現(xiàn)左邊項目 選擇畫面.3.選擇正確的項目進行提單.添加分類添加分類1.選擇管理項目管理出現(xiàn)左圖.2.將應用按照功能模塊劃分.3.將每個模塊作為一個分類進行添加.添加版本添加版本1.選擇管理項目管理 出現(xiàn)左圖.2.與項目經(jīng)理討

2、論版本劃分方案.3.根據(jù)項目迭代特點制定版本劃分方案.添加項目成員添加項目成員1.選擇管理項目管理出現(xiàn)上圖.2.確定項目組成員.3.將項目組成員加入到項目中.4.設(shè)置成員操作權(quán)限.設(shè)置標簽設(shè)置標簽1.選擇管理標簽管理出現(xiàn)上圖.2.確認需要添加的標簽.3.測試Leader找PPQA幫忙添加.個人設(shè)置個人設(shè)置1.選擇個人資料更改個人設(shè)置出現(xiàn)上圖.2.主要用于設(shè)置郵件通知.設(shè)置問題單列表項設(shè)置問題單列表項1.選擇個人資料管理列出 現(xiàn)上圖.2.可以設(shè)置查看問題單列表項.3.可以設(shè)置打印問題單列表項.4.可以設(shè)置導出表CSV/Excel 問題單列表項.分類:由隸屬于哪個分類測試組長在項目前期整理添加，如

3、在項目過程中發(fā)生變化，由測試更新. 測試人員在提交Bug時，請正確選擇問題.如果涉及到好幾個模塊的Bug, 測試可以確定分類的，那就選擇確定的分類，如果不能確認屬于哪個分類，那就選擇第 一個涉及的模塊.屬性分類：功能界面性能網(wǎng)絡異常壓力交互兼容內(nèi)存出現(xiàn)頻率:如果問題小于100%大于50%出現(xiàn)，選擇（總是）；如果問題小于50%大于10%出現(xiàn),選 擇（有時）；如果問題小于10%出現(xiàn)，選擇（無法復現(xiàn)）.嚴重性:小錯誤-界面文字圖片顯示或提示性不準確的問題，以及不合理性問題.很嚴重-功能不可用或嚴重背離需求的問題.崩潰-應用崩潰或僵死等嚴重問題.優(yōu)先級 :高-很嚴重或崩潰的問題，或影響迭代版本發(fā)布的問

4、題.中-功能性問題.低-小細節(jié)的顯示問題.產(chǎn)品版本 :問題單產(chǎn)生時的軟件版本號.分派給 :下個環(huán)節(jié)問題單跟蹤處理者(對應的開發(fā),測試,主審人).摘要 :崩潰修改引入版本號模塊名稱:崩潰修改引入1.2.2.1注冊：使用一個已經(jīng)注冊過的賬號注冊發(fā)生崩潰.描述:【前提條件】： 機型:XXXX 系統(tǒng):XXXX 其他:XXXX【步驟以及現(xiàn)象】:XXXXXXXXXXX【預期結(jié)果】:XXXXXXXXXX 提交者:姓名+聯(lián)系方式【前提條件】 機型：iphone 4gs 系統(tǒng)：4.1 其他系統(tǒng)也有此現(xiàn)象【步驟和現(xiàn)象】 首頁面點擊新建，新建普通記事，點擊語音輸入，點擊取消后立即點擊返回 客戶端崩潰【預期結(jié)果】 客

5、戶端不會崩潰【前提條件】 機型：iphone 4gs 系統(tǒng)：4.1 其他系統(tǒng)也有此現(xiàn)象【步驟和現(xiàn)象】1.進入天天應用首頁. 2.點擊“新建”選項，選擇普通記事.3.從工具欄選擇“語音輸入”圖標.4.在語音輸入框上點擊“取消”按鈕，立即點擊“返回”按鈕，應用崩潰-KO.【預期結(jié)果】4.應用可以正常返回，不出現(xiàn)崩潰.回歸測試提單 :如果不是修改引入的選擇No,如果是修改引入的選擇Yes.問題單狀態(tài) :請參見問題單狀態(tài)詳細說明.上傳文件:.如果涉及到界面/提示等問題,請將問題圖片附上(圖片不用打包).如有正確的高 保真,請把高保真也附上.如是崩潰問題,請將Log附上.目標版本:首先需要修改的版本.在

6、提交Bug時由測試選擇.是否已經(jīng)合入主線:記錄是否將修改的代碼合入了主線版本.這個由開發(fā)在將修改代碼合入了主線版本后選擇的,初始狀態(tài)是(未合入),如果Bug已經(jīng)修改,代碼且已經(jīng)合入了主線,則選擇(已合入).(在此解釋演示版本、上線版本、主線版本)測試人員提交缺陷單（PR）,狀態(tài):分派給,處理狀態(tài):未處理.以后這兩個選項就保持這個狀態(tài), 不做任何處理和關(guān)注. 當測試提交了PR以后,大家只要關(guān)注PR分配在誰名下,以及”問題單狀態(tài)”.測試經(jīng)理審核:測試組員提交PR,將分派給選擇測試負責人,問題單狀態(tài)選擇”測試經(jīng)理審核”.項目經(jīng)理審核:當測試經(jīng)理看到自己名下有狀態(tài)為”測試經(jīng)理審核”的PR時,測試經(jīng)理進

7、行審核,判定此PR是一個Bug且和以前提交的PR不重復,那測試經(jīng)理再將此PR分派給項目經(jīng)理,問題單狀態(tài)改為”項目經(jīng)理審核”.(有時項目經(jīng)理無時間顧及PR,那就由測試經(jīng)理直接將PR分派給對應的開發(fā)).開發(fā)定位,修改:當項目經(jīng)理看到自己名下有問題單狀態(tài)為”項目經(jīng)理審核”的PR時,項目經(jīng)理進行審核,判定此PR是一個Bug且和以前提交的PR不重復,那項目經(jīng)理再將此PR分派給對應的開發(fā),問題單狀態(tài)改為”開發(fā)定位,修改”.不是問題,駁回:.當項目經(jīng)理在審核PR的時候,發(fā)現(xiàn)此PR不是Bug,可以寫清楚注釋,然后將PR分派給測試經(jīng)理,將問題單狀態(tài)改為”不是問題,駁回”.當開發(fā)定位在自己名下PR時,發(fā)現(xiàn)此PR不

8、是Bug,可以寫清楚注釋,然后將PR分派給測試經(jīng)理,將問題單狀態(tài)改為”不是問題,駁回”.測試經(jīng)理組織測試:當開發(fā)將自己名下PR修改以后,且提交了修改代碼,將PR分派給測試經(jīng)理,且問題單狀態(tài)改為”測試經(jīng)理組織測試”.測試人員回歸測試:當測試經(jīng)理發(fā)現(xiàn)自己名下有”測試經(jīng)理組織測試”的PR單時,積累一定數(shù)量后,讓開發(fā)打個測試版本,然后將這些PR分派給對應的Bug提交者,讓他們進行回歸測試.三版驗證：當測試發(fā)現(xiàn)“測試人員回歸測試”狀態(tài)的偶現(xiàn)問題單時，將狀態(tài)改為“三版驗證”，在以后的新版本都需要搜出這些Bug驗證加備注，當連續(xù)三個版本都不復現(xiàn)，那么將單子關(guān)閉.回歸不通過，繼續(xù)修改：當PR提交者看到自己名下

9、有“測試人員回歸測試”的PR時，使用最新版本進行回歸測試，如果測試不通過，則將該PR分派給對應的開發(fā)，將問題單狀態(tài)改為“回歸不通過，繼續(xù)修改”.重復：當開發(fā)發(fā)現(xiàn)自己名下，問題單狀態(tài)為“開發(fā)定位，修改”的PR進行定位，如果發(fā)現(xiàn)已經(jīng)有和此PR相同的PR，則將我們內(nèi)部提交的PR分派給測試經(jīng)理，并將問題狀態(tài)改為“重復”.（在備注中一定要寫清楚相同PR的Bug ID）當項目經(jīng)理在審核PR的時候，發(fā)現(xiàn)有重復PR，可以將內(nèi)部的PR問題單狀態(tài)改為“重復”，分派給測試經(jīng)理.（在備注中一定要寫清楚相同PR的Bug ID ）關(guān)閉（重復關(guān)閉）：.當測試經(jīng)理在審核PR，發(fā)現(xiàn)重復PR時，將內(nèi)部的PR問題單狀態(tài)改為“關(guān)閉（

10、重復關(guān)閉）”（在備注中一定要寫清楚相同PR的Bug ID ）.當測試經(jīng)理看到自己名下有“重復”狀態(tài)的問題單，進行確認，如果確實重復，將此PR問題狀態(tài)改為“關(guān)閉（重復關(guān)閉）”.關(guān)閉（非問題關(guān)閉):測試經(jīng)理在審核PR時，確認不是問題的，或看到自己名下“不是問題，駁回”狀態(tài)的PR，確認不是PR的，將狀態(tài)改為“關(guān)閉（非問題關(guān)閉）”.關(guān)閉(內(nèi)部關(guān)閉)：當測試在回歸來自客戶提交的PR時，如果回歸通過，那么暫時將PR問題單狀態(tài)改為“關(guān)閉（內(nèi)部關(guān)閉）”.關(guān)閉(修改關(guān)閉)：.當測試在回歸內(nèi)部的“測試人員回歸測試”狀態(tài)的PR時，如果回歸通過，則將此PR狀態(tài)改為“關(guān)閉（修改關(guān)閉）”.Mantis上的某Bug為“關(guān)閉

11、（內(nèi)部關(guān)閉）”狀態(tài)，且當華為Bug庫的此Bug改為“關(guān)閉 （修改關(guān)閉）”時，測試將Manis中此問題單狀態(tài)改為“關(guān)閉（修改關(guān)閉）”.主審人裁決：當測試經(jīng)理看到自己名下有問題單狀態(tài)為“掛起”的，那么測試經(jīng)理需要審核，如果堅持是一個PR,那么可以將PR分派給主審人，問題單狀態(tài)改為“主審人裁決”.掛起：當主審人看到自己名下有“主審人裁決”的PR時，需要組織測試經(jīng)理和項目經(jīng)理一起討論，如果確認問題改起來存在很大的風險或存在技術(shù)瓶頸，那么可以將問題狀態(tài)改“掛起”，寫清楚掛起的原因.轉(zhuǎn)需求：當主審人看到自己名下有“主審人裁決”的PR時，需要組織測試經(jīng)理和項目經(jīng)理一起討論，如果此問題以前無對應需求，且修改需要較多時間的，那么可以將問題狀態(tài)改“轉(zhuǎn)需求”。寫清楚轉(zhuǎn)需求的原因.測試員(測試經(jīng)理審核/回歸不通過，繼續(xù)修改/關(guān)閉（內(nèi)部關(guān)閉）/關(guān)閉(修改關(guān)閉)/三版驗證）測試經(jīng)理(項目經(jīng)理審核/測試人員回歸測試/關(guān)閉（重復關(guān)閉）/關(guān)閉（非問題關(guān)閉）/主審人裁決）開發(fā)(重復/不是問題，駁回/掛起/測試經(jīng)理組織測試）項目經(jīng)理(開發(fā)定位，修改/重復/不是問題，駁回/掛起)主審人(關(guān)閉（重復）/關(guān)閉（非問題關(guān)閉）/轉(zhuǎn)需求/掛起）每個迭代