缺陷级别定义和优先级定义.docVIP

附件一：缺陷级别定义和优先级定义 1、缺陷级别定义 缺陷严重级别 缺陷描述 备注 very low 风格不统一，包括相近流程的页面布局相异，相同的问题点提示信息相异，但对用户的使用方法和使用习惯不造成影响（需求中明确的风格要求除外） 对齐方式，包括文字对齐，页面排列项一致 UI需求建议，主要是关于页面的布局方式和显示格式 low UI错误，包括页面的描述显示错误（和需求中描述的信息不一致，或有明显的错误），字体错误，以及模板的显示错误等 错误定位及信息提示不准确，包括错误判断的顺序，出错后信息提示错误（包括出现后台信息），错误出现的光标定位 设计违反用户使用习惯，影响用户的使用方法和使用习惯 部署文档描述错误，增加部署难度 简单的业务功能实现错误，包括默认显示内容错误，查询列表初始查询条件错误和查询匹配错误 特殊字符处理错误，包括：“‘；等特殊字符 页面输入限制错误，包括输入长度，输入字符限制，特殊输入要求判断，图片上传限制错误和文件上传限制错误等 一般需求建议问题，主要是从用户使用的角度出发，对于一些需求的边缘条件提出合理的处理方法，如，某功能模块的查询条件设计不合理，建议增加和删除相应的查询条件 按钮设计遗漏，包括不同条件下的显示内容，提交后按钮灰显等 Medium 部署文档错误，导致部署失败 业务流程对应的功能未实现，但是有替代方法解决，不影响实际的使用 数据库建库（或升级）脚本错误，遗失表或字段，影响系统的正常运行 存储过程不能正常执行对应的设计功能 性能和压力测试中，在大数据量和并发压力大时，系统处理缓慢、网络异常及少量数据丢失（低于0.5％）等情况 需求遗漏，造成功能设计上的缺陷，如，设计2和2两个数计算得到4的所有方法，只设计了加，并未设计乘 JMS同步出错，主要为同步了不该同步的内容，或同步调用时少同步了部分内容 High 业务流程对应的功能未实现，且无替代方法 页面出现编译错误或404页面 性能和压力测试中，大数据量和并发压力大时，系统停止处理或大量数据丢失（大于0.5%） 配置项设计错误，无法正常配置，或配置后，测试中出现与配置相关的错误 JMS联动出错，包括出现丢包，数据传输失败，数据阻塞，处理异常等 FTP传输失败 数据链接未释放 需求设计不合理，导致该项功能只能在有限条件下运行，如，设计了3条路上山，但是实际只有一条可以上 与其它网元的接口，调用或提供错误（验证到数据库、日志和模拟器级别） Very high 正常的用户操作，导致系统崩溃 JMS、FTP异常停机，导致系统无法联动 数据库链接异常中断 2、缺陷优先级定义 缺陷优先级别 缺陷描述 备注 low 严重级别为very low，使用率低 严重级别为low，使用率低，且非主要流程 使用率见需求分析 Medium 严重级别为very low，使用率中或高 严重级别为low，使用率中 严重级别为Medium，使用率为低 High 严重级别为low，使用率高 严重级别为Medium，使用率中 严重级别为High，使用率低 Very high 严重级别为Medium，使用率高 严重级别为High，使用率低或中 严重级别为Very High，使用率低 Urgent 严重级别为Very High，使用率中或高 严重级别为High，使用率高 注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high和view high。 3、缺陷报告规范 在项目执行阶段，发现的所有问题都需要提交缺陷管理库－CQ中相应的Project库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等方面的内容； 缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3...形式提交，且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以附件形式提交； 对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题的严重级别对回归的结果做相应的描述。 具体的缺陷提交流程如下(针对测试人员) 在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权Rejected/Suspend，同时对于达成共识的Rejected缺陷一定要将意见写入CQ库中的comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间和条件下在处理等信息。 在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在：Closed、经过确认并达成共识的Rejected/Suspend。 4、缺陷跟踪 测试人员对