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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。