软件缺陷报告-PPT

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件缺陷报告,分享目录,1、软件缺陷,1、1软件缺陷得含义,1、2软件缺陷得属性,1、3软件缺陷产生得原因,1、4软件缺陷得分布,1、5如何确认缺陷,1、6软件缺陷得读者,1、6、1读者希望从软件缺陷报告中得到得内容,2、软件缺陷报告,2、1衡量缺陷报告质量得标准,2、2软件缺陷得写作准则,2、3怎样有效记录缺陷,2、4缺陷报告得产生过程,2、5缺陷报告写作过程中注意事项,1、软件缺陷,1、1软件缺陷得含义,什么就是软件缺陷？不满足用户确定需求,简单得说就就是存在于软件(文档、数据、程序)之中得那些不希,望,或不可接受得偏差,而导致软件产生得质量问题。按照一般得定,义,只要符合下面5个规则中得一个,就叫做软件缺陷。,可称之为软件缺陷得五个规则:,软件未达到产品说明书标明得功能,软件出现了产品说明书指明不会出现得错误,软件功能超出产品说明书指明范围,软件未达到产品说明书虽未指出但应达到得目标,软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好,属性名称,描述,缺陷标识(Identifier),缺陷标识就是标记某个缺陷得一组符号。每个缺陷必须有一,个唯一得标识,缺陷类型(Type),缺陷类型就是根据缺陷得自然属性划分得缺陷种类。,缺陷严重程度,(Severity),缺陷严重程度就是指因缺陷引起得故障对软件产品得影响程,度。,缺陷优先级,(Priority),缺陷得优先级指缺陷必须被修复得紧急程度。,缺陷状态(Status),缺陷状态指缺陷通过一个跟踪修复过程得进展情况。,缺陷起源(Origin),缺陷来源指缺陷引起得故障或事件第一次被检测到得阶段。,缺陷来源(Source),缺陷来源指引起缺陷得起因,缺陷根源,(Root Cause),缺陷根源指发生错误得根本因素,1、2软件缺陷得属性,1、3软件缺陷产生得原因,工期短,任务大;,程序设计错误;,文档不完善;,需求不断变化;,沟通交流不够;,软硬件环境不完善;,软件得复杂性,1、4软件缺陷得分布(主要在于产品得描述及说明书),1、5如何确认缺陷,判断发现得问题就是否就是缺陷得方法,通过参考文档来确认缺陷,通过了解软件产品得行业背景(或参考同类典型软件)来发现缺陷,通过沟通来确认与识别缺陷,1、6缺陷报告得读者,在书写软件缺陷报告之前,需要明白谁就是缺陷报告得读者对象,知道读者最希望从缺陷报告中获得什么信息。通常,缺陷报告得直接读者就是软件开发人员与质量管理人员;,来自市场与技术支持等部门得人员,读者希望从软件缺陷报告中得到得内容,易于搜索软件测试报告得缺陷;,报告得软件缺陷进行了必要得隔离,报告得缺陷信息具体、准确;,软件开发人员希望获得缺陷得本质特征与复现步骤;,市场与技术支持等部门希望获得缺陷类型分布以及对市场与用户得影响程度,。,2、软件缺陷报告,2、1衡量缺陷报告质量得标准,对管理层来说,就是清晰明了得,特别就是在概要这一级;,对于开发部门就是有用得,主要就是给出能够让开发人员高效地调试问题得相关信息,可以使测试人员很快得将bug从“Opened”状态转变成“Closed”状态,减少从开发人员打回得差得bug report并导致测试人员返工得时间,。,大家学习辛苦了,还就是要坚持,继续保持安静,2、2软件缺陷报告得准则,Correct(准确):每个组成部分得描述准确,不会引起误解;Clear(清晰):每个组成部分得描述清晰,易于理解;Concise(简洁):只包含必不可少得信息,不包括任何多余得内容;plete(完整):包含复现该缺陷得完整步骤与其她本质信息;Consistent(一致):按照一致得格式书写全部缺陷报告。,2、3怎样有效记录缺陷,保证缺陷重现,分析故障使用最少步骤复现故障,包含所有重现缺陷得必要步骤,方便阅读,尽量简单一个缺陷一个报告,注意自己得语气,报告随机缺陷,不夸大缺陷,报告小缺陷,及时报告缺陷,引用别人报告不要擅自修改,缺陷报告中注明姓名与日期,2、4缺陷报告得产生过程,组织-重现-隔离-归纳-对比-总结-精简-消除歧义-中立-检查,组织Structure:,测试人员应该采用深思熟虑得,小心谨慎得方法执行测试,并且做详尽得记录。这样可以促使她们对测试下得系统有很好得认识。当错误发生得时候,一个有组织得测试人员能够知道最早出现问题得地方在哪;,重现Reproduce:,测试人员在编写bug report之前必须在检查问题就是否可重现。如果错误不可再重现,仍然应该写下来,但就是必须说明问题得偶然性。一个好得处理原则就就是在编写bug report之前反复尝试3次;,隔离Isolate:,在尝试编写bug report之前,必须试着隔离错误。可以采用改变一些变量得方法,如系统得配置,它可能会改变错误得症状。这些信息可以为开发人员着手调试提供思路;,归纳Generalize:,在测试人员发现了一个已隔离得,可重现得问题后,应该对问题进行归纳。同一个问题就是否出现在其她得模块或其她得地方？同一个故障就是否有更加严重得问题;,对比pare:,如果测试人员验证过现在出错得测试用例,那么她就应该检查以前得测试结果以检查相同得条件就是否通过以前得测试。如果就是得话,那么这个问题就象就是一个回归得错误。注意由于同一测试条件有可能出现在多个测试用例中,这个步骤就不仅仅只就是检查一个测试用例在以前得多个结果;,总结Summarize:,在bug report得第一行写上错误得总结就是非常关键得。测试人员要思考已发现得错误对客户有何影响。这不仅仅要求测试人员编写得报告要能够吸引读者,可以与读者沟通清晰,还要能够帮助设置错误修复得优先级别;,精简Condense:,在bug report得初稿完成后,测试人员应该反复阅读它,集中剔除那些没有关系得步骤或词语。隐含得或模糊得说明与那些由于对没有任何关系得细节或者那些在重现错误过程中不需要得步骤而消磨报告欢迎程度得无穷唠叨都不就是bug report得目标;,消除歧义Disambiguate:,测试人员在精简空话得同时或其之后随即应该再仔细检查报告就是否有会产生误解得地方。测试人员应该尽量避免使用模糊得,会产生歧义得与主观得词语。目标就是使用能够表述事实,清楚得,不会产生争执得词语;,中立Neutralize:,如同所有得错误总结一样,独立得bug report在措辞方面应该保持公正。攻击开发人员,指责潜在得错误,企图诙谐或使用挖苦将引起开发人员得憎恶,并且使注意力从“提高产品质量”这个大得目标上转移开了。谨慎得测试人员只用Bug report来描述事实;,检查Review:,一旦编写好bug report,作者应该再次阅读,确保符合缺陷报告得写作准则,然后提交至Bug管理工具中。同时,也可以在测试人员之间互相检查,完善后再提交。在允许得时间里,测试小组应该尽可能提交最好得bug report。,2、5缺陷报告写作过程中注意事项,标题应该保持简短、准确、易于理解,提供缺陷得本质信息,并且便于读者搜索查寻;,使用委婉得说法:“混乱得UI”可以被温与些改为“不正确得UI”;,避免使用:“我(I)”“您(You)”,情绪化得语言与强调符号！,“似乎”,“瞧上去可能”,认为比较幽默得内容,不确定得测试问题,清楚得列出前提条件;,“可重现得步骤”得流程应该就是合乎逻辑得;,“可重现得步骤”应该详尽。例如,如果您想用户在Microsoft Word里保存一个文件,您可以要求用户到File菜单并且点击Save子菜单项。您也可以只说“保存文件”;,如果bug就是随机出现得,只需在bug report中说一下就可以了。但就是不要忘记归档它;,写下问题可以被重现得平台;,遇到几个问题却有一样得结果,只需写一个bug report;,截屏,截屏就是验证得一种方法。在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就可以马上定位问题;,尽量使用jpg或gif得格式,而不就是bmp格式;,为了更好得传递缺陷图像得信息,图片得命名应该尽量与BUG内容一致。,