第九章 软件BUG和管理
一、学习目的与要求
软件测试的目的就是为了发现软件BUG。通过本章的学习，应了解软件BUG的产生和影响，掌握软件开发过程中产生的BUG种类，掌握使BUG重现的技术，了解软件BUG报告单应该包括的主要内容及软件BUG的管理流程。
二、考核知识点与考核目标
（一）软件BUG的产生和影响（一般）
- 理解：软件BUG的产生和影响
产生
- 程序编写错误
- 需求变更过于频繁
- 软件的复杂度
- 交流不充分或者沟通出问题
- 测试人员的经验与技巧不足
- 时间过于紧迫
- 缺乏文档:
- 管理上的缺陷
影响：Bug会给用户或使用者带来相当大的麻烦,会给集体或者国家带来很大的经济损失。如:千年虫问题。
（二）软件BUG的种类（重点）
- 理解：需求阶段的BUG
- 模糊、不清晰的需求;
- 被忽略的需求;
- 相互冲突的需求;
- 理解：分析设计阶段的BUG
- 忽略设计;
- 混乱的设计;
- 模糊的设计;
- 理解：实现阶段的BUG
- 系统级别错误
（1）消息错误
（2）用户界面错误
（3）遗漏的功能
（4）内存溢出或者程序崩溃
（5）其他实现错误- 用户界面错误,可归纳为GUI错误。
- 遗漏的功能BUG(以输入框输入信息错误,程序抛出未异常为典型)
- 内存溢出或者程序崩溃BUG
- 理解：配置阶段的BUG
- 旧的代码覆盖了新的代码
- 测试服务器上的代码和实现人员本机最新代码版本不一致。
- 实现人员操作配置管理工具不正确引起的;
- 测试人员或者最终用户操作不正确。
- 理解：短视将来的BUG
- 为了节省硬件的设计
- 理解：静态文档的BUG
说明模糊、描述不完整和过期的都属于文档BUG。
- 说明模糊特指无充分的信息判断如何正确地处理事情;
- 描述不完整特指文档信息不足以支持用户完成某项工作;
- 过期的文档是没有及时更新过的、错误的文档。
（三）BUG报告单的提交和管理（一般）
- 理解：BUG报告单的内容
- 问题报告编号
- 程序名
- 版本标识:发布号和版本号。是用来识别被测的代码。
- 报告类型:描述了发现的问题类型。包括:编码错误、设计问题、建议、文档、硬件、质疑。
- 严重性:为问题严重程度评分。包含三个等级:三个等级:轻微的、严重的和致命的。
- 附件
- 问题概要:对问题进行描述,有助于评审突出的问题,并找到相应的问题报告。
- 问题能否重现。要多次测试看能否再次出现。
- 问题描述及如何重现。描述所有的步骤和现象,包括错误信息。一定要提交报告。
- 建议的改正措施
- 报告人
- 日期:指的是报告人员发现问题的日期。
- 功能域:对问题进行大体分类。
- 承办人
- 注释:程序员在这里简短地说明为什么要推迟处理,或说明是如何改正问题的。
- 状态。三个状态码:开放、关闭和已解决。
- 优先级。只由项目经理设置。
- 处理状态与处理版本。处理状态定义了问题的当前状态:
<1>未解决:初始化状态或仍有冲突状态。
<2>已改正
<3>不能重现
<4>暂缓:对存在的问题在下个版本改正。
<5>符合设计
<6>由报告人撤回
<7>需要进一步信息
<8>不同意建议
<9>重复:关闭重复上报的缺陷。
<7>需要进一步信息
<8>不同意建议
<9>重复:关闭重复上报的缺陷。- 签名:签署以表明已经对改动进行了测试,)
结果表示满意。- 暂缓处理:对缺陷的推迟处理。
报告单特点：一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。
- 理解：BUG的管理流程
（四）重现BUG的分析和方法（重点）
- 理解：重现BUG的分析和方法
- 寻找最关键的步骤
- 最大程度地提高程序运行的可见性
- 多尝试一些结果
- 查找后续错误
- 渐进地省略或改变步骤
- 在程序以前的版本中查找错误
- 查找配置依赖
三、习题
- BUG的来源及影响?
来源：
- 程序编写错误
- 需求变更过于频繁
- 软件的复杂度
- 交流不充分或者沟通出问题
- 测试人员的经验与技巧不足
- 时间过于紧迫
- 缺乏文档:
- 管理上的缺陷
影响：Bug会给用户或使用者带来相当大的麻烦,会给集体或者国家带来很大的经济损失
- BUG的种类有那些?并通过对实际案例的测试,分析一下找出的BUG都是在软件生命周期的哪个阶段出现的?
种类：
- 需求阶段的BUG
- 分析设计阶段的BUG
- 设计阶段的BUG
- 实现阶段的BUG
- 配置阶段的BUG
- 短视将来的BUG
- 静态文档的BUG
- BUG报告单应该包括哪些内容及特点?填写一份报告单给程序设计人员,听听他的意见。
报告单特点：一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。
- 简述BUG的管理流程
- 提交bug：测试人员提交新的Bug入库,错误状态为New。
- 确认bug：高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设没置状态为Open。如果不是错误,则拒绝,设置为Declined(拒绝)状态。
- 查询并修复bug：开发人员查询状态为Open的Bug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持Bug管理为Open状态。对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过会议(评审会)通过才能认可。
- 验证bug是否解决：测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为Closed,如没有解决置状态为Reopen。
- 程序员在编写代码时会出错，把这种错误称之为BUG 。
- 下列BUG中最危险的是
A需求阶段的BUG
B配置阶段的BUG
C设计阶段的BUG
D分析阶段的BUG - 下面有关软件缺陷的说法中错误的是______。
A. 缺陷就是软件产品在开发中存在的错误
B. 缺陷就是软件维护过程中存在的错误、毛病等各种问题
C. 缺陷就是导致系统程序崩溃的错误
D. 缺陷就是系统所需要实现的某种功能的失效和违背 - 简述BUG产生的原因
- 程序编写错误
- 需求变更过于频繁
- 软件复杂
- 交流不充分或沟通出现问题
- 测试人员的经验与技巧不足
- 时间过于紧迫，缺乏文档
- 简述制定测试计划的主要步骤
制定测试计划主要包括以下五个步骤∶
- 取得需求文档;
- 确定测试策略
- 确定测试系统;
- 预估测试工作量
- 准备并复查测试计划
- 简述软件缺陷（bug）与软件错误（error）的区别与联系
区别∶
- 软件缺陷是存在于软件之中的不希望或不可接受的偏差。而软件错误是由于人为的原因产生的错误
- 软件缺陷是在软件中抽象存在的，而错误是人为的问题
- 由于人为的错误，在设计或编码过程中的失误、导致了软件内部的缺陷，人为的错误是引发软件缺陷的直接原因，一个软件错误必然引发多个软件缺陷。
- 简述一般进行回归测试的步骤
- 建立测试基线，这是回归测试的前提·具体方式是将所有的测试用例放到配置库中，打上版本标记。
- 从基线测试用例库中提取合适的测试用例组成回归测试包。必要时进行开发和重新设计整理
- 在后续开发过程中，每次测试之前先运行回归测试包。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。
- 试论述在BUG重现时可能出现的问题及解决办法
- 竞争条件：出现竞争条件时，可以按照第一次运行时的节类，再将程序快速地测试一遍。如果还出现错误，就要试着减慢计算机的速度，或者在稍慢点的计算机上进行测试了
- 被遗忘的细节：很多时候测试是在没有制定测试计划的情况下进行的，在测试中发现了某个问题后却无法重现它，那么很可能是忘记了一些细节，因此应该努力回忆那写被遗忘的细节，这往往成为恢复BUG的关
- BUG造成的影响会导致其无法重现，如果发生这种情况，除非复原文件或将计算机恢复到正确状态。否则根本无法重现
- BUG依赖于内存，此时可以使用一些专用的内存监视软件
- 仅会在初次运行时出现的BUG"这种BUG危害并不大，只要在用户说明书中详细说明初始化数据前的操作步骤。这种BUG就可以避免
- 因数据错误导致的BUG：为重现这些错误，必须对程序进行相同的数据输入
- 间断性硬件故障，检查硬件
- BUG 依赖于时间，详细检查跨日、月、年等边界情况
- BUG 依赖于资源，必须重现资源请求受拒的情形
- 由于一些其他问题附带引起的BUG，在发现初始BUG后，就要重现它、 这样由它导致的后续BUG重现起来就要容易多了