如何使用MANTIS系统进行Bug跟踪 金锐显：赵学良　08.9.10

培训内容 Bug管理的基本概念 Mantis的介绍及操作 实际操作演示Mantis系统的各项功能

第一部门：bug管理的基本概念 现状 为什么要使用工具来管理Bug 一般的bug处理流程

目前现状 研发人员对Bug工具不是很熟悉，对工具的使用需求也不是很高。 地域分散的开发团队，目前主要是通过email和文档交流，相关人员无法及时获得有关的变更信息。 　　目前我们的研发团队有些项目是上海、深圳两地开发，需求、设计、开发、测试和用户反馈来自不同地区，使用电子邮件和文档来跟踪缺陷时，信息共享和错误状态更新都费时费力，随着项目的扩展，文档工作量也越来越大。无法实现bug处理流程的自动化 不能很好的对Bug进行追踪、指定相关责任人 有时会存在一些重复性的工作和处理过的问题不能做一些定量的统计分析。

为什么要使用工具进行bug管理 备忘 　　备忘是一个Bug管理系统最基本的作用，什么时候测出了Bug、怎么测的、当时环境怎样，开发人员解决了没有、什么时候解决的、如何解决的，需要及时记录下来；问题一多，没有遗漏地记下所有问题点并确保适当地处理掉，是Bug管理的基本要求。 沟通 　　Bug的产生、变更需及时通知相关人员，他们也应能随时查询不同状况的Bug 数据，良好的沟通才能保证有效的协作。 　　同时也解决了因地域分散带来的信息共享问题，实现bug处理流程的自动化，最大限度减少重复工作。 监控 　　　作为项目管理者，您需要及时全面了解目前的项目状况，有多少bug, Bug的严重程度，是否需要立即做出处理、决策；有些Bug需要决定改还是不改，或是放入以后版本、分配给其他人等等。所以项目管理者应该能够监控Bug状况。

为什么要使用工具进行bug管理 定量分析 　　对Bug数据作定量的统计分析是更进一步的需求，如：bug数量、从测试者、责任人、缺陷级别、缺陷原因等不同角度统计缺陷数量等等。 环境集成 　　可以与其他的一些项目管理工具进行集成，比如使用版本管理工具svn/cvs.vss 等来对整个开发项目做些控制。

Bug处理流程

小结： 使用工具可以有效地控制软件研发流程以保证产品质量和进度。 　　　使用工具可以有效地控制软件研发流程以保证产品质量和进度。 　　　上Bug不仅仅是测试人员的事情，而是整个开发团队中的每个人发现问题时都上个Bug来跟踪；

第二部门：Mantis使用指南 什么是Mantis? Mantis基本特征 怎么使用Mantis系统

什么是Mantis? Mantis是一个Bug管理系统；基于B/S 结构，可以配置到Internet 上，实现异地进行Bug管理，支持多个项目，同时可以通过Email报告跟踪缺陷，用户可以监视特殊的Bug，管理者可以方便的对bug数据进行定量的分析。

使用之前，先了解一下Mantis基本特性： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； Mantis是基于角色和项目模块为划分的BUG跟踪系统。权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式，支持可定制的报表输出； 有各种bug统计功能，为项目状态分析提供依据，也可以把数据输出到Excel中进一步分析； 可以对流程定制方便且符合标准，满足一般的缺陷跟踪。

系统中人员的分配 Mantis中默认人员可以分为以下几种： 　　查看人员 < 报告人员 < 修改人员 < 开发人员 < 经理 < 管理员　(权限依次递增) 我们公司的人员设置 　　分为三类人员： 报告人员（测试组、研发人员）报告和修改问题等 项目组长　（分派、处理问题） 经理　统筹安排

报告人员权限 对象：测试组、所有开发人员 能够及时报告问题，描述问题出错信息；提交bug到系统中的人员 1. 查看/报告问题和添加子项问题和建立依赖关系和打印 2. 问题提醒、修改问题状态 3.　　移动/删除/复制 问题　　 4. 添加/删除/修改 问题注释 5. 上传/删除 BUG附件 6. 启动/取消 监视问题 7. 搜索问题及过滤问题

项目组长／经理 经理除了拥有和开发人员基本的权限之外，还具有以下权限： 可以浏览更多的问题信息，包括 分派问题到指定责任人 还未指定人员的问题 已解决的问题 最近做过修改的问题 项目文档管理 编辑/删除/添加 新的项目文档

主界面栏目 未指定的：是指问题已经报告，但还没有指定由那个项目组成员进行跟进的问题列表。 已解决的：指问题已经得到解决，问题的状态为[已经解决]。 我正在监视的：指你正在监视那些问题，在问题报告中，你被选为监视人。 由我报告的：在这里将会显示由你报告的问题列表。 最近修改：这一栏显示那些问题报告最近被项目组成员修改了。 　　在各状态表格下，有bug的编号，这个编号是对应其详细信息的超链接，可以根据工作要求直接点击进入进行相应操作。此外在页面下部出现一个标识bug 流程状态的颜色条，这样在实际操作中对于不同流程状态的bug就能很好的区分开。

操作指南－－登录 网页浏览器地址栏里输入http://cultraview.vicp.net:83/mantis 进入Mantis的登录界面 系统管理员已经为每一个用户设置好个人登录帐号，用户名即为你的个人姓名如张三为zhang_s，密码为123456。请在登录后务必修改你的初始密码。

修改密码 为了你的帐号安全，务必修改个人帐号密码。 点击菜单栏的个人帐号超级链接进入Mantis密码修改页面

报告问题 填好问题报告后，点击[提交报告]，就会将此问题提交到系统，系统将会通过E-MAIL通知项目组的相关人员。至此，一个bug已经报告到系统里面了。等待项目组其他相关权限人员对此问题的跟踪。

问题查询 在工具栏的下方，有一个蓝灰相隔的表格，这些表格的内容正是查找的条件选项，点击其中一选项，就会出现一个下拉框代替任意两个字，让你输入你查找的内容。输入完成后，点击筛选按钮就会结果返回到下方的表格，即是

修改问题 修改问题：进入问题明细页面进行修改。 分派给：是指将这个问题分派给那个人员处理，一般只能选择开发员权限的人员。 将状态改为：更改问题的状态，将需要输入更改状态的理由。 监视问题：点击后，所有和这个问题相关的改动都会通过E-MAIL发到监视用户的邮箱。 创建子项问题：建立一个问题的子项，而这个子项报告的问题是依懒于这个问题而存在的。 移动问题：将这个问题转移到其它项目中。

Bug管理流程 测试人员或者开发人员 提交新的Bug入库。 项目组长、经理分配给相应的开发人员 测试人员查询bug状态,验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。 开发人员查询状态为Open和Reopen的Bug，不是Bug，则置状态为Not Bug，是Bug则解决并置状态为Fixed（或Resolved），不能解决的Bug，要留下文字说明及设置Bug状态。 对于不能解决和延期解决的Bug，最后由经理或者共同商议来决定问题的状态。

角色 处理问题 问题完成度 问题状态 报告人员   提交BUG 未处理 新建 项目组长/经理 分派给开发人员 已分派 开发人员 对分派的问题 1 修改问题 已修正 已解决 2 对问题情况不明确 可选择相应问题完成度 打回 对已解决的问题 复查后BUG已修改 关闭 复查后BUG仍存在 重新打开 对打回的问题 添加BUG描述 存在争议 公认 3 存在争议，但讨论后解决 不是问题 经理 对存在争议的问题提出修改意见，决定是否关闭

第三部分：实际演示

事例 通过一个bug处理实例来演示 人员 测试工程师 研发工程师 项目组长 经理

总结： mantis 仅仅是个工具而已，重要的是掌握其中蕴含的软件研发的流程思想，才能用好这个工具。如果你以前没有用过 Bug管理系统，那么一开始的时候也许你会觉得这个工具是在浪费时间，因为一个测试人员需要费神把发现 Bug的详细步骤记录下来，有时还要贴一张示意图，这一切都不如当面说或者直接邮件来得直接。 但是使用一段时间，你会发现mantis很有用，它忠实的记录着每个问题的处理过程，不断提醒你存在的问题，永远不会丢失和忘记。随着研发的规模越来越大，mantis的作用就会越大。

谢谢大家！