缺陷划分规划.doc

缺陷划分规划 为了在各项目中后期能对各项目质量做比较全面合理的评估，本次缺陷管理过程中定义了比较充分的质量评估考察点，将缺陷进行了多角度划分，下面将各划分方法一一列出。 1.1缺陷（defect）与错误的严重级别（severity）定义 问题性质QC中级别概要描述详细描述致命性问题5-Urgent（紧急）引起系统数据错误、操作不能继续进行、死机、系统崩溃等问题；系统崩溃 造成系统宕机 应用系统停止工作 导致程序异常退出的错误4-Very High（非常高）应用程序不能正常运行\窗口打开异常\死循环\数据被破坏 资源泄露严重性明显功能性问题3-High（高）功能不能正常完成或完成有误的问题主要功能未正常实现 功能执行错误 弹出系统异常告警性问题2-Medium（中）功能完成正常，但由于非正常操作而引起系统提示警告，属于系统健壮性问题；系统容错处理异常 输入框没有按照约定进行数据约束 窗口没有按照既定规定处理 没有合理弹出应用异常处理（正常提示）建议性问题1-Low（低）不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议；界面文字拼音错误； 不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议； 1.2缺陷（defect）的状态（status）定义 优先级别描述New（新建）测试中新报告的软件缺陷Open（打开）被确认并分配给相关开发人员处理Fixed（已修复）开发人员已完成修正，等待测试人员验证Reopen（重新打开）对开发人员已修复的缺陷，经回归测试后发现问题仍然存在Rejected（已否决）拒绝修改此缺陷，但要说明拒绝理由Postponed（延迟修改）不在当前版本修复的错误，下一版修复Closed（已关闭）缺陷已被成功修复 1.3缺陷（defect）的优先级（priority）定义 优先级别描述5-Urgent（紧急）高优先级，马上响应，对于紧急需要处理的问题。一般要求2小时内必须要求开??组做出响应。4-Very High（非常高）高优先级，优先级比5级低，但是也是高优先级，需要开发组尽快给予响应，一般要求当天内必须要求开发组做出响应。3-High（高）高优先级，优先级比4级低，但是也是高优先级，需要开发组尽快给予响应，一般要求几天内开发组必须做出响应。2-Medium(中)低优先级，响应时间要求更为宽松，需要开发组在限定的时间内予以响应，比如几个星期。1-Low（低）低优先级，优先级比2级更低一些，需要开发组在限定的时间内予以响应，甚至可以不用修改，只要写清原因：如时间紧暂时不改、可以忽略等。 1.4缺陷（defect）类型定义 缺陷类型描述1-代码错误因开发人员代码实现错误引起的缺陷（如：查询结果不对）2-界面优化操作界面中图标、按钮、文字、链接等大小位置不规范，需要优化界面3-界面设计功能能正确实现，但是操作方式不优，用户时候用起来很费劲，如同类的几个功能分到几个操作界面中，使用户使用起来不好操作又不好理解4-系统设计表明此缺陷是因系统设计引起，如模块功能划分，开发架构选型5-数据库设计表明此缺陷是因数据库设计引起6-数据库与程序不一致表明此缺陷是因数据与程序实现不一致引起7-设计变更表明此缺陷是因设计已变更而不考虑编码引起8-数据错误表明此缺陷是因数据库数据有误引起的9-需求不合理表明此缺陷是因用户所提需求不合理或前后矛盾引起10-需求变更表明此缺陷是因用户需求变更而不满足现实需求引起的 缺陷提交规范 2.1 缺陷提交原则 清晰、可重现、不重复 2.2缺陷填写要求 缺陷填写要求： 概述（summary）：必填，要求简单扼要的描述缺陷的出现位置以及缺陷的特征；如：用户管理-用户维护信息：Tab键跳格功能问题： 分派到（Assigned to）:必填，新提交的问题同意分配给子系统的开发组长； 检查者（Detected by）：必填，问题提交者，默认自己； 测试版本（Detected in Version）:必填，问题最开始发现的软件版本号； 测试日期（Detected on Date）:必填，问题最开始提交的日期，默认为当天； 优先级（Priority）：必填，问题要求解决的优先级，越高表示要求开发尽快修复问题； 严重级别（severity）：必填，问题本身的严重级别，越高表示问题越严重（严重级别请以及项目问题的级别划分规则进行划分）； 状态（status）：必填，问题的状态，新提交时默认为“New”； 模块名（subject）：必填，问题属于哪个模块（细分到第一级功能