软件测试第七讲.ppt

第七章　软件BUG和管理 [本章要点] １.软件Bug对软件质量的影响； ２.常见的软件Bug类型； ３.软件Bug的描述和管理。 [ 本章目标 ] 了解软件BUG的影响和产生； 掌握软件开发过程中产生的BUG种类； 了解软件BUG报告单应该包括的主要内容以及软件BUG的管理流程。 7.1软件BUG概述 在IEEE 1983 of IEEE Standard 729中对软件缺陷下了一个标准的定义： （1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； （2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷有很多种，其中主要软件缺陷类型有： 1.一些功能、特性没有实现或只实现了一部分； 2.软件设计不合理，存在缺陷。实际运行结果和预期结果不一致； 3.运行出错，包括运行中断、系统崩溃、界面混乱 4.数据结果不正确、精度不够； 5.用户不能接受的其他问题，如存取时间过长、界面不美观。 7.1.1 BUG的产生 对于软件而言，BUG是程序编写错误而导致软件产生问题的缺陷。 软件测试的目的就是找到软件程序代码内的BUG，纠正它，叫做DEBUG。 7.2 BUG的种类 BUG是软件“与生俱来”的特征，不同的软件开发阶段会产生不同的BUG，而不同的BUG又会产生不同的后果，因此BUG的属性也并非相同。 7.2.1需求阶段的BUG 这个阶段的BUG是最难发现、最难修复的，而且值得注意的是需求阶段的BUG如果没有及时发现等到实现阶段发现时，那么修复它的费用要比当初修复它要高15~75倍。 主要的原因如下： 1、模糊、不清晰的需求； 2、被忽略的需求； 3、相互冲突的需求； 7.2.2分析设计阶段的BUG 设计中的BUG比需求阶段产生的BUG特征明显 易于捕获，但是其维修代价很高，原因是设计BUG 已经作为一个整体影响着整个系统的实现。 原因主要有3种途径。 1 、忽略设计； 2、混乱的设计； 3、模糊的设计； 7.2.3实现阶段的BUG 就是软件系统中最普通、最一般的“常规BUG”。 可以将实现阶段出现的BUG分为下面几类： 1、消息错误 2、用户界面错误 3、遗漏的功能 4、内存溢出或者程序崩溃 5、其他实现错误 7.2.4配置阶段的BUG 配置阶段的BUG出现的原因是复杂的，比较典型 的是旧的代码覆盖了新的代码，或者测试服务器上的;可能是实现人员操作配置管理工具不正确引起的；还可能体现了测试人员或者最终用户操作不正确。代码和实现人员本机最新代码版本不一致。 7.2.6静态文档的BUG 文档BUG的定义很简单，即说明模糊、描述不完整和过期的都属于文档BUG。说明模糊特指无充分的信息判断如何正确地处理事情；描述不完整特指文档信息不足以支持用户完成某项工作；过期的文档是没有及时更新过的、错误的文档。 7.3.1 BUG报告单的内容 BUG报告单也叫缺陷报告单或者问题报告单。 介绍一下字段： （1）问题报告编号 （2）程序名 （3）版本标识：发布号和版本号。是用来识别被测的代码。 例如：某个版本号可能是1.01m，发布号是1.01，“m”指1.01版本的第13稿。 （4）报告类型：描述了发现的问题类型。包括：编码错误 、设计问题 、建议 、文档 、硬件、质疑。 （5）严重性：为问题严重程度评分。 包含三个等级：三个等级：轻微的、严重的和致命的。 （6）附件 （7）问题概要：对问题进行描述，有助于评审突出的问题，并找到相应的问题报告。 （8）问题能否重现。要多次测试看能否再次出现。 （9）问题描述及如何重现。描述所有的步骤和现象，包括错误信息。一定要提交报告。 （10）建议的改正措施 （11）报告人 （12）日期：指的是报告人员发现问题的日期。 （13）功能域：对问题进行大体分类。 （14）承办人 （15）注释：程序员在这里简短地说明为什么要推迟处理，或说明是如何改正问题的。 （16）状态。三个状态码：开放、关闭和已解决。 （17）优先级。只由项目经理