第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的功能及架构文档整理，以及对文档的汇总排版。
• 林灿林：负责对工做流程文档的整理。
• 王际超：负责工具的安装调试运行，配合林灿林整理工做流程文档，录制使用视频。
• 包纯：负责记录每日的例会内容，整理博客文档。