mantis中的bug状态流程

合集下载

向MANTIS提交Bug的基本流程

向MANTIS提交Bug的基本流程

向MANTIS提交Bug的基本流程1.在测试过程中发现了一个与预期效果不一样的地方时候,首先要确定此问题能否重现,重现的方法是什么,借此断定此问题是否为一个bug。

2.在发现一个bug的时候,我们首先需要做的就是登陆MANTIS系统然后到“查看问题”界面去查看管理系统中已有的bug,看看这个bug是不是duplicate,或者是不是之前已经closed掉的bug;duplicate就不要再次提交了,如果是之前已经closed的bug,就需要将bug的状态设置为reopened。

3 . 如果确定bug是第一次发现且查询后没有发现之前已经closed过的类似缺陷。

首先要选择页面的右上角选择项目,将下来菜单中的项目选定为“日常发现BUG”,如图:图7项目选定3.然后去进入问题提交页面,用来提交发现的问题。

●首先要选择的是问题的分类。

分类的选项可以从下拉列表的数据字典中选择出来。

图8 bug分类选择●接下来是出现频率。

点击后根据实际情况从下来列表中选出对应的描述选项,一般选择“总是”即可。

图9 bug出现频率选择●严重性的选择取决于发现的bug对系统功能的影响。

一般选择均为“小错误”图10 bug的严重性● Bug优先级是与bug的严重性先对应的。

如果是严重性为“崩溃”和“宕机”,一般优先级就必须为高或者以上。

如果只是一般的小错误,优先级可以为中或者低。

图11 bug的优先级选择●接下来需要填写的就是bug提交报告中比较重要的内容了,如图:图12 bug详细情况描述●“分配给”一栏一般是需要填写的是bug指定给谁去处理。

这个可以小组商量后填写。

摘要一般要用一句话简单描述一下bug的现象;而描述则需要详细的去填写bug的重现步骤和现象,并且有固定的格式。

如下:步骤:1、2、3、……实际结果:描述实际结果是什么样的期望结果:描述期望结果是什么样的步骤要尽量详细的描述要提交的bug重现的步骤;实际结果详细描写按以上步骤出现的bug现象;儿期望结果就是系统功能所需要的结果。

mantis缺陷管理系统使用说明

mantis缺陷管理系统使用说明

mantis缺陷管理系统使用说明关键信息项:1、系统登录方式2、缺陷创建流程3、缺陷状态及流转规则4、缺陷分配与处理责任人5、缺陷跟踪与监控机制6、缺陷报告生成与导出7、系统权限设置与管理11 系统登录方式111 用户需要通过指定的网址访问 mantis 缺陷管理系统。

112 输入预先分配的用户名和密码进行登录。

113 首次登录后,建议及时修改密码以保障账户安全。

12 缺陷创建流程121 进入系统后,点击“创建缺陷”按钮。

122 准确填写缺陷的标题,清晰概括缺陷的主要问题。

123 详细描述缺陷的表现,包括操作步骤、出现的错误提示等信息。

124 选择缺陷所属的项目、模块和版本。

125 设定缺陷的优先级,如高、中、低。

126 如有必要,上传相关的截图或文件作为辅助说明。

13 缺陷状态及流转规则131 缺陷状态包括新建、已分配、已解决、已关闭等。

132 新建的缺陷将由项目经理或指定人员进行分配。

133 被分配的开发人员接收并处理缺陷后,将状态更改为已解决。

134 测试人员对已解决的缺陷进行验证,若通过则关闭缺陷,否则重新打开并分配给相关人员。

14 缺陷分配与处理责任人141 项目经理根据团队成员的职责和技能,合理分配缺陷。

142 处理责任人应及时接收并处理分配给自己的缺陷。

143 若责任人无法处理,应及时反馈并重新分配。

15 缺陷跟踪与监控机制151 系统提供缺陷的跟踪功能,可查看缺陷的处理进度和历史记录。

152 定期对未解决的缺陷进行监控和提醒,确保及时处理。

153 对于重要或紧急的缺陷,设置特殊的提醒方式。

16 缺陷报告生成与导出161 可以根据需要生成缺陷报告,包括按项目、模块、时间段等条件筛选。

162 支持将报告导出为常见的格式,如 Excel、PDF 等,方便分享和存档。

17 系统权限设置与管理171 管理员拥有系统的最高权限,可进行用户管理、权限分配等操作。

172 普通用户的权限根据其角色和职责进行设定,确保信息安全和操作规范。

mantis使用文档

mantis使用文档

MANTIS使用文档(Bug管理系统使用文档)一、Bug相关背景知识图1 bug生命周期转换图上图展示的是一个bug的生命周期。

Bug的生命周期可以简单的理解为bug的状态在什么时候转换,以及基于什么原因触发bug的状态发生变化。

1.新建(NEW):当一个bug被第一次提交的时候,它的状态就是新建。

这就是说bug 并未被确认提交的是不是是不是一个真正的bug。

2.打开(OPEN):在测试者提交一个bug后,测试组长会在确认其确实为一个bug后,将其状态设置为打开状态。

3.分配(ASSIGN):Bug的状态被设置为打开后,就会由测试组组长将bug分配给测试组员或者测试组,这个时候bug的状态即转换为分配状态。

4.测试(TEST):当开发人员修复了bug之后,他们会把bug提交给测试组进行新一轮的测试,这个时候bug的状态就被设置成测试。

5.延后(DERERRED):Bug被设置成延后状态,意味着bug会在接下来的阶段解决。

一般这种情况的出现是因为bug本身对系统的影响不大,优先级不高等。

6.不接受(REJECTED):如果开发人员不认为其是一个bug,就会将该bug设置为不接受状态。

7.重复(DUPLICATE):如果一个缺陷被重复提交或者两个bug表明的意思是同一个或者指向的问题为同一个,则可以将这个bug的状态设置为重复。

8.已经核实(VERIFIED):Bug被分配给测试人员之后,如果测试人员经过测试发现问题已经修复,不会再重现,则可以将bug设置为已经核实状态。

9.再次打开(REOPENED):如果bug被开发人员修复后,测试中又出现了同样的问题,则将bug的状态设置为重新打开状态,再次交由开发人员修复。

10. 关闭(Closed):如果bug被设置为关闭装填,则表示该bug已由研发人员修复,经过测试人员测试核实,bug已经不存在了。

二、MANTIS功能介绍Mantis是一个基于PHP技术的轻量级的缺陷跟踪系统,其功能与前面提及的JIRA 系统类似,都是以Web操作的形式提供项目管理及缺陷跟踪服务。

Mantis 使用要点

Mantis 使用要点

Mantis 使用要点:1.系统中的角色在Mantis 系统中,分别有几种角色:管理员、经理、开发人员、修改人员、报告人员、查看人员。

每个角色所具备的权限不一样,权限的从大到小依次排列是:管理员→经理→开发人员→修改人员→报告人员→查看人员。

2.Bugbug 根据其以下工作状态分类成几个表格显示,符合这些工作状态的bug 都一一的罗列:1.分派给我的(未解决):是指Bug已经报告,指定由“我”来进行跟进的Bug列表;2.未分派的:是指Bug已经报告,但还没有指定由那个项目组成员进行跟进的Bug列表;3.我报告的:在这里将会显示由你报告的Bug列表;4.已解决的:指Bug已经得到解决,Bug的状态为[已经解决];5.最近修改的:这一栏显示那些Bug报告最近被项目组成员修改了;6.我监视的:指你正在监视那些Bug,在Bug报告中,你被选为监视人。

在该状态表格下,而且Bug编号是对应其详细信息的超链接,可以根据工作要求直接点击进入进行相应操作。

此外在页面下部出一个标识Bug流程状态的颜色条,如图表5,这样在实际操作中对于不同流程状态的Bug就能很好的区分开,下面主要描述Bug状态:1.新建:就是由报告员提交问题时没有选择分派对象时,Bug的默认状态便是新建(初始化);2.反馈:开发人员认为此bug不需要修改,就将其反馈(待评审),测试人员和开发人员讨论评估后,决定是否将其关闭;(评审委员会)3.认可:经理认为报告员提交的问题是个Bug,对这个Bug表示认可(待分配);4.已确认:开发人员确认存在此bug,并准备修改,将其设为已确认(待修正);5.已分派:当经理看到,原状态为“新建”的问题单,就会将其分派给某个开发人员;6.继续跟踪:被反馈的bug,在没有商定之前,暂定为“继续跟踪”;7.已解决:被分派的开发人员已经进行了修改,测试人员可以进行验证测试, 确认Bug已经解决(待验证);8.已关闭:确认Bug已解决,将其关闭(关闭)。

mantis使用简介

mantis使用简介
Mantis使用简介
一、mantis界面 二、提交bug Mantis系统操作使用培训 三、查看bug 四、修改bug
中国移动通信集团设计院有限公司
Mantis使用简介
一、Mantis主界面 二、提交需求或问题 三、查看所提交问题 四、修改问题或需求
一、Mantis主界面
二、提交bug
点击“报告问题”->填写具体信息->点击“提交问题”
切换项目:缩小查找范围 通过问题编号查找:精确查找 通过关键字查找:模糊查找
四、修改bug
• 找到希望修改的问题,如果该问题处于“已分派”或“新 建”状态,说明可以进行问题信息的修改,点击该问题编 号左侧的 进行信息更新,或者点击问题编号,修改问题 详情,最后点击“更新信息”,完成问题修改。
谢谢!Βιβλιοθήκη 填写具体信息注意事项• 摘 要:对问题的简要概括描述,格式如:模 块+子模块+功能点+操作过程+ 现象; 说 明:详细清楚的描述bug信息,如:具体 的运行环境、操作步骤和结果等; 附件信息: 后台报错的详细信息; 上传文件: 报错截图等。 添加完必须的信息,即可保存成功。
• • • •
三、查找bug

Mantis应用流程图

Mantis应用流程图

测试服务生产
测试组进行关闭开发人员发布新版本,并
自行测试完毕,保证产品
1.开发人员发布新版本,移交给测试组进行测试。

*开发发布之前需要进行内部测试,保证产品没有影响大功能模块导致无法进行测试的BUG。

2.测试组进行受入测试,测试通过以后承认版本正式发布。

3.版本正式发布以后测试介入测试。

测试,服务和生产在测试过程中发现的问题登陆到mantis指派给董时博。

4.董时博把BUG整理后指派给开发担当
5.开发担当收到BUG以后分析此问题是否属于BUG,如果属于BUG在mantis上的状态改为:已确认,如果认为不是BUG的话把状态置为notbug后分派给测试担当。

6.测试担当确认是否认可,如果认可不是BUG,直接关闭,如果不认可保留到会议评审。

7.BUG状态为已确认的问题,需要定期组织会议评审BUG修改等级
8.BUG评审通过需要修改的,由各开发担当进行修改,修改完成后指派给测试组进行验证。

9.测试组验证通过后进行关闭,如未通过在指派给开发进行二次修改。

Mantis操作手册-开发人员版本

Mantis操作手册-开发人员版本

Mantis操作手册
(开发人员版本)
一、打开Mantis的链接http://192.168.2.205:8080/mantis/login_page.php,登录
页面如下图:
二、登录成功后,开发人员可以在“我的视图”中查看到分配给我的问题。

如下图
点击“我的视图”如下:
点击编号进行查看,可以查看问题详情及附件。

三、开发人员在完成bug修改后,需要进入“查看问题”界面,进行状态修改。

1进入“查看问题”界面。

选择已经修改的bug,将下方下拉框中选择“处理状况”
2点击下拉框的状态选项为“已修正”,输入问题的解决方法及建议的测试用例。

再点击“解决问题”。

四当发现该问题出现问题分派错误或者经过初步查看后,需要将bug转移给其他操作人员的,本人完全无需要修改,则选择转移Bug。

1进入“查看问题”界面。

选择需要转移的bug,将下方下拉框中选择“分派”—确定
选择对应的开发人员,点击“分派问题”完成。

五、其他情况
有可能存在某些Bug,可能除了被分派的开发人员也涉及到其他开发人员协助进行修改。

这种情况,根据首问负责制,由首个接到任务的开发人员牵头,和其他涉及到的开发人员进行Bug修正。

不需要进行Bug转移。

附:mantis操作流程。

bug处理系统-Mantis使用说明详细版

bug处理系统-Mantis使用说明详细版

Mantis的说明文档一.把Mantis弄成简体中文版本二.Report一个bug1. 出现频率(Reproducibility)总是(Always):每次尝试都会出现有时(Sometimes):相对于下面的“随机”频率要高一些随机(Random):随机出现还没有尝试(Have not tried):即发现bug的操作只进行了一次不可重现(Unable to reproduce):只发现一次,之后的尝试都无法再现不可用(Not Applicable/Acceptable):即再次尝试的时候出现bug的功能不能用了2. 严重性(Severity)新功能(Feature):一般用来指系统缺乏一个所需要的特性细节(Trivial):比较小的问题,例如用户界面中Button位置等文字(Text):文字错误文字上的拼写错误小调整(Tweak):如: ¥123.345等小错误(Minor):不能用上述分类界定的,报告人认为是严重程度比较轻的问题严重错误(Major):不属于系统崩溃和死锁类的,但报告人认为比较严重的错误崩溃(Crash):引起系统崩溃的错误死锁(Block):引起系统死锁的错误3. 优先级(Priority )无(None):相关的bug已经resolve不存在了或者觉得优先级没有必要体现低(Low):留到最后解决,如果项目的进度很紧张可以在产品发布以前不解决中(Normal):中等优先级高(High):将处于Immediate和Urgent优先级的bug修改完毕后要进行修改紧急(Urgent):一到两天之内必须进行修改特急(Immediate):马上需要立即进行修改4.状态(Status):新建(New):当reporter新提交一个bug,不给其指派所有者的时候,bug的状态会自动的成为new的状态.(我们的权限设置,默认的reporter并没有指派的权利,所以reporter提交的一定是new状态的bug.)反馈(Feedback):要求reporter再次对bug进行说明认可(Acknowledged):开发人员解决了bug以后tester已经了解但是还没来得及确认已确认(Confirmed):bug的解决方案得到了tester的确认已分派(Assigned):当将bug指派给他所属的开发人员之后,bug的status会自动的并成为assigned已解决(Resolved):bug已经被解决但是还没有得到tester的验证已关闭(Closed):当bug已经确认被解决或者确认不是bug的时候将bug的状态改为closed5.处理状态(Resolution):未处理(Open):bug没有被解决已修复(Fixed):bug的修改已经登记并经过测试重新打开(Reopen):bug曾经被解决,但是解决方案被认为不正确无法重现(Unable to reproduce):不可重现,被指派的开发人员想要再现bug进行修改的时候发现bug始终不能再现的时候将bug的resolution设置为此项无法修复(Not fixable):不能修改这个bug重复问题(Duplicate):与某个已经存在的bug重复不必改(No change required):经理和相关开发人员经过需求和设计的核实后决定不需要修改延期(Suspended):一般是指当前版本不进行修改,下个版本再提供解决方案不做修改(Won’t fix):不准备修改这个bug三.查看隶属自己的bug或者某模块下的所有bug1.查看隶属自己的bug:进入Mantis系统后,点击"我的视图",可进行查看2.查看模块下的所有bug进入系统后,点击"查看问题",设置查询条件,点击"筛选"进行查询四.缺陷跟踪1.对bug的一些基本操作打开一个bug,查看bug的详细信息编辑:重新修改bug的信息分配:重新分配bug给某人状态:可以更改bug状态:1.一个新bug提交后默认为"新建(new)"状态2.开发修复一个bug后直接分派(assigned)给测试人员3.开发修复一个bug后,bug未修复,测试将状态改为"反馈(feedback)"状态,然后分派给对应的开发人员(循环)4.开发修复一个bug后,bug确认没有问题,测试人员将bug状态改为"已关闭/已修复(closed/resolved)"5.开发不能关闭任何bug,就算有权限也不允许直接关闭,只有tester和manager才能关闭一个bug删除:点击即可删除该bug,不推荐使用,若该bug单子真的没有必要存在,可以直接更改该bug状态为"已关闭(closed)",并在"处理状态"处选择关闭的原因,如图:2.一些需要注意的地方由于咱们的Mantis目前还没有关联到SVN上,所以麻烦开发人员修复好一个bug后加上一个note,注明该bug已修复,等待测试人员进行测试工作。

Mantis-流程操作手册2.0

Mantis-流程操作手册2.0

Mantis使用手册目录1.系统简述 (2)2.登陆方式 (2)3.系统中的角色 (3)3.1.管理员 (4)3.1.1.首页 (4)3.1.2.我的视图 (4)3.1.3.查看问题 (5)3.1.4.报告问题 (9)3.1.5.变更日志 (10)3.1.6.统计报表 (10)3.1.7.管理 (12)3.1.8.个人资料 (20)3.1.9.注销 (23)3.2.经理 (23)3.2.1.操作区别 (23)3.3.开发人员 (23)3.3.1.操作区别 (23)3.4.修改人员 (24)3.4.1.操作区别 (24)3.5.报告人员 (24)3.5.1.操作区别 (24)3.6.查看人员 (25)3.6.1.操作区别 (25)4.分派给我的工作 (25)4.1.查看问题详细资料 (25)4.2.关系 (26)4.3.上传文件 (27)4.4.正在监视该问题的用户 (27)4.5.问题注释 (27)4.6.添加问题注释 (28)4.7.问题历史 (28)1.系统简述Mantis管理平台是一个开源的缺陷跟踪系统,以Web操作的形式提供项目管理及缺陷跟踪服务。

Mantis可以帮助所有开发人员完成系统需求缺陷的有效管理,对于bug问题的状态变化将通过mail的形式由系统自动通知相关人员。

且可以自动生成统计报表和自动导出成doc或excel格式的文件。

2.登陆方式打开浏览器,在地址栏里键入:http://103.24.116.69,便可显示系统的登录页面(图表1),注册,有两种方式注册新用户:1)由管理员添加新用户(参见管理员操作说明);2)使用Email注册。

进入登录页面后,点击【注册一个新帐号】,输入帐号和E mail地址,提交注册,系统会将初始密码发送到Email中;用户正确的输入自己的帐号(即用户名)及密码后,即可成功登录。

图表 2.13.系统中的角色在Mantis 系统中,分别有几种角色:管理员、经理、开发人员、修改人员、报告人员、复查员。

Mantis_使用说明

Mantis_使用说明

Mantis 使用说明一、注册Mantis1、打开Manis在网页浏览器地址栏里输入http://192.168.1.27/Mantis,进入Mantis的登录界面,如下图:2、注册用户名点击Mantis的登录页面“注册一个新帐号”,转到以下界面:在此页面输入自定义的帐号和有效的E-MAIL,字符串,点击注册。

如果成功注册将会出现以下页面:Mantis将会随机生成一个用户密码以E-MAIL的形式发到你刚才填写的E-MAIL地址,所以填写的E-MAIL地址一定要真实有效,否则你将不能收到你的登录密码。

3、修改注册密码注册成功后,查看你所填写的E-MAIL邮箱是否已经收到由Mantis发出的用户注册确认信,如下图:点击入面的超级链接进入Mantis新注册用户的密码修改页面,如下图:在此页面输你所希望的密码,然后点击页面下方的“更新帐号信息”按钮,完成密码修改。

注意:默认的新注册用户只有[报告人员]的存取权限,其它一些权限的设定需要管理员另行配置。

如果还想更改密码,点击菜单栏的“个人帐号”,即进入了帐户管理界面,如下图:图上有“个人帐户”,“更改个人设置”,“管理平台配置”功能操作,当前默认界面为个人帐户编辑页面。

●个人帐户:为点击“个人帐户”界面进入的默认界面,可以在此修改密码,Email,真实姓名等等帐户信息。

●更改个人设置:点击“更改个人设置”,进入如下图:可对页面相关项进行重新设置。

●管理平台设置:点击“管理平台配置”,进入如下图:在此可以增加平台设置,也可以对现有的平台数据进行编辑或删除。

这样,在自己报告bug 的时候,采用“高级报告”的报告报表就可以直接选用对应的平台数据而不需求自行输入,节省工作时间。

注:管理平台配置的内容只限于本人采用。

二、使用Mantis1、登录Mantis在登录的页面,输入注册的用户名,进入Mantis的主界面。

主界面如下图:在主界面可以看到一条工具栏。

在工具栏的下方我们看到有5大栏,分别是:●未指定的:是指问题已经报告,但还没有指定由那个项目组成员进行跟进的问题列表。

mantis问题跟踪流程说明

mantis问题跟踪流程说明

MANTIS跟踪流程说明一、Mantis缺陷状态变化图二、Mantis缺陷状态变化说明下面描述一个缺陷状态由新建到关闭的过程。

1)状态:【新建】实施人员收集用户问题,通过mantis界面上方的【报告问题】,进入录入问题界面,如下图所示:录入问题时,请注意【分类】、【产品版本】的选择。

【产品版本】注意选择最新的版本,表明现在最新的版本仍存在上述问题录入用户问题时,【分类】选择“用户问题”,实施人员现场测试发现的问题,分类选择”集成测试”。

录入问题以后,问题状态变为【新建】。

2)状态:【新建】→【已分派】/【已延迟】/【已拒绝】/【需求待确认】经理分析问题后,对问题进行处理:如果确认是缺陷,由分派给适合人员处理,状态改为【已分派】。

如果确认是缺陷,但现在暂时不做处理,状态改为【已延迟】。

如果认为不是缺陷,不做修复,状态改为【已拒绝】。

如果分析问题描述不明确,难以开发/修复,需要现场实施人员进一步明确需求,状态改为【需求待确认】。

问题状态的改变可通过mantis【将状态改为】实现问题状态的改变。

3)状态:【需求待确认】→【需求已确认】现场实施人员与用户沟通以后,描述需求不明确的地方,将问题状态转化为【需求已确认】。

4)状态:【已分派】→【已解决】开发人员修复问题后,将状态改为【已解决】。

问题状态既可以手工改,也可以提交时日志信息,在日志信息”填写fixed bug#mantis问题编号+摘要”,如下图所示:Mantis问题状态自动将状态变为【已解决】,而且会记录修复此问题的文件及具体修改内容。

建议提交时用上述方法,方便以后问题追溯。

5)状态:【已解决】→【已关闭】/【打回】实施人员升级系统后,验证问题是否修复。

如果问题已修复,将问题状态改为【已关闭】。

如果问题没有修复,将问题状态改为【打回】,同时注意更改版本号为最新的版本号。

三、各角色关注问题状态及注意事项实施人员重点关注【需求待确认】、【已延迟】、【已拒绝】状态的问题。

Mantis bug处理流程

Mantis bug处理流程

测试人员 已解决 重新打开
测试人员 已关闭的 问题 状态 动作 已关闭 重新打开
重新打开 分派问题 状态 动作
开发人员 已分派 解决问题
解决问题 完成度: 已修正 状态 动作
测试人员 已解决 确认是否已修正 No:打回问题 开发人员 状态 动作 打回 解决问题
Yes
关闭 问题
解决问题
完成度: 已修正
测试人员 已解决 确认是否已修正
解决问题 完成度: 已修正 状态 动作
开发人员 打回 解决问题
Yes:
解决问题 完成度: 未处理、 无法修复、 不做修改
测试人员
状态 动作 新建 报告问题
新建、 分派问题
开发人员
状态 动作 已分派 分析问题, 需要项目 经理确认 分派问题 状态 动作
项目经理 已分派 是否同意
测试人员 状态 动作 已解决 关闭问题
No: 打 回 问 题
Yes
关闭问题 状态 No: 打 动作 回 问 题
测试人员 已解决 确认是否已修正
解决问题 完成度: 已修正 状态 动作
开发人员 打回 解决问题
关闭问题
测试人员
状态 动作 新建 报告问题
新建、 分派问题
开发人员
状态 动作 已分派 暂停问题, 需要项目 经理确认 分派问题 状态 动作
状态 新建 打回 已分派 已解决 已关闭
完成度
可否结束对应 × × × × ○
项目经理 已分派 是否暂停
Yes: 解决问题 完成度: 暂停
暂停问题
No: 打 回 问 题
状态 重新打开, 分派给开 发人员 动作
一旦不再 受限,重 新打开
Yes
关闭问题 状态 No: 打 动作 回 问 题

MANTIS缺陷管理工具操作指南

MANTIS缺陷管理工具操作指南

MANTIS缺陷管理工具操作指南一、注册1、绑定HOST文件:路径C:\Windows\System32\Drivers\etc,使用记事把打开hosts文件,填加一条”192.168.9.12 ”(不需要引号)2、mantis地址:请加入收藏夹,方便日后使用。

2、mantis采用管理员统一注册方式。

还没有注册帐号或遗失帐号的同事,请联系管理员。

3、帐号使用个人姓名的拼音全拼,管理员在创建新账号后,后有确认邮件发送到邮箱,通过邮件中的确认链接,用户可以对新账号进行密码设置。

二、登录输入账号(个人姓名拼音全拼)、密码后,点击登录按钮。

三、我的视图1、我的视图页面展示内容主要为缺陷缺陷列表,根据不同状态分为五个列表展示未分派的:提出了缺陷,还未分配人员处理。

我报告的:我提出的缺陷。

已解决的:缺陷已经被处理过。

最近修改:按修改时间排序。

我监视的:用户根据需要,对个别缺陷进行特别关注的。

2、缺陷状态,mantis在我的视图页面通过不同颜色区分缺陷的处理状态。

分为七个状态:新建、反馈、认可、已确认、已分派、已解决、已关闭1)新建:新发现的BUG,状态设置为新建。

2)反馈:不确定是否为BUG,或是需要进行项目负责人确认的,设置为反馈。

3)认可:项目负责人认为是BUG或可进行优化的,状态设置为认可。

4)已确认:BUG被确认的,状态设置为已确认。

5)已分派:BUG分派给指点人员处理的,状态设置为已分派6)已解决:开发人员处理完BUG后,状态设置为已解决,并指定分派给测试人员。

7)已关闭:测试人员对BUG进行验证后,对已经修复的或不是问题的BUG进行关闭操作。

四、提交缺陷1、点击提交问题,跳转到选择项目页面2、选择新版学习中心项目,如果近期常用这个项目,可以选中“设为默认值”。

点击选择项目按钮跳转到缺陷详情页面3、缺陷详情页面1)分类:根据功能模块分为(个人设置、关注动态、成就系统、我的网校、找老师、找课程、教师页、测试题、课程学习页、课程详情页、首页)2)出现频率:对缺陷出现在频率进行区分(总是、有时、随机、没有试验、无法重现、不适用)3)严重性:对缺陷的严重程度进行区分(新功能、小细节、文字、小调整、小错误、很严重、崩溃、宕机)4)优先级:对缺陷的处理先后进行区分(无、低、中、高、加急、特急)5)选择平台配置:主要包括浏览器、系统、系统版本(选择平台配置后,下方配置可不必输入)6)产品版本:产品开发版本号7)分派给:将问题分配给相关人员处理(默认为管理员根据功能模块分配的修改员)8)摘要(必填):BUG的简要说明9)描述(必填):BUG的具体说明10)问题重现步骤:重新BUG的操作步骤。

缺陷管理平台(mantis)操作说明

缺陷管理平台(mantis)操作说明

1.1 文档说明该文档根据项目部商议按照一览网络公司具体情况且而制定的测试流程,非依照完全正规流程进行说明。

如有异议可以按照建议的形式告知。

如符合公司具体情况且采用。

为了方便大家查看文档,建议大家点击:word里视图,勾选导航窗格文档里图片有看不清楚的地方,大家可以扩大word的比例!1.2 B ug地址和账号使用地址:192.168.60.202使用账号:研发部以OA账号为bug账号使用密码:123456(可以自己修改密码)首页视图:点击查看问题1.3 报告人员操作流程第一步:点击首页的报告问题链接第二步:选择问题严重性(严重性的描述详见图片下面的说明表格)说明:第三步:选择优先级(优先级描述,详见图片下面说明)优先等级描述特急:立即修复,停止经一步测试加急:在产品发布之前必须修复中高:如果时间允许应该修复的低:可能会修复,但是也能发布优先等级说明:致命的bug优先等级高的会在致命bug中要先处理严重的bug优先等级高的会在严重bug中要先处理一般的bug优先等级高的会在一般bug中要先处理第三步:查看报告完毕bug的状态:(中间省略了点击提交按钮的操作)3.2开发人员操作流程第一步:选择属于自己的平台第二部:搜索属于自己的bug第三步:按照问题的严重等级解决bug说明:致命的bug优先等级高的在致命bug中要先处理严重的bug优先等级高的在严重bug中要先处理一般的bug优先等级高的在一般bug中要先处理特急:立即修复,停止经一步测试加急:在产品发布之前必须修复中高:如果时间允许应该修复的低:可能会修复,但是也能发布第四步:修改bug,修改完毕以后将状态改为“已解决”然后再点击:“将状态改为”按钮。

最好是问题解决备注一下。

简述使用mantis软件的工作流程

简述使用mantis软件的工作流程

简述使用Mantis软件的工作流程1. 概述Mantis是一款开源的缺陷跟踪系统,广泛应用于软件开发过程中的缺陷管理和问题追踪。

本文将从以下几个方面简述使用Mantis软件的工作流程。

2. 创建项目在开始使用Mantis软件进行工作流程管理之前,首先需要创建一个项目。

在Mantis中,项目是一个虚拟组织单元,用于组织和跟踪软件中的缺陷和问题。

3. 添加缺陷一旦项目创建完成,就可以开始添加缺陷。

缺陷是在软件开发过程中发现的问题,可能包括功能错误、界面问题、性能问题等。

通过Mantis软件添加缺陷时,需要填写缺陷的详细信息,包括标题、描述、优先级、严重程度、指派给谁等。

4. 跟踪缺陷添加完缺陷后,Mantis会为每个缺陷生成一个唯一的缺陷编号,用于跟踪和管理缺陷。

跟踪缺陷主要包括以下几个方面:•更新缺陷状态:可以将缺陷的状态更新为新建、已指派、已解决、已关闭等。

•添加备注:可以添加备注来记录缺陷的跟踪过程、解决方法等。

•附件管理:可以上传和管理与缺陷相关的文件和文档。

•关联缺陷:可以将多个缺陷关联起来,形成一个缺陷链条,以便更好地追踪和管理。

5. 分配任务除了缺陷跟踪外,Mantis还可以用于分配任务。

项目组成员可以通过Mantis 软件接收和处理分配给自己的任务,以保证项目的顺利进行。

分配任务的过程主要包括以下几个步骤:•创建任务:创建任务时需要填写任务的详细信息,包括任务标题、描述、优先级、指派给谁等。

•分配任务:在创建完成后,可以将任务分配给特定的项目组成员。

•跟踪任务:分配任务后,可以跟踪任务的进度和状态,及时了解任务的执行情况。

6. 报表生成Mantis软件提供了丰富的报表功能,可以根据特定的条件和需求生成各种统计和分析报表,帮助项目团队更好地了解项目进展和问题情况。

报表生成主要包括以下几个方面:•缺陷统计报告:可以根据缺陷状态、优先级、严重程度等条件生成缺陷统计报告,用于了解项目中的缺陷情况。

缺陷分类和状态划分

缺陷分类和状态划分

一、缺陷分类划分
注:
1.A/B/C/D/E为智能家庭测试时的严重级别划分;
2.S1/S2/S3/S4/S5为国检第三方对应的严重级别划分;
3.P0/P1/P2/P3/P4为支付测试时的严重级别划分。

二、对Bug分类的一些补充:
1、崩溃
存在重大安全漏洞是指系统存在已知的较重大的安全漏洞,黑客通过此漏洞可以很容易的进入该系统、
导致该系统或功能无法正常使用,此类漏洞可能是由于开发方没有对系统做好安全加固工作。

2、严重
存在一般安全漏洞是指系统存在可能的安全隐患,存在黑客通过此漏洞获取系统数据的可能,此类漏洞可能是由于开发方的程序引起的或者是开发方对系统的错误配置引起的。

3、小调整
界面不规范是指界面风格不统一,界面风格与通用软件产品界面风格出处较多,例如:对话框的设计风格。

4、细节
输入输出不规范是指对于数据输入输出方式,方法与通用的软件产品出处较多,例如:通用软件中如果输出数据为文件方式,将支持标准的文件格式,如 .Doc、.RTF、.XLS、.GIF、.PDF等。

三、Mantis中缺陷状态划分
四、缺陷管理流程
Mantis中缺陷管理流程,如下图:
Mantis 系统缺陷处理流程。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Fixed(已修改)
复测是否解决 是
Closed(关闭)

Reopen(重新打开)
需求缺陷 功能问题 界面优化 兼容问题 性能问题 配置相关
建议 安全问题 修复BUG引发问题
被描述的问题是一个bug,但是不准备进 行修改(建议性bug,修改成本较大) 原需求就是这样设计的,数据来源就是 这样的,测试员操作问题、测试准备的
开发同事,修复bug引起的新bug
需求文档描述不准确、未描述
功能(逻辑、文字等)与文档描述不一 致,包括未实现
前端开发与制作稿 不一致(经过ui重新 更改的bug属于需求问题)
浏览器兼容、分辨率兼容、设备兼容
响应时长等问题
环境因素(线上线下环境切换、文件发 布问题、数据同步问题)
测试从用户体验角度出发,给出的建议 问题
涉及到安全性的问题
测试 测试 开发 开发 测试
测试
New(新建)
建议
Feedback(反馈)【产品】 无需修改
Open(指定开发)
需要修改
需求认
是否修改bug


Resolved(已处理)
Rejected(拒绝修改)
拒绝理由
Wontfix(不修改) Invalid(不是问题) Later(以后版本修改) Remand(认可保留) Duplicate(重复问题) Worksforme(无法重现)
数据问题 被描述的问题是一个bug,但是不在产品
的目前版本中进行修改
产品认可不修改(如用户体验问题等)
提出的问题和当前已经存在的某个bug 重复(需标记重复的bugid)
查看源代码也不知道为什么会出现这样 的bug现象,若有更多的关于这个bug的
线索,重新接受这个bug
对bug的一个修改已经被登记,并且已经 经过测试(开发自己的测试)
相关文档
最新文档