第九章 软件BUG和管理

一、学习目的与要求

软件测试的目的就是为了发现软件BUG。通过本章的学习，应了解软件BUG的产生和影响，掌握软件开发过程中产生的BUG种类，掌握使BUG重现的技术，了解软件BUG报告单应该包括的主要内容及软件BUG的管理流程。

二、考核知识点与考核目标

（一）软件BUG的产生和影响（一般）

1. 理解：软件BUG的产生和影响

产生

1. 程序编写错误
2. 需求变更过于频繁
3. 软件的复杂度
4. 交流不充分或者沟通出问题
5. 测试人员的经验与技巧不足
6. 时间过于紧迫
7. 缺乏文档:
8. 管理上的缺陷

影响：Bug会给用户或使用者带来相当大的麻烦,会给集体或者国家带来很大的经济损失。如:千年虫问题。

（二）软件BUG的种类（重点）

1. 理解：需求阶段的BUG

1. 模糊、不清晰的需求;
2. 被忽略的需求;
3. 相互冲突的需求;

2. 理解：分析设计阶段的BUG

1. 忽略设计;
2. 混乱的设计;
3. 模糊的设计;

3. 理解：实现阶段的BUG

1. 系统级别错误
   （1）消息错误
   （2）用户界面错误
   （3）遗漏的功能
   （4）内存溢出或者程序崩溃
   （5）其他实现错误
2. 用户界面错误,可归纳为GUI错误。
3. 遗漏的功能BUG(以输入框输入信息错误,程序抛出未异常为典型)
4. 内存溢出或者程序崩溃BUG

4. 理解：配置阶段的BUG

1. 旧的代码覆盖了新的代码
2. 测试服务器上的代码和实现人员本机最新代码版本不一致。
3. 实现人员操作配置管理工具不正确引起的;
4. 测试人员或者最终用户操作不正确。

5. 理解：短视将来的BUG

1. 为了节省硬件的设计

6. 理解：静态文档的BUG

说明模糊、描述不完整和过期的都属于文档BUG。

1. 说明模糊特指无充分的信息判断如何正确地处理事情;
2. 描述不完整特指文档信息不足以支持用户完成某项工作;
3. 过期的文档是没有及时更新过的、错误的文档。

（三）BUG报告单的提交和管理（一般）

1. 理解：BUG报告单的内容

1. 问题报告编号
2. 程序名
3. 版本标识:发布号和版本号。是用来识别被测的代码。
4. 报告类型:描述了发现的问题类型。包括:编码错误、设计问题、建议、文档、硬件、质疑。
5. 严重性:为问题严重程度评分。包含三个等级:三个等级:轻微的、严重的和致命的。
6. 附件
7. 问题概要:对问题进行描述,有助于评审突出的问题,并找到相应的问题报告。
8. 问题能否重现。要多次测试看能否再次出现。
9. 问题描述及如何重现。描述所有的步骤和现象,包括错误信息。一定要提交报告。
10. 建议的改正措施
11. 报告人
12. 日期:指的是报告人员发现问题的日期。
13. 功能域:对问题进行大体分类。
14. 承办人
15. 注释:程序员在这里简短地说明为什么要推迟处理,或说明是如何改正问题的。
16. 状态。三个状态码:开放、关闭和已解决。
17. 优先级。只由项目经理设置。
18. 处理状态与处理版本。处理状态定义了问题的当前状态:
    <1>未解决:初始化状态或仍有冲突状态。
    <2>已改正
    <3>不能重现
    <4>暂缓:对存在的问题在下个版本改正。
    <5>符合设计
    <6>由报告人撤回
    <7>需要进一步信息
    <8>不同意建议
    <9>重复:关闭重复上报的缺陷。
    <7>需要进一步信息
    <8>不同意建议
    <9>重复:关闭重复上报的缺陷。
19. 签名:签署以表明已经对改动进行了测试,)
    结果表示满意。
20. 暂缓处理:对缺陷的推迟处理。

报告单特点：一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。

2. 理解：BUG的管理流程

（四）重现BUG的分析和方法（重点）

1. 理解：重现BUG的分析和方法

1. 寻找最关键的步骤
2. 最大程度地提高程序运行的可见性
3. 多尝试一些结果
4. 查找后续错误
5. 渐进地省略或改变步骤
6. 在程序以前的版本中查找错误
7. 查找配置依赖

三、习题

1. BUG的来源及影响?

来源：

1. 程序编写错误
2. 需求变更过于频繁
3. 软件的复杂度
4. 交流不充分或者沟通出问题
5. 测试人员的经验与技巧不足
6. 时间过于紧迫
7. 缺乏文档:
8. 管理上的缺陷

影响：Bug会给用户或使用者带来相当大的麻烦,会给集体或者国家带来很大的经济损失

2. BUG的种类有那些?并通过对实际案例的测试,分析一下找出的BUG都是在软件生命周期的哪个阶段出现的?

种类：

1. 需求阶段的BUG
2. 分析设计阶段的BUG
3. 设计阶段的BUG
4. 实现阶段的BUG
5. 配置阶段的BUG
6. 短视将来的BUG
7. 静态文档的BUG

3. BUG报告单应该包括哪些内容及特点?填写一份报告单给程序设计人员,听听他的意见。

报告单特点：一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。

4. 简述BUG的管理流程

1. 提交bug：测试人员提交新的Bug入库,错误状态为New。
2. 确认bug：高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设没置状态为Open。如果不是错误,则拒绝,设置为Declined(拒绝)状态。
3. 查询并修复bug：开发人员查询状态为Open的Bug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持Bug管理为Open状态。对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过会议(评审会)通过才能认可。
4. 验证bug是否解决：测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为Closed,如没有解决置状态为Reopen。

5. 程序员在编写代码时会出错，把这种错误称之为BUG 。
6. 下列BUG中最危险的是
   A需求阶段的BUG
   B配置阶段的BUG
   C设计阶段的BUG
   D分析阶段的BUG
7. 下面有关软件缺陷的说法中错误的是______。
   A. 缺陷就是软件产品在开发中存在的错误
   B. 缺陷就是软件维护过程中存在的错误、毛病等各种问题
   C. 缺陷就是导致系统程序崩溃的错误
   D. 缺陷就是系统所需要实现的某种功能的失效和违背
8. 简述BUG产生的原因

1. 程序编写错误
2. 需求变更过于频繁
3. 软件复杂
4. 交流不充分或沟通出现问题
5. 测试人员的经验与技巧不足
6. 时间过于紧迫，缺乏文档

9. 简述制定测试计划的主要步骤

制定测试计划主要包括以下五个步骤∶

1. 取得需求文档;
2. 确定测试策略
3. 确定测试系统;
4. 预估测试工作量
5. 准备并复查测试计划

10. 简述软件缺陷（bug）与软件错误（error）的区别与联系

区别∶

1. 软件缺陷是存在于软件之中的不希望或不可接受的偏差。而软件错误是由于人为的原因产生的错误
2. 软件缺陷是在软件中抽象存在的，而错误是人为的问题
3. 由于人为的错误，在设计或编码过程中的失误、导致了软件内部的缺陷，人为的错误是引发软件缺陷的直接原因，一个软件错误必然引发多个软件缺陷。

11. 简述一般进行回归测试的步骤

1. 建立测试基线，这是回归测试的前提·具体方式是将所有的测试用例放到配置库中，打上版本标记。
2. 从基线测试用例库中提取合适的测试用例组成回归测试包。必要时进行开发和重新设计整理
3. 在后续开发过程中，每次测试之前先运行回归测试包。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

12. 试论述在BUG重现时可能出现的问题及解决办法

1. 竞争条件：出现竞争条件时，可以按照第一次运行时的节类，再将程序快速地测试一遍。如果还出现错误，就要试着减慢计算机的速度，或者在稍慢点的计算机上进行测试了
2. 被遗忘的细节：很多时候测试是在没有制定测试计划的情况下进行的，在测试中发现了某个问题后却无法重现它，那么很可能是忘记了一些细节，因此应该努力回忆那写被遗忘的细节，这往往成为恢复BUG的关
3. BUG造成的影响会导致其无法重现，如果发生这种情况，除非复原文件或将计算机恢复到正确状态。否则根本无法重现
4. BUG依赖于内存，此时可以使用一些专用的内存监视软件
5. 仅会在初次运行时出现的BUG"这种BUG危害并不大，只要在用户说明书中详细说明初始化数据前的操作步骤。这种BUG就可以避免
6. 因数据错误导致的BUG：为重现这些错误，必须对程序进行相同的数据输入
7. 间断性硬件故障，检查硬件
8. BUG 依赖于时间，详细检查跨日、月、年等边界情况
9. BUG 依赖于资源，必须重现资源请求受拒的情形
10. 由于一些其他问题附带引起的BUG，在发现初始BUG后，就要重现它、 这样由它导致的后续BUG重现起来就要容易多了