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