Defect Report书写规范

版本信息
简述
提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表
简述
提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表
提交规范性bug报告的重要性
书写不规范、难于理解的bug报告耗费时间，影响工作效率 书写好的bug报告可以让所有人理解问题所在、客户影响率以及风险度 书写好的bug报告可以辅助缺陷的修改 Bug报告是测试部门对其它部门输出的最重要的交付物
规范性bug报告特质
一致性：跟标准性模版一致 清晰：不会包含模糊、令人困惑的信息 简洁：描述用词简明 正确性：不会出现错误的描述语句 完整性：不会缺失必备的bug描述 易读性：阅读起来容易理解 有辅助性的：包含辅助理解、分析问题的信息 聚焦性：指明问题的本质 测试工程师的使命：书写清晰简明的bug报告 “The best tester isn’t the one who finds the most bugs…The best tester is the one who gets the most bugs fixed…”-Cem Kaner
简述
提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表
建议模版
简要描述：一句话描述bug 步骤：列举导向重现问题的操作 实际结果：描述以上步骤导致的问题 期望结果：描述以上步骤下我们期望发生的现象 附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度 配置：列出bug发生时的配置或环境
建议模版
简要描述：一句话描述bug 步骤：列举导向重现问题的操作 实际结果：描述以上步骤导致的问题 期望结果：描述以上步骤下我们期望发生的现象 附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度 配置：列出bug发生时的配置或环境
简要描述-意图
使每个人都能快速浏览bug 是被bug报告中被阅读最频繁的部分 -管理人员、开发人员、测试人员、需求人员 有利于与其它bug作区分 就像新闻的标题一样，使问题的本质更引人注目 不用研读bug详细描述，就可以知晓问题所在 利于bug查找
简要描述-指导方针
使用一句话描述问题 用词简明并且直击要点，不使用段落 保持描述是简明的一句话 陈述问题放在第一位，其次才是操作 描述问题要明确 避免使用“失败”、“错误”、“差的”、“不起作用”、“不正确”、“坏掉的”等词汇 不包含难理解的缩词，比SUT、DEU、ENU，除非是通用的。 不包含“请查看详情”之类词汇 不可包含步骤描述 不可包含配置信息，除非是引发bug相关的 不要使用带主观色彩的词语，使问题听起来比实际轻微或者更严重