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

《缺陷级别定义和优先级定义》由会员分享，可在线阅读，更多相关《缺陷级别定义和优先级定义（5页珍藏版）》请在金锄头文库上搜索。

1、附件一：缺陷级别定义和优先级定义1、缺陷级别定义缺陷严重级别缺陷描述备注风格不统一，包括相近流程的贝面布局相异，相同 的问题点提示信息相异，但对用户的使用方法和使 用习惯不造成影响（需求中明确的风格要求除外）very low对齐方式，包括文字对齐，页面排列项一致UI需求建议，主要是关于页面的布局方式和显示格 式UI错误，包括页面的描述显示错误（和需求中描述 的信息不一致，或有明显的错误），字体错误，以及 模板的显示错误等错误定位及信息提示不准确，包括错误判断的顺序， 出错后信息提示错误（包括出现后台信息），错误出 现的光标定位设计违反用户使用习惯，影响用户的使用方法和使 用习惯部署文档描述错误

2、，增加部署难度简单的业务功能实现错误，包括默认显示内容错误，low查询列表初始查询条件错误和查询匹配错误特殊字符处理错误，包括：“； 等特殊字符页面输入限制错误，包括输入长度，输入字符限制， 特殊输入要求判断，图片上传限制错误和文件上传 限制错误等一般需求建议问题，主要是从用户使用的角度出发， 对于一些需求的边缘条件提出合理的处理方法，如， 某功能模块的查询条件设计不合理，建议增加和删 除相应的查询条件按钮设计遗漏，包括不同条件下的显示内容，提交 后按钮灰显等Medium部署文档错误，导致部署失败缺陷严重级别缺陷描述备注业务流程对应的功能未实现，但是有替代方法解决， 不影响实际的使用数据库建库

3、（或升级）脚本错误，遗失表或字段， 影响系统的正常运行存储过程不能正常执行对应的设计功能性能和压力测试中，在人数据量和并发压力人时， 系统处理缓慢、网络异常及少量数据丢失（低于 0.5%）等情况需求遗漏，造成功能设计上的缺陷，如，设计2和 2两个数计算得到4的所有方法，只设计了加，并 未设计乘JMS同步出错，主要为同步了不该同步的内容，或 同步调用时少同步了部分内容业务流程对应的功能未实现，且无替代方法页面出现编译错误或404页面性能和压力测试中，人数据量和并发压力人时，系 统停止处理或大量数据丢失（大于0.5%）配置项设计错误，无法正常配置，或配置后，测试 中出现与配置相关的错误JMS联动出

4、错，包括出现丢包，数据传输失败，数High据阻塞，处理异常等FTP传输失败数据链接未释放需求设计不合理，导致该项功能只能在有限条件下 运行，如，设计了3条路上山，但是实际只有一条 可以上与其它网兀的接口，调用或提供错误（验证到数据 库、日志和模拟器级别）正常的用户操作，导致系统崩溃Very highJMS、FTP异常停机，导致系统无法联动数据库链接异常中断2、缺陷优先级定义缺陷优先级别缺陷描述备注low 严重级别为very low,使用率低 严重级别为low,使用率低，且非主要流程使用率见 需求分析Medium 严重级别为very low,使用率中或咼 严重级别为low,使用率中 严重级别为M

5、edium，使用率为低High 严重级别为low,使用率咼 严重级别为Medium，使用率中严重级别为High，使用率低Very high 严重级别为Medium，使用率高 严重级别为High，使用率低或中 严重级别为Very High,使用率低Urgent 严重级别为Very High,使用率中或咼 严重级别为High，使用率咼注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high 和 view high。3、缺陷报告规范 在项目执行阶段，发现的所有问题都需要提交缺陷管理库 CQ 中相应的 Project 库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等

6、方 面的内容； 缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3.形式提交， 且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过 于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以 附件形式提交； 对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题 的严重级别对回归的结果做相应的描述。 具体的缺陷提交流程如下（针对测试人员）在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确 认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权 Rejected/Suspend,同时对

7、于达成共识的Rejected缺陷一定要将意见写入CQ库中的 comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间 和条件下在处理等信息。在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在:Closed、经过 确认并达成共识的Rejected/Suspend。4、缺陷跟踪测试人员对其发现的缺陷有义务和责任进行全程的跟踪。从缺陷的提交一直到 缺陷的关闭，在这一整套的过程中，测试人员应该一丝不苟的进行把关，不要让错 误轻易的从手边遛走。要定期的向开发组通报缺陷状态，同时及时的更新缺陷库中 缺陷的状态。在一定的条件和时间内，还要对以关闭的缺陷做回归测试。制定有

8、效 而可行的回归测试时间表，尽可能的减少由回归测试间隙产生的测试逃逸。5、缺陷分析对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布 等状态做统计分析。为开发组提供一些必要的信息。对测试人员而言，统计包括以下步骤： 收集和分类缺陷信息。 尝试对每个缺陷的形成原因（例如，不符合规约、设计错误、违背标准、与客 户通信不利等）进行追溯。（此方面的最终定位需要与相关的开发人员进行确 认。） 使用Pareto规则（80%的缺陷的20%成因有可能可以追溯到），将这20% （少 数重要的）分离出来。简单而言，Pareto原则暗示着测试发现的错误中的80% 很可能起源与程序模块中的20%。当然，问题在于如何孤立这些有疑点的模 块并进行彻底的测试。一旦标出少数几个重要的原因，就可以开始纠正引起缺陷的问题。（当然这一 步是测试人员辅助开发人员进行）当然以上四点中除了第一第二两点以外，更多的定位应该是开发人员去定位问 题，测试人员只需提供辅助信息。（测试人员应该尽量避免陷入程序调试工作中， 这即不高效一一肯定没有开发人员专业，也不必要的占用了紧张的测试资源）。