软件缺陷及bugzilla的使用.pptx

软件缺陷及bugzilla的使用,什么是缺陷,未达到产品说明书标明的功能。 出现了产品说明书指明不会出现的错误。 功能超出产品说明书指明范围。 未达到产品说明书虽未指出但应达到的目标。 测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。,软件缺陷产生的原因,人员之间的沟通交流不够、交流上有误解或者根本不进行交流 程序设计本身有错误 软件复杂性 需求变化 时间压力 代码文档贫乏 软件开发工具和系统软硬件的支持不完善,缺陷的分类,按严重性划分 影响进度的问题 死机 功能问题 界面问题 建议,缺陷的分类,按优先级划分 应立即修复的问题 在产品发布之前必须修复的问题 如果时间允许应该修复的问题 可以在发布版本中存在的问题,有效地记录缺陷！,保证重现缺陷 分析故障，使用最少步骤重现缺陷 包含所有重现缺陷的必要步骤 方便阅读 尽量简单一个缺陷一个报告 不要将bug步骤和看到的结果放在一起,缺陷跟踪系统-Bugzilla,Bugzilla是一个错误跟踪系统，用于对软件产品程序开发过程的错误跟踪。具有如下特点: 基于Web方式，安装简单、运行方便快捷、管理安全。 有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的Bug报告 系统灵活，强大的可配置能力.,Bugzilla的功能,强大的检索功能 用户可配置的通过Email公布Bug变更 历史变更记录 通过跟踪和描述处理Bug 附件管理 完备的产品分类方案和细致的安全策略 安全的审核机制 强大的后端数据库支持 Web，Xml，Email和控制界面 友好的网络用户界面 富多样的配置设定 版本间向下兼容,Bugzilla操作流程：,打开浏览器，输入Bugzilla服务器地址：28/index.cgi 在帐号login栏输入使用的E-Mail地址，在密码password栏输入邮件的初始密码，然后，点击Login登陆。如果成功登录后 点击change password-name and password ，进行密码修改。 点击菜单new或enter a new bug report之后选择项目进入bug报告输入页. 根据实际情况,选择输入项,并提交,Bugzilla登陆页面,成功登陆后的操作页面,修改密码页面,测试人员报告Bug的流程,请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个后自己去修改。 若Bug不存在，创建一份有效的bug报告后进行提交。 具体操作：点击新建new，选择产品后，填写一个Bug报告的表格，点击提交。,Bug表格,Bug表格,Bug报告中的字段,Componen：项目中的模块 Version：产生Bug的软件版本 Platform：硬件平台 OS：操作系统 Severity:bug的严重度 Priority：Bug报告优先级，P1 至 P5 优先级逐渐减弱 Initial State：bug报告的状态 Assign To：可以指定一个处理人， 如不指定处理人， 则系统指定管理员为默认处 理人 CC：可以添写多个人的邮件地址，中间用逗号隔开 Default CC：默认邮件抄送人,Bug报告中的字段,Estimated Hours：处理时间 Deadline：限定期限 URL：输入超链接地址，引导处理人找到与报告相关联的信息 Summary：bug概述 Description:bug的详细描述， Attachment：附件 Depends on：如果该Bug必须在其他Bug修改以后才能够修改，则在此项目后填写那个Bug的编号 Blocks：如果该Bug的存在影响了其他Bug的修改，则在此项目后填写被影响的Bug编号,Severity,Blocker，阻碍开发和/或测试工作 Critical，死机，丢失数据，内存溢出 Major，较大的功能缺陷 Normal，普通的功能缺陷 Minor，较轻的功能缺陷 Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等 Enhancement，建议或意见,Summary,应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。 如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。,Desription,发现问题的步骤 执行上述步骤后出现的情况 期望应出现的正确结果,Additional Comments,在Bug跟踪过程中测试与开发人员通过这里进行沟通 开发人员可以在这里填写处理意见和处理记录 测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述,Bug的处理流程,试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。 开发者收到E-Mail信息后，判断是否为自己的修改范围。 若不是，重新reassigned分配给项目组长或应该分配的开发者； 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）； 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。 还有问题，REOPENED，状态重新变为“New“，并发邮件通知。 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail骚扰它的属主，直到采取行动为止,缺陷报告处理流程图,缺陷报告处理流程图二,Bug报告状态分类,待确认的（Unconfirmd）:待确认后提交到系统中 新提交的（New）:这个Bug刚刚被提交到系统中，还没有做任何的处理和响应 未解决的（Reopened）:这个Bug曾经被处理过一次，但是处理的结果不太正确,Bug报告状态分类,已解决的（Resolved）：这个Bug已经被处理了，提醒测试组对此Bug进行验证 已验证的（Verified）：QA认可了处理意见，并且对Bug进行了验证 已关闭的（Closed）：产品发布以后对Bug进行关闭，归档,Bug状态转换图,Bug处理意见,已修改的（Fixed）：开发人员对此Bug进行了修改，并且经过自己的单元测试后已经check in到库中 不是问题（Lnvalid）：这个Bug中描述的不是问题 不修改（Wontfix）：这个Bug描述的是问题，但是不修改，以后也不修改 以后版本解决（Later）：这个Bug描述的是问题，但是不在这个版本中解决 保留（Remind）：这个Bug描述的是问题，但是不能确定是否在这个版本中修改 重复（Duplicate）：这个Bug与已有的Bug重复了，将状态置在重复的时候必须说明其与哪个Bug重复 需要更多信息（Worksforme）：根据Bug描述无法查找问题的原因并解决，需要提供更多的关于这个Bug的信息,bug查询,登录