Bug提交与管理规范研讨.pptVIP

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