缺陷编写规范V11.docx

缺陷编写规范一、目的统一缺陷编写的规范，为了测试工程师提供缺陷编写的指导，提高编写的缺陷的可读性、无歧义性、可操作性。为开发工程师更好的复现缺陷，理解问题发生现象，提高效率，最终提高公司整个产品的质量。二、范围 适用于缺陷报告编写，辅助工具为Jira三、背景描述目前JIRA里提交的BUG很多表述含糊，过于简练，缺少URL、用户或密码信息造成程序员没有办法明白这个BUG的含义，也无法重现该问题，很难分析问题产生的原因，延误了BUG修改时间，同时增加了很多沟通成本，为了解决这个问题，BUG报告必须按照规范来编写。四、JIRA中提交BUG的规范 每个bug状态表示的具体含义说明如下：状态描述OpenBug已经确认，等待被处理InProgressBug正在处理中ResolvedBug已处理，待确认Closed 确认被修复的Bug，如果已修复，置为此状态Reopen确认被修复的Bug，如果没修复，置为此状态已处理，待确认状态中，处理结果又包含(fixed,wont fix,duplicate,incomplete,cannot reproduce,Work as Design)分别对应(修改完成，不需要修改，重复提交的bug，描述不完整，不能复现，按设计来实现的不需要修改各状态);不需要修改和推迟修改的状态时请开发或相关人员加备注说明下原因,修改完成的bug需要开发人员写上问题产生原因. 优先级别的定义和举例说明 5级：致命缺陷 修复优先级: 阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试;例如：导致系统崩溃、死机、死循环、数据丢失、计算错误、安装错误;播放黑屏、flash崩溃、程序崩溃、数据库崩溃、服务器不能访问或崩溃；需求中的功能未实现；产品logo和其他影响品牌形象的界面错误；占有率比较大的浏览器页面严重错位；404、500错误&报黄页(即指向未知页面错误页)等； 4级：严重功能缺陷 修复优先级: 必须修改,且在短时间内必须修复.例如：开发实现的功能跟产品确认的功能不一致；业务流程处理不正确；占有率比较大的浏览器样式问题，主要的一级功能有bug，如登录、退出，正常播放、主页和二级分类页不能正常访问；播放窗口错位、面板错位、面板打开无法关闭等； 3级：主要缺陷 修复优先级: 必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正(如第一轮测试结束前或上线前)例如：查询结果不正确、有调试信息、前后端未进行数据校验、数据长度不一致、翻页错误等； 2级：次要缺陷, 错误是表面化或微小的, 对功能几乎没有影响，产品及属性仍可使用； 修复优先级: 如果时间允许应该修改,指明修复日期或版本例如：提示信息不太准确友好、错别字、UI 布局或罕见故障等，应该本页打开却打开新窗口； 1级：建设性的意见或建议 修复优先级: 允许不修改例如:网友使用不便;没有给出用户友好提示等五、缺陷报告编写原则1.1 可理解缺陷可理解指的是：尽量用短句客观的描述缺陷，避免使用修饰性的词汇和复杂句型。检查拼写和语法错误，保证缺陷描述无错别字附加图片说明，必要的时候附加截屏、录屏文件，减少和开发的沟通时间1.2 唯一性每一个缺陷报告只包括一个问题，同一个功能点出现两个缺陷，应提两条缺陷报告，多个的以此类推。同一个问题出现在多个功能点时，只提交一个缺陷报告，列出其他出问题的位置1.3 可操作缺陷复现步骤完整，准确，简短，有条理，每个步骤尽量只记录一个操作；六、缺陷报告编写的要素及规范项目与问题类型项目不要选错了， 要看清楚；问题类型选为defect.这里需要说明的就是，不能把所有问题都默认选为defect，defect一般都会认为是程序员的问题，但实际情况中，很多并非程序员的原因引起的问题，如果都归咎于程序员，会打消程序员修改问题的积极性。缺陷标题必填项格式为：页面和功能定位+问题现象例如：“搜狐付费视频后台：商品管理：新建单集商品：点保存按钮报错”优先级根据严重程度和对用户的影响选择优先级：致命缺陷选择紧急，严重功能缺陷选择高，其他程度根据经验选择 模块的选择问题或需求属于哪个模块 就选哪个模块， 如果不清楚的话， 就选“其他” 影响版本和修复版本影响版本是指在哪个版本出现的问题，修复的版本是需要在哪个版本里解决该问题。这里修复版本比较重要，一般会作为统计比如这个版本一共有多少个问题，所以要选对版本。 经办人抄送人通常如果你知道这个模块是谁开发的就选这个人为任务接收人，可以抄送给他的领导或者对应的产品负责人；如果你不是很清楚这个模块是谁编写的，一般可以指定该项目组的技术负责人。尽量不要使用“自动”， 自动会分配给项目总负责人，他可能很忙，没时间看BUG，就会延误Bug的分配。 测试环境的填写由于不同的浏览器会对页面进行不同的解析，所以必须要写明发现问题时候所用的浏览器，要写具体的版本， 比如是IE9 ，还是FF8 ， 不能笼统地写firefox或者IE，否则别人就不能快速地再现问题。必要的时候需要写上测试环境，测试环境或者回测环境和绑定的hosts. 描述的填写描述是缺陷报告的核心，必须填写清楚，它必须包含如下信息：l URL：出现问题的url地址；l 输入数据以及前提条件：所使用得用户和密码以及其他信息；l 复现步骤：包含如何使别人能够很容易的复现出该缺陷的完整步骤；l 实际结果：执行后出现的实际的有问题的结果l 预期结果：需求或者设计中的预期的正确的结果复现步骤要完整、准确、简短。具体含义如下： 不要遗漏任何操作步骤 每个步骤都是准确无误的 没有任何多余的步骤实际结果的描述很像缺陷的概要，可以说是概要的再次强调，要列出具体的表现行为，而不是简单地指出“某某不正确”、“某某不起作用”或“某某不好使用”。由于Bug分布的特点，有些时候，一个动作会产生不同的多个缺陷结果，则这些结果应该使用数字列表分割开来；有些时候，一个动作将产生一个结果，而这个结果又产生另一个结果，这种情况要尽可能地将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。缺陷描述举例：定位：付费商城前台：我的订单步骤1. 使用登录2. 点击我的订单问题描述在我的订单中报错误代码url /web/order/orderList.do预期结果：实际结果：其他具有相同问题的页面或控件XX页面备注我的修改建议或注解a) 附件附件包括截图、测试用的导入导出文件、系统日志等等截图要求：必须圈出有问题的地方例如：七、线上bug提交管理流程发现线上问题后,提交bug给对应的项目测试负责人，项目测试负责人将bug提给相应的开发主管并抄送给对应的产品负责人。附录:一、缺陷报告编写的细节与技巧1.每个缺陷报告只书写一个缺陷或错误 这样可以每次只处理一个确定的错误，定位明确，提高效率，也便于修复错误后方便的进行验证。2.对错误的描述要做到简洁、准确、完整，揭示错误实质 描述要准确反映缺陷或错误的本质内容，简短明了。为了便于在缺陷跟踪工具中寻找，包含错误发生时的用户界面是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。3. 明确指明错误类型和严重程度 根据错误的现象，总结判断错误的类型和严重程度，例如，是功能错误？还是界面布局错误？该错误是属于特别严重的错误还是一般错误？是否影响软件的后续开发和发布？4. 每一个步骤尽量只记录一个操作 简洁、条理井然，容易重复操作步骤，以便确认、修复、验证该错误。 5. 复现的操作步骤要完整，准确，简短 保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。6. 附加必要的缺陷特征图像（Snagit抓图工具或者FSCapture等等） 为了直观的观察缺陷或错误现象，通常需要附加错误出现的界面，作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。7. 必要时附加相关的测试用例如果打开某个特殊的测试用例而产生的错误，则必须附加该测试用例，从而可以迅速再