1、Defect Report书写规范,版本信息,简述,提交规范性bug报告的重要性Bug书写规范Bug附件实训Bug填写表,简述,提交规范性bug报告的重要性Bug书写规范Bug附件实训Bug填写表,提交规范性bug报告的重要性,书写不规范、难于理解的bug报告耗费时间，影响工作效率书写好的bug报告可以让所有人理解问题所在、客户影响率以及风险度书写好的bug报告可以辅助缺陷的修改Bug报告是测试部门对其它部门输出的最重要的交付物,规范性bug报告特质,一致性：跟标准性模版一致清晰：不会包含模糊、令人困惑的信息简洁：描述用词简明正确性：不会出现错误的描述语句完整性：不会缺失必备的bug描述易读性
2、：阅读起来容易理解有辅助性的：包含辅助理解、分析问题的信息聚焦性：指明问题的本质测试工程师的使命：书写清晰简明的bug报告“The best tester isnt the one who finds the most bugsThe best tester is the one who gets the most bugs fixed”-Cem Kaner,简述,提交规范性bug报告的重要性Bug书写规范Bug附件实训Bug填写表,建议模版,简要描述：一句话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员
3、debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,建议模版,简要描述：一句话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,简要描述-意图,使每个人都能快
4、速浏览bug 是被bug报告中被阅读最频繁的部分 -管理人员、开发人员、测试人员、需求人员有利于与其它bug作区分就像新闻的标题一样，使问题的本质更引人注目不用研读bug详细描述，就可以知晓问题所在利于bug查找,简要描述-指导方针,使用一句话描述问题 用词简明并且直击要点，不使用段落 保持描述是简明的一句话陈述问题放在第一位，其次才是操作描述问题要明确 避免使用“失败”、“错误”、“差的”、“不起作用”、“不正确”、“坏掉的”等词汇 不包含难理解的缩词，比SUT、DEU、ENU，除非是通用的。 不包含“请查看详情”之类词汇不可包含步骤描述不可包含配置信息，除非是引发bug相关的不要使用带主观
5、色彩的词语，使问题听起来比实际轻微或者更严重,简要描述-举例,有待改进：（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,简要描述-范例,（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,建议模版,简要描述：一句话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,步骤-意图,提供重现问题或
6、者如何发现问题的系统性方法列举导向问题的操作,建议模版,简要描述：一句话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,实际结果,意图 描述步骤产生的问题指导方针 详细描述： 不包含期望结果相关内容 不描述操作，也不要使用“当时候”、“在期间”开头，直接阐述现象 用词清晰： 不要使用“错误”、“差的”、“不
7、能操作”等词语 不使用难于理解的缩写词 只描述一个问题： 同样的操作引发多个问题，只需报一个bug 不同的操作引发不同现象，需分别报bug 如果不同操作引发相同问题，需跟开发人员沟通如何报这个bug。建议测试人员可以一个操作为基准报bug，然后把其它操作填写在附加信息中。 如果不是很确定如何报一个bug比较好，可以通过与开发人员讨论 若截取了实际现象log或者图片，需添加描述“详细请查看附件”,实际结果-举例,有待改进：（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,实际结果-范例,（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,建议模版,简要描述：一句话描述bug步骤
8、：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,期望结果,意图 描述期望结果或者行为指导方针 不描述操作，只描述期望现象 不使用模糊的、歧义的词语 尽量使用一句话描述一个期望结果。若有多个期望结果要描述，可以使用列举方式,期望结果-范例,（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,建议模版,简要描述：一句
9、话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,附加信息-意图,提供支撑信息 特性 用户影响度 测试影响度 变通方案 错误恢复附加信息用来辅助进一步理解问题所在、客户影响度和bug引起的风险，也有可能包含bug相关的其它需同步解决的问题。,附加信息-指导方针,使用列举，使阅读更方便 尽量写成段落如果问题不
10、明显，可以解释为什么定义成bug 有必要的话，填写参考文档信息描述问题为什么需要被解决 对客户的影响度或者存在的风险如果有的话，描述跳过问题的变通方案描述错误发生的恢复方法提供利于描述问题所在的附件 输出产物、截屏、测试报告,附加信息-指导方针,量化问题发生的概率 比如：10次中发生7次 尝试重现每个问题至少三次描述你可能掌握的任何特征信息 问题在其它机器上发生 问题在之前的产品上面的同样功能模块也发生 问题在之前的版本上也发生 有类似的bug解决方案可以参考 是否在其它的配置环境中重现过这个问题 是否尝试过减少步骤数量 是否尝试其它步骤并发现引发问题的其它条件。比如：你发现问题发现在一个OS
11、上面，在你的报告中应该包含其它OS的情况；问题发生在最新的IE版本上，我们的bug书写内容应该包含在其它版本上面问题发现的情况 在发现问题的时候，是否有其它操作在做,附加信息-范例,需要改进： 这个问题有时发生。我的电脑是开启状态并且安装了windows。我认为它是一个很严重的问题，并且应该被马上解决。这是一个很差而且无法令人接受的设计。返厂，再从竞争对手买一个更好点的产品方能修正这个问题。我尝试过重现这个问题，但是情况不乐观，一直没找到重现的方法。得到很好书写的： 1. 以上问题10次中发生1次； 2. 这个问题发生率很低，但是一旦发生，会阻拦用户使用，客户很容易察觉到。这个问题存在退机的风
12、险； 3. 请查看附件1，附件1中的文档显示发生错误的信息； 4. 这个问题在win7上面发生，在XP上面也发生； 5. 发生这个问题时，我正在上传文档到系统。当时使用的文档，我上传上来了，请看附件2； 6. 当发生这个问题的时候，查看首页的功能依然是好的； 7. 我尝试了以下方法去重现这个问题以及重现情况如下： 8. 发生时的log信息请查看附件3； 9. 此问题期望可以保持Open状态一段时间，请项目经理将此bug保留三个或者以上版本,我将和开发工程师一块跟踪验证。若一直不发生，再请关闭。谢谢！,建议模版,简要描述：一句话描述bug步骤：列举导向重现问题的操作实际结果：描述以上步骤导致的问
13、题期望结果：描述以上步骤下我们期望发生的现象附加信息：能帮助开发人员debug的任何信息 特性描述：描述bug的重要特征 错误恢复：描述从错误情形恢复的方法 变通方案：描述避免此bug发生的方法 客户影响：描述此bug对终端用户的影响度配置：列出bug发生时的配置或环境,配置,意图 列出详细的配置环境指导方针 提供详细的测试环境信息或者重现测试环境的方法 不包含如何重现bug相关描述 相关配置信息，不限OS、语言、应用程序、PC硬件配置、软件版本,配置-范例,范例配置： 1. OS=Win7 64bit; 2. Browser=IE10; 3. SW Version=hospital20130
14、524; 4. DB Version=hospital20130524; 5. Tool=Not need; 6. Hardware=Not need; 7. Test Case=hospitaldoc.,Bug书写范例,（此部分会根据测试组内实践情况抽取例子，后续再添加进去。）,简述,提交规范性bug报告的重要性Bug书写规范Bug附件实训Bug填写表,附件-意图,附件的意图： 帮助开发重现bug包以及debug 帮助bug的解决,附件-类型,1. 截图2. Log文件3. 其它能帮助开发进行debug的特殊文件。比如：记录现象的视频。4. 重现bug的测试资源。比如：测试用导致bug发生的
15、特殊文档。,截图-指导方针,格式：最好是.jpg格式 如果截图被保存为.bmp格式，不要直接更改后缀为.jpg。请使用作图工具白转换图片格式，比如: 微软画图、ADB See、PS等内容： 截取必须区域。不包括非必须的截图边框。 最好能用红色字体表明出错区域，并且添加清晰描述。批注必须使用亮丽的颜色，通常也是使用红色字体。 把实际结果和期望结果摆放在一起，利于作对比。 如果bug是因为一系列操作导致，可以把截图放在一张图片中 如果是描述有误，需提供建议的描述。命名： 设定与问题相关的命名，比如领购_提交用品需求单_失败.jpg。避免使用模糊的命名，比如：图片1.jpg或者图片2.jpg。,截图-范例,实训,课题1：基本信息中，患者信息模块，新增患者信息，在手机选项输入手机号码时，提示信息显示不合乎用户逻辑。范例：,简述,提交规范性bug报告的重要性Bug书写规范Bug附件实训Bug填写表,Bug填写表,注：以下暂时只是初稿，后期会更新。,问题解答环节,实践出真知,Thank You!,
