Bug追踪管理系统Mantis的培训.ppt

上传人:b****1 文档编号:1385337 上传时间:2022-10-21 格式:PPT 页数:26 大小:884KB
下载 相关 举报
Bug追踪管理系统Mantis的培训.ppt_第1页
第1页 / 共26页
Bug追踪管理系统Mantis的培训.ppt_第2页
第2页 / 共26页
Bug追踪管理系统Mantis的培训.ppt_第3页
第3页 / 共26页
Bug追踪管理系统Mantis的培训.ppt_第4页
第4页 / 共26页
Bug追踪管理系统Mantis的培训.ppt_第5页
第5页 / 共26页
点击查看更多>>
下载资源
资源描述

Bug追踪管理系统Mantis的培训.ppt

《Bug追踪管理系统Mantis的培训.ppt》由会员分享,可在线阅读,更多相关《Bug追踪管理系统Mantis的培训.ppt(26页珍藏版)》请在冰豆网上搜索。

Bug追踪管理系统Mantis的培训.ppt

Bug追踪管理系统(Mantis)的培训,*,Bug追踪管理综述Bug追踪管理的流程Mantis操作简述,主要内容,Bug追踪管理概述,Bug追踪管理的重要性保证Bug能够得到及时的发现和解决解决bug的过程细节能够得到完整的记录和存档随时了解当前项目中的bug的处理状况和整体情况Bug追踪管理中的主要角色项目经理:

PM主要职责:

确认问题,分派任务,协调任务,重新打开问题开发人员:

DEV主要职责:

解决问题,申请协调测试人员(报告人员):

RP主要职责:

报告问题,测试并确认问题解决,Bug追踪管理综述Bug追踪管理的流程Mantis操作简述,主要内容,Bug追踪管理的状态,已关闭,已解决,已分派,提请协调,新建,已确认,打回,Bug追踪管理的流程,已关闭,已解决,已分派,提请协调,新建,已确认,打回,报告问题,分派任务,认为问题描述不合格,重新说明问题,认为分派有误或者需要帮助,重新分派,接受任务开始工作,已解决完毕,已完成自己的部分需要其他人再处理,确认问题解决,重新打开该问题,认为问题没有解决,需要协调,重新解决问题,重新分派,Bug追踪管理的状态转移矩阵,新建,该矩阵表示从当前状态可以到达哪些下一状态,流程示例,角色定义PM:

great(mantis帐号)RP:

chijxDEV:

zhangb,liangyb问题背景:

妈妈爱问部分内容块的ie和firefox下有兼容性的显示问题需要美工zhangb和程序员liangyb共同配合完成,但首先是美工的工作,流程示例-续1,1Chijx提交bug,问题进入“新建状态”2great认为描述不当,出现频率和问题说明不清楚,因此打回,问题进入“打回状态”(此时不应对问题进行分派,否则流程会有问题)3.1chijx在“我的视图”中发现自己报告的问题被打回,于是进行修改,重新提交3.2chijx将问题状态改为“新建”,流程示例-续2,4great发现重新修改的问题之后,如果认为描述得当,则将问题分派给开发人员,问题进入“已分派”状态,由于问题牵涉到界面显示,所以分派给美工zhangb。

5zhangb在“我的视图”中看到,查看问题,并且任务分配没有异议(否则可以申请协调),则将问题的状态改为“已确认”,表示接受任务,开始工作。

流程示例-续3,确认问题的时候,需要填入对于问题的注释,如对于问题的大致分析,解决方案等等。

流程示例-续4,6如zhangb完成修改,认为解决问题可以将状态改为“已解决”,如果觉得这个问题自己已经做好能做的部分,需要其他人再继续修改,则,并且填写申请协调的理由,问题进入“申请协调状态”。

7Great发现了需要协调的问题,经过讨论之后,将问题重新分派给liangyb,即由程序员做必要的调整。

8Liangyb确认工作,问题进入“已确认”状态。

流程示例-续5,9liangyb解决了问题,将问题的状态置为“已解决”,并添加解决问题的说明,如解决的方法,是否还有注意事项,或者这是重复问题,或者不是问题,而是设计的考虑。

10.1chijx在我的视图发现该问题已解决,需要对此进行确认是否真正解决。

流程示例-续6,10.2Chijx认为该问题没有解决,因此打回11liangyb发现被打回的问题,如重新解决问题之后,再次提交解决。

如认为该问题无法解决则申请协调。

流程示例-续7,12chijx最终确认问题的解决,这样一个典型的bug解决的周期才算是正式结束了。

该问题会在我的视图中的“已解决的”出现,对于解决的方式进行说明,流程示例的总结,从问题历史我们可以看到整个流程的各个步骤,哪些人做了哪些操作。

Bug追踪管理综述Bug追踪管理的流程Mantis操作简述,主要内容,我的视图页面,在这个页面上可以看到项目的bug追踪情况看到自己负责的问题的状态,在本页面的最底端用颜色标示了问题的状态,点击视图的标题可以进入该视图的所有问题的列表页面,点击我的视图可以显示所有的问题视图,我的视图页面,开发人员应重点关注的视图测试人员应重点关注的视图,点击视图的标题可以进入该视图的所有问题的列表页面,查看问题的页面,搜索的过滤条件,问题列表,报告问题,报告问题的注意事项,对于分类,出现频率,严重性这三个选项认真选择。

摘要:

力求简明扼要,一针见血说明:

报告问题时必须清楚,翔实,确保程序员不要花太多时间重现问题,要做到完整报告如下几点:

1)发生问题时的登录用户,页面URL(及浏览器地址栏中的地址)2)输入是什么,说明操作步骤;3)在什么操作下发生了问题;该操作能否重现,说明清楚问题的具体表现,错误的提示信息。

4)为清楚说明问题,必要的时候应该截图,作为问题的附件5)不光是问题,如果是一些合理化建议和观点,也可以作为问题报告,可以在“严重性”那里作为“新特性”来提交。

修改个人信息,登录之后,请尽快修改默认的密码和常用email,其他注意事项,误区开发人员把问题置为“已解决”就是把事情做完了只有测试人员确认并关闭了才算是真正解决了问题测试是测试人员的事情开发人员同样应该主动发现和报告问题,而且有些测试只有开发人员才能做好测试人员把问题报告了,就是测试工作完成了在程序员解决问题之后,还要确认问题是否解决了并最终关闭问题。

解决问题是程序员的事情测试人员同样应该了解问题的本质,问题的解决方法,并积极提供解决建议问题关闭之后,就肯定没问题了定期要进行回归测试,即把已经测试关闭之后的问题重新进行测试,因为后面的问题的修改可能会影响到前面的问题,原来正确的地方反而出错了。

其他注意事项,测试的基本原则是换位思考:

如果我是程序员,别人这么报告问题,我能否很快知道问题是什么?

优先级项目经理PM在分派任务的时候应该标注问题的优先级,或在问题注释中说明问题解决的进度开发人员应该根据优先级和问题注释选择解决问题的先后次序尽量减少使用“申请协调”,对于问题需要协作完成的情况,如果能简单沟通协调解决,就不需要提出“申请协调”,双方自行解决,否则增加问题的解决的周期,防止无休止循环。

对于确实需要分阶段分人员做的情况,则一定要提出协调。

要求尽量放置真实的内容,例如博客、视频等;这一方面是为内容作准备,一方面是有些问题必须在真实的情况下才能体现要开展页面的可用性,用户体验方面的测试与分析,谢谢大家!

希望大家对于使用过程中出现的问题踊跃提出,对于工作流程提出建议!

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 考试认证 > IT认证

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1