您好,欢迎访问三七文档
第6章测试报告和测试评测•软件缺陷•测试总结6.1软件缺陷的概念•什么是缺陷–缺陷既指程序中存在的错误–缺陷也指可能出现在设计中,甚至在需求、规格说明或其他的文档中的种种错误3/52•软件缺陷(Defect或Bug)是软件开发过程中的副产品“–缺陷会导致软件产品在某种程度上不能满足用户的需要–软件缺陷是对软件产品预期属性的偏离现象。包括检测缺陷和残留缺陷4/52•软件缺陷定义–软件缺陷就是存在于软件(文档、数据、程序)之中的那些不希望,或不可接受的偏差,而导致软件产生的质量问题软件缺陷产生的原因•导致软件产生缺陷的九类原因①需求的不完善定义②客户——开发者通信失败③对软件需求的故意偏离④逻辑设计错误⑤编码错误⑥不符合文档编制与编码规定⑦测试过程不足⑧规程错误⑨文档编制错误6/52很难找出缺陷的原因?7/52软件缺陷跟踪管理•缺陷跟踪管理是测试工作的一个重要部分8/52软件缺陷跟踪管理•缺陷跟踪管理的目标•确保每个被发现的缺陷都能够被解决•收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段•收集缺陷数据并进行数据分析,作为组织的过程财富9/52软件缺陷的有效简述规则•单一准则•可以再现•完整统一•短小简练•特定条件•补充完善•不做评价缺陷的属性•缺陷标识•缺陷类型•缺陷严重程度•缺陷优先级•缺陷状态•缺陷起源•缺陷来源•缺陷根源11/52•缺陷严重程度致命严重一般较小12/52•缺陷优先级1.立即解决2.高优先级3.正常排队4.低优先级13/526.2分离和再现软件缺陷确保所有的步骤都被记录。特定条件和时间。压力和负荷、内存和数据溢出相关的边界条件。考虑资源依赖性包括内存、网络和硬件共享的相互作用等。不能忽视硬件。与软件不同,硬件不按预定方式工作。和开发人员紧密合作6.3正确面对软件缺陷•原则:•并不是所有缺陷都要修复•发现缺陷的数量与软件质量无关6.4软件缺陷的生命周期及处理技巧•软件缺陷的生命周期发现打开修复关闭软件缺陷处理技巧审阅。拒绝。完善。分配。验证。重新打开。关闭。暂缓。报告软件缺陷的基本原则•尽快•有效•专一•不做评价•补充完善缺陷报告优秀的缺陷报告重现步骤:a)打开一个编辑文字的软件并且创建一个新的文档(这个文件可以录入文字)b)在这个文件里随意录入一两行文字c)选中一两行文字,通过选择Font菜单然后选择Arial字体格式d)一两行文字变成了无意义的乱字符期望结果:当用户选择已录入的文字并改变文字格式的时候,文本应该显示正确的文字格式不会出现乱字符显示。实际结果:它是字体格式的问题,如果改变文字格式成Arial之前,你保存文件,缺陷不会出现。缺陷仅仅发生在Windows98并且改变文字格式成其它的字体格式,文字是显示正常的。见所附的图片有一个链接,点击即可看到散漫的缺陷报告的示例重现步骤:•在Window98上打开一个编辑文字的软件并且编辑存在文件•文件字体显示正常•我添加了图片,这些图片显示正常•在此之后,我创建了一个新的文档•在这个文档中我随意录入了大量的文字•在我录入这些文字之后,选择几行文字.并且通过选择Font菜单然后选择Arial字体格式改变文字的字体。•有三次我重现了这个缺陷•我在Solaris操作系统运行这些步骤,没有任何问题。•我在Mac操作系统运行这些步骤,没有任何问题。期望结果:当用户选择已录入的文字并改变文字格式的时候,文本应该显示正确的文字格式不会出现乱字符显示。实际结果:我试着选择少量的不同的字体格式,但是只有Arial字体格式有软件缺陷,不论如何,它可能会出现在我没有测试的其它的字体格式6.6软件缺陷跟踪管理•缺陷管理的基本流程–对缺陷进行管理需要:1.对缺陷进行描述2.对缺陷进行分类A.通过对缺陷进行分类,可以迅速找出哪一类缺陷的问题最大B.然后集中精力预防和排除这一类缺陷C.而这正是缺陷管理的关键,一旦这几类缺陷得到控制,再进一步找到新的容易引起问题的几类缺陷上21/52缺陷的描述•可追踪信息——缺陷ID(唯一的缺陷ID,可以根据该ID追踪缺陷)•缺陷基本信息–缺陷标题—描述缺陷的标题–缺陷的严重程度—描述缺陷的严重程度,一般分为“致命”、“严重”、“一般”、“建议”四种–缺陷的紧急程度—描述缺陷的紧急程度,从1-4,1是优先级最高的等级,4是优先级最低的等级–缺陷提交人—缺陷提交人的名字(邮件地址)–缺陷提交时间—缺陷提交的时间–缺陷所属项目/模块—缺陷所属的项目和模块,最好能较精确的定位至模块22/52缺陷的描述(续)•缺陷基本信息(续)–缺陷指定解决人—缺陷指定的解决人,在缺陷“提交”状态为空,在缺陷“分发”状态下由项目经理指定相关开发人员修改–缺陷指定解决时间—项目经理指定的开发人员修改此缺陷的deadline–缺陷处理人—最终处理缺陷的处理人–缺陷处理结果描述—对处理结果的描述,如果对代码进行了修改,要求在此处体现出修改–缺陷处理时间—缺陷处理的时间–缺陷验证人—对被处理缺陷验证的验证人–缺陷验证结果描述—对验证结果的描述(通过、不通过)–缺陷验证时间—对缺陷验证的时间23/52缺陷的描述(续)•缺陷的详细描述——对缺陷的详细描述–对缺陷描述的详细程度直接影响开发人员对缺陷的修改,描述应该尽可能详细•测试环境说明——对测试环境的描述•必要的附件——对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的•从统计的角度出发,还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目24/52缺陷管理流程•了解缺陷–必须首先收集缺陷数据,然后才能了解这些缺陷,并且找出如何预防它们,同时也能领会到如何更好地发现,修复甚至预防仍在引入的缺陷–可以按照以下步骤收集关于缺陷的数据•为测试和同行评审中发现的每一个缺陷做一个记录•对每个缺陷要记录足够详细的信息,以便以后能更好地了解这个缺陷•分析这些数据以找出哪些缺陷类型引起大部分的问题•设计出发现和修复这些缺陷的方法(缺陷排除)25/52缺陷管理流程(续)26/52缺陷管理流程(续)•缺陷管理流程中的各种角色–测试人员:进行测试的人员,缺陷的发现者–项目经理:对整个项目负责,对产品质量负责的人员–开发人员:执行开发任务的人员,完成实际的设计和编码工作–评审委员会:对缺陷进行最终确认,在项目成员对缺陷达不成一致意见时,行使仲裁权力•缺陷所处的状态–初始化:缺陷的初始状态–待分配:缺陷等待分配给相关开发人员处理–待修正:缺陷等待开发人员修正–待验证:开发人员已完成修正,等待测试人员验证–待评审:开发人员拒绝修改缺陷,需要评审委员会评审–关闭:缺陷已被处理完成27/52缺陷管理流程(续)•软件缺陷流程管理的要点–为了保证错误的正确性,需要:•有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误•测试步骤是否准确、简洁、可以重复–软件错误的确认并不总是轻而易举的事情•由于对软件设计具体要求的不了解,对测试报告的个别软件错误,可能无法确认是否属于真正的软件错误,本地化服务商需要与软件供应商交流并确认–每次对错误的处理都要保留处理信息•包括处理者姓名,时间,处理方法,处理步骤,错误状态,处理注释等–对错误的拒绝不能由程序员单方面决定•应该由项目经理,测试经理和设计经理共同决定–对错误延期处理不能由本地户服务商决定•应该由软件供应商决定–错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭28/5229/52缺陷度量与分析•在软件开发过程中实施缺陷的度量与分析对于提高软件开发和测试效率,预防缺陷发生,保证软件产品质量有着十分重要的作用•软件缺陷度量–缺陷度量是对项目过程中产生的缺陷数据进行采集和量化,将分散的缺陷数据统一管理,使其有序而清晰•通过采用一系列数学函数,对数据进行处理,分析缺陷密度和趋势等信息,从而提高产品质量和改进开发过程–缺陷度量是软件质量度量的重要组成部分,它和软件测试密切相关•尽管缺陷度量本身并不能发现缺陷、剔除缺陷,但是有助于这些问题的解决–软件缺陷度量的方法较多,从简单的缺陷计数到严格的统计建模,主要有•缺陷密度(软件缺陷在规模上的分布)•缺陷率(缺陷在时间上的分布)、预期缺陷发现率•整体缺陷清除率、阶段性缺陷清除率•缺陷趋势等等30/52缺陷度量与分析(续)•软件缺陷分析–将软件开发各个阶段产生的缺陷信息进行分类和汇总统计,计算分析指标,编写分析报告的活动•发现各种类型缺陷发生的概率,掌握缺陷集中的区域、明确缺陷发展趋势、挖掘缺陷产生的根本原因,便于有针对性地提出遏制缺陷发生的措施、降低缺陷数量•缺陷分析报告中的统计数据及分析指标既是对当前软件质量状况的评估,也是判定软件是否能按期发布或交付使用的重要依据•分析的前提是需要一个符合项目要求的缺陷数据管理系统,通过采集完整的缺陷数据信息,进行缺陷数据分析,来改进软件过程质量并实施缺陷预防措施–用来评估当前软件的可靠性,并且预测软件产品可靠性变化,缺陷分析在软件可靠性评估中占有相当大的作用31/52缺陷度量与分析(续)•软件缺陷分析(续)–通过缺陷分析达到缺陷预防的目的(缺陷管理的核心任务之一)•缺陷预防的着眼点在于寻找缺陷的共性原因•通过寻找、分析和处理缺陷的共性原因,实现缺陷预防•缺陷预防并不是一个不切实际的目标,测试人员在开发过程中应该积极为开发小组提供缺陷分析,就有可能降低缺陷产生的数量。•缺陷管理的最终目标是预防缺陷,不断提高整个开发团队的技能和实践经验–缺陷预防策略•测试活动尽量提前,通过及时消除开发前期阶段引入的缺陷,防止这些缺陷遗留并放大到后续环节•通过对已有缺陷进行分析,找出产生这些缺陷的技术上不足和流程上不足(缺陷的根源),然后寻找一个方法来对这些不足进行改进,预防类似的缺陷在将来出现32/52缺陷度量与分析(续)•软件缺陷分析(续)–缺陷分析步骤1.记录缺陷(记录缺陷不应该满足于记录缺陷的表面症状)2.进行缺陷分类,找出那些关键的缺陷类型,进一步分析其产生的根源,针对性地制定改进措施3.进行缺陷预防分析,它是整个缺陷分析过程的核心4.编写缺陷分析报告,绘制缺陷分析图–缺陷分析报告中的统计数据及分析指标既是对软件质量的权威评估,也是确定测试是否达到结束标准、判定测试是否已达到客户可接受状态和判定软件是否能发布或交付使用的重要依据–缺陷分析图表会告诉我们很多有价值的信息。比如说,可分析开发和测试在人力资源的配比上是否恰当,可以分析出某个严重的缺陷所造成的项目质量的波动–缺陷分析方法•ODC缺陷分析、Gompertz分析、Rayleigh分析、根本原因分析、缺陷注入分析、四象限分析、DRE/DRM分析缺陷跟踪系统•特别适用于大型软件测试项目集中管理测试缺陷的要求–这些测试项目一般测试周期长,测试范围广,存在较多软件缺陷–便于添加、修改、排序、查找、存储和跟踪软件测试错误•对于大型软件的测试,报告的错误可能成百上千个–便于跟踪和监控错误的处理过程和方法•方便地检查处理方法是否正确•确定处理者的姓名和处理时间,作为工作质量的统计和考核的参考–便于集中管理,提高效率•软件开发商、服务商和软件供应商共享同一个错误跟踪系统数据库,各自负责处理己方需要处理的软件错误•对于需要对方提供更多信息的错误,可以通过改变错误的当前信息(状态、处理者、处理建议等),使对方尽快处理–安全性高,通过权限设置,不同权限的用户能执行不同的操作,保证只有适当的人员才能执行正确的处理–保证处理顺序的正确性,根据当前错误状态,决定当前错误处理方法–便于项目结束后的存档33/52软件缺陷报告•软件问题或缺陷报告是软件测试过程中最重要的文档–它记录了缺陷发生的环境,如各种资源的配置情况,缺陷的再现步骤以及缺陷性质的说明–更重要的是它还记录着缺陷的处理过程和状态–缺陷的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程34/52软件缺陷报告(续)•在软件测试过程中,每发现一个软件错误都要记录该错误的特征和复现步骤等信息–以便分析、处理和管理测试发现的软件错误•通常要采用软件缺陷数据库•将每一个发现的错误输入到软件缺陷数据库中•
本文标题:6软件缺陷管理
链接地址:https://www.777doc.com/doc-3755190 .html