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

《19 软件测试技术与测试实训教程讲座(19 ) 第19章 软件缺陷测试和测试评估v1 2学时.ppt》由会员分享，可在线阅读，更多相关《19 软件测试技术与测试实训教程讲座(19 ) 第19章 软件缺陷测试和测试评估v1 2学时.ppt（54页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、软件测试技术与测试实训教程软件测试技术与测试实训教程黎连业 王华 李龙 黎照北京：机械工业出版社 2012.05 第第1919讲：讲：第第19章章软件缺陷测试和测软件缺陷测试和测试评估试评估在程序中存在的软件缺陷如文档缺陷、代码缺陷、在程序中存在的软件缺陷如文档缺陷、代码缺陷、测试缺陷、过程缺陷，软件缺陷导致系统或部件测试缺陷、过程缺陷，软件缺陷导致系统或部件不能实现其功能，引起系统的失效。对软件缺陷不能实现其功能，引起系统的失效。对软件缺陷测试和测试评估是不可缺少的、相当重要的。本测试和测试评估是不可缺少的、相当重要的。本章重点讨论以下内容：章重点讨论以下内容：软件缺陷的概述；软件缺陷的概述

2、；软件缺陷的生命周期；软件缺陷的生命周期；软件缺陷的跟踪管理；软件缺陷的跟踪管理；软件测试的评估。软件测试的评估。191软件缺陷的概述软件缺陷的概述1911软件缺陷的定义软件缺陷的定义缺陷（缺陷（bug）是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句，缺陷可能出现在设计中，）是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句，缺陷可能出现在设计中，甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能，引起系统的失效。缺陷定义为：甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能，引起系统的失效。缺陷定义为：软件没有达

3、到产品说明书表明的功能；软件没有达到产品说明书表明的功能；程序中存在语法错误；程序中存在语法错误；程序中存在拼写错误；程序中存在拼写错误；程序中存在不正确的程序语句；程序中存在不正确的程序语句；软件出现了产品说明书中不一致的表现；软件出现了产品说明书中不一致的表现；软件功能超出产品说明书的范围；软件功能超出产品说明书的范围；软件没有达到用户期望的目标；软件没有达到用户期望的目标；测试员或用户认为软件的易用性差。测试员或用户认为软件的易用性差。按照定义，将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。按照定义，将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。文档缺陷文档缺陷文档缺陷是指对文档

4、的静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的文档缺陷是指对文档的静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷；缺陷；代码缺陷代码缺陷代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷；代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷；测试缺陷测试缺陷测试缺陷是指由测试执行活动发现的被测对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的测试缺陷是指由测试执行活动发现的被测对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题）的缺陷，测试活动主要包括内部测试、连接测试、

5、系统集成测试、用户验收测试，测试活动中发现的缺陷为问题）的缺陷，测试活动主要包括内部测试、连接测试、系统集成测试、用户验收测试，测试活动中发现的缺陷为测试缺陷；测试缺陷；过程缺陷过程缺陷过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员。过程缺陷的发现者一般是质量经理、测试经理、管理人员。1912软件缺陷的特征软件缺陷的特征软件缺陷的特征主要有如下软件缺陷的特征主要有如下7点内容：点内容：单一准确单一

6、准确每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。会导致缺陷部分被注意和修复，不能得到彻底的修正。可以再现（要求软件缺陷具有精确的步骤）可以再现（要求软件缺陷具有精确的步骤）提供缺陷的精确操作步骤，容易看懂再现这个缺陷。提供缺陷的精确操作步骤，容易看懂再现这个缺陷。完整统一完整统一提供完整、前后统一的软件缺陷的步骤和信息如：图片信息，提供完整、前后统一的软件缺陷的步骤和信息如：图片信息，Log文件等。文件等。短小简练短小简练通过使用关键词，使软件缺陷的标题的

7、描述简练，准确解释产生缺陷的现象。通过使用关键词，使软件缺陷的标题的描述简练，准确解释产生缺陷的现象。如如“主页主页”、“导航栏导航栏”、“分辨率分辨率”等关键词。等关键词。特定条件特定条件软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视特定条件如特定的操作系统、浏览器或某种设置等。件缺陷描述不要忽视特定条件如特定的操作系统、浏览器或某种设置等。补充完整补充完整测试人员发现测试人员发现bug要保证它被正确的报告，并且得到应有的重视，继续监视要保证它被正确的报告，并且得到应有的重视，继续监视

8、其修复的全过程。其修复的全过程。不做评价不做评价在软件缺陷描述不要带有个人观点对开发人员进行评价。软件缺陷报告是针对在软件缺陷描述不要带有个人观点对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何对开产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何对开发人员评价或议论。发人员评价或议论。1913软件缺陷的类型软件缺陷的类型软件缺陷的类型分为：功能类、性能类、软件缺陷的类型分为：功能类、性能类、系统系统/模块接口类、用户界面类、数据处理模块接口类、用户界面类、数据处理类、流程类、提示信息类类、流程类、提示信息类软件包类、建议软件

9、包类、建议类、常识类、文档。软件缺陷类型如表类、常识类、文档。软件缺陷类型如表19-1所示。所示。1914BUG状态状态 缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。BUG状态分为：状态分为：激活或打开（激活或打开（ActiveorOpen）：问题还没有解决，存在源代码中，确认）：问题还没有解决，存在源代码中，确认“提交提交的缺陷的缺陷”，等待处理，如新报的缺陷。，等待处理，如新报的缺陷。已提交：测试员发现已提交：测试员发现BUG后提交到后提交到BUG管理系统中的状态（初始状态）。管理系统中的状态（初始状态）。已修改已修改(FixedorRe

10、solved)：已被程序员检查、修复过的缺陷，通过单元测试，：已被程序员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证提交到认为已解决但还没有被测试人员验证提交到BUG管理系统中的状态。管理系统中的状态。不修改（保留）：程序员或项目经理根据需求分析、概要设计、详细设计说明不修改（保留）：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对书等上的要求经过考虑后决定对BUG不进行修改（由于技术原因或第三者软件不进行修改（由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷），其的缺陷，开发人员不能修复的缺陷），其BUG的状态为不修改。的状态为不修

11、改。延迟：根据目前项目进程或计划等情况，暂时延期的状态，缺陷可以在下一个版延迟：根据目前项目进程或计划等情况，暂时延期的状态，缺陷可以在下一个版本中解决。本中解决。待讨论：需要进行讨论后才能决定是否需要修改的待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。的状态。已验证：已经解决的并经过测试员复测的已验证：已经解决的并经过测试员复测的BUG的状态。的状态。关闭：完全解决了，只供以后备查的状态关闭：完全解决了，只供以后备查的状态重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复，重重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复，重新打开以前关闭的新打

12、开以前关闭的bug状态状态(在在bug工具中，可以自己定制适合项目的状态工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等项目，比如废除，拒绝等)。1915BUG的等级划分与优先级的等级划分与优先级1BUG的等级划分的等级划分BUG的等级划分为的等级划分为4级：级：严重：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系严重：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系统崩溃等错误。修改优先级为最高，该级别需要程序员立即修改。统崩溃等错误。修改优先级为最高，该级别需要程序员立即修改。较高：统的主要功能部分丧失、数据不能保存，导致严重的问题或致较高：统的主要功能部分丧失、数据

13、不能保存，导致严重的问题或致命的错误。修改优先级为较高，该级别需要程序员尽快修改。命的错误。修改优先级为较高，该级别需要程序员尽快修改。一般：系统的部分功能没有完全实现，但不影响用户的正常使用，如一般：系统的部分功能没有完全实现，但不影响用户的正常使用，如提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先级为中，该级别需要程序员修改。级为中，该级别需要程序员修改。轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字、操作者不方便。修改优先级为低，该级

14、别需要程序员如有个错别字、操作者不方便。修改优先级为低，该级别需要程序员修改或不修改。修改或不修改。2BUG的优先级的优先级BUG的优先级一般与的优先级一般与BUG等级挂钩分为等级挂钩分为4级：级：1级（严重）：立即解决。缺陷导致系统几乎不能使级（严重）：立即解决。缺陷导致系统几乎不能使用或测试不能继续，需立即修复。用或测试不能继续，需立即修复。2级（较高）：缺陷严重，影响测试，需要优先考虑。级（较高）：缺陷严重，影响测试，需要优先考虑。3级（一般）：正常排队缺陷需要正常排队等待修复。级（一般）：正常排队缺陷需要正常排队等待修复。4级（轻微）：缺陷可以在开发人员有时间的时候被级（轻微）：缺陷可

15、以在开发人员有时间的时候被纠正。纠正。1916软件缺陷的缺陷标识种类和属性软件缺陷的缺陷标识种类和属性1缺陷标识缺陷标识缺陷标识是指是标记某个缺陷的唯一的表缺陷标识是指是标记某个缺陷的唯一的表示，可以使用数字序号表示，如表示，可以使用数字序号表示，如表19-2所所示。示。缺陷标识是按照问题的复杂度来排列的，缺陷标识是按照问题的复杂度来排列的，类型类型10到到40是比较简单的编码缺陷，类型是比较简单的编码缺陷，类型50到到100是比较复杂的设计缺陷。是比较复杂的设计缺陷。2软件缺陷的种类软件缺陷的种类软件缺陷的种类有如下软件缺陷的种类有如下15点内容：点内容：（1）功能不正常；）功能不正常；（2

16、）软件在使用上不方便；）软件在使用上不方便；（3）软件的结构未做良好规划；）软件的结构未做良好规划；（4）功能不充分；）功能不充分；（5）与软件操作者的互动不良；）与软件操作者的互动不良；（6）使用性能不佳；）使用性能不佳；（7）未做好错误处理；）未做好错误处理；（8）边界错误；）边界错误；（9）计算错误；）计算错误；（10）使用一段时间所产生的错误；）使用一段时间所产生的错误；（11）控制流程的错误；）控制流程的错误；（12）在大数据量压力之下所产生的错误；）在大数据量压力之下所产生的错误；（13）在不同硬件环境下产生的错误；）在不同硬件环境下产生的错误；（14）版本控制不良所产生的错误；）

17、版本控制不良所产生的错误；（15）软件文档的错误。）软件文档的错误。3软件缺陷的属性软件缺陷的属性软件缺陷的属性主要有如下软件缺陷的属性主要有如下10点内容：点内容：（1）缺陷标识；）缺陷标识；（2）缺陷描述与缺陷注释；）缺陷描述与缺陷注释；（3）缺陷类型；）缺陷类型；（4）缺陷严重程度；）缺陷严重程度；（5）缺陷产生可能性；）缺陷产生可能性；（6）缺陷的优先级；）缺陷的优先级；（7）缺陷状态；）缺陷状态；（8）软件缺陷的起源；）软件缺陷的起源；（9）软件缺陷的来源；）软件缺陷的来源；（10）缺陷根源。）缺陷根源。4软件缺陷属性操作软件缺陷属性操作软件缺陷属性操作如表软件缺陷属性操作如表19-

18、3所示。所示。1917缺陷的起源来源和根源缺陷的起源来源和根源1缺陷的起源缺陷的起源缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段，给软件带来缺陷的原因有很多，需求、构架、设计、段，给软件带来缺陷的原因有很多，需求、构架、设计、编码、测试、用户这里列举几点：编码、测试、用户这里列举几点：需求：参与人员的过度自信，在需求阶段产生的错误；需求：参与人员的过度自信，在需求阶段产生的错误；构架：人员之间的沟通交流不够，交流上有误解或者根构架：人员之间的沟通交流不够，交流上有误解或者根本不进行交流，在系统构架设计阶段产生的错误；本不进行交流，在系统

19、构架设计阶段产生的错误；设计设计：工期短，任务重，时间压力大，在程序设计阶段：工期短，任务重，时间压力大，在程序设计阶段产生的错误；产生的错误；编码：编码：在编码阶段程序设计本身有错误产生的错误；在编码阶段程序设计本身有错误产生的错误；测试：在测试阶段发现的缺陷；测试：在测试阶段发现的缺陷；用户：在用户使用阶段发现的错误。；用户：在用户使用阶段发现的错误。；2缺陷的来源缺陷的来源缺陷的来源是指缺陷所在的地方如需求说明书、设计文档、缺陷的来源是指缺陷所在的地方如需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等。系统集成接口、数据流（库）、程序代码等。需求说明书：需求说明书的错误或不清

20、楚引起的问题；需求说明书：需求说明书的错误或不清楚引起的问题；设计文档：设计文档描述不准确。和需求说明书不一致的设计文档：设计文档描述不准确。和需求说明书不一致的问题；问题；系统集成接口：系统个模块参数不匹配、开发组之间缺乏系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；协调引起的缺陷；数据流（库）：由于数据字典、数据库中的错误引起的缺数据流（库）：由于数据字典、数据库中的错误引起的缺陷；陷；程序代码：纯粹在编码中的问题所引起的缺陷。程序代码：纯粹在编码中的问题所引起的缺陷。3缺陷的根源缺陷的根源缺陷的根源是指造成软件错误的根本因素如测试策略、过缺陷的根源是指造成软件错误的根

21、本因素如测试策略、过程工具和方法、团队程工具和方法、团队/人、缺乏组织和通讯、硬件、软件、人、缺乏组织和通讯、硬件、软件、工作环境等。工作环境等。测试策略：错误的测试范围，误解测试目标，超越测试能测试策略：错误的测试范围，误解测试目标，超越测试能力等；力等；过程工具和方法：无效的需求收集过程，果实的风险管理过程工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；更控制过程等；团队团队/人：项目团队职责交叉，缺乏培训。没有经验的项人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气

22、和动机不纯等；目团队，缺乏士气和动机不纯等；缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；等；硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；丢失，内存溢出等；软件：软件设置不对、缺乏，或操作系统错误导致无法释软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等；放资源，工具软件的错误，编译器的错误等；工作环境：组织机构调整，预算改变，工作环境恶劣。工作环境：组织机构调整，预算改变，工作环境恶劣。1918BUG记录记录BUG记录内容

23、如表记录内容如表19-4所示。所示。192软件缺陷的生命周期软件缺陷的生命周期1921软件缺陷的生命周期软件缺陷的生命周期软件缺陷的生命周期是指一个软件缺陷被发现、报告到这个缺陷被修改、软件缺陷的生命周期是指一个软件缺陷被发现、报告到这个缺陷被修改、验证直至最后关闭的完整过程。软件缺陷的生命周期分为简单的软件缺陷验证直至最后关闭的完整过程。软件缺陷的生命周期分为简单的软件缺陷生命周期和复杂的软件缺陷生命周期。生命周期和复杂的软件缺陷生命周期。1简单的软件缺陷生命周期简单的软件缺陷生命周期简单的软件缺陷生命周期简单的软件缺陷生命周期发现发现打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；打

24、开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；打开打开修复：开发人员再现、修改缺陷，然后提交测试人员去验证；修复：开发人员再现、修改缺陷，然后提交测试人员去验证；修复修复关闭：测试人员验证修改过的软件，关闭已不存在的缺陷。关闭：测试人员验证修改过的软件，关闭已不存在的缺陷。发现发现打开打开修复修复关闭。关闭。这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。的各种情况都还是非常多的。2复杂的软件缺陷生命周期复杂的软件缺陷生命周期复杂的软件缺陷生命周期复杂的软件缺陷生命周期打开一个软件缺

25、陷：打开一个软件缺陷：对软件缺陷进行对软件缺陷进行bug审查，是程序员代码问题还是设计问题？审查，是程序员代码问题还是设计问题？是立即修改还是可以延期修改？是立即修改还是可以延期修改？审查决定软件缺陷是否应该修改；审查决定软件缺陷是否应该修改；审查可能认定软件缺陷应该在将来的同一时间考虑修改，但是在该版本审查可能认定软件缺陷应该在将来的同一时间考虑修改，但是在该版本软件中不修改。软件中不修改。一个软件缺陷看是否清楚可重现，如果不能重现，就是缺少信息，需一个软件缺陷看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到打开状态；如果能够重现，就进行修正，修正后关闭，进行要返回到打开状态；如果能

26、够重现，就进行修正，修正后关闭，进行回归测试。回归测试。缺陷生命周期过程是测试员、程序员、管理者一起参与、协同测试工缺陷生命周期过程是测试员、程序员、管理者一起参与、协同测试工作的过程。缺陷状态不仅表示出缺陷被修改、终结的进程，同时还标作的过程。缺陷状态不仅表示出缺陷被修改、终结的进程，同时还标明了测试员、程序员、管理者的职责。明了测试员、程序员、管理者的职责。1922软件缺陷生命状态的定义软件缺陷生命状态的定义每一个软件缺陷都有每一个软件缺陷都有6个生命状态：打开（个生命状态：打开（Open）、缺陷修改）、缺陷修改（Working）、缺陷验证（）、缺陷验证（Verify）、缺陷删除（）、缺陷

27、删除（Cancel）、缺）、缺陷关闭（陷关闭（Close）、缺陷延期（）、缺陷延期（Defer）。它们的基本定义是：）。它们的基本定义是：Open态态-缺陷初试状态，测试员报告一个缺陷，缺陷生命周期缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始；开始；Working态态-缺陷修改状态，程序员接收缺陷，正在修改中；缺陷修改状态，程序员接收缺陷，正在修改中；Verify态态-缺陷验证状态，程序员修改完毕，等待测试员验证；缺陷验证状态，程序员修改完毕，等待测试员验证；Close态态-缺陷关闭状态，测试员确认缺陷被改正，将缺陷关缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭；闭；Cancel态态-

28、缺陷删除状态，测试员确认不是缺陷，将缺陷置为缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态删除状态（不做物理删除）；（不做物理删除）；Defer态态-缺陷延期状态，管理者确认缺陷需要延期修改或追踪，缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷置为延期状态；将缺陷置为延期状态；上述打开态、缺陷修改态、缺陷验证态，称为缺陷的活动态；上述打开态、缺陷修改态、缺陷验证态，称为缺陷的活动态；缺陷关闭态、缺陷删除态、缺陷延期态，称为缺陷的终结态。缺陷关闭态、缺陷删除态、缺陷延期态，称为缺陷的终结态。软件缺陷的生命周期示意图如图软件缺陷的生命周期示意图如图19-1所示。所示。图图19-1中：

29、中：1.典型的缺陷生命历程典型的缺陷生命历程典型的缺陷生命历程有三种过程：典型的缺陷生命历程有三种过程：打开态打开态缺陷修改态缺陷修改态缺陷验证态缺陷验证态打开态打开态/缺陷关闭态缺陷关闭态/缺陷删除态；缺陷删除态；打开态打开态缺陷关闭态缺陷关闭态/缺陷删除态；缺陷删除态；打开态打开态缺陷延期态。缺陷延期态。2缺陷生命状态的控制与转换缺陷生命状态的控制与转换（1）当测试员报告一个缺陷，程序员接受打开（）当测试员报告一个缺陷，程序员接受打开（Open）态的缺陷，缺陷生命周期开始，为）态的缺陷，缺陷生命周期开始，为打开态；打开态；打开态打开态缺陷修改态缺陷修改态缺陷验证态缺陷验证态打开态打开态/缺

30、陷关闭态缺陷关闭态/缺陷删除态；缺陷删除态；程序员接受打开态的缺陷，修改中可将其置为缺陷修改态、修改完毕可置为缺陷验证态；程序员接受打开态的缺陷，修改中可将其置为缺陷修改态、修改完毕可置为缺陷验证态；测试员验证缺陷验证态的缺陷，确认修改结果正确，可将打开态置为缺陷关闭态；确认不测试员验证缺陷验证态的缺陷，确认修改结果正确，可将打开态置为缺陷关闭态；确认不是缺陷，可将打开态置为缺陷删除态；认修改结果不正确，可以将缺陷验证态置为打是缺陷，可将打开态置为缺陷删除态；认修改结果不正确，可以将缺陷验证态置为打开态，要求程序员重新修改；打开态缺陷关闭态开态，要求程序员重新修改；打开态缺陷关闭态/缺陷删除态

31、。缺陷删除态。（2）当测试员发现自己误报或重报了缺陷，可直接将打开态置为缺陷删除态；当测试员发现自己误报或重报了缺陷，可直接将打开态置为缺陷删除态；当测试员发现一个缺陷由于其它缺陷的修改而随之消失，可直接将打开态缺陷置为缺当测试员发现一个缺陷由于其它缺陷的修改而随之消失，可直接将打开态缺陷置为缺陷关闭态；打开态陷关闭态；打开态缺陷延期态缺陷延期态。（3）管理者确认缺陷需延期修改或追踪，可将打开态缺陷置为缺陷延期态；）管理者确认缺陷需延期修改或追踪，可将打开态缺陷置为缺陷延期态；此外，终结态必要时可以重新打开：此外，终结态必要时可以重新打开：在适当的时候，管理者可将缺陷延期态改为打开态，要求程序

32、员修改；在适当的时候，管理者可将缺陷延期态改为打开态，要求程序员修改；在复查缺陷处理结果时，发现缺陷关闭态或缺陷删除态的处理有误，测试员可以将缺陷关在复查缺陷处理结果时，发现缺陷关闭态或缺陷删除态的处理有误，测试员可以将缺陷关闭或缺陷删除态重新置为打开态，要求程序员重新修改；闭或缺陷删除态重新置为打开态，要求程序员重新修改；一般在测试初期，活动态的缺陷数会急剧上升，随着程序员、测试员的处理逐渐转为一般在测试初期，活动态的缺陷数会急剧上升，随着程序员、测试员的处理逐渐转为终结态。当所有软件缺陷的状态都转变为终结态，且在一段时间内没有被打开，也没终结态。当所有软件缺陷的状态都转变为终结态，且在一段

33、时间内没有被打开，也没有新的缺陷发生，即意味着测试可以结束或告一段落。有新的缺陷发生，即意味着测试可以结束或告一段落。19.3软件缺陷的跟踪管理软件缺陷的跟踪管理1931软件缺陷测试报告软件缺陷测试报告软件中不可能没有缺陷，发现很多的缺陷对于测试工作来软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。如果，测试中发现缺陷，需要报告。说，是件很正常的事。如果，测试中发现缺陷，需要报告。1报告软件缺陷的原则报告软件缺陷的原则（1）尽快报告软件缺陷）尽快报告软件缺陷（2）有效地描述软件缺陷）有效地描述软件缺陷有效的软件缺陷描述要求如下：有效的软件缺陷描述要求如下：简单与短小；简单

34、与短小；明确指明错误类型；明确指明错误类型；单一；单一；使用使用IT业界惯用的表达术语和表达方法。业界惯用的表达术语和表达方法。（3）在报告软件缺陷时不做任何评价）在报告软件缺陷时不做任何评价 2缺陷跟踪系统报告的信息缺陷跟踪系统报告的信息任何一个缺陷跟踪系统的核心都是任何一个缺陷跟踪系统的核心都是“软件软件缺陷报告缺陷报告”，缺陷跟踪系统报告的详细信缺陷跟踪系统报告的详细信息如表息如表19-5所示。所示。3跟踪软件缺陷手工报告记录跟踪软件缺陷手工报告记录显然，在软件测试工作中，每个测试用例显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺的结果都必须进行记录。如果使用软

35、件缺陷跟踪系统，那么测试工具将自动记录软陷跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。文的信息可以直接记录在相应的文档中。文档如表档如表19-6所示。所示。4IEEE软件缺陷报告模板软件缺陷报告模板ANS/IEEE8291998标准定义了一个称为标准定义了一个称为软件缺陷报告的文档，用于报告软件缺陷报告的文档，用于报告“在测试在测试期间发生的任何异常事件期间发生的任何异常事件”。模板标准如。模板标准如表表19-7所示。所示。19

36、32缺陷类别缺陷类别缺陷类别划分为缺陷类别划分为5类：类：A类、类、B类、类、C类、类、D类、类、E类。类。1A类类A类是由程序执行引起的死机、非法退出、死循环。类是由程序执行引起的死机、非法退出、死循环。数据库发生死锁；数据库发生死锁；数据库设计未达到范式的要求或需求规格说明的水平；数据库设计未达到范式的要求或需求规格说明的水平；数据功能实现错误；数据功能实现错误；与数据库连接错误；与数据库连接错误；数据通讯错误。数据通讯错误。2B类类B类是由程序语法引起的错误。类是由程序语法引起的错误。因错误操作迫使程序中断。因错误操作迫使程序中断。数据库的表、业务规则、缺省值未加完整性。数据库的表、业务

37、规则、缺省值未加完整性。3C类类C类是由操作界面引起的错误。类是由操作界面引起的错误。打印内容、格式错误；打印内容、格式错误；简单的输入限制未放在前台进行控制；简单的输入限制未放在前台进行控制；删除操作未给出提示；删除操作未给出提示；数据库表中有过多的空字。数据库表中有过多的空字。4D类类D类是由界面不规范引起的错误。类是由界面不规范引起的错误。辅助说明描述不清楚；辅助说明描述不清楚；输入输出不规范；输入输出不规范；长操作未给用户提示；长操作未给用户提示；提示窗口文字未采用行业术语；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志。可输入区域和只读区域没有明显的区分标志。5E

38、类类E类是由遗漏部分功能引起的错误类是由遗漏部分功能引起的错误实现功能与需求不相吻合。实现功能与需求不相吻合。1933缺陷的分离和重现缺陷的分离和重现软件缺陷的分离和再现是考验测试人员专业技能，测试人软件缺陷的分离和再现是考验测试人员专业技能，测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。和再现的形式进行描述。1缺陷的分离缺陷的分离缺陷分离的方法主要有：缺陷分离的方法主要有：确保所有的测试步骤都被记录（记录每一个测试步骤、每确保所有的测试步骤都被记录（记录每一个测试步骤、每一件工作）；一件工作）；注意时间和运行条

39、件上的因素（查找时间依赖和竞争条件注意时间和运行条件上的因素（查找时间依赖和竞争条件的问题的问题(slow软盘、软盘、quick硬盘、时间发生次序硬盘、时间发生次序)；注意软件的边界条件、内存容量和数据溢出的问题；注意软件的边界条件、内存容量和数据溢出的问题；注意事件发生次序导致的软件缺陷；注意事件发生次序导致的软件缺陷；考虑资源依赖性和内存、网络、硬件共享的相互作用；考虑资源依赖性和内存、网络、硬件共享的相互作用；注意系统的压力条件；注意系统的压力条件；不能忽视硬件。与软件不同，硬件不按预定方式工作。不能忽视硬件。与软件不同，硬件不按预定方式工作。2缺陷的重现缺陷的重现缺陷的重现要采取繁杂的

40、步骤才能再现，缺陷的重现要采取繁杂的步骤才能再现，或者根本无法再现。开发人员有时可以根或者根本无法再现。开发人员有时可以根据相对简单的错误信息就能找出问题所在。据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷得到查找软件缺陷的线索。一个软件缺陷的再现问题有时需要小组的共同努力。如的再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需也

41、无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。要记录和报告软件缺陷。缺陷重现的方法同于缺陷分离的方法。缺陷重现的方法同于缺陷分离的方法。1934软件缺陷跟踪系统软件缺陷跟踪系统软件缺陷跟踪系统（软件缺陷跟踪系统（BugTrackingSystem）是）是用于记录、跟踪、并归类处理软件开发过程出现的用于记录、跟踪、并归类处理软件开发过程出现的Bug和硬件系统中存在的缺陷（和硬件系统中存在的缺陷（defect）。集中管）。集中管理软件测试过程中所发现缺陷的数据库程序，可以理软件测试过程中所发现缺陷的数据库程序，可以通过添加、修改、排序、查寻、存储操作来管理软通过添加、修改、排序、查寻、存

42、储操作来管理软件缺陷。目的是：保持进度、保证质量，提高整个件缺陷。目的是：保持进度、保证质量，提高整个机构的生产效率。机构的生产效率。在测试工作中应用软件缺陷管理系统具有以下优点：在测试工作中应用软件缺陷管理系统具有以下优点：保持高效率的测试过程；保持高效率的测试过程；提高软件缺陷报告的质量；提高软件缺陷报告的质量；实施实时管理，安全控制；实施实时管理，安全控制；利于项目组成员间协同工作。利于项目组成员间协同工作。1软件缺陷跟踪系统常用的功能要求软件缺陷跟踪系统常用的功能要求缺陷跟踪管理系统应采用缺陷跟踪管理系统应采用B/S结构；结构；采用标准技术，基于网络，多功能，快速，可靠，好用性好；采用

43、标准技术，基于网络，多功能，快速，可靠，好用性好；无需在用户终端机器上装任何附加软件，可从网络上任何地方通过无需在用户终端机器上装任何附加软件，可从网络上任何地方通过HTTP或或SMTP联接；联接；支持网页界面，内部网和外部网的用户均可使用；支持网页界面，内部网和外部网的用户均可使用；支持各种数据库系统，基于支持各种数据库系统，基于SQL92标准，使用开放型数据库设计，可升级；标准，使用开放型数据库设计，可升级；可设置性和多用途可设置性和多用途,不仅可用做不仅可用做Bug跟踪系统，而且可用做集成服务台热线流程管理；跟踪系统，而且可用做集成服务台热线流程管理；支持各种自定域数据类型，表格栏目可根

44、据需要添加和删减；支持各种自定域数据类型，表格栏目可根据需要添加和删减；页面可做个性化调整，如添加公司标志等；页面可做个性化调整，如添加公司标志等；可同时支持多个项目，设置访问权限，自我注册；可同时支持多个项目，设置访问权限，自我注册；可设置基于表格栏目域的多层次权限；可设置基于表格栏目域的多层次权限；自定义工作流程（对每个项目）；自定义工作流程（对每个项目）；自动或手动分配任务负责人；自动或手动分配任务负责人；可一次附加多个任何类型的文件；可一次附加多个任何类型的文件；支持直接屏幕抓图（支持直接屏幕抓图（Screencapture）；）；具有自动自定义电子邮件通知功能；具有自动自定义电子邮件

45、通知功能；可通过电子邮件和文档版本管理软件可通过电子邮件和文档版本管理软件(CVS,Perforce)集成；集成；图表报告，高级搜索，自定义常用搜索；图表报告，高级搜索，自定义常用搜索；全面且易读的记录和修改历史；全面且易读的记录和修改历史；快速排序和导出（快速排序和导出（export)；支持目录服务支持目录服务(LDAP/ActiveDirectory)集成集成；具有自定义电子邮件提醒催单功能具有自定义电子邮件提醒催单功能(Reminder)；方便的基于网络的系统管理。方便的基于网络的系统管理。软件缺陷跟踪系统的选用软件缺陷跟踪系统的选用软件缺陷跟踪系统（缺陷管理工具），现在网上可以查得到的

46、缺陷管理软软件缺陷跟踪系统（缺陷管理工具），现在网上可以查得到的缺陷管理软件有英文版的，也有中文版的，有要收费的，有免费提供的。国内外已出件有英文版的，也有中文版的，有要收费的，有免费提供的。国内外已出现了一批质量较好的缺陷管理工具，其中比较有代表性的有：现了一批质量较好的缺陷管理工具，其中比较有代表性的有：开源软件开源软件Bugzilla、jira；Compuware公司的公司的TrackRecord；Rational公司的公司的ClearQuest；北京航空航天大学的北京航空航天大学的QAMonitor；上海微创软件有限公司的上海微创软件有限公司的BMS等。等。选用软件缺陷跟踪系统应该具备

47、如下要求：选用软件缺陷跟踪系统应该具备如下要求：安装简易、操作简易安装简易、操作简易；支持开发、构建、测试、验收多重迭代；支持开发、构建、测试、验收多重迭代；支持前台用户界面、后台缺陷数据库以及中间数据处理层；支持前台用户界面、后台缺陷数据库以及中间数据处理层；显示测试工作的成效和项目的进展情况；显示测试工作的成效和项目的进展情况；支持项目经理全程追踪督促支持项目经理全程追踪督促；支持开发组长、测试组长多级指派；支持开发组长、测试组长多级指派；完整的追踪信息展现完整的追踪信息展现；支持发现软件错误的类型，错误的严重等级；支持发现软件错误的类型，错误的严重等级；支持发布版本的缺陷关联支持发布版本

48、的缺陷关联；Mail实时通知缺陷任务实时通知缺陷任务。194软件测试的评估软件测试的评估软件测试的主要评测方法包括测试覆盖评估、质量评软件测试的主要评测方法包括测试覆盖评估、质量评估、缺陷评估和性能测试评估。估、缺陷评估和性能测试评估。1941测试覆盖评估测试覆盖评估覆盖测试评估是对测试完全程度的评估，它建立在测试覆覆盖测试评估是对测试完全程度的评估，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。执行代码的覆盖表示的。覆盖指标提供了覆盖指标提供了测试的完全程度如何？测试的完全程度如何？这一问题的答案。这一

49、问题的答案。最常用的覆盖测试评估是基于需求的测试覆盖和基于代码最常用的覆盖测试评估是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计或代码的设计/实施标准（基于代码的）而言的完全程度实施标准（基于代码的）而言的完全程度的评估，如用例的核实（基于需求的）或所有代码行的执的评估，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。行（基于代码的）。1基于需求的测试覆盖评估基于需求的测试覆盖评估基于需求的测试覆盖在测试生命周期中要评估多次，每一个测试阶段结束时给出测试覆基于需求的测试覆盖在测试生命

50、周期中要评估多次，每一个测试阶段结束时给出测试覆盖的度量。并在测试生命周期的各阶段（里程碑）提供测试覆盖的标识（如基于需求的、盖的度量。并在测试生命周期的各阶段（里程碑）提供测试覆盖的标识（如基于需求的、已计划的、已实施的、已执行的成功测试覆盖）。已计划的、已实施的、已执行的成功测试覆盖）。基于需求的基于需求的基于需求的测试覆盖率通过以下公式计算：基于需求的测试覆盖率通过以下公式计算：测试覆盖率测试覆盖率=T(p,i,x,s)/RfT%其中：其中：T是用测试过程或测试用例表示的测试是用测试过程或测试用例表示的测试(Test)数（已计划的、已实施的或成功数（已计划的、已实施的或成功的）。的）。R