Bug提交与管理规范

《Bug提交与管理规范》由会员分享，可在线阅读，更多相关《Bug提交与管理规范（15页珍藏版）》请在金锄头文库上搜索。

1、Bug提交与管理规范编写人：姚妮娜 2010.8.20Bug提交与管理规范概述 Bug的生命周期 测试流程中的角色与职责 判断Bug的规则 Bug的分类、状态、级别 Bug的报告、跟踪、关闭 测试人员验证/关闭问题描述 开发人员解决问题描述Bug的生命周期角色与职责流程工作内容/管理方法职责输出建立bug库提交系统测试后，建立相 应bug库测试经理Bug库名称提交版本开发经理提交软件版本号 和详细信息开发经理Build号提交测试bug测试人员提交测试bug测 试经理审阅后，提交开发 人员待处理测试人员 测试经理Bug记录Bug修改开发经理分配bug给相关 开发人员修改，修改后提 交待开发提交开

2、发经理 开发人员修改记录提交新版本开发经理提交新的版本， 将修改信息和修改的bug 写明在记录中开发经理版本说明Bug回归测试测试人员根据修改说明， 返测bug测试人员Bug状态记录Bug归档返测结果正确，可以提交 归档。如果有问题，继续 退还开发人员处理测试经理 测试人员Bug状态其他渠道反映的 bug客户、销售、邮件或者会 议上反映的bug，确认后 可以记录到bug库中开发经理 测试经理 产品经理Bug记录判断Bug的规则软件未达到产品规格说明书（需求）标明的功能。 软件出现了规格说明书指明不会出现的错误。 软件功能超出规格说明书指明的范围。 软件未达到规格说明书虽未指出但应达到的目标（隐

3、含需求）。 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终 用户认为不好。 需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对 于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景 为止。Bug的分类1. 功能 A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。2. 易用性 A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不 完全； C.功能操作复杂，提示信息不合理，易产生歧义。3. 安全性 A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制

4、或认证不合理； 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

5、） 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态 改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题， 如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。 关闭状态（CLOSED） Bug生命周期的结束。 解决状态（VERIFIED） 经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。 未经证实状态（UNCONFIRMED） 由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变 为“New”。Bug的级别在软件测试过程中发现的Bug，要根据其严重程度进行分类， 然后，进行不同的处理。可以把Bug划分为七级：第一级（blocker）: 引起操

6、作系统“挂起”或“崩溃”的错误； 第二级（critical）: 引起软件本身“挂起”或“崩溃”的错误； 第三级（major）: 不能完成软件说明书定义的功能的错误； 第四级（normal）: 程序所完成的功能与软件说明书定义不符的错误 ； 第五级（minor） : 显示方面的错误； 第六级（trivial） : 其它“轻微”的错误（如文本差错）； 第七级（enhancement）：增强或者改进。Bug的修改优先级修改优先级通常可分为五个级别： P1：尽快（或立刻）修正； P2：每个里程碑（或测试周期）结束前必须修正； P3：如果时间允许就修正； P4：低优先级。 P5：在将来的某个版本修正也可

7、以处理的工作日 Blocker、critical：响应时间1天，处理1天 Major、normal：响应时间1天，处理3天 Minor、trivial：响应时间1天，处理7天 Enhancement:时间未定Bug报告的内容缺陷IDBug的唯一标志，由Bug管理系统自动生成缺陷标题简明扼要地对Bug进行概要描述产品名称每个要测试软件项目都有唯一的名称测试版本报告错误时，一定要正确填写产生错误的软件版本号 。 测试环境软件环境：操作系统和其他必要的软件程序；硬件环 境：测试计算机和其他设备的配置信息 前提条件问题来源，引起错误发生的前提条件基本信息Bug的类型 、严重程度 以及处理的优先级；Bu

8、g所属 模块；测试者名称、测试时间操作步骤详细描述错误重现的步骤，便于重现错误，修复错误 和验证错误。 实际结果描述实际测试后得到的结果。 期望结果描述满足设计要求的结果。 出现频率错误出现的概率文字注释与 附图测试者的建议与必要的附图,便于确认错误的表现形 式和错误位置。 有效描述Bug 短小：只解释事实和演示、描述Bug必需的细节； 单一：每一个报告中针对一个Bug； 步骤清晰：要清楚地描述出Bug的发生场景，包括前置条 件和操作的详细步骤； 再现：按照预定步骤可以重现相同状况； 在报告Bug时只描述事实，不做评价，也不要有人身攻击 ； 必要的时候可以添加注释（remarks）； 可以上载

9、屏幕抓图和其他附件。Bug的验证与关闭测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。 新提交的Bug为NEW状态，经开发人员修改后，Bug变为RESOLVED（待 验证）状态。此时就需要测试人员对Bug进行回归测试，验证问题是 否修正。如果问题仍然存在，则测试人员将该Bug的状态修改为 REOPENED（重新打开）；如果通过验证确认问题已经修改好了，则测 试人员将该Bug的状态置为VERIFIED（已验证），同时添加附加意见 如“该Bug在Release xx.xx版本中已经修正”。 还有一种情况：开发人员认为Bug在当前版本可以暂不修改，而考虑 在后续版本中再做修正，Bug的对应状

10、态为LATER。 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相 关人员进行讨论，如果讨论结果为同意在后续版本修正，则测试人员 可以将该Bug的状态置为VERIFIED；如果讨论结果是需要在本版本中 解决问题，则测试人员应将该Bug的状态置为REOPENED，重新打开Bug 。 对于状态为VERIFIED的Bug，应由Bug的开启者即测试人员关闭。开发 人员无权关闭Bug。将Bug的状态标记为CLOSED，则Bug生命周期的结 束。测试人员验证/关闭Bug测试人员验证/关闭Bug说明：当Bug由open变为fixed，应进行回归测试，如果回归测试后该问题被解决 ，则closed该

11、Bug，并在注释中填写如下信息：验证版本：xxx验证次数：xxx验证通过：是验证日期：xxx验证人员：xxx如果回归测试验证不通过，则Reopened该Bug，并在注释中仍填写注释信 息：验证版本：xxx验证次数：xxx验证通过：否验证日期：xxx验证人员：xxx研发人员解决Bug研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息，以便以后的信息收集和更好的保存作 成果。 针对不同情况，须按以下模块填写注释1.已经改正的BugBug产生原因Bug解决方案Bug修改后的版本号解决人员：*2.不能解决的Bug：Bug原因分析无法解决原因（技术问题，条件问题）解决人员：*3.Bug重复：注明与之重复的Bug ID如根本原因相同，现象不同，给出简要分析说明解决人员：*开发人员做此修改，必须由项目经理或主管经理确认，批准。4.无效Bug：给出无效原因，例如设计方案就是如此。解决人员：*开发人员做此修改，必须由项目经理或主管经理确认，批准。Bug状态报告项目进入系统测试阶段后，SQA人员要定期做Bug状态报告。Bug状态报告要以邮件方式发送给项目组长、项目组 成员、测试人员和项目高层管理者。