软件测试方法和技术 - Ch15报告所发现的软件缺陷

1报告所发现的软件缺陷1.软件缺陷的描述软件缺陷的基本描述软件缺陷属性2.软件缺陷相关的信息软件缺陷的图片、记录信息分离和再现软件缺陷3.软件缺陷的处理和跟踪软件缺陷生命周期软件缺陷处理技巧软件缺陷跟踪系统缺陷跟踪的方法和图表2软件缺陷的描述软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。软件缺陷是什么？3软件缺陷的基本描述软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。以下是软件缺陷的有效描述规则：单一准确可以再现完整统一短小简练特定条件补充完善不做评价4软件缺陷标识和类型软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。缺陷类型：是根据缺陷的自然属性划分缺陷种类。见软件缺陷类型列表：缺陷类型描述功能影响了各种系统功能、逻辑的缺陷用户界面影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷文档影响发布和维护，包括注释，用户手册，设计文档软件包由于软件配置库、变更管理或版本控制引起的错误性能不满足系统可测量的属性值，如执行时间，事务处理速率等。系统/模块接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。5软件缺陷缺陷严重程度缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。见软件缺陷严重等级列表：缺陷严重等级描述致命(Fatal)系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全严重(Critical)系统的主要功能部分丧失、数据不能保存，系统所提供的功能或服务受到明显的影响一般(Major)系统的部分功能没有完全实现，但不影响用户的正常使用，例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。较小(Minor)使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别的不影响产品理解的错别字、文字排列不整齐等一些小问题。6软件缺陷缺陷产生的可能性和优先级缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示。缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素。缺陷产生可能性描述总是(Always)总是产生这个软件缺陷，其产生的频率是100%通常(Often)按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90%有时(Occasionally)按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50%很少(rarely)按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1-5%缺陷优先级描述立即解决(P1级)缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级(P2级）缺陷严重，影响测试，需要优先考虑正常排队(P3级）缺陷需要正常排队等待修复低优先级(P4级）缺陷可以在开发人员有时间的时候被纠正。7软件缺陷缺陷状态缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如软件缺陷状态列表所示:缺陷状态描述激活或打开（ActiveorOpen）问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。已修正或修复(FixedorResolved)已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证关闭或非激活(ClosedorInactive)测试人员验证后，确认缺陷不存在之后的状态。重新打开(Reopen)测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复推迟(Deferred)这个软件缺陷可以在下一个版本中解决保留(onhold)由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷不能重现(Cannotduplicate)开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。需要更多信息(Needmoreinfor)开发能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件，图片等。重复（Duplicate）这个软件缺陷已经被其他的软件测试人员发现。不是缺陷（Notabug）这个问题不是软件缺陷需要修改软件规格说明书（Specmodified）由于软件规格说明书对软件设计的要求，软件开发人员无法修复这个软件缺陷，必须要修改软件规格说明书。8软件缺陷缺陷起源和来源缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段，如软件缺陷起源列表所示。缺陷来源：指缺陷所在的地方，如文档、代码等，如软件缺陷来源列表所示。缺陷来源描述需求说明书需求说明书的错误、或不清楚引起的问题设计文档设计文档描述不准确、和需求说明书不一致的问题系统集成接口系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷数据流(库)由于数据字典、数据库中的错误引起的缺陷程序代码纯粹在编码中的问题所引起的缺陷缺陷起源描述需求在需求阶段发现的缺陷构架在系统构架设计阶段发现的缺陷设计在程序设计阶段发现的缺陷编码在编码阶段发现的缺陷测试在测试阶段发现的缺陷用户在用户使用阶段发现的缺陷9软件缺陷缺陷根源缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如软件缺陷根源列表所示。缺陷根源描述测试策略错误的测试范围，误解了测试目标，超越测试能力等过程，工具和方法无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等团队/人项目团队职责交叉，缺乏培训,没有经验的项目团队，缺乏士气和动机不纯等缺乏组织和通讯缺乏用户参与，职责不明确，管理失败等硬件硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等软件软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000千年虫问题等。工作环境组织机构调整，预算改变，工作环境恶劣，如噪音过大。10软件缺陷相关的信息软件缺陷相关的信息包括软件缺陷的图片、记录信息和如何再现和分离软件缺陷；对于某一个软件缺陷报告，测试人员应该给予相关的信息，例如捕捉到软件缺陷日志文件和图片，保证开发人员和其他的测试人员可以分离和重现它。软件缺陷的图片、记录信息记录软件缺陷的相关图片一些涉及用户界面(UserInterface)的软件缺陷可能很难用文字清楚地描述，因此软件测试人员通过附上图片比较直观地表示缺陷发生在产品界面什么位置、有什么问题等。11分离和再现软件缺陷为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法和具有较高的技巧性，虽然有时少数几个缺陷很难再现、或者根本无法再现。以下就介绍如何分离和再现缺陷的一些常用方法和技巧。确保所有的步骤都被记录。特定条件和时间。压力和负荷、内存和数据溢出相关的边界条件。考虑资源依赖性包括内存、网络和硬件共享的相互作用等。不能忽视硬件。与软件不同，硬件不按预定方式工作。开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。12分离和调试软件缺陷之间的区别讨论分离和调试软件缺陷之间的区别，是为了划清测试人员与开发人员的责任，增加界限的清晰度与测试资源的控制能力。面对一个软件缺陷时，开发人员或测试人员为了修复它，会提出一系列分步骤地、处理缺陷的疑问：再现软件缺陷现象所需的最少步骤有哪些？这些步骤成功再现的可能性多大？软件缺陷是否成立存在？换句话说，测试结果是否可能起源于测试因素或者测试人员自身的错误，还是影响顾客需求的、系统真正的故障？哪些外部因素产生软件缺陷？哪些内部因素，是代码、网络、还是环境引起的软件缺陷？怎样才能在不产生新的缺陷的条件下使这个软件缺陷得到修复？这种修复是否经过调试，单元是否经过测试？问题解决了吗？它是否通过了确认和回归测试，确定系统的其余部分仍工作正常？13软件缺陷的处理和跟踪软件缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，而对软件缺陷进行跟踪管理的目的是确保每个被发现的缺陷都能够及时得到处理。软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理，一般而言需要达到以下目标：确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式（例如，延迟到下一个版本中修正或者由于技术原因不能被修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段；决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。收集缺陷数据并在其上进行数据分析，作为组织过程改进的财富。14简单、优化的软件缺陷生命周期生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态的变化，来跟踪项目进度和软件质量。一个简单、优化的软件缺陷生命周期：发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。发现打开修复关闭15复杂的软件缺陷生命周期在实际工作中，软件缺陷的生命周期不可能像如上那么简单，需要考虑其它各种情况，给出了一个复杂的软件缺陷生命周期的例子，如图所示：16综上所述，软件缺陷在生命周期中经历了数次的审阅和状态变化，最终测试人员关闭软件缺陷来结束软件缺陷的生命周期。软件缺陷生命周期中的不同阶段是测试人员、开发人员和管理人员一起参与、协同测试的过程。软件缺陷一旦发现，便进入测试人员、开发人员、管理人员的严密监控之中，直至软件缺陷生命周期终结，这样即可保证在较短的时间内高效率地关闭所有的缺陷，缩短软件测试的进程，提高软件质量，同时减少开发、测试和维护成本。软件缺陷生命周期综述17软件缺陷处理技巧管理员、测试人员和开发人员需要掌握在软件缺陷生命周期的不同阶段处理软件缺陷技巧，从而尽快处理软件缺陷，缩短软件缺陷生命周期。以下列出处理软件缺陷基本技巧：审阅。当测试人员在缺陷跟踪数据库中输入了一个新的缺陷时，测试员应该提交它，以便在它能够起作用之前进行审阅。这种审阅可以由测试管理员、项目管理员或其他人来进行，主要审阅缺陷报告的质量水平；拒绝。如果审阅者决定需要对一份缺陷报告进行重大修改，例如需要添加更多的信息或者需要改变缺陷的严重等级，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交；完善。如果测试员已经完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告；分配。当开发组接受完整描述特征并被分离的问题时，测试员会将它分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员；18软件缺陷处理技巧测试。一旦开发人员修复一个缺陷，它就将进入测试阶段。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入