搜索
软件测试方法和技术第2版第15章报告所发现的缺陷第15章报告所发现的缺陷15.l软件缺陷的描述15.2软件缺陷相关的信息15.3软件缺陷跟踪和分析15.4软件缺陷跟踪系统15.1软件缺陷的描述15.1.1软件缺陷的生命周期15.1.2严重性和优先级15.1.3缺陷的其它属性15.1.4完整的缺陷信息15.1.5缺陷描述的基本要求15.1.6缺陷报告的示例15.1软件缺陷的描述软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。4软件缺陷是什么？软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。缺陷生命周期是各类开发人员一起参与、协同测试的过程。软件缺陷一旦发现，便进入严密监控之中，直至软件缺陷生命周期终结，这样即可保证在较短的时间内高效率地关闭所有的缺陷，缩短软件测试的进程，提高软件质量，同时减少开发、测试和维护成本。15.1.1软件缺陷的生命周期软件缺陷生命周期生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态的变化，来跟踪项目进度和软件质量。6简单、优化的缺陷生命周期新打开的，发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。已修正，打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。已关闭，修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。发现打开修复关闭复杂的软件缺陷生命周期15.1.2严重性和优先级严重性（severity）衡量缺陷对客户满意度的影响程度致命的（fatal）、严重的（critical）、一般的（major）、微小的（minor）优先级(Priority)：指缺陷被修复的紧急程度。缺陷优先级描述立即解决(P1级)缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级(P2级）缺陷严重，影响测试，需要优先考虑正常排队(P3级）缺陷需要正常排队等待修复低优先级(P4级）缺陷可以在开发人员有时间的时候被纠正。15.1.3缺陷的其它属性缺陷标识（ID）缺陷类型（type）缺陷产生可能性（frequency）缺陷来源（source）缺陷原因（rootcause）见P.327~328诸表15.1.4完整的缺陷信息前提操作步骤期望结果实际结果上述的各种缺陷属性见P.328表15-7软件缺陷报告任何一个缺陷跟踪系统的核心都是“软件缺陷报告”，一份软件缺陷报告详细信息如下表：12分类项目描述可跟踪信息缺陷ID唯一的、自动产生的缺陷ID，用于识别、跟踪、查询软件缺陷基本信息缺陷状态可分为“打开或激活的”、“已修正”、“关闭”等缺陷标题描述缺陷的最主要信息缺陷的严重程度一般分为“致命”、“严重”、“一般”、“较小”等四种程度缺陷的优先级描述处理缺陷的紧急程度，1是优先级最高的等级，2是正常的，3是优先级最低的缺陷的产生频率描述缺陷发生的可能性1%-100%缺陷提交人缺陷提交人的名字（会和邮件地址联系起来），一般就是发现缺陷的测试人员或其他人员缺陷提交时间缺陷提交的时间软件缺陷报告13软件缺陷基本信息缺陷所属项目/模块缺陷所属的项目和模块，最好能较精确的定位至模块缺陷指定解决人估计修复这个缺陷的开发人员，在缺陷状态下由开发组长指定相关的开发人员；也会自动和该开发人员的邮件地址联系起来，并自动发出邮件缺陷指定解决时间开发管理员指定的开发人员修改此缺陷的时间缺陷验证人验证缺陷是否真正被修复的测试人员；也会和邮件地址联系起来缺陷验证结果描述对验证结果的描述（通过、不通过）缺陷验证时间对缺陷验证的时间软件缺陷报告14缺陷的详细描述步骤对缺陷的操作过程，按照步骤，一步一步地描述期望的结果按照设计规格说明书或用户需求，在上述步骤之后，所期望的结果，即正确的结果实际发生的结果程序或系统实际发生的结果，即错误的结果测试环境说明测试环境对测试环境描述，包括操作系统、浏览器、网络带宽、通讯协议等必要的附件图片、Log文件对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的；对于软件崩溃现象，需要使用Soft_ICE工具去捕捉日志文件作为附件提供给开发人员。软件缺陷的详细描述软件缺陷的详细描述，如上所述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论：“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里；“期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。“实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。1515.1.5缺陷描述的基本要求单一准确可以再现完整统一短小简练特定条件补充完善不做评价15.1.6软件缺陷报告的示例一份优秀的缺陷报告记录下最少的重复步骤，不仅包括了期望结果，实际结果和必要的附件，还提供必要的数据、测试环境或条件，以及简单的分析。17优秀的缺陷报告重现步骤:a)打开一个编辑文字的软件并且创建一个新的文档（这个文件可以录入文字）b)在这个文件里随意录入一两行文字c)选中一两行文字，通过选择Font菜单然后选择Arial字体格式d)一两行文字变成了无意义的乱字符期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。实际结果:它是字体格式的问题，如果改变文字格式成Arial之前，你保存文件，缺陷不会出现。缺陷仅仅发生在Windows98并且改变文字格式成其它的字体格式，文字是显示正常的。见所附的图片有一个链接，点击即可看到软件缺陷报告的示例而一份含糊而不完整的缺陷报告，缺少重建步骤，并且没有期望结果、实际结果和必要的图片，如下描述。18含糊而不完整的缺陷报告重现步骤：•打开一个编辑文字的软件.•录入一些文字•选择Arial字体格式•文字变成了乱字符期望结果：实际结果：软件缺陷报告的示例一份散漫的缺陷报告（无关的重建步骤，以及对开发人员理解这个错误毫无帮助的结果信息）如下描述：19重现步骤：•在Window98上打开一个编辑文字的软件并且编辑存在文件•文件字体显示正常•我添加了图片，这些图片显示正常•在此之后，我创建了一个新的文档•在这个文档中我随意录入了大量的文字•在我录入这些文字之后，选择几行文字.并且通过选择Font菜单然后选择Arial字体格式改变文字的字体。•有三次我重现了这个缺陷•我在Solaris操作系统运行这些步骤，没有任何问题。•我在Mac操作系统运行这些步骤，没有任何问题。期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。实际结果：我试着选择少量的不同的字体格式，但是只有Arial字体格式有软件缺陷，不论如何，它可能会出现在我没有测试的其它的字体格式15.2软件缺陷的相关信息15.2.1软件缺陷的图片信息15.2.2使用WinDBG记录软件缺陷信息15.2.3使用Soft-ICE记录软件缺陷信息15.2.4分离和再现软件缺陷15.2.1软件缺陷的图片信息软件缺陷相关的信息包括软件缺陷的图片、记录信息和如何再现和分离软件缺陷，使开发人员和其他的测试人员更容易分离和重现它。一些涉及用户界面(UserInterface)的软件缺陷可能很难用文字清楚地描述，因此软件测试人员通过附上图片比较直观地表示缺陷发生在产品界面什么位置、有什么问题等。15.2.2使用WinDBG记录软件缺陷信息WinDbg是微软发布的源码级调试工具，用于Kernel模式调试和用户模式调试，可用于调试软件崩溃后形成Dump文件，包括操作系统的信息、进程运行的状态、时间和环境变量、汇编指令、调用堆栈等安装、使用的具体操作方法，如提供了图形界面和命令行两种运行方式调试方式：远程调试、Dump调试、本地进程调试windbg–remotenpipe:server=SERVER_NAME,pipe=PIPE_NAMEwindbg–zDUMP_FILE_NAMEWindbg–p“processid”常用命令15.2.3使用Soft-ICE记录软件缺陷信息stackueip-80如果数据窗口是开启的状态，可以输入”wd”来关闭该窗口，然后再输入“ddesp-20”命令。stack、ddesp-20是为了标注跟踪信息。通过输入x，退出Soft-ICE的窗口；如果还是无法退出Soft-ICE，需要输入faultsoff，然后输入x。打开Soft-ICE应用程序，立即保存日志文件。一旦再次打开Soft-ICE，请输入faultson为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法和具有较高的技巧性，虽然有时少数几个缺陷很难再现、或者根本无法再现。以下就介绍如何分离和再现缺陷的一些常用方法和技巧。确保所有的步骤都被记录。特定条件和时间。压力和负荷、内存和数据溢出相关的边界条件。考虑资源依赖性包括内存、网络和硬件共享的相互作用等。不能忽视硬件。与软件不同，硬件不按预定方式工作。开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。2415.2.4分离和再现软件缺陷分离和调试软件缺陷之间的区别①再现缺陷现象所需的最少步骤有哪些？这些步骤成功再现的可能性多大？②缺陷是否成立存在？测试结果是否可能起源于测试因素或者测试人员自身的错误，还是影响顾客需求的、系统真正的故障？③哪些外部因素产生软件缺陷？④哪些内部因素，是代码、网络、还是环境引起的软件缺陷？⑤怎样在不产生新的缺陷的条件下使这个软件缺陷得到修复？⑥这种修复是否经过调试，单元是否经过测试？⑦问题解决了吗？它是否通过了确认和回归测试，确定系统的其余部分仍工作正常？15.3软件缺陷跟踪和分析15.3.1软件缺陷处理技巧15.3.2缺陷趋势分析15.3.3缺陷分布分析15.3.4缺陷跟踪方法软件缺陷的处理和跟踪确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式（例如，延迟到下一个版本中修正或者由于技术原因不能被修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段；决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。收集缺陷数据并在其上进行数据分析，作为组织过程改进的财富。15.3.1软件缺陷处理技巧审阅。可以由测试管理员、项目管理员或其他人来进行，审阅缺陷报告的质量水平；拒绝。如果审阅者决定需要对一份缺陷报告进行重大修改，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交；完善。完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告；分配。分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员；软件缺陷处理技巧(2)验证。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题；重新打开。重新打开一个缺陷，需要加注