《软件测试及其案例分析》课件第3章

第三章软件缺陷3.1基本概念3.2软件Bug的生命周期和Bug评估3.3软件Bug的特点和属性描述3.4软件Bug分类与评估3.5Bug产生的原因、查询经验和消除措施第三章软件缺陷3.6实际软件测试中常见的Bug3.7Bug收集、描述、分析、提交 3.8Bug确认、跟踪管理及管理系统3.9软件Bug处理及处理代价本章小结 软件测试的主要目的是发现软件存在的缺陷(Bug)。Bug存在于软件生存期的各个阶段，不同阶段的Bug的性质不同，而且不同的Bug需要的软件测试方法不同。对于如何处理测试中发现的Bug，将直接影响到测试的效果。只有尽早发现Bug、适当描述Bug、准确处理Bug，才能确保软件质量。本章介绍关于Bug的基本知识，以及Bug的确认、修复、验证、跟踪管理和处理等过程。

(1)软件错误：指在软件生存期内的不希望或不可接受的人为错误，其结果导致软件Bug的产生。软件错误是一种人为过程，相对于软件本身，是一种外部行为。

(2)软件故障：软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。当软件出现故障时，若无适当措施(如容错措施)加以及时处理，便产生软件失效。软件故障是一种动态行为。3.1基本概念

(3)软件缺陷(Bug)：是对软件产品预期属性的偏离现象。IEEE729-1983对Bug有一个标准定义：从产品内部看，Bug是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，Bug是系统所需要实现的某种功能的失效或违背。

(4)软件失效：软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。用户可以根据软件失效对系统服务的影响选择对于各种不同的失效的严重程度级别，如灾难性的失效、重大失效、微小失效等。

(5)

Bug严重程度：Bug严重程度是指因Bug引起的故障对软件产品的影响程度，是软件Bug对软件质量的破坏程度，即此软件Bug的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件Bug的严重性的判断应该从软件最终用户的观点出发，即判断Bug的严重性要为用户考虑，即考虑Bug对用户使用造成的恶劣后果的严重性。

(6)

Bug优先级：Bug的优先级指Bug必须被修复的紧急程度，是表示处理和修正软件Bug先后顺序的指标，即哪些Bug需要优先修正，哪些Bug可以稍后修正。

确定软件Bug优先级，更多的是站在软件开发工程师的角度考虑问题，因为Bug的修正是一个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正Bug的难度和风险。

(7)软件Bug的主要现象：

●

功能、特性没有实现或部分实现。

●

设计不合理，存在Bug。

●

实际结果和预期结果不一致。

●

运行出错，包括运行中断、系统崩溃、界面混乱。

●

数据结果不正确、精度不够。

●

用户不能接受的其他问题，如数据存取时间长、界面不美观等。

(8)每日构造Bug：每日构造Bug是现实“零Bug”管理的一项具体措施。所谓“零Bug”，只是一种高度负责的理念，是小组对质量的承诺。“零Bug”的产品并非没有Bug，而是符合预先定义的质量标准。所谓每日构造就是把每天做的源程序都编译成可执行的形式并在组内公开，每个人都可以看到每天的进展，并能做出评估。每日构造的好处在于易于暴露未预料的设计Bug；较早地诊断Bug；同步小组成员的工作；减少Bug集成的风险；提高了软件质量；保持对项目进度监控并且有利于增强小组成员和客户信心，同时增强项目成功的信心。

软件Bug的生命周期中的不同阶段是测试人员、开发人员和管理人员一起参与、协同测试的过程。软件Bug一经发现，便进入测试人员、开发人员、管理人员的严格监控之中，直至软件Bug的生命周期终结，这样可保证在较短的时间内高效地关闭所有Bug、缩短软件测试的进程、提高软件质量，同时减少开发和维护成本。3.2软件Bug的生命周期和Bug评估

1．概念

软件Bug的生命周期是指一个软件Bug被发现、报告到这个Bug被修改、验证直至最后关闭的完整过程。图3.1为Bug的生命周期描述。

图3.1Bug的生命周期具体的软件Bug的生命周期分为7个生命状态：New、Open、Reopen、Verify、Fixed、Close和Reject。这些状态能详细记录、跟踪和管理每个软件Bug的生命过程，直至排除这个Bug。

为软件Bug设定严重级别、优先级、Bug类型等属性，以自动分清软件Bug的轻重缓急，并能提供相关的分析和统计功能。软件Bug的生命周期分为简单的和复杂的软件Bug生命周期。

(1)简单的软件Bug生命周期的过程如下：

发现Bug→打开Bug→修复Bug→关闭Bug

●

发现→打开：测试人员找到软件Bug并将软件Bug提交给开发人员。

●

打开→修复：开发人员重现、修改Bug，然后提交给测试人员去验证。

●

修复→关闭：测试人员验证修改过的软件，关闭已不存在的Bug。上面的过程只是一种理想的状态，在实际的测试中是很难这样顺利执行，需要考虑到各种突发情况。

(2)复杂的软件Bug生命周期的过程如图3.2所示。

图3.2复杂的软件Bug生命周期

2．软件生命周期中Bug的费用统计

在计算机科学与技术领域，基于以下几点理由需要对Bug进行统计分析：①软件正成为一些关键系统中的重要部分；②软件是由易于出错的人来编制的；③软件的运行环境难以准确预计；④软件在开发和维护过程中对经费预算和进度的重视程度远比对其他环节的重视程度高；⑤软件规模日益扩大，软件复杂程度日益增高等，也促使软件测试正在逐步成为软件过程中一个新的重要行业。据统计分析表明，软件Bug在软件全生命周期中的分布规律见表3.1。软件测试在软件生命周期中的费用已占43%，见图3.3。比较表3.1和图3.3，可以看出软件测试和维护的重要性。表3.1软件Bug的分布规律

图3.3软件生命周期费用软件Bug并不像人们想象的那样，软件经过一段时间运行后Bug就很少了。但由于软件和硬件一样都有一个从成熟到衰老、直至淘汰的过程，而且在软件的使用过程中，其突发性Bug相比硬件来说会更突然、更致命。

软件Bug隐藏在代码中，如果按照正常的运行顺序、给出合乎常规的输入数据显示就不会使软件出异常。一旦发现软件Bug，就要设法找到引起这个Bug的原因，分析其对产品质量的影响，然后确定软件Bug的严重性和处理这个Bug的优先级。3.3软件Bug的特点和属性描述

1．软件Bug不可避免

软件Bug的一个最大特点是Bug不可避免。原因如下：

(1)在软件开发中会产生各种各样Bug。这些Bug可能从软件项目进行的初期阶段，如需求分析阶段就存在了。随着软件项目的进展，Bug的影响范围可能会不断扩大，到后期发现时可能已经到了无法弥补的程度，因为要修改这个Bug可能需要这个项目从头开始。在这种情况下，项目管理者和开发人员一般会尽全力进行补救，但是所有的办法可能都是权宜之计，根本的Bug仍然存在。

(2)从软件测试的角度认为根本不可能“完全”测试一个程序，因为在实际中人们不可能测试所有的输入，也不可能测试程序中所有的执行路径。如对于一个最简单的两个一位或两位数相加的程序，其有效的输入就有39601个不同数对；又如一个仅包含一个循环和一些IF语句的20行代码的简单程序，其程序的执行路径就有100万亿条之多，所以人们不可能“完全”测试程序，所以说软件总是存在Bug。

(3)在软件测试过程中，即使发现了Bug，并进行了改正，但是人们必须再一次进行测试，也可能会发现更多的Bug。因为改正一个Bug，可能会产生另一个Bug，只有改正了第一个，第二个才会暴露出来。有统计得出：如果对程序源代码的改动在10行以上或更多，那么首次就正确改正程序的可能性有50%；如果对程序源代码的改正50行左右，那么首次就正确改正程序的可能性仅有20%。

2．Bug属性描述

软件Bug属性一般包括Bug来源、Bug根源、Bug严重性、Bug优先级、Bug状态、Bug标识、Bug类型等。

1)

Bug来源描述

●

Requirement：由需求问题引起的Bug。

●

Architecture：由构架问题引起的Bug。

●

Design：由设计问题引起的Bug。

●

Code：由编码问题引起的Bug。

●

Test：由测试问题引起的Bug。

●

Integration：由集成问题引起的Bug。

2)

Bug根源描述

●

目标：错误的范围，误解了的目标，超越能力的目标等。

●

过程、工具和方法：无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等。

●

人：项目团队职责交叉，缺乏培训，没有经验的项目团队，缺乏士气和动机不纯等。

●

缺乏组织和通讯：缺乏用户参与，职责不明确，管理失败等。●

硬件：处理器Bug导致算术精度丢失，内存溢出等。

●

软件：操作系统错误导致无法释放资源、工具软件的错误、编译器的错误等。

●

环境：组织机构调整，预算改变、罢工、噪音、中断、工作环境恶劣等。

3)

Bug严重性等级描述

各种Bug所造成的后果不一样，有的仅仅是不方便，有的可能是灾难性的。根据Bug对系统的影响程度设定Bug的等级。一般Bug越严重，其处理优先级就越高，软件Bug可以概括为以下五种级别：

(1)轻微的(Cosmetic)。使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能，例如某个控件没有对齐，某个标点符号丢失等。

(2)微小的(Minor)。一些小Bug，指影响系统要求或基本功能的实现，但存在合理的更正办法。对功能几乎没有影响，产品或属性仍可以使用，如有个别错别字、文字排版不整齐等。

注意：重新安装或重新启动该软件不属于更正办法，如本地化软件的某些字符没有翻译或者翻译不准确。

(3)一般的(Major)。不太严重的Bug，指严重地影响系统要求或基本功能的实现，且没有办法更正。如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。这样的Bug虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。注意：重新安装或重新启动该软件不属于更正办法，如软件的某个菜单不起作用或者产生Bug的结果。

(4)严重的(Critical)。严重Bug，指不能执行正常工作功能或重要功能，或者危及人身安全。功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明，例如软件的意外退出甚至操作系统崩溃，造成数据丢失。

(5)致命的(Fatal)。致命的Bug，造成系统崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。

此外，有时还需要设置建议(Suggestion)级别来处理测试人员所提出的建议或质疑。

有时我们还会看到下面三种等级：

●

错误(Error)：可能会影响某个模块或功能的)。

●

功能Bug(DE-Bug)：指功能可以完成，但是还存在一些异常的小Bug。

●

缺陷(Bug)：指不会影响系统功能的Bug，如页面显示、美观、操作方便性等。

4)

Bug优先级描述

Bug优先级可以分为4级：1、2、3、4。描述如下：1级：最高优先级，如软件的主要功能Bug或者造成软件崩溃，数据丢失的Bug；2级：较高优先级，如影响软件功能和性能的一般Bug；3级：一般优先级，如本地化软件的某些字符没有翻译或者翻译不准确的Bug；4级：低优先级，如对软件的质量影响非常轻微或出现几率很低的Bug。

解决优先级描述：

●

立即解决(ResolveImmediately)—Bug必须被立即解决。●

正常排队(NormalQueue)—Bug需要正常排队等待修复或列入软件发布清单。

●

不紧急(NotUrgent)—Bug可以在方便时被纠正。

一般地，严重性程度高的软件Bug具有较高的优先级。严重性高说明Bug对软件造成的质量危害性大，需要优先处理，而严重性低的Bug可能只是软件不太尽善尽美，可以稍后处理。但是，严重性和优先级并不总是一一对应。有时候严重性高的软件Bug，优先级不一定高，甚至不需要处理，而一些严重性低的Bug却需要及时处理，具有较高的优先级。

5)

Bug状态描述

除了严重性和优先级外，还存在反映软件Bug处于一种什么样的状态，以便于及时跟踪和管理。Bug的不同状态有：

●

激活状态(ActiveorOpen)：测试人员新报的Bug，或验证后的Bug依然存在。

●

已修正状态(FixedorResolved)：开发人员针对所存在的Bug，修改程序后已解决问题或通过单元测试。

●

关闭或非激活状态(CloseorInactive)：测试人员验证FixedBug后，确认Bug不存在后的状态。●

仍存在的(Reopen)：程序员修改过，而测试未通过。

除了以上的基本状态，此外还有一些中间状态：

●

保留(Hold)：Bug目前无法解决或是由第三方软件产品引起的。

●

延期(Defer)：Bug暂时不需要解决或在下一版本中解决更彻底一些。

Bug处理状态描述：

●

Submitted：已提交的Bug。

●

Open：确认“提交的Bug”，等待处理。●

Rejected：拒绝“提交的Bug”，不需要修复或不是Bug。

●

Resolved：Bug被修复。

●

Closed：确认被修复的Bug，将其关闭。

同行评审Bug的严重程度：Major指主要的较大的Bug；Minor指次要的小的Bug。

根据一般的Bug管理软件，系统中的Bug一般采用状态管理方法。设置Bug的状态及等级的建议：

●

可以根据团队的习惯设置。

●

Bug的状态及等级，主要是以能使所有的开发人员及测试人员看懂Bug的情况为准。

6)

Bug处理角色

●

高级测试人员验证Bug，如果确认是Bug，分配给相应的开发人员，设置状态为Open；如果不是Bug，则拒绝，设置为Declined状态。●

开发人员查询状态为Open的Bug，如果不是Bug，则状态置为Declined；如果是Bug，则修复并置状态为Fixed；不能解决的Bug，要文字说明及保持Bug为Open状态。

●

对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议(评审会)认可。

●

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决状态置为Reopen。

7)

Bug的严重性和优先级

确定Bug的严重性和优先级要全面了解和深刻体会Bug的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的Bug较为严重，具有较高的优先级，而软件界面类Bug的严重性一般较低，优先级也较低。

Bug的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。为了尽量准确的表示Bug信息，通常将Bug的严重性和优先级分成4级。如果分级数超过4级，则造成分类和判断尺度过于复杂，而少于4级，精确性有时不能保证。具体的表示方法可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到低或从低到高的顺序，需在软件测试前达成一致。例如使用数字1、2、3、4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1、2、3、4可以分别表示低优先级、一般、较高优先级和最高优先级。

8)

Bug的严重性和优先级之间的联系

Bug的严重性和优先级是含义不同但相互联系密切的两个概念。它们从不同的侧面描述了软件Bug对软件质量和最终用户的影响程度和处理方式。软件测试初学者或者没有软件开发经验的测试工程师，对于软件Bug的严重性和优先级的作用及处理方式往往理解的不彻底。实际测试工作中不能正确表示Bug的严重性和优先级将会影响软件Bug报告的质量，不利于尽早处理严重的软件Bug，可能影响软件Bug的处理时机。

9)其他注意事项

修正软件Bug不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。

(1)如果某个严重的软件Bug只在非常极端的条件下产生，则没有必要马上解决。

(2)如果修正一个软件Bug，需要重新修改软件的整体架构，可能会产生更多潜在的Bug，而且软件由于市场的压力必须尽快发布，此时即使Bug的严重性很高，是否需要修正，需要多方面考虑。

(3)如果软件Bug的严重性很低，如界面单词拼写错误，可暂缓处理。但如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

比较规范的软件测试，使用软件Bug管理数据库进行Bug报告和处理，需要在测试项目开始前对全体测试和开发人员进行培训，对Bug严重性和优先级的表示和划分方法统一规定和遵守。在项目测试过程中和项目交付后，充分利用统计方法，做以下两项工作：

(1)统计Bug的严重性，确定软件模块的开发质量，评估软件项目实施进度。

(2)统计Bug优先级的分布情况，控制开发进度，使开发按照项目计划尽快进行，有效处理Bug，降低风险和成本。

为了保证报告Bug的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现的Bug及时反馈给项目负责人及时解决。对于测试人员而言，一般经验丰富的人员可以正确的表示Bug的严重性和优先级，为Bug的及时处理提供准确的信息。对于开发人员来说，开发经验丰富人员的严重的Bug较少。但是不要将Bug的严重性作为衡量开发人员水平高低的主要判断指标，因为软件模块的开发难度不同，各个模块的质量要求也有所差异。

因此，正确处理和区分Bug的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起测试人员的足够重视。

很多学者试图对软件的Bug进行分类，包括根据Bug发生的时间、Bug引起的后果、Bug性质等分类。这些分类方法都是从Bug的表现来分类的，3.4软件Bug分类与评估其作用只能是加深人们对软件Bug的认识，从以往所检测的效果分析出软件的Bug来源，从而可进一步分析Bug产生的原因，以期在未来的软件开发过程中尽量避免此类Bug的产生。但是这种模式对Bug的检测而言意义不大。其原因是每类Bug又对应着多种具体的子类型，难以用统一的方法对其进行测试。3.4.1Bug分类

1．按Bug的严重性分类(参考Bug的属性)

(1)致命Bug：使系统崩溃或挂起、破坏数据。

(2)严重Bug：使系统不稳定、菜单功能无法实现，而且是常规操作中经常发生或非常规操作中不可避免的。

(3)一般Bug：在完成某一功能时出现的Bug，但并不影响该功能的实现。系统性能降低或响应时间变慢、产生Bug的中间结果但不影响最终结果(如显示不正确但输出正确)，界面拼写错误或用户使用不方便。

(4)建议项：软件不完善或用户使用不方便之处。

从软件测试观点出发，可以把Bug分为五类：功能Bug、系统Bug、加工Bug、数据Bug和代码Bug等。

2．从功能角度分类(称为功能Bug)

(1)规格说明书Bug：规格说明书不完全、有二义性或自身矛盾。另外，在设计过程中可能修改功能，如果不能根据这种变化及时修改规格说明书，则产生规格说明书错误。

(2)产品说明书Bug：软件未达到产品说明书中规定的功能；软件功能超出产品说明书指定的范围。

(3)隐藏Bug：程序实现的功能与用户要求的不一致。一般是由于规格说明书包含错误的功能、多余的功能或遗漏的功能所致。在发现和改正这些Bug的过程中又可能引入新的Bug。

(4)文档Bug：是指对文档的静态检查过程中发现的Bug，通过测试需求分析、文档审查而发现的Bug。

(5)测试Bug：软件测试的设计与实施发生Bug，是指由测试执行活动发现的被测对象(被测对象一般是指可运行的代码、系统)的Bug，因此软件测试自身也可能发生Bug。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多Bug。

(6)测试标准引起的Bug：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能性就大。

(7)稳定性Bug：影响用户正常运行，系统不断申请但不完全释放资源，造成系统性能越来越低，并出现不规律的死机现象且不能重现的Bug，有些与代码中的未初始化变量有关，有些与系统不检查异常情况有关。

(8)界面Bug：用户无法使用或不方便使用设计的界面。

(9)测试人员认为软件难以理解、不易使用、运行速度缓慢，或最终用户认为该软件不好。

3．从系统角度分类

(1)外部接口Bug：外部接口是指终端、打印机、通信线路等系统与外部环境通信的接口。所有外部接口之间、人与机器之间的通信使用专门的协议，如果协议有错，或太复杂难以理解，致使在使用中出错。此外，还包括对输入/输出格式的错误理解，对输入数据不合理的容错等。

(2)内部接口Bug：内部接口是指程序内部子系统或模块之间的联系。它所发生的Bug与外部接口相同，只是与程序内实现的细节有关，如使用协议错、输入/输出格式错、数据保护不可靠、子程序访问错误等。

(3)硬件结构Bug：与硬件结构有关的软件Bug在于不能正确地理解硬件如何工作。如忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。

(4)软件结构Bug：由于软件结构不合理而产生的Bug。这种Bug通常与系统的负载有关，而且往往在系统满载时才出现。如错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元已初始化；错误地假定被调用子程序常驻内存或非常驻内存等，都可能导致软件出错。

(5)操作系统Bug：与操作系统有关的软件Bug在于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有Bug，而一般用户很难发现这种Bug。

(6)控制与顺序Bug：如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉先决条件；规定Bug的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。

(7)资源管理Bug：由于不正确地使用资源而产生的Bug。如使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接到错误的队列中等。

4．从加工的角度分类

(1)算法与操作Bug：指在算术运算、函数求值和一般操作过程中发生的Bug。如数据类型转换错；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮点数进行比较等。

(2)初始化Bug：如忘记初始化工作区，忘记初始化寄存器和数据区等；错误地对循环控制变量赋初值；用不正确的格式、数据或类的类型进行初始化等。

(3)控制和次序Bug：与系统级同名Bug相比，它是局部Bug。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。

(4)静态逻辑Bug：如不正确地使用switch语句；在表达式中使用不正确的否定(如用“>”代替“<”的否定)；对情况不适当地分解与组合；混淆“或”与“异或”等。

(5)过程Bug：又称为不符合项Bug，指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的Bug。过程Bug的发现者一般是质量经理、测试经理、管理人员等。

5．从数据角度分类

(1)动态数据Bug：动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域。若程序启动时对这个区域未初始化而导致数据出错。

(2)静态数据Bug：静态数据在内容和格式上都是固定的。它们直接或间接的出现在程序或数据库中，有编译程序或其他专门对他们做预处理，但预处理也会出错。

(3)数据内容、结构和属性Bug：数据内容指存储于存储单元或数据结构中的位串、字符串或数字。数据内容Bug是指由于内容被破坏或被错误地解释而造成的Bug。数据结构指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构Bug包括结构说明Bug及数据结构误用的Bug。数据属性是指数据内容的含义或语义。数据属性Bug包括对数据属性不正确地解释，如错把整数当实数，允许不同类型数据混合运算而导致的Bug等。

(4)数据有效性Bug：对输入的数据没有进行充分并且有效的有效性检查，造成不合要求的数据进入数据库。

6．从代码的角度分类

代码Bug指在代码被同行评审、审计或代码走查过程中发现的Bug，包括数据说明Bug、数据使用Bug、计算Bug、比较Bug、控制流Bug、界面Bug、输入\输出Bug等。

3.4.2Bug评估

Bug评估是对测试过程中Bug达到的比率或发现的比率提供一个软件可靠性指标。对于Bug分析，常用的主要参数有四个：①状态：Bug的当前状态；②优先级：必须处理和解决Bug的相对重要性；③严重性：对最终用户、组织或第三方的影响等；④起源：导致Bug的起源故障及其位置，或排除该Bug需要修复的构件。

软件测试的Bug评估可依据以下四类进行度量：Bug发现率、Bug潜伏期、Bug分布(密度)和整体软件Bug清除率。图3.4Bug发现率

(1)

Bug发现率：将发现的Bug数量作为时间的函数来评估。创建Bug趋势图或报告，如图3.4所示。

由图3.4看出，Bug发现率将随着测试时间和修复进度而减少；随着测试时间延长而测试成本增加。可以设定一个阈值，在Bug发现率低于该阈值时才能应用软件。

(2)

Bug潜伏期：Bug潜伏期是一种特殊类型的Bug分布度量。Bug潜伏期报告显示Bug处于特定状态下的时间长短。在实际测试工作中，发现Bug的时间越晚，此Bug所带来的危害就越大，修复该Bug所消耗的成本就越多。

(3)

Bug分布：Bug分布报告允许把Bug计数作为一个或多个Bug参数的函数来显示。软件Bug分布是一种以平均值来估算软件Bug的分布值。程序代码通常是以千行为单位，软件Bug分布度量使用下面的公式计算：

(4)整体软件质量、Bug注入率、清除率：

设F为描述软件规模用的功能点；D1为软件开发过程中发现的所有软件Bug数；D2为软件使用后发现的软件Bug数；D为发现软件Bug的总数，则D

=

D1

+

D2。

对于一个软件项目，可从不同角度来估算软件的质量、Bug注入率、清除率：

(5)

Bug修复率标准。

①一、二级Bug修复率应达到100%(若对一、二、三级Bug给出了定义)。

②三、四级Bug修复率应达到80%以上。

③五级Bug修复率应达到60%以上。

1．Bug产生的原因

在软件开发过程中，软件Bug的产生是不可避免的。造成软件Bug的原因有很多，下面从软件本身、技术问题、团队工作和软件项目管理问题等角度，分析造成软件Bug的主要因素。3.5Bug产生的原因、查询经验和消除措施

1)软件本身

●

文档Bug。用户使用场合、时间上不一致或不协调所带来的Bug。

●

系统的自我恢复或数据的异地备份、灾难性恢复等的Bug。

2)技术问题

主要包括：算法Bug、语法Bug、计算和精度Bug、系统结构不合理、算法选择不科学，造成系统性能低下、接口参数传递不匹配、导致模块集成出现的Bug等。

●

算法Bug指在给定条件下没能给出正确或准确的结果。●

语法Bug指对于编译性语言程序，编译器可以发现这类Bug；但对于解释性语言程序，只能在测试运行时才能发现这类Bug。

●

计算和精度Bug指计算的结果没有满足所需要的精度。

3)团队工作

●

系统需求分析时对客户的需求理解不清楚，或与用户的沟通存在一些困难。●

不同阶段的开发人员相互理解不一致。如软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

●

对于设计或编程上的一些假定或依赖性，相关人员之间没有充分沟通。

●

项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起Bug。

4)项目管理的问题

●

缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试等所需要的时间，遗留的Bug会比较多。

●

系统分析时对客户的需求不是十分清楚，或与用户的沟通存在一些困难。

●开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照拟定的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短还给各类开发人员造成太大的压力，引起一些人为的Bug。●

开发流程不够完善，存在一些随机性和缺乏严谨的内审或评审机制，容易产生问题。

●

文档不完善，风险估计不足等。

5)其他原因

从软件产品的特点和开发过程分析，软件Bug产生的主要因素如下：

●

需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的Bug。●

需求规格说明书包含错误的需求，或漏掉一些需求，或没有准确表达客户所需要的内容。

●

需求规格说明书中有些功能不可能或无法实现。

●

程序设计中的Bug，或程序代码中的问题，包括错误的算法、复杂的逻辑等。

●

对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界Bug。

●

系统设计中的不合理性。●

系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面Bug。

●

对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调、不一致性带来的Bug。●

没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等Bug，从而存在系统安全性、可靠性的隐患。

●

系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的Bug；在系统实际应用中，数据量很大。从而会引起强度或负载Bug。

●

由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等Bug。

●

新技术的采用可能涉及技术或系统兼容的Bug。

2．查找Bug的经验

(1)像无经验的用户那样做：输入意想不到的数据；中途变卦而退回去执行其他操作；单击不应该单击的选项等。

(2)在已找到软件Bug之处再找，原因是：①软件Bug具有集中性特点。如果发现在不同的特性中找出了大量上边界条件Bug，那么就应该对所有特性着重上边界条件。对某个存在的Bug，应当投入一些案例来保证这个问题不是普遍存在；②程序员往往倾向于只修改报告出来的软件Bug。如报告启动－终止－再启动255次导致冲突，程序员可能只修复了这个问题。重新测试时，一定要重新执行同样的测试256次以上。

(3)凭借经验、直觉和预感：记录哪些技术有效，哪些不行。尝试不同的途径，如果认为有可疑之处，就要仔细探究。按照预感行事，直至证实这是Bug为止。

3．消除措施

任何软件都存在Bug，通过完全测试发现所有的软件Bug是不现实也是不可能的。有两项措施来尽量减少软件中的Bug：

(1)应该在开发软件时由软件开发机构和客户一起制订合理、客观的验证规则，满足客户需求。

(2)由于需求的改变造成设计、编码上的修改要及时以文档的形式给出。

在软件开发过程中可能出现的Bug：问题判定Bug、算法Bug、设计Bug、逻辑Bug、语法Bug、编译Bug、输入Bug、输出Bug等。

1．软件开发过程Bug列举

根据软件开发过程，人们认为以下7种情况软件有Bug：

(1)软件没有完成需求规格说明书给出的功能需求。3.6实际软件测试中常见的Bug

(2)由于理解上的偏差，没有严格遵循软件设计要求。

(3)由于编码实现与软件设计之间的接口出现了问题，使得软件出现了不应有的Bug，有时甚至无法运行。

(4)软件功能超出了产品说明书预先指明的范围。

(5)软件没有达到产品说明书虽未指出但应达到的目标。

(6)软件测试人员在实施静态分析时，发现编码实现冗余，导致运行速度缓慢。

(7)客户认为软件有Bug，不能满足其要求。

2．常见的Bug类型

下面给出一些常见的Bug类型：

●

功能：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构，并且设计文档需要正式的变更，如逻辑、指针、循环、递归和功能等Bug。

●

赋值：需要修改少量代码，如初始化或控制块、声明、重复命名、范围、限定等Bug。

●

性能：不满足系统可测量的属性值，如执行时间、事务处理速率等。●

接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的Bug。

●

检查：提示错误信息，不适当的数据验证等的Bug。

●

联编打包：由于配置库、变更管理或版本控制引起的Bug。

●

文档：需求、设计、影响发布和维护等文档，包括注释的Bug。

●

语法：拼写、标点符号、打字等的Bug。

●

用户接口：人机交互特性，如屏幕格式，确认用户输入，功能有效性，页面排版等方面的Bug。●

数据接口：未提供与一些常用的文件格式的接口，如txt文件、Word文件。

●

标准：不符合各种标准的要求，如编码标准、设计符号等的Bug。

●

环境：设计、编译、其他支持系统问题等的Bug。

3．容易忽略的Bug

下面列举一些显而易见的、容易被项目组忽略的Bug，这些Bug可能是容易修改或容易避免的，但是常常会给软件测试组测试或用户使用造成困难。

●

不符合用户操作习惯。如快捷键定义不科学、不实用，键位分布不合理，按键太多，甚至没有快捷键。

●

输入无合法性检查和值域检查，允许用户输入Bug的数据类型，并导致不可预料的后果。

●

无自动安装程序或安装程序不完善。●

程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(缺少一些必要的模块或文件)。

●

说明书或帮助的排版格式不对：如中英文搭配不对、标点符号全角半角不分、没有排版准则等。

●

要求用户输入多余的、本来系统可以自己得到的数据。如服务是否启动，安装后用户要手动修改某些配置文件。

●

某一项功能的冗余操作太多，如对话框嵌套层次太多。

●

对复杂的操作无联机帮助。

●

对一般性Bug的屏蔽能力较差。

4．稳定性问题的Bug

●

不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低。

●

主系统和子系统使用同样的临界资源而互相不知道。如使用同样的类名或临时文件名、使用同样的数据库字段名或登录账号。

●

不能重现的Bug，许多与代码中的未初始化变量(在DeBug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。

5．计算中常见的Bug

●

误解或用错了运算符的优先级。

●

精度不够。

●

混合类型运算错误。

●

表达式符号错误。

●

变量初值错误。

6．用户界面Bug

●

界面元素参差不齐，文字显示不全，按Tab键时鼠标乱走。

●

界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词。

●

表达不清或模糊的信息提示。

●

为了达到某个设置或对话框，用户必须做许多冗余操作，如对话框嵌套层次太多。

●

不能记忆用户的设置或操作习惯，用户每次进入都需要重新设置初始环境。●

使用不完善的功能且不给用户以恰当的提示。

●

提示信息意义不明或为原始的英文提示。如Setup界面中“CopyRight1994-1996和缺省认为用户使用某种分辨率”，用户不知何意。

●

不经用户确认就对系统或数据进行重大修改，影响用户正常工作。

●

界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。如数据库中剩余记录个数和参数设置对话框中的预设值常常显示为历史值而不是当前值。

7．其他的Bug

●

用户文档问题：无标准；无新功能使用方法；无版本改动说明。

●

兼容性问题：对硬件平台或软件平台的兼容性不好。如在这台计算机上可以稳定运行，而在另一台上运行就极不稳定。

●

运行时不检查内存、数据库或硬盘空间等。

●

无根据地假设用户环境：硬件/网络环境；某些动态库；假设网络随时都是连通的。●

提供的版本带病毒，或根本无法安装，或没有加密。

●

提供Bug版本给软件测试组或软件测试用户，或项目组与软件测试组使用不同版本。

●

用户现场开发和修改，又没有记录和保留。

●

Bug反复出现，改动得不彻底、或版本管理出现混乱。

●

Bug越改越多，改动得不彻底、或改动得不细心。

●

版本中部分内容和接口倒退。●

有些选项永远是灰的；有些选项、菜单项在该灰色时不灰，并且还能状态显示。

●

资源没有和代码分离，不同语言版本间不能平滑转换。

●

缺少第三方软件产品的评估。

●

软件产品配合不好，准备当做一套软件产品或方案推出，互相之间却各不负责，没有整个项目负责人等。

项目组期望关注的一些Bug：●

修改Bug的人考虑得不够周全，可能没有能力考虑周全，因为他不懂全部程序。

●

一些开发人员不仔细进行软件测试、不小心修改、甚至不全面修改(不彻底)，存在问题留给软件测试组去发现的心态。

在程序代码中，比较判断语句与控制流语句常常紧密相关，测试用例还应致力于发现下列Bug：

●

不同数据类型的对象之间进行比较。

●

错误地使用逻辑运算符或优先级。●

因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等。

●

比较运算或变量出错。

●

循环终止条件或不可能出现。

●

Bug修改了循环变量。

●

迭代发散时不能退出。

一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列Bug：●

输出的出错信息难以理解。

●

记录的Bug与实际遇到的Bug不相符。

●

在程序自定义的出错处理段运行之前，系统已介入。

●

异常处理不当。

●

Bug陈述中未能提供足够的出错定位信息。

人们平时测得的Bug实际上是软件故障与失效的体现。一旦软件Bug得到修改，相应的故障与失效也就解除了。3.7Bug收集、描述、分析、提交为了对Bug进行管理，首先应对Bug进行分类，通过对Bug进行收集、分析、分类、提交和跟踪管理，可以迅速找出哪一类Bug的问题最大，然后集中精力预防和排除这一类Bug。这也是Bug管理的关键，一旦这类Bug得到控制，再进一步找到新的容易引起问题的几类Bug。确保每个被发现的Bug都能够及时得到处理，是软件测试工作的一项重要内容。

1．收集

Bug管理的第一步是了解Bug。为此，首先必须收集Bug数据，并且找出如何处理它们的方法，同时也能更好地发现、修复甚至预防仍在引入的Bug。收集关于Bug的数据的步骤如下：

(1)对测试和同行评审中发现的每个Bug要记录详细的信息，以便能更好地了解这个Bug。

(2)分析这些数据，找出引起大部分问题的Bug类型。

(3)设计出发现这些Bug的方法(以便排除Bug)。

通常为了收集Bug数据，可以采用Bug记录日志方式登记(见表3.2)所发现的每一个Bug。表3.2Bug记录日志修复Bug一栏说明此Bug是由于修复其他Bug而引入。引入阶段表示该Bug的来源，排除阶段表示发现这个Bug的阶段。对于Bug记录日志中的描述应该足够清楚，以便今后可以了解该Bug的起因。

系统测试中需详细记录Bug的信息。

(1)出现Bug的操作顺序及操作数据。以便程序员更改Bug时可以重现。最好有截图显示Bug。

(2)

Bug出现的版本或日期。

(3)

Bug的严重程度——对系统的影响程度。

2．Bug信息描述

Bug记录总的来说包括两方面：由谁提交和Bug描述。一般而言，Bug都是谁测试谁提交，当然有些公司可能为了保证所提交Bug的质量，还会在提交前进行Bug评估，以确保所提交的Bug的准确性。如果做得不好，会误导读者；好的Bug描述应该包括以下基本部分：标题、项目、预置条件、操作步骤、预期结果、所属模块、优先级、严重性、异常等级、重复性、分布概率、版本、测试者、测试日期和附件等。至少要包括以下一些方面内容(可以填表形式提交)，见表3.3。表3.3Bug信息描述

Bug的基本信息详细介绍

●

Bug的ID：唯一的表示Bug，可以根据该ID追踪Bug。

●

Bug状态：Bug的状态分为已提交、待分配、已分配、已处理、已关闭、未关闭。

●

Bug标题：描述Bug的标题。

●

Bug级别：一级(功能错误或系统错误)、二级(加工或数据错误)、三级(数据完整性或规范性错误)、建议类(界面提示错误)、疑问(此功能不理解错误)。

●

Bug优先级：立刻解决、一般关注、低优先级。●

Bug类别：程序错误、接口错误、文档错误、数据错误等。

●

Bug提交人、时间：Bug提交人的名字(包括邮件地址)、Bug提交时间。

●

Bug所属项目、模块：Bug所属的项目和模块最好能较精确的定位至模块。

●

Bug指定解决人：在Bug分发状态下由项目经理指定相关开发人员修改Bug、修改结果反馈。

●

Bug处理人：最终处理Bug的处理人的姓名和邮件地址。●

Bug指定解决时间：项目经理指定的开发人员修改此Bug的期限。

●

Bug处理时间：处理Bug的时间。

●

Bug处理结果描述：如果对代码进行了修改，要求在此处体现出修改的过程和修改

内容。

●

Bug验证人：对被处理Bug验证的验证人。

●

Bug验证结果描述：对验证结果的描述(通过、不通过)。

●

Bug验证时间：对Bug验证的时间。

●

对于某些文字很难表达清楚的Bug，可使用图片。●

对Bug的详细描述：对Bug描述详细程度直接影响开发人员对Bug的修改，描述应该尽可能详细，包括对测试环境的描述。

以上是描述一个Bug时通常所要描述的内容，当然在实际提交Bug时还可以根据实际情况进行补充，如附上图片、log文件等。另外，一个版本软件测试完毕，还要根据测试情况给出一份测试报告，这也是需要经过的一个环节。

3．状态描述(参考上面描述)

软件Bug的状态描述如下：

(1)新信息：测试中新报告的软件Bug。

(2)打开：被确认并分配给相关开发人员处理。

(3)修正：开发人员已完成修正，等待测试人员验证。

(4)拒绝：拒绝修改Bug。

(5)延期：不在当前版本修复的Bug，在下一版本修复。

(6)关闭：Bug已被修复。

4．Bug分布、统计分析

(1)按照Bug严重程度及软件类型分布：由此可以统计整个项目生命周期中所有同行评审的Bug分布，也可以统计某一阶段所有同行评审的Bug分布。

(2)按照Bug类型分布：按照Bug类型统计分布图。

●

某一次评审的Bug统计。

●

某一类型软件评审的Bug统计。

●

某一阶段所有同行评审的Bug统计。

●

整个项目周期内所有同行评审的Bug统计。

建议以某一类型软件和某一阶段来进行统计分布。

(3)按Bug的分布曲线：

●

正常的Bug分布曲线描述为刚开始Bug数很多，几个版本后，Bug数趋于收敛，到最后Bug数很少或没有严重、致命的Bug。

●

非正常的曲线描述为刚开始很少，到后期越来越多的趋势，而且很多隐藏比较深的Bug也是在软件快要交付的时候才被发现，甚至在软件系统试验后。在这种情况下，往往在规定的时间测试无法正常结束，产品也就不能按时交付，其成本很高。

5．Bug提交

测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理。如果这个Bug在软件需求说明书中明确提到，称其为软件功能Bug，它必须让程序员实现，提交程序员进行处理。但如果需求说明书没有明确提到，则可以定位为需求Bug。这样处理有以下好处：

(1)需求Bug再不像以前，没有人进行确认，需求的处理人员本来就是需求人员，应该由他们确认与跟踪需求Bug，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。

(2)测试人员从本质上来说与程序员是对立的。测试人员协调好与开发人员的关系，让他们更有效的对软件本身的Bug形成有效的关注是最好的。

(3)测试人员的激情很重要，如果他们的想法没有得到体现，这时会渐渐地失去对测试的兴趣，从而软件的质量就无法得到保证。他们的建议通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。

对于一个测试人员，要提交好的测试Bug必须遵循以下八个步骤：

①结构：无论是做探索性的还是描述性的、手工的、自动的测试，都要认真仔细测试。②再现：尽量三次再现Bug。如果问题是间断的，则最好报告Bug发生的概率。如每测试三次出现一次，每测试三次出现两次等。

③推广：确定系统其他部分是否可能出现这种Bug，以及使用不同的数据是否可能出现这种Bug，特别是那些存在严重影响的Bug。

④总结：简要描述客户或用户的质量体验和观察到的一些特征。

⑤精简：精简任何不必要的信息，特别是冗余的测试步骤。⑥去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。

⑦中立：公正地表达自己的意思，对Bug及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。

⑧评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在提交测试报告或测试评估报告之前先自己读一遍。

测试Bug的正确描述是测试人员发现了什么，而不是他做了什么。因此，只需要根据上述八个步骤写下最少的必须重现步骤即可。

6．Bug分析

分析Bug的标准是通过收集Bug，对比测试用例和Bug数据库，分析确定是漏测还是Bug复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。对于已有相应测试用例，则反映实施测试或变更处理存在问题。

1．确认

(1)程序员修改Bug后，可能出现因修改一个Bug，引起更多其他Bug的情况。所以对Bug的确认，不但要确认修改的Bug情况，更要重新测试与Bug相关的其他功能，有时甚至要对整个系统重新测试。3.8Bug确认、跟踪管理及管理系统

(2)系统后期测试。因时间比较紧迫，当进行Bug确认测试时，测试员往往只忙于正确性测试，容易忽略做破坏性测试，导致测试不全面。

2．Bug跟踪管理

对Bug进行跟踪管理，确保每个被发现的Bug都能够及时得到处理是测试工作的一项重要内容。Bug管理的一般步骤：

(1)测试人员提交新的Bug入库，Bug状态为New。

(2)高级测试人员验证B