(缺陷编写规范V11.docxVIP

缺陷编写规范一、目的统一缺陷编写的规范，为了测试工程师提供缺陷编写的指导，提高编写的缺陷的可读性、无歧义性、可操作性。为开发工程师更好的复现缺陷，理解问题发生现象，提高效率，最终提高公司整个产品的质量。二、范围 适用于缺陷报告编写，辅助工具为Jira三、背景描述目前JIRA里提交的BUG很多表述含糊，过于简练，缺少URL、用户或密码信息造成程序员没有办法明白这个BUG的含义，也无法重现该问题，很难分析问题产生的原因，延误了BUG修改时间，同时增加了很多沟通成本，为了解决这个问题，BUG报告必须按照规范来编写。四、JIRA中提交BUG的规范每个bug状态表示的具体含义说明如下：状态描述OpenBug已经确认，等待被处理In　ProgressBug正在处理中ResolvedBug已处理，待确认Closed 确认被修复的Bug，如果已修复，置为此状态Reopen确认被修复的Bug，如果没修复，置为此状态已处理，待确认状态中，处理结果又包含(fixed,won’t fix,duplicate,incomplete,cannot reproduce,Work as Design)分别对应(修改完成，不需要修改，重复提交的bug，描述不完整，不能复现，按设计来实现的不需要修改各状态);不需要修改和推迟修改的状态时请开发或相关人员加备注说明下原因,修改完成的bug需要开发人员写上问题产生原因.优先级别的定义和举例说明5级：致命缺陷修复优先级:阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试;例如：导致系统崩溃、死机、死循环、数据丢失、计算错误、安装错误;播放黑屏、flash崩溃、程序崩溃、数据库崩溃、服务器不能访问或崩溃；需求中的功能未实现；产品logo和其他影响品牌形象的界面错误；占有率比较大的浏览器页面严重错位；404、500错误报黄页(即指向未知页面错误页)等；4级：严重功能缺陷修复优先级:必须修改,且在短时间内必须修复.例如：开发实现的功能跟产品确认的功能不一致；业务流程处理不正确；占有率比较大的浏览器样式问题，主要的一级功能有bug，如登录、退出，正常播放、主页和二级分类页不能正常访问；播放窗口错位、面板错位、面板打开无法关闭等；3级：主要缺陷修复优先级:必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正(如第一轮测试结束前或上线前)例如：查询结果不正确、有调试信息、前后端未进行数据校验、数据长度不一致、翻页错误等；2级：次要缺陷, 错误是表面化或微小的, 对功能几乎没有影响，产品及属性仍可使用；修复优先级:如果时间允许应该修改,指明修复日期或版本例如：提示信息不太准确友好、错别字、UI 布局或罕见故障等，应该本页打开却打开新窗口； 1级：建设性的意见或建议修复优先级:允许不修改例如:网友使用不便;没有给出用户友好提示等五、缺陷报告编写原则可理解缺陷可理解指的是：尽量用短句客观的描述缺陷，避免使用修饰性的词汇和复杂句型。检查拼写和语法错误，保证缺陷描述无错别字附加图片说明，必要的时候附加截屏、录屏文件，减少和开发的沟通时间唯一性每一个缺陷报告只包括一个问题，同一个功能点出现两个缺陷，应提两条缺陷报告，多个的以此类推。同一个问题出现在多个功能点时，只提交一个缺陷报告，列出其他出问题的位置可操作缺陷复现步骤完整，准确，简短，有条理，每个步骤尽量只记录一个操作；六、缺陷报告编写的要素及规范　１．项目与问题类型项目不要选错了， 要看清楚；问题类型选为defect.　这里需要说明的就是，不能把所有问题都默认选为defect，defect一般都会认为是程序员的问题，但实际情况中，很多并非程序员的原因引起的问题，如果都归咎于程序员，会打消程序员修改问题的积极性。　　　２．缺陷标题必填项格式为：页面和功能定位+问题现象例如：“搜狐付费视频后台：商品管理：新建单集商品：点保存按钮报错”　　４．优先级　根据严重程度和对用户的影响选择优先级：致命缺陷选择紧急，严重功能缺陷选择高，其他程度根据经验选择　 ５．模块的选择问题或需求属于哪个模块 就选哪个模块， 如果不清楚的话， 就选“其他”影响版本和修复版本　影响版本是指在哪个版本出现的问题，修复的版本是需要在哪个版本里解决该问题。这里修复版本比较重要，一般会作为统计比如这个版本一共有多少个问题，所以要选对版本。经办人＆抄送人通常如果你知道这个模块是谁开发的就选这个人为任务接收人，可以抄送给他的领导或者对应的产品负责人；如果你不是很清楚这个模块是谁编写的，一般可以指定该项目组的技术负责人。尽量不要使用“自动”， 自动会分配给项目总负责人，他可能很忙，没时间看BUG，就会延误Bug的分配。测试环境的填写由于不同的浏览器会对页面进行不同的解析，所以必须要写明发现问