Bug提交与管理规范.ppt

Bug提交与管理规范 编写人 姚妮娜2010 8 20 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报告的内容 有效描述Bug 短小 只解释事实和演示 描述Bug必需的细节 单一 每一个报告中针对一个Bug 步骤清晰 要清楚地描述出Bug的发生场景 包括前置条件和操作的详细步骤 再现 按照预定步骤可以重现相同状况 在报告Bug时只描述事实 不做评价 也不要有人身攻击 必要的时候可以添加注释 remarks 可以上载屏幕抓图和其他附件 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生命周期的结束 测试人员验证 关闭Bug 测试人员验证 关闭Bug说明 当Bug由open变为fixed 应进行回归测试 如果回归测试后该问题被解决 则closed该Bug 并在注释中填写如下信息 验证版本 xxx验证次数 xxx验证通过 是验证日期 xxx验证人员 xxx如果回归测试验证不通过 则Reopened该Bug 并在注释中仍填写注释信息 验证版本 xxx验证次数 xxx验证通过 否验证日期 xxx验证人员 xxx 研发人员解决Bug 研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息 以便以后的信息收集和更好的保存作成果 针对不同情况 须按以下模块填写注释1 已经改正的BugBug产生原因Bug解决方案Bug修改后的版本号解决人员 2 不能解决的Bug Bug原因分析无法解决原因 技术问题 条件问题 解决人员 3 Bug重复 注明与之重复的BugID如根本原因相同 现象不同 给出简要分析说明解决人员 开发人员做此修改 必须由项目经理或主管经理确认 批准 4 无效Bug 给出无效原因 例如设计方案就是如此 解决人员 开发人员做此修改 必须由项目经理或主管经理确认 批准 Bug状态报告 项目进入系统测试阶段后 SQA人员要定期做Bug状态报告 Bug状态报告要以邮件方式发送给项目组长 项目组成员 测试人员和项目高层管理者