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