第九章 软件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都是在软件生命周期的哪个阶段出现的?

种类：需求阶段的BUG，分析设计阶段的BUG，设计阶段的BUG，实现阶段的BUG，配置阶段的BUG，短视将来的BUG，静态文档的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。