Bug追踪管理系统(Mantis)的培训
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
时间重现问题，要做到完整报告 如下几点：
1）发生问题时的登录用户，页面URL（及浏览器 地址栏中的 地址） 2）输入是什么，说明操作步骤； 3）在什么操作下 发生了问题；该操作能否 重现，说明清楚 问题的 具体表现，错误的提示信息。 4）为清楚说明问题，必要的时候应该截图，作为问题的附件 5）不光是问题，如果是一些合理化建议和观点，也可以作为 问题报告, 可以在“严重性”那里作为“新特性”来提交。
流程示例-续1
1 Chijx提交bug，问题进入“新建状态” 2 great认为描述不当，出现频率和问题说明不
清楚，因此打回，问题进入“打回状态”（此时不 应对问题进行分派，否则流程会有问题） 3.1 chijx在“我的视图”中发现自己报告的问 题被打回，
于是进行修改
，重新提交
3.2 chijx将问题状态改为“新建”
Bug追踪管理系统(Mantis)的培训
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
Bug追踪管理概述
Bug追踪管理的重要性 保证Bug能够得到及时的发现和解决 解决bug的过程细节能够得到完整的记录和存档 随时了解当前项目中的bug的处理状况和整体情况 Bug追踪管理中的主要角色 项目经理：PM 主要职责：确认问题，分派任务，协调任务，重新
该矩阵表示从当前状态可以到达哪些下一状态
流程示例
角色定义 PM：great（mantis帐号） RP：chijx DEV：zhangb，liangyb 问题背景： 妈妈爱问部分内容块的ie和firefox下有兼容性
的显示问题 需要美工zhangb和程序员liangyb共同配合完成
，但首先是美工的工作
7 Great发现了需要协调的问题，经过讨论之后 ，将问题重新分派给liangyb，即由程序员做必 要的调整。
8 Liangyb确认工作， ，问题进入“已确认”状态。
流程示例-续5
9 liangyb解决了问题，将问题的状态置为“已 解决”，并添加解决问题的说明，如解决的方法 ，是否还有注意事项，或者这是重复问题，或者 不是问题，而是设计的考虑。
打开问题 开发人员：DEV 主要职责：解决问题，申请协调 测试人员（报告人员）：RP
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
Bug追踪管理的状态
状态 新建
已分派 已确认 打回 已解决 提请协调
已关闭
说明
报告一个新问题
问题由管理员或者项目经理分派到人
问题分派到人之后，相关负责人确认这个问题，即接受这个问 题并开始处理
问题描述或者问题解决被打回，即问题需要重新说明，或者测 试人员认为问题并没有真正得到解决
问题负责人认为解决了问题
问题的相关负责人或者报告人，认为1）问题难以解决，需要 帮助；2）分派有误；3）负责人已完成他的工作，但问题解决 需要其他人的配合；或者其他问题，需要提请协调解决。 问题解决并被测试人员确认，从而关闭，完成一个bug的处理 周期
务，开始工作。
流程示例-续3
确认问题的时候，需要填入对于问题的注释，如 对于问题的大致分析，解决方案等等。
流程示例-续4
6 如zhangb完成修改，认为解决问题可以将状态 改为“已解决” ，如果觉得这个问题自己已经做好能做的部分， 需要其他人再继续修改，则 ，并且填写申请协调的理由，问题进入“申请协 调状态”。
Bug追踪管理的流程
报告问题
新建
分派任务
已分派
认为问题 描述不合格
重新说明问题
认为分派有误 或者需要帮助
重新分派
打回
提请协调
需要协调
接受任务开始工作
已确认
已完成自己的部分 需要其他人再处理
已解决完毕
重新解决问题
认为问题没有解决
已解决
重新分派
已关闭
确认问题解决
重新打开该问题
Bug追踪管理的状态转移矩阵
修改个人信息
登录之后，请尽快修改默认的密码和常用email
其他注意事项
误区
开发人员 把问题置为“已解决”就是把事情做完了——只
有测试人员确认 并关闭了才算是真正解决了问 题 测试是测试人员的事情——开发人员同样应该主 动发现和报告问题，而且有些测试只有开发人员 才能做好
测试人员 把问题报告了，就是测试工作完成了——在程序
点击视图的标题可 以进入该视图的所 有问题的列表页面
在本页面的最底 端用颜色标示了 问题的状态
我的视图页面
开发人员应重点关注的视图
点击视图的标题可 以进入该视图的所 有问题的列表页面
测试人员应重Байду номын сангаас关注的视图
查看问题的页面
搜索的过滤条件
问题列表
报告问题
报告问题的注意事项
对于分类，出现频率，严重性这三个选项认真选择。 摘要：力求简明扼要，一针见血 说明：报告问题时必须 清楚，翔实，确保程序员不要花太多
对于解决的方式进行说明
该问题会在我的视图中的“已解决的”出现
流程示例的总结
从问题历史我们可以看到整个流程的各个步骤， 哪些人做了哪些操作。
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
我的视图页面
在这个页面上可以看到项目的bug追踪情况 看到自己负责的问题的状态 点击我的视图可以显示所有的问题视图
流程示例-续2
4 great发现重新修改的问题之后，如果认为描 述得当，则将问题分派给开发人员，问题进入“ 已分派”状态，由于问题牵涉到界面显示，所以 分派给美工zhangb。
5 zhangb在“我的视图”中看到，查看问题，
并且任务分配没有异议（否则可以申请协调
），则将问题的状态改为“已确认”，表示接受任
员解决问题之后，还要确认问题是否解决了并最 终关闭问题。
其他注意事项
测试的基本原则是换位思考：如果我是程序员， 别人这么报告问题，我 能否很快知道问题 是什 么？
10.1 chijx在我的视图发现该问题已解决，需要 对此进行确认是否真正解决。
流程示例-续6
10.2 Chijx认为该问题没有解决，因此打回
11 liangyb发现被打回的问题，如重新解决问题 之后，再次提交解决。如认为该问题无法解
决则申请协调。
流程示例-续7
12 chijx最终确认问题的解决， 这样一个典型的bug解决的周期才算是正式结束了 。
1）发生问题时的登录用户，页面URL（及浏览器 地址栏中的 地址） 2）输入是什么，说明操作步骤； 3）在什么操作下 发生了问题；该操作能否 重现，说明清楚 问题的 具体表现，错误的提示信息。 4）为清楚说明问题，必要的时候应该截图，作为问题的附件 5）不光是问题，如果是一些合理化建议和观点，也可以作为 问题报告, 可以在“严重性”那里作为“新特性”来提交。
流程示例-续1
1 Chijx提交bug，问题进入“新建状态” 2 great认为描述不当，出现频率和问题说明不
清楚，因此打回，问题进入“打回状态”（此时不 应对问题进行分派，否则流程会有问题） 3.1 chijx在“我的视图”中发现自己报告的问 题被打回，
于是进行修改
，重新提交
3.2 chijx将问题状态改为“新建”
Bug追踪管理系统(Mantis)的培训
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
Bug追踪管理概述
Bug追踪管理的重要性 保证Bug能够得到及时的发现和解决 解决bug的过程细节能够得到完整的记录和存档 随时了解当前项目中的bug的处理状况和整体情况 Bug追踪管理中的主要角色 项目经理：PM 主要职责：确认问题，分派任务，协调任务，重新
该矩阵表示从当前状态可以到达哪些下一状态
流程示例
角色定义 PM：great（mantis帐号） RP：chijx DEV：zhangb，liangyb 问题背景： 妈妈爱问部分内容块的ie和firefox下有兼容性
的显示问题 需要美工zhangb和程序员liangyb共同配合完成
，但首先是美工的工作
7 Great发现了需要协调的问题，经过讨论之后 ，将问题重新分派给liangyb，即由程序员做必 要的调整。
8 Liangyb确认工作， ，问题进入“已确认”状态。
流程示例-续5
9 liangyb解决了问题，将问题的状态置为“已 解决”，并添加解决问题的说明，如解决的方法 ，是否还有注意事项，或者这是重复问题，或者 不是问题，而是设计的考虑。
打开问题 开发人员：DEV 主要职责：解决问题，申请协调 测试人员（报告人员）：RP
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
Bug追踪管理的状态
状态 新建
已分派 已确认 打回 已解决 提请协调
已关闭
说明
报告一个新问题
问题由管理员或者项目经理分派到人
问题分派到人之后，相关负责人确认这个问题，即接受这个问 题并开始处理
问题描述或者问题解决被打回，即问题需要重新说明，或者测 试人员认为问题并没有真正得到解决
问题负责人认为解决了问题
问题的相关负责人或者报告人，认为1）问题难以解决，需要 帮助；2）分派有误；3）负责人已完成他的工作，但问题解决 需要其他人的配合；或者其他问题，需要提请协调解决。 问题解决并被测试人员确认，从而关闭，完成一个bug的处理 周期
务，开始工作。
流程示例-续3
确认问题的时候，需要填入对于问题的注释，如 对于问题的大致分析，解决方案等等。
流程示例-续4
6 如zhangb完成修改，认为解决问题可以将状态 改为“已解决” ，如果觉得这个问题自己已经做好能做的部分， 需要其他人再继续修改，则 ，并且填写申请协调的理由，问题进入“申请协 调状态”。
Bug追踪管理的流程
报告问题
新建
分派任务
已分派
认为问题 描述不合格
重新说明问题
认为分派有误 或者需要帮助
重新分派
打回
提请协调
需要协调
接受任务开始工作
已确认
已完成自己的部分 需要其他人再处理
已解决完毕
重新解决问题
认为问题没有解决
已解决
重新分派
已关闭
确认问题解决
重新打开该问题
Bug追踪管理的状态转移矩阵
修改个人信息
登录之后，请尽快修改默认的密码和常用email
其他注意事项
误区
开发人员 把问题置为“已解决”就是把事情做完了——只
有测试人员确认 并关闭了才算是真正解决了问 题 测试是测试人员的事情——开发人员同样应该主 动发现和报告问题，而且有些测试只有开发人员 才能做好
测试人员 把问题报告了，就是测试工作完成了——在程序
点击视图的标题可 以进入该视图的所 有问题的列表页面
在本页面的最底 端用颜色标示了 问题的状态
我的视图页面
开发人员应重点关注的视图
点击视图的标题可 以进入该视图的所 有问题的列表页面
测试人员应重Байду номын сангаас关注的视图
查看问题的页面
搜索的过滤条件
问题列表
报告问题
报告问题的注意事项
对于分类，出现频率，严重性这三个选项认真选择。 摘要：力求简明扼要，一针见血 说明：报告问题时必须 清楚，翔实，确保程序员不要花太多
对于解决的方式进行说明
该问题会在我的视图中的“已解决的”出现
流程示例的总结
从问题历史我们可以看到整个流程的各个步骤， 哪些人做了哪些操作。
主要内容
Bug追踪管理综述 Bug追踪管理的流程 Mantis操作简述
我的视图页面
在这个页面上可以看到项目的bug追踪情况 看到自己负责的问题的状态 点击我的视图可以显示所有的问题视图
流程示例-续2
4 great发现重新修改的问题之后，如果认为描 述得当，则将问题分派给开发人员，问题进入“ 已分派”状态，由于问题牵涉到界面显示，所以 分派给美工zhangb。
5 zhangb在“我的视图”中看到，查看问题，
并且任务分配没有异议（否则可以申请协调
），则将问题的状态改为“已确认”，表示接受任
员解决问题之后，还要确认问题是否解决了并最 终关闭问题。
其他注意事项
测试的基本原则是换位思考：如果我是程序员， 别人这么报告问题，我 能否很快知道问题 是什 么？
10.1 chijx在我的视图发现该问题已解决，需要 对此进行确认是否真正解决。
流程示例-续6
10.2 Chijx认为该问题没有解决，因此打回
11 liangyb发现被打回的问题，如重新解决问题 之后，再次提交解决。如认为该问题无法解
决则申请协调。
流程示例-续7
12 chijx最终确认问题的解决， 这样一个典型的bug解决的周期才算是正式结束了 。