jirabug相关.docVIP

什么是软件缺陷（bug） 软件未达到产品说明书标明的功能（功能缺失）。 软件出现了产品说明书指明不会出现的错误。 软件功能超出产品说明书指明范围（多余的功能）。 软件未达到产品说明书虽未指出但应达到的目标（隐含功能）。 软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 Bug:虫子，计算机软硬件错误 判断是否是bug的唯一标准是是否符合用户的需求，不符合用户需求的功能，就算是bug 软件缺陷产生原因： 导致软件缺陷最大的原因是产品说明书(需求)。 软件缺陷的第二大来源是设计方案。 编写代码 其他 信息传递的误差： 导致实际软件，都不能完全代表用户的真实需求，这就需要测试人员参与到需求的讨论调研中。 测试人员素质（三心二意一能力） 细心、耐心、信心 服务意识、团队合作意识 沟通能力（开发人员、项目经理、测试经理、客户等） bug的级别定义 Blocker：阻塞用例执行 Critical：错误导致死机、重启、系统崩溃、数据丢失；重要特性不可用 Major：重要特性不可用，系统稳定性问题，进程挂死 Minor：一般特性有问题 Trival:表面或微小的错误（提示信息不太友好、错别字、UI布局等），对功能几乎没有影响，产品属性仍可用；建设性的建议或意见 Mantis是以严重性为来定义的：拓机、崩溃、很严重、小错误、小调整、文字、细节、新功能Critical:拓机、崩溃Major:很严重Minor:小错误、小调整、Trivial:文字、细节 如果出现Critical问题，原则上版本不允许发布。 Bug处理流程 ①测试人员提交一个bug,状态为New ②测试人员或测试组长将bug指定分配给相关开发人员，开发人员收到该bug并接收，bug状态为Assigned ③开发人员修改bug,bug修改完毕，将其状态置为Resolved，等待回归测试 在修改bug状态为Resolved时，需附加bug处理意见: 如果bug已修改，处理意见为Fixed； 如果开发人员认为该bug不是问题，处理意见为Not a problem; 如果开发人员暂时无法修改这个问题，处理意见为Won’t fix 如果开发人员决定以后的版本修改，处理意见为Later/Pending 如果开发人员无法复现该bug,需要更多的附件信息，处理意见为not reproduce 如果发现新bug与以前提交的重复，处理意见为Duplicate ④开发人员解决完bug后，需要验证，验证通过的话，将bug状态置为Verified ⑤测试人员验证问题通过后，关闭bug,状态修改为Closed ⑥如果已经关闭的bug重现，需要将其状态修改为Reopen 在Jira上提交bug 40:8088/secure/Dashboard.jspa 报bug举例： 进入40:8088/secure/Dashboard.jspa，点击创建按钮，进入填写bug界面： 上面的红色框为必须填入的项目； 优先级：选择bug的优先级，重大问题优先解决 上传文件：附件截图，日志log，视频等 测试人员Bug追踪（各处理情况，按照bug处理流程进行）： 每天查看下需要自己处理的bug 选择问题-搜索问题： 显示： 建立bug列表查询条件或者选择Reported by me 点击Save as: 保存为bug列表过滤条件，可对其进行各项基本操作，下次进入搜索条件页面，就可以利用bug列表查询条件来查看自己需要处理的bug 2.对于Resolved的bug，在相应版本上验证之后： 如果不能重现，请加comments备注并关闭 如果该bug 仍然能重现，需要reopen，并加comments说明 open状态assign给我们的bug，按照comments要求做相应处理后（如在新版本拿到新的截图，日志等），需assign回给开发，选择分配给**，加上comments 如果只是修改bug，选择编辑，对bug进行修改后保存即可。