Bug提交与管理规范.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,*,Bug,提交与管理规范,编写人：姚妮娜,2010.8.20,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,状态报告要以邮件方式发送给项目组长、项目组成员、测试人员和项目高层管理者。,