1、Defect Report书写规范,版本信息,简述,提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表,简述,提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表,提交规范性bug报告的重要性,书写不规范、难于理解的bug报告耗费时间,影响工作效率 书写好的bug报告可以让所有人理解问题所在、客户影响率以及风险度 书写好的bug报告可以辅助缺陷的修改 Bug报告是测试部门对其它部门输出的最重要的交付物,规范性bug报告特质,一致性:跟标准性模版一致 清晰:不会包含模糊、令人困惑的信息 简洁:描述用词简明 正确性:不会出现错误的描述语句 完整性:
2、不会缺失必备的bug描述 易读性:阅读起来容易理解 有辅助性的:包含辅助理解、分析问题的信息 聚焦性:指明问题的本质 测试工程师的使命:书写清晰简明的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对终端用户的影响度 配置:列出
4、bug发生时的配置或环境,简要描述-意图,使每个人都能快速浏览bug是被bug报告中被阅读最频繁的部分-管理人员、开发人员、测试人员、需求人员 有利于与其它bug作区分 就像新闻的标题一样,使问题的本质更引人注目 不用研读bug详细描述,就可以知晓问题所在 利于bug查找,简要描述-指导方针,使用一句话描述问题用词简明并且直击要点,不使用段落保持描述是简明的一句话 陈述问题放在第一位,其次才是操作 描述问题要明确避免使用“失败”、“错误”、“差的”、“不起作用”、“不正确”、“坏掉的”等词汇不包含难理解的缩词,比SUT、DEU、ENU,除非是通用的。不包含“请查看详情”之类词汇 不可包含步骤描
5、述 不可包含配置信息,除非是引发bug相关的 不要使用带主观色彩的词语,使问题听起来比实际轻微或者更严重,简要描述-举例,有待改进: (此部分会根据测试组内实践情况抽取例子,后续再添加进去。),简要描述-范例,(此部分会根据测试组内实践情况抽取例子,后续再添加进去。),建议模版,简要描述:一句话描述bug 步骤:列举导向重现问题的操作 实际结果:描述以上步骤导致的问题 期望结果:描述以上步骤下我们期望发生的现象 附加信息:能帮助开发人员debug的任何信息特性描述:描述bug的重要特征 错误恢复:描述从错误情形恢复的方法变通方案:描述避免此bug发生的方法客户影响:描述此bug对终端用户的影响
6、度 配置:列出bug发生时的配置或环境,步骤-意图,提供重现问题或者如何发现问题的系统性方法 列举导向问题的操作,建议模版,简要描述:一句话描述bug 步骤:列举导向重现问题的操作 实际结果:描述以上步骤导致的问题 期望结果:描述以上步骤下我们期望发生的现象 附加信息:能帮助开发人员debug的任何信息特性描述:描述bug的重要特征 错误恢复:描述从错误情形恢复的方法变通方案:描述避免此bug发生的方法客户影响:描述此bug对终端用户的影响度 配置:列出bug发生时的配置或环境,实际结果,意图描述步骤产生的问题 指导方针详细描述:不包含期望结果相关内容不描述操作,也不要使用“当时候”、“在期间
7、”开头,直接阐述现象用词清晰:不要使用“错误”、“差的”、“不能操作”等词语不使用难于理解的缩写词只描述一个问题:同样的操作引发多个问题,只需报一个bug不同的操作引发不同现象,需分别报bug如果不同操作引发相同问题,需跟开发人员沟通如何报这个bug。建议测试人员可以一个操作为基准报bug,然后把其它操作填写在附加信息中。如果不是很确定如何报一个bug比较好,可以通过与开发人员讨论 若截取了实际现象log或者图片,需添加描述“详细请查看附件”,实际结果-举例,有待改进: (此部分会根据测试组内实践情况抽取例子,后续再添加进去。),实际结果-范例,(此部分会根据测试组内实践情况抽取例子,后续再添
8、加进去。),建议模版,简要描述:一句话描述bug 步骤:列举导向重现问题的操作 实际结果:描述以上步骤导致的问题 期望结果:描述以上步骤下我们期望发生的现象 附加信息:能帮助开发人员debug的任何信息特性描述:描述bug的重要特征 错误恢复:描述从错误情形恢复的方法变通方案:描述避免此bug发生的方法客户影响:描述此bug对终端用户的影响度 配置:列出bug发生时的配置或环境,期望结果,意图描述期望结果或者行为 指导方针不描述操作,只描述期望现象不使用模糊的、歧义的词语 尽量使用一句话描述一个期望结果。若有多个期望结果要描述,可以使用列举方式,期望结果-范例,(此部分会根据测试组内实践情况抽
9、取例子,后续再添加进去。),建议模版,简要描述:一句话描述bug 步骤:列举导向重现问题的操作 实际结果:描述以上步骤导致的问题 期望结果:描述以上步骤下我们期望发生的现象 附加信息:能帮助开发人员debug的任何信息特性描述:描述bug的重要特征 错误恢复:描述从错误情形恢复的方法变通方案:描述避免此bug发生的方法客户影响:描述此bug对终端用户的影响度 配置:列出bug发生时的配置或环境,附加信息-意图,提供支撑信息特性用户影响度测试影响度变通方案错误恢复 附加信息用来辅助进一步理解问题所在、客户影响度和bug引起的风险,也有可能包含bug相关的其它需同步解决的问题。,附加信息-指导方针
10、,使用列举,使阅读更方便尽量写成段落 如果问题不明显,可以解释为什么定义成bug有必要的话,填写参考文档信息 描述问题为什么需要被解决对客户的影响度或者存在的风险 如果有的话,描述跳过问题的变通方案 描述错误发生的恢复方法 提供利于描述问题所在的附件输出产物、截屏、测试报告,附加信息-指导方针,量化问题发生的概率比如:10次中发生7次尝试重现每个问题至少三次 描述你可能掌握的任何特征信息问题在其它机器上发生问题在之前的产品上面的同样功能模块也发生问题在之前的版本上也发生有类似的bug解决方案可以参考是否在其它的配置环境中重现过这个问题是否尝试过减少步骤数量是否尝试其它步骤并发现引发问题的其它条
11、件。比如:你发现问题发现在一个OS上面,在你的报告中应该包含其它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=hospital2
14、0130524;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的测试资源。比如:测试用导致
15、bug发生的特殊文档。,截图-指导方针,格式:最好是.jpg格式如果截图被保存为.bmp格式,不要直接更改后缀为.jpg。请使用作图工具白转换图片格式,比如: 微软画图、ADB See、PS等 内容:截取必须区域。不包括非必须的截图边框。最好能用红色字体表明出错区域,并且添加清晰描述。批注必须使用亮丽的颜色,通常也是使用红色字体。把实际结果和期望结果摆放在一起,利于作对比。如果bug是因为一系列操作导致,可以把截图放在一张图片中如果是描述有误,需提供建议的描述。 命名:设定与问题相关的命名,比如领购_提交用品需求单_失败.jpg。避免使用模糊的命名,比如:图片1.jpg或者图片2.jpg。,截图-范例,实训,课题1:基本信息中,患者信息模块,新增患者信息,在手机选项输入手机号码时,提示信息显示不合乎用户逻辑。范例:,简述,提交规范性bug报告的重要性 Bug书写规范 Bug附件 实训 Bug填写表,Bug填写表,注:以下暂时只是初稿,后期会更新。,问题解答环节,实践出真知,Thank You!,