第1周小組博客做業——Mantis使用總結

1. 工具概述

Mantis是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操做的形式提供項目管理及缺陷跟蹤服務。在功能上、實用性上足以知足中小型項目的管理及跟蹤。更重要的是其開源，不須要負擔任何費用。具備多特性包括：易於安裝，易於操做，基於Web，支持任何可運行PHP的平臺。須要自行安裝MySQL、EasyPHP軟件及兼容性測試。

2. 對應的流程

2.1 角色介紹

1. 系統管理員：主要建立用戶，建立項目；維護其餘信息。
2. 經理：主要維護項目信息（如：維護測試模塊，維護項目組成員，測試版本，發佈公告；維護缺陷分類、實施版本）。研發部的項目經理、系統實施顧問、測試部的測試負責人、技服部項目經理有此權限；（各部門經理：不維護信息，監督特殊問題的處理、瀏覽統計報表數據等功能）
3. 報告人員：主要提交bug。測試工程師執行測試時，提交發現的bug；技術工程師提交客戶反饋的軟件缺陷。
4. 開發人員：主要修復bug。研發部各項目的bug修改人員有此權限。
5. 查看人員：主要瀏覽bug。
6. 修改人員：目前不用此角色。

Mantis中的經理角色擁有「報告人員」「開發人員」「查看人員」的操做權限。各操做權限限制在所分配的項目範圍內。

2.2 Bug的狀態含義

1. 新建：新提交的且還沒有指派給開發人員的bug。
2. 已分派：項目經理或系統實施顧問將bug指派給開發人員，開發人員還沒有接收確認的bug。
3. 公認：開發人員看到指派給本身修改的bug後，將bug狀態設置爲「公認」，以告知指派人本身收到了分配的bug。
4. 已解決：開發人員修復bug後，將bug狀態設置爲「已解決」；等待驗證測試的bug。
5. 打回：驗證測試未經過，須要開發人員從新修改的bug。
6. 已關閉：驗證測試經過，關閉的bug。
7. 已確認：即暫時不改的bug，（完成度）「暫停」的bug。

2.3 使用流程

Mantis使用流程圖以下所示：
)
詳細步驟：

2.3.1 管理員創建請測項目

1. 項目名稱爲：產品名稱；
2. 維護模塊信息（能夠不維護）；
3. 維護測試版本信息；
4. 維護項目組成員（部門經理也要加上）；

2.3.2 測試人員提交bug及跟蹤過程

1. 測試人員提交bug：選擇項目名稱（產品名稱）→模塊名稱→bug出現頻率、嚴重性、優先權→產品版本→bug標題/bug詳細說明→查看狀態設置爲「公共的」，提交。
2. 項目經理指派bug：點擊bug編號後進入的頁面，將bug指派給開發人員。(能夠設定某模塊的bug由固定的開發人員修改，實現自動指派。)
3. 開發人員接收bug：將指派給本身的bug狀態設置爲「公認」狀態。
4. 開發人員修改bug：修改完成，設置完成度，將bug狀態設置爲「已解決」狀態。
5. 測試人員驗證已解決的bug：驗證測試經過，需填寫「修正此問題的軟件版本」，將bug設置爲「已關閉」狀態。
6. 測試人員驗證已解決的bug：驗證測試未經過，將bug設置爲「打回」狀態，請開發人員從新修改。
7. 暫時不改的bug須要項目經理、測試負責人確認後，開發人員將bug設置爲「已確認」狀態。

2.3.3 項目測試階段的其餘相關活動

1. 項目經理、測試負責人可在測試以前將測試注意事項等發表公告，項目成員在「首頁」上瀏覽。見【編輯公告】功能。
2. 若測試人員提交bug時選錯了項目名，用「移動問題」功能，將bug移動至所屬項目bug單中；
3. 在上述步驟1.和2.進行的過程當中，項目經理、測試負責人可就Bug單上的特殊問題進行監視，在「個人視圖/我正在監視」列表中顯示全部監視的bug；
4. 針對同一因素形成的不一樣表現的多條bug，開發人員修改完一個bug,相關bug描述的現象已解決時，可就多個bug創建關聯，提醒測試人員集中驗證。測試人員也可用「建立子項問題」功能，提交同一因素形成的多個現象bug，供開發人員定位問題根源。

2.3.4 管理員創建實施項目

（有客戶反饋的產品缺陷維護此項目）

1. 項目名稱爲：醫院名稱/產品名稱；
2. 維護缺陷分類：Bug，新需求，工程問題，客戶建議（必須維護）；
3. 維護實施版本信息（必須維護：開發人員根據此版本號能找到對應的源碼作修改）；
4. 維護項目組成員（部門經理和系統實施顧問也要加上）；

2.3.5 技服人員提交bug及跟蹤過程

1. 技術工程師提交bug：選擇項目名稱（醫院名稱/產品名稱）→bug分類（必填項）→bug出現頻率、嚴重性、優先權→產品版本→bug標題/bug詳細說明→查看狀態設置爲「公共的」，提交。
2. 系統實施顧問指派bug：點擊bug編號後進入的頁面，將bug指派給開發人員。
3. 開發人員接收bug：將指派給本身的bug狀態設置爲「公認」狀態。
4. 開發人員修改bug：修改完成，設置完成度，將bug狀態設置爲「已解決」狀態。
5. 測試人員驗證已解決的bug：在註釋欄寫上「驗證結果」。
6. 技服人員爲客戶安裝新版本，客戶承認修改方案後，技服人員將對應的bug關閉。
7. 測試人員驗證已解決的bug：驗證測試未經過，將bug設置爲「打回」狀態，請開發人員從新修改。
8. 暫時不改的bug須要經技服部項目經理確認後，開發人員將bug設置爲「已確認」狀態。

2.3.6 項目測試階段的其餘相關活動

1. 若技服人員提交bug時選錯了項目名，用「移動問題」功能，將bug移動至所屬項目bug單中；
2. 在上述步驟4.和5.進行的過程當中，項目經理、技服人員可就Bug單上的特殊問題進行監視，在「個人視圖/我正在監視」列表中顯示全部監視的bug。

2.3.7 bug搜索

1. 按編號搜索：輸入bug編號，點擊【跳轉到該問題編號】；
2. 按標題中所含的文字搜索：輸入查詢文字（支持模糊查詢），點擊【篩選】；
3. 「查詢問題」頁面：設置查詢條件，點擊【篩選】；

2.3.8 修改我的登陸密碼

在「我的賬號」功能。

2.3.9 瀏覽統計報表

1. 部門經理查看全部項目的統計報表；
2. 項目經理查看單個項目的統計報表。見【統計報表】功能。

2.3.10 打印報告

可導出bug記錄至Excel，打印。

2.3.11 根據須要，可增長字段

見【自定義字段管理】

3. 工具的特色和侷限性

3.1 特色

做爲一款缺陷管理軟件，Mantis有如下特色:

1. 免費

   與BUGZILLA，JIRA等收費軟件相比，Mantis是徹底免費且開源的。它基於PHP技術開發，以Web操做的形式提供項目管理及缺陷跟蹤服務。

2. 兼容

   不管是C/S或B/S架構軟件，均可以用Mantis進行缺陷的管理，而沒必要另外再搭建新的環境。功能上/實用性上足以知足中小型項目的管理及跟蹤。

3. 界面

   Mantis的界面通俗易懂，各個管理模塊之間分工明確，不管測試人員經驗如何，都能一目瞭然的找到本身須要的內容。

4. 可用性

   對於小型軟件開發團隊，Mantis的標準配置已經可以很好的知足缺陷管理須要，對於大中型軟件開發團隊，在稍微修改代碼以豐富缺陷的狀態，控制人員的權限，定製缺陷處理流程，也可以知足須要。

3.2 侷限性

圖1：bug工做流流程圖設置圖

1. 在自動發送郵件通知時，若是操做人員是來自不一樣的郵箱服務器，可能出現發送郵件超時的狀況。部分人員必須登錄系統查看。

2. 管理上的侷限在於流程定製不太靈活。

圖2：流程圖在bug流轉過程當中操做方法圖

圖2中，右下角分派給處和將狀態修改成兩個多選框都是沒有限制的，咱們小組組員一致認爲該處應該有嚴格的限制，假設將bug當一個任務來看，這個任務有多步，那麼每一步之間的應該有明確的前後關係，這樣才能讓整改缺陷流起色制更加規範。

4. 工具的改進

4.1 針對侷限點1

能夠在缺陷跟蹤系統的環境上增長免費的郵件系統，由於使用的人數較少，因此負荷較低，可安裝在同一電腦上。

4.2 針對侷限點3

採用工做流的方式來控制bug在項目成員中流轉，而且可以以工做流流程圖的方式直觀顯示每一個bug流程進度，每一步都是由項目組中哪個小夥伴負責。
具體改進方法：

1. 在圖1處新建項目；
2. 在圖1處選擇項目組成員，分別命名爲ABCDEF
3. 在圖1處爲新項目添加項目獨有的流程圖（一樣可使用流程圖通用模板，不繪製個性化流程圖），該步驟可在圖1處完成，核心思想：每一個項目都有本身的工做流流程圖，這個流程圖對每一個bug都通用，且每一個項目只能有一個工做流；

圖3：項目bug處理工做流流程圖

1. 在圖1處爲項目成員指定工做流中節點任務，在分派任務時，先選下一步節點（只能選擇流程圖中下一步節點），再選對應節點的人，不是對應節點責任人強制不能選擇；
2. 在圖2處新建bug，而後按照工做流流程圖處理bug，詳見圖2。

5. 成員貢獻

每位同窗都嘗試安裝運行了Mantis並反饋了問題，並全體參與了對本篇博客文檔的整理，可是每人任務的側重點不一樣。
具體分配狀況爲：

• 羅平：負責Mantis的基本狀況整理。
• 董英豪：負責對下載安裝教程的整理。
• 張希：負責Mantis的功能及架構文檔整理，以及對文檔的彙總排版。
• 林燦林：負責對工做流程文檔的整理。
• 王際超：負責工具的安裝調試運行，配合林燦林整理工做流程文檔，錄製使用視頻。
• 包純：負責記錄每日的例會內容，整理博客文檔。