《Bug提交与管理规范.ppt》由会员分享，可在线阅读，更多相关《Bug提交与管理规范.ppt（15页珍藏版）》请在三一办公上搜索。
1、Bug提交与管理规范,编写人：姚妮娜,Bug提交与管理规范,概述,Bug的生命周期测试流程中的角色与职责判断Bug的规则Bug的分类、状态、级别Bug的报告、跟踪、关闭测试人员验证/关闭问题描述开发人员解决问题描述,Bug的生命周期,角色与职责,判断Bug的规则,软件未达到产品规格说明书（需求）标明的功能。软件出现了规格说明书指明不会出现的错误。软件功能超出规格说明书指明的范围。软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug
2、，应当反复测试，直到最终确定Bug的发生场景为止。,Bug的分类,1.功能A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。2.易用性A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全；C.功能操作复杂，提示信息不合理，易产生歧义。3.安全性A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理；D.数据产生缺乏随机性；E网络安全性：开放端口、服务；F系统日志、审计。4.可靠性A.数据存贮的可靠性；B.业务处理的可靠性；C硬件可靠性：如打印机；D.应急处理措施；E数据备份、
3、恢复。5.性能A.并发量；B.吞吐量；C.响应时间。6.兼容性A.硬件兼容性；B.软件兼容性。7.可维护性A.可扩展性；B.方便升级。,Bug的状态,新建状态（NEW）Bug创建后的初始状态。已分配状态（ASSIGNED）经过确认为合法软件问题后分配给开发人员的状态。待验证状态（RESOLVED）开发部门对软件问题进行处理或修改后的状态。重新打开状态（REOPENED）对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。关闭状态（CLOSED）Bug生命周期的结束。解
4、决状态（VERIFIED）经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。未经证实状态（UNCONFIRMED）由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变为“New”。,Bug的级别,在软件测试过程中发现的Bug，要根据其严重程度进行分类，然后，进行不同的处理。可以把Bug划分为七级：第一级（blocker）:引起操作系统“挂起”或“崩溃”的错误；第二级（critical）:引起软件本身“挂起”或“崩溃”的错误；第三级（major）:不能完成软件说明书定义的功能的错误；第四级（normal）:程序所完成的功能与软件说明书定义不符的错误；第五级（minor）:显示
5、方面的错误；第六级（trivial）:其它“轻微”的错误（如文本差错）；第七级（enhancement）：增强或者改进。,Bug的修改优先级,修改优先级通常可分为五个级别：P1：尽快（或立刻）修正；P2：每个里程碑（或测试周期）结束前必须修正；P3：如果时间允许就修正；P4：低优先级。P5：在将来的某个版本修正也可以处理的工作日Blocker、critical：响应时间1天，处理1天Major、normal：响应时间1天，处理3天Minor、trivial：响应时间1天，处理7天Enhancement:时间未定,Bug报告的内容,有效描述Bug,短小：只解释事实和演示、描述Bug必需的细节；单
6、一：每一个报告中针对一个Bug；步骤清晰：要清楚地描述出Bug的发生场景，包括前置条件和操作的详细步骤；再现：按照预定步骤可以重现相同状况；在报告Bug时只描述事实，不做评价，也不要有人身攻击；必要的时候可以添加注释（remarks）；可以上载屏幕抓图和其他附件。,Bug的验证与关闭,测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。新提交的Bug为NEW状态，经开发人员修改后，Bug变为RESOLVED（待验证）状态。此时就需要测试人员对Bug进行回归测试，验证问题是否修正。如果问题仍然存在，则测试人员将该Bug的状态修改为REOPENED（重新打开）；如果通过验证确认问题已经修改好了
7、，则测试人员将该Bug的状态置为VERIFIED（已验证），同时添加附加意见如“该Bug在Release xx.xx版本中已经修正”。还有一种情况：开发人员认为Bug在当前版本可以暂不修改，而考虑在后续版本中再做修正，Bug的对应状态为LATER。对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意在后续版本修正，则测试人员可以将该Bug的状态置为VERIFIED；如果讨论结果是需要在本版本中解决问题，则测试人员应将该Bug的状态置为REOPENED，重新打开Bug。对于状态为VERIFIED的Bug，应由Bug的开启者即测试人员关闭。开发人员无权关闭
8、Bug。将Bug的状态标记为CLOSED，则Bug生命周期的结束。,测试人员验证/关闭Bug,测试人员验证/关闭Bug说明：当Bug由open变为fixed，应进行回归测试，如果回归测试后该问题被解决，则closed该Bug，并在注释中填写如下信息：验证版本：xxx 验证次数：xxx 验证通过：是 验证日期：xxx 验证人员：xxx如果回归测试验证不通过，则Reopened该Bug，并在注释中仍填写注释信息：验证版本：xxx 验证次数：xxx 验证通过：否 验证日期：xxx 验证人员：xxx,研发人员解决Bug,研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息，以便以后的信
9、息收集和更好的保存作成果。针对不同情况，须按以下模块填写注释1.已经改正的Bug Bug产生原因 Bug解决方案 Bug修改后的版本号 解决人员：*2.不能解决的Bug：Bug原因分析 无法解决原因（技术问题，条件问题）解决人员：*3.Bug重复：注明与之重复的Bug ID 如根本原因相同，现象不同，给出简要分析说明 解决人员：*开发人员做此修改，必须由项目经理或主管经理确认，批准。4.无效Bug：给出无效原因，例如设计方案就是如此。解决人员：*开发人员做此修改，必须由项目经理或主管经理确认，批准。,Bug状态报告,项目进入系统测试阶段后，SQA人员要定期做Bug状态报告。Bug状态报告要以邮件方式发送给项目组长、项目组成员、测试人员和项目高层管理者。,
