19软件测试技术与测试实训教程讲座(19)第19章软件缺陷测试和测试评估v12学时

软件测试技术与测试实训教程黎连业王华李龙黎照北京：机械工业出版社2012.05第19讲：第19章软件缺陷测试和测试评估•在程序中存在的软件缺陷如文档缺陷、代码缺陷、测试缺陷、过程缺陷，软件缺陷导致系统或部件不能实现其功能，引起系统的失效。对软件缺陷测试和测试评估是不可缺少的、相当重要的。本章重点讨论以下内容：★软件缺陷的概述；★软件缺陷的生命周期；★软件缺陷的跟踪管理；★软件测试的评估。19．1软件缺陷的概述19．1．1软件缺陷的定义•缺陷（bug）是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句，缺陷可能出现在设计中，甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能，引起系统的失效。缺陷定义为：★软件没有达到产品说明书表明的功能；•程序中存在语法错误；•程序中存在拼写错误；★程序中存在不正确的程序语句；•软件出现了产品说明书中不一致的表现；•软件功能超出产品说明书的范围；•软件没有达到用户期望的目标；•测试员或用户认为软件的易用性差。•按照定义，将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。★文档缺陷•文档缺陷是指对文档的静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷；★代码缺陷•代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷；★测试缺陷•测试缺陷是指由测试执行活动发现的被测对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题）的缺陷，测试活动主要包括内部测试、连接测试、系统集成测试、用户验收测试，测试活动中发现的缺陷为测试缺陷；★过程缺陷•过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员。19．1．2软件缺陷的特征•软件缺陷的特征主要有如下7点内容：★单一准确•每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。★可以再现（要求软件缺陷具有精确的步骤）•提供缺陷的精确操作步骤，容易看懂再现这个缺陷。★完整统一•提供完整、前后统一的软件缺陷的步骤和信息如：图片信息，Log文件等。★短小简练•通过使用关键词，使软件缺陷的标题的描述简练，准确解释产生缺陷的现象。如“主页”、“导航栏”、“分辨率”等关键词。★特定条件•软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视特定条件如特定的操作系统、浏览器或某种设置等。★补充完整•测试人员发现bug要保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。★不做评价•在软件缺陷描述不要带有个人观点对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何对开发人员评价或议论。19．1．3软件缺陷的类型•软件缺陷的类型分为：功能类、性能类、系统/模块接口类、用户界面类、数据处理类、流程类、提示信息类软件包类、建议类、常识类、文档。软件缺陷类型如表19-1所示。19．1．4BUG状态•缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。BUG状态分为：★激活或打开（ActiveorOpen）：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。★已提交：测试员发现BUG后提交到BUG管理系统中的状态（初始状态）。★已修改(FixedorResolved)：已被程序员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证提交到BUG管理系统中的状态。★不修改（保留）：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对BUG不进行修改（由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷），其BUG的状态为不修改。★延迟：根据目前项目进程或计划等情况，暂时延期的状态，缺陷可以在下一个版本中解决。★待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。★已验证：已经解决的并经过测试员复测的BUG的状态。★关闭：完全解决了，只供以后备查的状态★重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复，重新打开以前关闭的bug状态(在bug工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等)。19．1．5BUG的等级划分与优先级1．BUG的等级划分•BUG的等级划分为4级：★严重：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系统崩溃等错误。修改优先级为最高，该级别需要程序员立即修改。★较高：统的主要功能部分丧失、数据不能保存，导致严重的问题或致命的错误。修改优先级为较高，该级别需要程序员尽快修改。★一般：系统的部分功能没有完全实现，但不影响用户的正常使用，如提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先级为中，该级别需要程序员修改。•★轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字、操作者不方便。修改优先级为低，该级别需要程序员修改或不修改。2．BUG的优先级•BUG的优先级一般与BUG等级挂钩分为4级：1级（严重）：立即解决。缺陷导致系统几乎不能使用或测试不能继续，需立即修复。2级（较高）：缺陷严重，影响测试，需要优先考虑。3级（一般）：正常排队缺陷需要正常排队等待修复。4级（轻微）：缺陷可以在开发人员有时间的时候被纠正。19．1．6软件缺陷的缺陷标识种类和属性1．缺陷标识•缺陷标识是指是标记某个缺陷的唯一的表示，可以使用数字序号表示，如表19-2所示。•缺陷标识是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。2．软件缺陷的种类•软件缺陷的种类有如下15点内容：（1）功能不正常；（2）软件在使用上不方便；（3）软件的结构未做良好规划；（4）功能不充分；（5）与软件操作者的互动不良；（6）使用性能不佳；（7）未做好错误处理；（8）边界错误；（9）计算错误；（10）使用一段时间所产生的错误；（11）控制流程的错误；（12）在大数据量压力之下所产生的错误；（13）在不同硬件环境下产生的错误；（14）版本控制不良所产生的错误；（15）软件文档的错误。3．软件缺陷的属性•软件缺陷的属性主要有如下10点内容：（1）缺陷标识；（2）缺陷描述与缺陷注释；（3）缺陷类型；（4）缺陷严重程度；（5）缺陷产生可能性；（6）缺陷的优先级；（7）缺陷状态；（8）软件缺陷的起源；（9）软件缺陷的来源；（10）缺陷根源。4．软件缺陷属性操作•软件缺陷属性操作如表19-3所示。19．1．7缺陷的起源来源和根源1．缺陷的起源•缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段，给软件带来缺陷的原因有很多，需求、构架、设计、编码、测试、用户这里列举几点：★需求：参与人员的过度自信，在需求阶段产生的错误；★构架：人员之间的沟通交流不够，交流上有误解或者根本不进行交流，在系统构架设计阶段产生的错误；★设计：工期短，任务重，时间压力大，在程序设计阶段产生的错误；★编码：在编码阶段程序设计本身有错误产生的错误；★测试：在测试阶段发现的缺陷；★用户：在用户使用阶段发现的错误。；2．缺陷的来源•缺陷的来源是指缺陷所在的地方如需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等。★需求说明书：需求说明书的错误或不清楚引起的问题；★设计文档：设计文档描述不准确。和需求说明书不一致的问题；★系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；★数据流（库）：由于数据字典、数据库中的错误引起的缺陷；★程序代码：纯粹在编码中的问题所引起的缺陷。3．缺陷的根源•缺陷的根源是指造成软件错误的根本因素如测试策略、过程工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境等。★测试策略：错误的测试范围，误解测试目标，超越测试能力等；★过程工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；★团队/人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；★缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；★硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；★软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等；★工作环境：组织机构调整，预算改变，工作环境恶劣。19．1．8BUG记录•BUG记录内容如表19-4所示。19．2软件缺陷的生命周期19．2．1软件缺陷的生命周期•软件缺陷的生命周期是指一个软件缺陷被发现、报告到这个缺陷被修改、验证直至最后关闭的完整过程。软件缺陷的生命周期分为简单的软件缺陷生命周期和复杂的软件缺陷生命周期。1．简单的软件缺陷生命周期•简单的软件缺陷生命周期★发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；★打开——修复：开发人员再现、修改缺陷，然后提交测试人员去验证；★修复——关闭：测试人员验证修改过的软件，关闭已不存在的缺陷。•发现——〉打开——〉修复——〉关闭。•这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。2．复杂的软件缺陷生命周期•复杂的软件缺陷生命周期•打开一个软件缺陷：★对软件缺陷进行bug审查，是程序员代码问题还是设计问题？★是立即修改还是可以延期修改？●审查决定软件缺陷是否应该修改；●审查可能认定软件缺陷应该在将来的同一时间考虑修改，但是在该版本软件中不修改。★一个软件缺陷看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到打开状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。•缺陷生命周期过程是测试员、程序员、管理者一起参与、协同测试工作的过程。缺陷状态不仅表示出缺陷被修改、终结的进程，同时还标明了测试员、程序员、管理者的职责。19．2．2软件缺陷生命状态的定义•每一个软件缺陷都有6个生命状态：打开（Open）、缺陷修改（Working）、缺陷验证（Verify）、缺陷删除（Cancel）、缺陷关闭（Close）、缺陷延期（Defer）。它们的基本定义是：★Open态---缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始；★Working态---缺陷修改状态，程序员接收缺陷，正在修改中；★Verify态---缺陷验证状态，程序员修改完毕，等待测试员验证；★Close态---缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭；★Cancel态---缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态（不做物理删除）；★Defer态---缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷置为延期状态；•上述打开态、缺陷修改态、缺陷验证态，称为缺陷的活动态；•缺陷关闭态、缺陷删除态、缺陷延期态，称为缺陷的终结态。•软件缺陷的生命周期示意图如图19-1所示。图19-1中：1.典型的缺陷生命历程•典型的缺陷生命历程有三种过程：★打开态—〉缺陷修改态—〉缺陷验证态—〉打开态/缺陷关闭态/缺陷删除态；★打开态—〉缺陷关闭态/缺陷删除态；★打开态—〉缺陷延期态。2．缺陷生命状态的控制与转换（1）当测试员报告一个缺陷，程序员接受打开（Open）态的缺陷，缺陷生命周期开始，为打开态；★打开态—〉缺陷修改态—〉缺陷验证态—〉打开态/缺陷关闭态/缺陷删除态；★程序员接受打开态的缺陷，修改中可将其置为缺陷修改态、修改完毕可置为缺陷验证态；★测试员验证缺陷验证态的缺陷，确认修改结果正确，可将打开态置为缺陷关闭态；确认不是缺陷，可将打开态置为缺陷删除态；认修改结果不正确，可以将缺陷验证态置为打开态，要求程序员重新修改；打开态缺陷关闭态/缺陷删除态。（2）当测试员发现自己误报或重报了缺陷，可直接将打开态置为缺陷删除态；•当测试员发现一个缺陷由于其它缺陷的修改而随之消失，可直接将打开态缺陷置为缺陷关闭态；打开态—〉缺陷延期态。（3）管理者确认缺陷需延期修改或追踪，可将打开态