软件缺陷报告.ppt

,单击,acd,ac,单击此处编辑母版文本样式,ABC,第二级,第三级,*,公司内部培训教材,2005,年,5,月,培 养 超 一 流 工 作 精 英 打 造 世 界 级 卓 越 企 业,软件缺陷报告,分享目录,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,（简洁）：只包含必不可少的信息，不包括任何多余的内容；,Complete,（完整）：包含复现该缺陷的完整步骤和其他本质信息；,Consistent,（一致）：按照一致的格式书写全部缺陷报告。,2.3,怎样有效记录缺陷,保证缺陷重现,分析故障,使用最少步骤复现故障,包含所有重现缺陷的必要步骤,方便阅读,尽量简单,一个缺陷一个报告,注意自己的语气,报告随机缺陷,不夸大缺陷,报告小缺陷,及时报告缺陷,引用别人报告不要擅自修改,缺陷报告中注明姓名和日期,2.4,缺陷报告的产生过程,组织,-,重现,-,隔离,-,归纳,-,对比,-,总结,-,精简,-,消除歧义,-,中立,-,检查,组织,Structure,：,测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方在哪；,重现,Reproduce,：,测试人员在编写,bug report,之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写,bug report,之前反复尝试,3,次；,隔离,Isolate,：,在尝试编写,bug report,之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能会改变错误的症状。这些信息可以为开发人员着手调试提供思路；,归纳,Generalize,：,在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题,;,对比,Compare,：,如果测试人员验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果；,总结,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,内容一致。,书写摘要的例子,原始描述,错误原因,改进的标题,英文单词的连字符不管用,描述太笼统。什么时候不起作用？,在行末尾换行时，不能根据英文单词长度设置连字符。,段落调整出现错误状态,描述太笼统。不正确的行为是什么？,选定两个单词，启动单词,“,字间距,”,自动调整后间隔排版错误。,警告：该命令产生了错误的结果。,没有包含原因与结果信息。描述内容太长。,更新位图图像保存到服务器时，警告：,“,错误,”,。,在鼠标点击执行每一个拷贝或复制的编辑功能之后，响应时间很长。,没有指明原因与结果，包含了过分详细的细节信息。,拷贝和复制功能执行效率低。,插入的引号成为特殊符号。,信息没有充分隔离。所有的引号都如此吗？什么类型的引号。,在文档中插入一个智能引号成为不可识别的字符串。,