概述CMMI质量管理体系——软件测试缺陷管理.ppt

缺陷状态 * 缺陷状态 状态描述 新建 测试或评审人员记录缺陷后的状态 已分配 开发经理接受测试人员提交的缺陷是缺陷后，将其分配给对应的开发人员，并将状态置为“已分配”状态 已拒绝 开发经理或者开发人员看到分配给自己的缺陷不是缺陷，将缺陷置为“已拒绝”状态 已修复 开发人员在开发环境对一个缺陷已经修复完，开发人员置为“已修复”状态 重新打开 测试人员看到缺陷处于“已修复”状态，经验证失败后，将缺陷置为“重新打开”状态；“已挂起”的缺陷开始处理，开发人员将缺陷置为“重新打开”状态 已拒绝已关闭 表示缺陷被开发经理拒绝并已通过测试人员的认可 已挂起 开发经理判断缺陷为推迟修改的，将状态置为“已挂起”状态；开发人员判断缺陷为推迟修改的，将状态置为“已挂起”状态 已关闭 测试人员看到缺陷处于“已修复”状态，经验证通过后，将缺陷置为“已关闭”状态 缺陷管理相关属性 * 缺陷属性 描述 缺陷描叙（Summary） 简单描述缺陷，主要是什么缺陷 缺陷发现提交者（Detected By） 描叙缺陷是由谁发现提出的。 缺陷发现时间（Detected on Date） 描叙缺陷发现提出时间。 缺陷严重性（Severity） 描述缺陷的严重性。 缺陷分给谁（Assigned to） 指缺陷分派给谁。 缺陷在哪个版本发现(Detected in Version) 描叙缺陷发现的版本 缺陷被修改的时间（Modified） 描叙缺陷被修改的时间。 计划修复时间（Plan fixed Data） 描叙缺陷计划完成修复的时间。 缺陷优先级（priority） 描述缺陷的优先级。 缺陷所属项目（Project） 描述缺陷所属的工程。 是否是重现缺陷(Reproducible) 描述缺陷是否是重现缺陷。 缺陷的状态(Status) 描述缺陷的状态 缺陷所属于的模块（subject） 描述缺陷所属的模块。 缺陷详细描述（Description） 缺陷详细描述，包括缺陷产生的步骤，缺陷的实际结果，缺陷的理想结果，建议等。 缺陷实际关闭的版本（Closed in Version） 描述缺陷实际关闭的版本。 缺陷实际修复所花的时间（Actual Fixed Time） 描述缺陷实际修复所花的时间 缺陷修复完成时间（Closing Date） 描述缺陷实际关闭的时间。 注释(Comments) 描叙对缺陷的注释。 附件（Attachments） 添加缺陷附件。 缺陷优先级 * 缺陷的优先级是根据用户对缺陷修改的时间要求划分的，具体如下： 序号 优先等级 紧急程度 描述 1 P1 立即解决 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 2 P2 高优先级 缺陷严重影响测试需要优先考虑 3 P3 正常排队 缺陷需要正常排队等待修复 4 P4 低优先级 缺陷可以在开发人员有时间的时候再被纠正 缺陷严重等级定义 * 序号 严重程度 缺陷性质 定义标准 优先级 1 A类 致命缺陷 直接影响测试继续执行的错误。必须在最短时间内修复，否则测试无法继续进行。包含但不限于： 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用 3.程序实现与需求严重不符 4.其他导致无法测试的错误 5.严重的数值计算错误 6.存在致命的安全漏洞 7.Bug被重开3次及以上 立即解决 2 B类 严重缺陷 影响其他测试案例的继续执行或与功能规格严重不符的错误，以及有可能给银行造成损失和风险的错误。包含但不限于： 1.产品功能实现不正确 2.主业务流程对应的功能未实现，阻碍测试继续进行 3.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定 位； 4.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 5.程序实现与需求功能上不符 6.其他导致部分模块无法测试的错误 7.主要数值计算错误 8.严重的功能逻辑错误 9.Bug被重开2次 高优先级 3 C类 一般缺陷 影响客户服务的错误。对系统功能影响比较小的错误,在测试结束前必须修复。 如报表格式不完全正确，提示信息不对，画面布局文字有错误等 正常排队 4 D类 微小缺陷 如提示信息不准确，画面布局位置不合理 低优先级 5 E类 建议 对系统功能提出自己的见解或意见，具使其具备一定的改革和改良的条件，使其向着更加良好的、积极的方面去完善和发展。 低优先级 缺陷管理——缺陷来源 * 序号 缺陷起源 描述 1 需求 由于需求问题引起的缺陷 2 设计 由于设计问题引起的缺陷 3 编码 由于编码问题引起的缺陷 4 集成 由于集成问题引起的缺陷 5 其他 由于其他问题引起的缺陷 缺陷管理——缺陷分类 * 序号 缺陷类型 描述 子类型名称 1 功能问题 影响了重要的特性、用户界面、产品接口、硬件结构接