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

转载于:https://www.cnblogs.com/SoftwareTestingHust-1706-03/p/7885462.html