Bug提交与管理规范.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,*,Bug提交与管理规范,编写人：姚妮娜,Bug提交与管理规范,概述,Bug的生命周期,测试流程中的角色与职责,判断Bug的规则,Bug的分类、状态、级别,Bug的报告、跟踪、关闭,测试人员验证/关闭问题描述,开发人员解决问题描述,Bug的生命周期,角色与职责,流程,工作内容/管理方法,职责,输出,建立bug库,提交系统测试后，建立相应bug库,测试经理,Bug库名称,提交版本,开发经理提交软件版本号和详细信息,开发经理,Build号,提交测试bug,测试人员提交测试bug测试经理审阅后，提交开发人员待处理,测试人员,测试经理,Bug记录,Bug修改,开发经理分配bug给相关开发人员修改，修改后提交待开发提交,开发经理,开发人员,修改记录,提交新版本,开发经理提交新的版本，将修改信息和修改的bug写明在记录中,开发经理,版本说明,Bug回归测试,测试人员根据修改说明，返测bug,测试人员,Bug状态记录,Bug归档,返测结果正确，可以提交归档如果有问题，继续退还开发人员处理,测试经理,测试人员,Bug状态,其他渠道反映的bug,客户、销售、邮件或者会议上反映的bug，确认后可以记录到bug库中,开发经理,测试经理,产品经理,Bug记录,判断Bug的规则,软件未达到产品规格说明书（需求）标明的功能。

软件出现了规格说明书指明不会出现的错误软件功能超出规格说明书指明的范围软件未达到规格说明书虽未指出但应达到的目标（隐含需求）软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止Bug的分类,1.功能,A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符2.易用性,A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；,C.功能操作复杂，提示信息不合理，易产生歧义3.安全性,A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；,D.数据产生缺乏随机性；E网络安全性：开放端口、服务；F系统日志、审计4.可靠性,A.数据存贮的可靠性；B.业务处理的可靠性；C硬件可靠性：如打印机；D.应急处理措施；E数据备份、恢复5.性能,A.并发量；B.吞吐量；C.响应时间6.兼容性,A.硬件兼容性；B.软件兼容性7.可维护性,A.可扩展性；B.方便升级。

Bug的状态,新建状态（NEW）,Bug创建后的初始状态已分配状态（ASSIGNED）,经过确认为合法软件问题后分配给开发人员的状态待验证状态（RESOLVED）,开发部门对软件问题进行处理或修改后的状态重新打开状态（REOPENED）,对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态关闭状态（CLOSED）,Bug生命周期的结束解决状态（VERIFIED）,经测试部门对修改后的软件问题进行验证并确认修改正确后的状态未经证实状态（UNCONFIRMED）,由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变为“New”Bug的级别,在软件测试过程中发现的Bug，要根据其严重程度进行分类，,然后，进行不同的处理可以把Bug划分为七级：,第一级（blocker）,:引起操作系统“挂起”或“崩溃”的错误；,第二级（critical）,:引起软件本身“挂起”或“崩溃”的错误；,第三级（major）,:不能完成软件说明书定义的功能的错误；,第四级（normal）,:程序所完成的功能与软件说明书定义不符的错误；,第五级（minor）,:显示方面的错误；,第六级（trivial）,:其它“轻微”的错误（如文本差错）；,第七级（enhancement）,：增强或者改进。

Bug的修改优先级,修改优先级通常可分为五个级别：,P1：尽快（或立刻）修正；,P2：每个里程碑（或测试周期）结束前必须修正；,P3：如果时间允许就修正；,P4：低优先级P5：在将来的某个版本修正也可以,处理的工作日,Blocker、critical：响应时间1天，处理1天,Major、normal：响应时间1天，处理3天,Minor、trivial：响应时间1天，处理7天,Enhancement:时间未定,Bug报告的内容,缺陷ID,Bug的唯一标志，由Bug管理系统自动生成,缺陷标题,简明扼要地对Bug进行概要描述,产品,名称,每个要测试软件项目都有唯一的名称,测试,版本,报告错误时，一定要正确填写产生错误的软件版本号测试环境,软件环境：,操作系统和其他必要的软件程序；硬件环境：测试计算机和其他设备的配置信息,前提条件,问题来源，引起错误发生的前提条件,基本信息,Bug的类型、严重程度 以及处理的优先级；Bug所属模块；测试者名称、测试时间,操作步骤,详细描述错误重现的步骤，,便于重现错误，修复错误和验证错误实际结果,描述实际测试后得到的结果期望结果,描述满足设计要求的结果出现频率,错误出现的概率,文字注释与附图,测试者的建议与,必要的附图,便于确认错误的表现形式和错误位置。

有效描述Bug,短小：只解释事实和演示、描述Bug必需的细节；,单一：每一个报告中针对一个Bug；,步骤清晰：要清楚地描述出Bug的发生场景，包括前置条件和操作的详细步骤；,再现：按照预定步骤可以重现相同状况；,在报告Bug时只描述事实，不做评价，也不要有人身攻击；,必要的时候可以添加注释（remarks）；,可以上载屏幕抓图和其他附件Bug的验证与关闭,测试人员要不断跟踪Bug，直到Bug修正，问题解决为止新提交的Bug为NEW状态，经开发人员修改后，Bug变为RESOLVED（待验证）状态此时就需要测试人员对Bug进行回归测试，验证问题是否修正如果问题仍然存在，则测试人员将该Bug的状态修改为REOPENED（重新打开）；如果通过验证确认问题已经修改好了，则测试人员将该Bug的状态置为VERIFIED（已验证），同时添加附加意见如“该Bug在Release xx.xx版本中已经修正”还有一种情况：开发人员认为Bug在当前版本可以暂不修改，而考虑在后续版本中再做修正，Bug的对应状态为LATER对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意在后续版本修正，则测试人员可以将该Bug的状态置为VERIFIED；如果讨论结果是需要在本版本中解决问题，则测试人员应将该Bug的状态置为REOPENED，重新打开Bug。

对于状态为VERIFIED的Bug，应由Bug的开启者即测试人员关闭开发人员无权关闭Bug将Bug的状态标记为CLOSED，则Bug生命周期的结束测试人员验证/关闭Bug,测试人员验证/关闭Bug说明：,当Bug由open变为fixed，应进行回归测试，如果回归测试后该问题被解决，则closed该Bug，并在注释中填写如下信息：,验证版本：xxx,验证次数：xxx,验证通过：是,验证日期：xxx,验证人员：xxx,如果回归测试验证不通过，则Reopened该Bug，并在注释中仍填写注释信息：,验证版本：xxx,验证次数：xxx,验证通过：否,验证日期：xxx,验证人员：xxx,研发人员解决Bug,研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息，以便以后的信息收集和更好的保存作成果针对不同情况，须按以下模块填写注释,1.已经改正的Bug,Bug产生原因,Bug解决方案,Bug修改后的版本号,解决人员：*,2.不能解决的Bug：,Bug原因分析,无法解决原因（技术问题，条件问题）,解决人员：*,3.Bug重复：,注明与之重复的Bug ID,如根本原因相同，现象不同，给出简要分析说明,解决人员：*,开发人员做此修改，必须由项目经理或主管经理确认，批准。

4.无效Bug：,给出无效原因，例如设计方案就是如此解决人员：*,开发人员做此修改，必须由项目经理或主管经理确认，批准Bug状态报告,项目进入系统测试阶段后，SQA人员要定期做Bug状态报告Bug状态报告要以邮件方式发送给项目组长、项目组成员、测试人员和项目高层管理者。