第8章_软件BUG和管理

1、第八章软件第八章软件BUGBUG和管理和管理 本章要点本章要点 .软件Bug对软件质量的影响； .常见的软件Bug类型，重现软件Bug的分析技术； .软件Bug的描述和管理。 本章目标本章目标 了解软件BUG的影响和产生； 掌握软件开发过程中产生的BUG种类； 掌握使BUG重现的技术； 了解软件BUG报告单应该包括的主要内容以及 软件BUG的管理流程。 8.1软件BUG概述 在IEEE 1983 of IEEE Standard 729中对软 件缺陷下了一个标准的定义： （1）从产品内部看，软件缺陷是软件产品开发或 维护过程中所存在的错误、毛病等各种问题； （2）从外部看，软件缺陷是系统所需要

2、实现的某 种功能的失效或违背。 软件缺陷有很多种，其中主要软件缺陷类 型有： 1.一些功能、特性没有实现或只实现了一部分； 2.软件设计不合理，存在缺陷。实际运行结果和预期 结果不一致； 3.运行出错，包括运行中断、系统崩溃、界面混乱 4.数据结果不正确、精度不够； 5.用户不能接受的其他问题，如存取时间过长、界面 不美观。 8.1.1 8.1.1 BUG的影响的影响 Bug会给用户或使用者带来相当大的麻烦，会 给集体或者国家带来很大的经济损失。如：千年虫 问题。 8.1.2 BUG的产生的产生 BUG的由来。的由来。 对于软件而言，对于软件而言，BUG是程序编写错误而导致软是程序编写错误而导

3、致软 件产生问题的缺陷。件产生问题的缺陷。 软件测试的目的就是找到软件程序代码内的BU G，纠正它，叫做DEBUG。 BUG产生的原因很多，具体有以下几点。 1程序编写错误 Bug的难以避免性。 2需求变更过于频繁 需求变更所造成的结果就是变更程序代码，程序 代码只要稍做变更就必须经过测试来确保运行正常， 所以这个影响是一个连锁反应或称为依存问题。 3软件的复杂度 图形用户界面（GUI）、BS 结构、面向对象设计、 分布式运算、底层通信协议、超大型关系型数据库 以及庞大的系统规模，都体现了软件复杂度大大高 于以前，Bug出现可能性就更高。 4交流不充分或者沟通出问题 大部分项目人员在同客户进行

4、交流时常常存在着各 种各样的问题，究其原因，还是因为项目人员、参 与人员和客户之间没有详细、充分、谨慎地进行交 流。 5测试人员的经验与技巧不足 6时间过于紧迫 7缺乏文档：贫乏或者差劲的文档使得代码维护 和修改变得非常困难，结果会导致其他开发人员 或客户有许多错误的理解。 8管理上的缺陷 8.2 BUG的种类的种类 BUG是软件“与生俱来”的特征，不同的软 件开发阶段会产生不同的BUG，而不同的BUG又 会产生不同的后果，因此BUG的属性也并非相同。 8.2.1需求阶段的需求阶段的BUG 这个阶段的BUG是最难发现、最难修复的，而 且值得注意的是需求阶段的BUG如果没有及时发现 等到实现阶段

5、发现时，那么修复它的费用要比当初 修复它要高1575倍。 主要的原因如下： 1、模糊、不清晰的需求； 2、被忽略的需求； 3、相互冲突的需求； 8.2.2分析设计阶段的分析设计阶段的BUG 设计中的BUG比需求阶段产生的BUG特征明显 易于捕获，但是其维修代价很高，原因是设计BUG 已经作为一个整体影响着整个系统的实现。 原因主要有3种途径。 1 、忽略设计； 2、混乱的设计； 3、模糊的设计； 8.2.3实现阶段的BUG 就是软件系统中最普通、最一般的“常规BUG”。 可以将实现阶段出现的BUG分为下面几类： 1、消息错误 2、用户界面错误 3、遗漏的功能 4、内存溢出或者程序崩溃 5、其他

6、实现错误 第一类型说明了软件系统向用户发送了出错的 消息，可能消息是合理的或者表现为某种中断机 制，但是用户认为这是一个BUG。 如下图： 第二类型就是用户界面错误，可归纳为GUI错误。 可能是由于GUI制作不标准而导致用户不能正确地 工作。 第三种类型为遗漏的功能BUG (以输入框输入信 息错误，程序抛出未异常为典型) 第四种类型为内存溢出或者程序崩溃BUG，表现 为程序挂起、系统崩溃，属于一种比较严重的软件 BUG类型。（详见教材的药房药品进存销的软件测 试BUG） 8.2.4配置阶段的配置阶段的BUG 配置阶段的BUG出现的原因是复杂的，比较典型 的是旧的代码覆盖了新的代码，或者测试服务

7、器上 的代码和实现人员本机最新代码版本不一致。 可能是实现人员操作配置管理工具不正确引起 的；还可能体现了测试人员或者最终用户操作不 正确。 8.2.5短视将来的短视将来的BUG “千年虫”问题就是当初的设计人员为了节省 一点硬件成本给全球造成了难以估量的损失。 作者曾经为一家大药房开发了一套药品管理 的进销存软件，由于最初的时候对业务流程并不 是很熟悉，所以在定义药品编码的时候把许多药 品的ID号定义为了整型变量（INT），开始作者认 为这些足以定义所有的药品名称了，没想到 一年以后，由于药房的业务量急增，药品的ID也 就不够了，由于整套系统是由Power Builder编写， 整型变量的最

8、大值只有32767，因此程序经常由于 数据溢出而出现问题，所以作者被迫用了近一个 星期的时间来修改原来的程序。 8.2.6静态文档的静态文档的BUG 文档BUG的定义很简单，即说明模糊、描述 不完整和过期的都属于文档BUG。说明模糊特指 无充分的信息判断如何正确地处理事情；描述不 完整特指文档信息不足以支持用户完成某项工作； 过期的文档是没有及时更新过的、错误的文档。 8.3.1 BUG报告单的内容报告单的内容 BUG报告单也叫缺陷报告单或者问题报告单。 问题报告单所需的基本信息类型是大同小异的， 不同的只是组织和标志。 介绍一下字段： （1）问题报告编号 （2）程序名 （3）版本标识：发布号

9、和版本号。是用来识别被 测的代码。 例如：某个版本号可能是1.01m，发 布号是1.01，“m”指1.01版本的第13稿。 （4）报告类型：描述了发现的问题类型。包括：编 码错误 、设计问题 、建议 、文档 、硬件、质疑。 （5）严重性：为问题严重程度评分。 包含三个等级： 三个等级：轻微的、严重的和致命的。 （6）附件 存有测试数据的软盘、键盘捕获记录或一组可产 生测试用例的宏、程序的打印输出、内存dump或 一份注释，里面详细描述了你所做的操作，以及 你认为该问题很重要的原因。 （7）问题概要：对问题进行描述，有助于评审突出 的问题，并找到相应的问题报告。 （8）问题能否重现。要多次测试看

10、能否再次出现。 （9）问题描述及如何重现。描述所有的步骤和现象， 包括错误信息。一定要提交报告。 （10）建议的改正措施 （11）报告人 （12）日期：指的是报告人员发现问题的日期。 （13）功能域：对问题进行大体分类。 （14）承办人 （15）注释：程序员在这里简短地说明为什么要推 迟处理，或说明是如何改正问题的。 （16）状态。三个状态码：开放、关闭和已解决。 （17）优先级。只由项目经理设置。 （18）处理状态与处理版本 处理状态定义了问题的当前状态： 未解决：初始化状态或仍有冲突状态。 已改正 不能重现 暂缓：对存在的问题在下个版本改正。 符合设计 由报告人撤回 需要进一步信息 不同意

11、建议 重复:关闭重复上报的缺陷。 （19）签名:签署以表明已经对改动进行了测试，对 结果表示满意。 （20）暂缓处理：对缺陷的推迟处理。 图图8-3 8-3 、8-48-4整合起来即为一张完整的报告单。整合起来即为一张完整的报告单。 公司名称 密级 问题报告编号: 程序名 发布号 版本号 报告类型(1-6) 严重性（1-3） 附件（Y/N） 1.编码错误 4.文档 1.致命性 2.设计问题 5.硬件 2.严重性 3.建议 6.质疑 3.轻微性 如果有,请描述: 问题概要 问题能否重现?(Y/N) 问题描述及如何重现 建议的改正措施(可选) 报告人日期 下面各项仅供开发组填写 功能域 承办人 注

12、释 状态(1-2)优先级(1-5) 1.开放 2.关闭 处理状态(1-9) 处理版本 1.未解决 4.暂缓 7.由报告人撤回 2.已改正 5.符合设计 8.需要进一步信息 3.不能重现 6.重复 9.不同意建议暂缓处理(yes/no) 图8-3 报告单(part 1) 公司名称 密级 问题报告编号: 程序名 发布号 版本号 报告类型(1-6) 严重性（1-3） 附件（Y/N） 1.编码错误 4.文档 1.致命性 2.设计问题 5.硬件 2.严重性 3.建议 6.质疑 3.轻微性 如果有,请描述: 问题概要 问题能否重现?(Y/N) 问题描述及如何重现 建议的改正措施(可选) 报告人日期 下面各

13、项仅供开发组填写 功能域 承办人 注释 状态(1-2)优先级(1-5) 1.开放 2.关闭 处理状态(1-9) 处理版本 1.未解决 4.暂缓 7.由报告人撤回 2.已改正 5.符合设计 8.需要进一步信息 3.不能重现 6.重复 9.不同意建议暂缓处理(yes/no) 图8-4 报告单(part 2) 8.3.2 BUG 8.3.2 BUG报告的特点报告的特点 一份好的问题报告应是书面的、已编号的、 简单的、易于理解的、可重现的、易读的和不做 判断的。 1) 书面的 一份书面的报告是必要的，供日后对修改后 的程序进行测试时使用；让管理层、销售人员和 产品支持人员检查。 2) 已编号的 依据惟

14、一的编号跟踪问题报告。 3) 简单的 一份报告应只描述一个问题，不要在一份 报告中记录多个缺陷。 4) 可重现的 一定要强调BUG的可重现性。 5) 不做判断的 对程序员的评价要三思而后行，本着合作的 精神，作出合理的判断。 8.3.38.3.3重现重现BUGBUG的分析和方法的分析和方法 本节重点是报告编码错误报告编码错误，而非报告设计问题。 一、重现BUG的分析 “可重现”隐含了下列定义： 我们能够描述如何让程序进入某个已知的状态。 任何熟悉程序的人都能够依照我们的描述使程 序进入该状态。 从那个状态出发，我们确定出精确的一组步骤 来暴露出问题。 为使报告更有效，我们应该对问题进一步分析，

15、 目的在于： 1）找出问题最严重的后果。 找出某个BUG导致的最严重的后果，这样可 以激发人们改正它的兴趣。一个看来很轻微的问 题往往更有可能被暂缓处理。 例如：假设有个BUG在屏幕角落显示了一个 无用的字符，这个问题很轻微，但是是可以报告 的。有些时候，屏幕上显示出无用信息只是一个 孤立的问题（因此对它置之不理的决定可能是明 智的，尤其是程序快要交付的时候）。但是如果 继续运行这个程序，可能会出现一旦显示无用 信息之后，程序几乎会马上崩溃-最严重的后 果。 2）找出最简单、最直接和最常见的BUG触发条件。 如果理解和改正问题仅需要很小的工作量，那 么就会修复它。 如果问题的解决需要（或看起来

16、需要）很长的 时间和精力，程序员会不太情愿改正它。 如果问题会在程序日常使用的过程中发生，管 理层对问题的关注会增加。 如果问题的出现几乎无人知晓，关注程度会很 低。 3）找出产生相同问题的其他路径。 有时不止一种方法可以触发一个错误，若有 两条不同的路径通往同一个BUG，比起仅有一条 路径来势更有力的危险信号。即使每条路径都包 含着很复杂的步骤序列，存在两条路径也意味着 代码中含有严重的错误。 要充分展示各条路径的差异，不能让程序员 把多条路径视为对同一个BUG的相似描述。 4）找出相关的问题。 根据积累的经验，仿照以前发现BUG的方法， 查找程序中其他可能的位置，能有相当的机会在 新的代码

17、中找出类似的问题。 二、可重现BUG的分析技术 1）寻找最关键的步骤 根据BUG查找代码中的错误，不要忽略任何细微 的有关错误的线索。 应该查找下列的问题： 1. 错误信息； 2.处理延时； 3.屏幕闪烁； 4. 光标跳跃； 5.文本错误； 6. 工作指示灯在设备未使用时亮起。 2）最大程度地提高程序运行的可见性 将程序运行的越多方面变的可见，就越能看 到更多的出错情况，也就越有可能明确关键的步 骤。 用调试工具可以报告出当前活动的进程、程 序占用的内存或其他资源的数量、正在使用的堆 栈的数量以及其他的内部信息。 1.监测堆栈中的遗留数据的多少 2.监侧进程的收发消息，内存的占用情况。 另一条

18、途径是将屏幕显示的所有内容和磁盘文件 的所有变更统统都打印出来，然后进行分析。 3）多尝试一些结果 将程序的事件进行组合的执行。 4）查找后续错误 一旦发现了某个错误，也应该再坚持运行程 序一段时间，看看是否会有其他的错误出现。 我们要认真细致地做这件事，最初出现的问题 可能会诱发一系列后续问题。 5）渐进地省略或改变步骤 问题复杂的时候可以跳过一些步骤，但对每 个要省略的步骤进行测试，看看它是否是重现B UG的必要环节。 至于改变步骤，可以在每个步骤中查找是否 存在边界条件，对边界条件的敏感程度，是一 个测试人员技术成熟与否的标志之一。 6）在程序以前的版本中查找错误 7）查找配置依赖 三、

19、让BUG可重现 如何触发BUG? 将我们记得的有关第一次操作的所有事情都记 下来，进行一步一步的问题回溯。 倘若没有效果，可能是没有满足确切的条件， BUG没有显现出来。 下面列举了几种应该考虑到的情况: 1）竞争条件 2）被遗忘的细节 3）BUG造成的影响会导致其无法重现 4）BUG是依赖于内存的 5）仅会在初次运行时出现的BUG 6）因数据错误导致的BUG 7）由于一些其他问题附带引起的BUG 8）间断性硬件故障 9）BUG依赖于时间 10）BUG依赖与资源 11）BUG由长期积累形成 8.3.4 BUG管理流程管理流程 对BUG的跟踪管理是测试工作的一个重要部 分，测试的目的是为了尽早发

20、现软件系统中的缺 陷，因此，对BUG进行跟踪管理，确保每个被发 现的缺陷都能及时得到处理。 BUG管理流程是一套复杂的处理过程，涉及 到测试员（复审员）、项目数据库管理员、实施 员（设计员）三方的交互，图8-4所示的BUG管理 流转图详细描述了三方关联关系（同样适合正式 技术复审问题处理流程）。 测 试 员 （ 复 审 员 ）项 目 数 据 库实 施 员 （ 设 计 员 ） 测 试 用 例 开 始 （ 用 例 规 约 ） 填 写 测 试 结 果 （ 复 审 结 果 ） 的 实 际 结 果 和 备 注 输 入 框 根 据 反 馈 检 查 修 改 后 结 果 提 交 记 录 至 项 目 数 据 库

21、 A u to M a il S e n d 自 动 返 回 邮 件 通 知 测 试 人 员 （ 复 审 人 员 ） 如 果 测 试 结 果 （ 复 审 结 果 ） 为 已 解 决 ,项 目 数 据 库 会 自 动 通 知 相 关 人 员 ， 告 知 问 题 已 经 关 闭 将 反 馈 提 交 至 项 目 数 据 库 针 对 测 试 结 果 （ 复 审 结 果 ） 填 写 相 应 修 改 意 见 已 经 解 决 M e s s a g e 未 解 决 回 U p D a ta F in d V ie wM e s s a g e S u b m it F in d 数 据 库 图8-4 BUG

22、管理流转图 BUG跟踪管理的起始动作是测试员（复审员） 选择一个测试用例开始测试，当测试员（复审 员）发现程序实际输出值和程序期望值不符的 时候，他就发现了一个BUG，并执行流程第二 个动作“填写测试的实际结果”。 当测试员（复审员）向BUG跟踪管理系统递 交该BUG时，系统将该BUG保存至“项目数据 库”中，并且同步发送一个消息至“AutoMail S end”（可以是一个程序），由它向该BUG的最 终负责者实施员（设计员）发送一份“Error Re port”。 实施员（设计员）会及时接受到这样的BUG 报告，并且根据报告中包含的BUG唯一序号向 “项目数据库”查询该BUG的详细信息。 当

23、实施员（设计员）对BUG跟踪的修复动 作完成后，就会在“项目数据库”中将该BUG 的状态转换为“Fixed”，BUG跟踪管理系统接收 到这样的“UpData”动作，就会自动向BUG的测 试员（复审员）发送BUG已经修复的消息，测 试员（复审员）对BUG进行确认测试，如果该B UG正确修复则关闭它，如果该BUG依然存在问 题，整个动作回复到BUG跟踪管理的起始处。 1、如何提交系统中的BUG 不要在同一封邮件或者同一个错误输入框中 报告多个（尤其在不同软件包之中的）错误。 2、使用自动BUG报告工具 使用成熟的BUG管理工具实现BUG全程管理， 可以有效避免被大量的测试数据所淹没而引发一 系列问

24、题。 有如下一些优点： BUG管理工具安装简单、运行方便、管理安 全。 BUG管理工具有利于BUG的清楚传递，由于 使用了后台数据库进行管理，提供全面详尽的 报告输入项，可产生标准化的BUG报告。 BUG管理工具提供大量的分析选项和强大的 查询匹配能力，能根据各种条件组合进行BUG 统计。当BUG在它的生命周期中变化时，开发 人员、测试人员、及项目管理人员将及时获得 动态的变化信息。 BUG管理人员允许你获取BUG历史记录，并 在检查BUG的状态时参考这一记录。 BUG管理工具可针对软件产品设定不同的模 块，并针对不同的模块设定相关的责任人员， 这样可以实现提交报告时自动发给指定的责任 人。

25、BUG管理工具支持权限，设定不同的用户对B UG记录的操作权限不同，可有效控制进程管理。 BUG管理工具设定不同的BUG严重程度和优 先级，从最初的报告到最后的解决，确保了错 误不会被忽略，同时可以使注意力集中在优先 级和严重程度高的错误上。 BUG管理工具自动发送邮件通知相关责任人 员，并且根据设定的不同责任人，自动发送最 新的BUG动态信息，有效地帮助测试人员和开 发人员进行沟通。 3、通过电子邮件发送BUG报告 描述主题是要清楚而简洁地描述BUG。 邮件内容第一行的格式为：Package:, 指要报告的包含错误的Class包名称。 邮件内容的第二行格式为：Version:， 指该软件包的

26、版本。 其他内容应该注意以下几点： 确切而完整的错误信息（这非常重要）。 您做了或输入了些什么，以便重现该问题。 错误行为的描述：您预期应该有什么样的行为， 而您看到的是如何。 您建议如何改正，或甚至您自己做的修补程序。 详细解释您如何设置该程序，包含完整的设置文 件属性。 任何其他依赖于这个问题软件包的软件包版本。 4、 BUG详细内容信息 如表8-1所示。 5、 轻微的BUG报告 轻微的BUG报告应该和重要的BUG报告分开发 送。 BUG描 述信息 BUG类别可追踪BUG标志 BUG 基本 描述 BUG所属项目 子系统模块 所属的项目子系统模块，最好能较精确的定位 至模块 BUG标题BUG

27、简明描述 BUG流转状态BUG流转状态，可分为Unconfirmed、New、Assi gned、Reassigned、Needinfo、Reopened、Res olved、Reopen、Verified、Closed BUG严重等级BUG严重等级,可分为Critical、Grave、Serious、 Blocker、Important、Normal、Minor、Trivial BUG解决关键字 BUG解决关键字,可分为Fixed、Wontfix、Later、 Remind、Duplicate、Incomplete、NotaBUG、I nvalid、Worksforme BUG提交人BUG提

28、交人的名字(邮件地址) BUG提交时间BUG提交的时间，例如2003-1-23 14：00 表8-1 Bug详细内容描述(part 1) BUG 过程描 述 BUG指定 解决人 由测试人员确定，如果该BUG的流转状态从Unconfir med&New变为Assigned BUG指定解 决时间 由测试人员确定，如果该BUG超过指定修复时间而未 修复，则系统自动发送报警邮件。 BUG处理 描述 如果实现人员对代码进行了修改，要求在此处体现出 修改内容，如果代码行数很多则缩略书写 BUG处理时间记录BUG处理时间 BUG确认测试 人员 验证该BUG被正确的修复了 BUG确认描述BUG确认修复内容 B

29、UG确认时间BUG确认修复时间 BUG详 细描述 对BUG的详细描述，对BUG描述的详细程度直接影响 实现人员对该BUG的修复效果，描述应该尽可能详细 BUG环 境说明 对测试环境的描述，避免实现人员和测试人员环境的 不同造成BUG异议 BUG附 带附件 附件包括对BUG现场出错快照(图片)，错误输出文件 信息等，加强该BUG的表现力 表8-1 Bug详细内容描述(part 2) 6、不知道归属的BUG 设置默认的BUG修复人员，防止意外的丢失了 BUG负责人的信息。 7、关闭BUG报告 提出的BUG被修正后，通过测试人员确认、测 试通过才可以关闭。 BUG的提出和关闭都是 只能由测试人员执行。 将所有不能被修复的BUG收集起来标记为 “Wontfix”，统一递交给代码评审委员会。 8、接续的讨论信息 BUG的管理系统的流转过程中，会有针对该 BUG的新的描述信息加入，例如实现人员或者测 试人员加上的对处理BUG自己的理解和曾经使用 过的解决方案等。 对于新的描述信息，请遵循以下规则： 新的描述信息和旧的描述信息之间应该增加 醒目的隔离条。 新的信息描述应该包括提供者的名称和电子 邮件地址。 新的描述信息应该包括信息的新增时间。 新的描述信息如果是建议修改意见，应该在该 信息