Bug提交与管理的学习课件

Bug提交与管理的学习课件第1页/共16页Bug提交与管理规范Bug提交与管理规范第2页/共16页概述Bug的生命周期测试流程中的角色与职责判断Bug的规则Bug的分类、状态、级别Bug的报告、跟踪、关闭测试人员验证/关闭问题描述开发人员解决问题描述第3页/共16页Bug的生命周期第4页/共16页角色与职责流程工作内容/管理方法职责输出建立bug库提交系统测试后，建立相应bug库测试经理Bug库名称提交版本开发经理提交软件版本号和详细信息开发经理Build号提交测试bug测试人员提交测试bug测试经理审阅后，提交开发人员待处理测试人员测试经理Bug记录Bug修改开发经理分配bug给相关开发人员修改，修改后提交待开发提交开发经理开发人员修改记录提交新版本开发经理提交新的版本，将修改信息和修改的bug写明在记录中开发经理版本说明Bug回归测试测试人员根据修改说明，返测bug测试人员Bug状态记录Bug归档返测结果正确，可以提交归档。如果有问题，继续退还开发人员处理测试经理测试人员Bug状态其他渠道反映的bug客户、销售、邮件或者会议上反映的bug，确认后可以记录到bug库中开发经理测试经理产品经理Bug记录第5页/共16页判断Bug的规则软件未达到产品规格说明书（需求）标明的功能。软件出现了规格说明书指明不会出现的错误。软件功能超出规格说明书指明的范围。软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。第6页/共16页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.方便升级。第7页/共16页Bug的状态新建状态（NEW）

Bug创建后的初始状态。已分配状态（ASSIGNED） 经过确认为合法软件问题后分配给开发人员的状态。待验证状态（RESOLVED） 开发部门对软件问题进行处理或修改后的状态。重新打开状态（REOPENED） 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。关闭状态（CLOSED）

Bug生命周期的结束。解决状态（VERIFIED） 经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。未经证实状态（UNCONFIRMED） 由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变为“New”。第8页/共16页Bug的级别在软件测试过程中发现的Bug，要根据其严重程度进行分类，然后，进行不同的处理。可以把Bug划分为七级：第一级（blocker）:引起操作系统“挂起”或“崩溃”的错误；第二级（critical）:引起软件本身“挂起”或“崩溃”的错误；第三级（major）:不能完成软件说明书定义的功能的错误；第四级（normal）:程序所完成的功能与软件说明书定义不符的错误；第五级（minor）:显示方面的错误；第六级（trivial）:其它“轻微”的错误（如文本差错）；第七级（enhancement）：增强或者改进。第9页/共16页Bug的修改优先级修改优先级通常可分为五个级别：P1：尽快（或立刻）修正；P2：每个里程碑（或测试周期）结束前必须修正；P3：如果时间允许就修正；P4：低优先级。P5：在将来的某个版本修正也可以处理的工作日Blocker、critical：响应时间1天，处理1天Major、normal：响应时间1天，处理3天Minor、trivial：响应时间1天，处理7天Enhancement:时间未定第10页/共16页Bug报告的内容缺陷IDBug的唯一标志，由Bug管理系统自动生成缺陷标题简明扼要地对Bug进行概要描述产品名称每个要测试软件项目都有唯一的名称测试版本报告错误时，一定要正确填写产生错误的软件版本号。测试环境软件环境：操作系统和其他必要的软件程序；硬件环境：测试计算机和其他设备的配置信息前提条件问题来源，引起错误发生的前提条件基本信息Bug的类型、严重程度以及处理的优先级；Bug所属模块；测试者名称、测试时间操作步骤详细描述错误重现的步骤，便于重现错误，修复错误和验证错误。实际结果描述实际测试后得到的结果。期望结果描述满足设计要求的结果。出现频率错误出现的概率文字注释与附图测试者的建议与必要的附图,便于确认错误的表现形式和错误位置。第11页/共16页有效描述Bug短小：只解释事实和演示、描述Bug必需的细节；单一：每一个报告中针对一个Bug；步骤清晰：要清楚地描述出Bug的发生场景，包括前置条件和操作的详细步骤；再现：按照预定步骤可以重现相同状况；在报告Bug时只描述事实，不做评价，也不要有人身攻击；必要的时候可以添加注释（remarks）；可以上载屏幕抓图和其他附件。第12页/共16页Bug的验证与关闭测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。新提交的Bug为NEW状态，经开发人员修改后，Bug变为RESOLVED（待验证）状态。此时就需要测试人员对Bug进行回归测试，验证问题是否修正。如果问题仍然存在，则测试人员将该Bug的状态修改为REOPENED（重新打开）；如果通过验证确认问题已经修改好了，则测试人员将该Bug的状态置为VERIFIED（已验证），同时添加附加意见如“该Bug在Releasexx.xx版本中已经修正”。还有一种情况：开发人员认为Bug在当前版本可以暂不修改，而考虑在后续版本中再做修正，Bug的对应状态为LATER。对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意在后续版本修正，则测试人员可以将该Bug的状态置为VERIFIED；如果讨论结果是需要在本版本中解决问题，则测试人员应将该Bug的状态置为REOPENED，重新打开Bug。对于状态为VERIFIED的Bug，应由Bug的开启者即测试人员关闭。开发人员无权关闭Bug。将Bug的状态标记为CLOSED，则Bug生命周期的结束。第13页/共16页测试人员验证/关闭Bug测试人员验证/关闭Bug说明：当Bug由open变为fixed，应进行回归测试，如果回归测试后该问题被解决，则closed该Bug，并在注释中填写如下信息：验证版本：xxx

验证次数：xxx

验证通过：是验证日期：xxx

验证人员：xxx如果回归测试验证不通过，则Reopened该Bug，并在注释中仍填写注释信息：验证版本：xxx

验证次数：xxx

验证通过：否验证日期：xxx

验证人员：xxx第14页/共16页研发人员解决Bug研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息，以便以后的信息收集和更好的保存作成果。针对不同情况，须按以下模块填写注释1.已经改正的BugBug产生原因

Bug解决方案

Bug修改后的版本号解决人员：***2.不能解决的Bug：

Bug原因分析无法解决原因（技术问题，条件问题……）解决人员：***3.Bug重复：