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