缺陷级别定义和优先级定义_第1页
缺陷级别定义和优先级定义_第2页
缺陷级别定义和优先级定义_第3页
缺陷级别定义和优先级定义_第4页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

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

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

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

5、dium,使用率中严重级别为High,使用率低Veryhigh严重级别为Medium,使用率局严重级别为High,使用率低或中严重级别为VeryHigh,使用率低Urgent严重级别为VeryHigh,使用率中或高严重级别为High,使用率高注:当缺陷被Reopen时,建议通过有效途径通知相关人员,特别是严重级别为high和viewhigh。3、缺陷报告规范在项目执行阶段,发现的所有问题都需要提交缺陷管理库一CQ中相应的Project库中,主要包括软件需求、开发程序缺陷、各种需要审核的文档等方面的内容;缺陷报告的填写,需要将问题的重现步骤写清晰,建议安1、2、3.形式提交,且缺陷的相关外部测试

6、条件需要说明详细,缺陷标题要简明、扼要,不要用过于笼统和模糊的语言加以描述,根据需要适当的将出现的场景、日志等信息以附件形式提交;对于缺陷的回归,应在CQ中的Comments中注明回归的版本号,并依据问题的严重级别对回归的结果做相应的描述。具体的缺陷提交流程如下(针对测试人员)在缺陷的管理中,对于新增的Rejected和Suspend的缺陷,需要定期时常整理确认,对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷,开发人员无权Rejected/Suspend,同时对于达成共识的Rejected缺陷一定要将意见写入CQ库中的comments,M于Suspend状态的缺陷,建议要注明由于什么

7、原因被刮起,在什么时间和条件下在处理等信息。在测试任务完成以后,缺陷库中的缺B1状态应只以三种状态存在:Closed、经过确认并达成共识的Rejected/Suspendo4、缺陷跟踪测试人员对其发现的缺陷有义务和责任进行全程的跟踪。从缺陷的提交一直到缺陷的关闭,在这一整套的过程中,测试人员应该一丝不苟的进行把关,不要让错误轻易的从手边遛走。要定期的向开发组通报缺陷状态,同时及时的更新缺陷库中缺陷的状态。在一定的条件和时间内,还要对以关闭的缺陷做回归测试。制定有效而可行的回归测试时间表,尽可能的减少由回归测试间隙产生的测试逃逸。5、缺陷分析对于缺陷数据库,测试人员应该经常维护更新,并对缺陷的状态,数量,分布等状态做统计分析。为开发组提供一些必要的信息。对测试人员而言,统计包括以下步骤:收集和分类缺陷信息。尝试对每个缺陷的形成原因(例如,不符合规约、设计错误、违背标准、与客户通信不利等)进行追溯。(此方面的最终定位需要与相关的开发人员进行确认。)使用Pareto规则(80%的缺陷的20%成因有可能可以追溯到),将这20%(少数重要的)分离出来。简单而言,Pareto原则暗示着测试发现的错误中的80%很可能起源与程序模块中的20%。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。一旦标出少数几个重要的原因,就可以开始纠正引起缺陷的问题。

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论