缺陷管理指南讲解.docx

缺陷管理指南讲解.docx

《缺陷管理指南讲解.docx》由会员分享，可在线阅读，更多相关《缺陷管理指南讲解.docx（15页珍藏版）》请在冰豆网上搜索。

缺陷管理指南讲解

缺陷管理指南

北京博微广华科技有限公司

（版权所有，翻版必究）

变更记录

版本

修改条款

修改内容

修改人/日期

批准人/日期

1.0.0

正式版

郝海凤20141128

1.目的

本文对规范缺陷上报、缺陷的处理流程及缺陷分析进行详细说明,以提高测试效率，确保软件测试目的的实现。

2.适用范围

1）软件项目集成测试阶段（即软件开发阶段的测试）、系统测试阶段和系统维护阶段。

2）能验证阶段。

3）客户反馈的问题。

3.缺陷定义

1

2

3

3.1缺陷产生的原因

1）软件项目自身问题引起的

●软件需求定义不够清晰，导致设计目标偏离客户的需求。

●软件系统结构非常复杂而又无法构造成一个有序的层次结构或者组件结构，从而导致很多意想不到的问题。

●新技术的应用导致涉及技术和兼容性的问题事先没有考虑周到。

2）软件项目管理的问题

●项目计划不够完善，对质量、资源、任务、成本的平衡性把握不好，容易压缩需求分析、评审、测试的时间从而遗留较多缺陷。

●项目流程不够完善，存在较多的随机性和缺乏严谨的内审和评审机制。

●沟通不够流畅，导致不同阶段、不同团队的开发人员对问题的理解不一致。

3.2缺陷的定义

●从产品内部看，软件缺陷是软件产品在需求定义，开发设计过程中所存在的错误。

●从外部看，缺陷就是软件项目在某种程度上不能满足用户的需要。

4.缺陷报告

为了准确、清楚地描述缺陷，现定义软件缺陷的属性，如下表所示：

类别

属性名称

是否必填

含义并简要说明

可跟踪信息

缺陷ID

自动生成

缺陷的唯一标识，用于识别、跟踪、查询、排序、存储管理等。

一般使用数字序号表示

基本描述信息

摘要

必填

对缺陷的概括性描述，方便列表、浏览、管理等

详细描述

必填

包括测试前提、操作步骤、预期结果和实际结果等

测试环境

必填

缺陷发现时所处的测试环境，包括操作系统和IE

所属模块

必填

缺陷所属模块，以及模块下的组件，方便缺陷统计分析

检测版本

必填

缺陷发现于产品的哪个版本

状态

自动默认

缺陷默认为“新建”状态，根据缺陷的修改情况，更改为相应的状态

测试阶段

必填

测试所处的阶段，包括功能验证、集成测试、系统测试、系统维护

修正所需信息

严重程度

必填

指的是缺陷对软件质量的破坏程度，一般分为“严重”，“一般”，“轻微”三种程度

优先级

必填

指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。

一般分为“紧急”，“高”，“中”，“低”四种级别

缺陷类型

必填

属于哪方面的缺陷。

如功能、需求、数据内容错误、用户界面、建议性、刷新问题、性能、安装兼容性、稳定性问题、安全性问题

可重现频率

必填

缺陷产生的频率。

包括每次、较高、较低

创建者

自动默认

新建缺陷的人员，根据缺陷管理系统的登录用户名自动默认

检测者

必填

检测确认缺陷的人员。

检测者默认为创建者，如需重新打开缺陷，则将检测者修改为当前人员

分配给

可选

指派给缺陷下一步操作的人员

检测时间

自动默认

默认为提交缺陷时的当前系统时间

关闭于版本

可选

确认缺陷已经被成功解决时的版本信息

4

4.1缺陷类型

类型

描述

功能

功能实现错误或者未实现，功能控制错误

需求

需求规格说明书中存在的问题

1）需求设计有误

2）软件中使用的模板，资源，编码（项目划分编码，WBS编码）错误

3）需求设计不完备

4）软件默认值设置错误

5）小数位数控制

数据内容错误

软件中动态读取的值错误，如数据计算错误，数据误差，变量调用错误，报表数据错误

建议性

提出关于软件功能实现不合理，提高软件易用性的建议性意见

刷新问题

数据刷新，内容刷新，界面刷新等问题

用户界面

软件界面布局不合理

软件中静态读取的值错误，如界面错别字

界面信息显示不全

安装兼容性

1）安装过程中出现的问题，如：

安装向导问题，安装文件问题

2）卸载过程中出现的问题，如：

卸载后用户工程被删除

3）成功安装后与软件环境或硬件环境不兼容引起的问题，如：

需求中明确要求兼容win7系统，但是软件不能在win7下安装成功；在特定的配置下软件崩溃。

稳定性问题

软件长时间使用过程中，软件异常退出

内存、GDI存在泄漏等

安全性问题

软件锁权限控制问题，如：

资源控制，节点数量控制

用户权限控制问题

数据安全问题，如用户密码显示为明文；

性能

不满足系统提出的性能指标，如：

右键功能响应时间超出需求制定的指标；生成报表时间超出需求制定的指标

“缺陷类型等级”的概念，当一个缺陷同时符合几个缺陷类型的特征时，其缺陷类型以“缺陷类型等级”较高的类型为准。

建议缺陷类型等级如下（’>’左侧表示等级高）：

安全性问题>稳定性问题>性能>需求>数据内容错误>安装兼容性>刷新问题>用户界面>建议性>功能

4.2缺陷的严重程度

Bug的严重级别指的是软件缺陷对软件质量的破坏程度

●严重：

软件缺陷对软件质量的破坏程度严重。

主要包括以下几种情况：

1）主体功能正常操作实现错误或者未实现。

主体功能即系统的本质特征，是必不可少的。

即主界面各模块内包含的功能。

2）需求设计错误或不完备：

需求规格说明书中设计或者考虑不全面导致的错误，如：

业务流程不正确，需求逻辑错误等。

3）数据错误：

主要为数据读取错误，数据计算错误，如：

变量数据，报表数据调用错误或计算错误。

录入的资源数据错误（原价，单价，单重等）。

4）权限及安全问题。

用户密码是否泄漏，权限控制是否得当。

●一般：

软件缺陷对软件质量的破坏程度一般

主要包括以下几种情况：

1）辅助功能正常操作实现错误或者未实现。

辅助功能即完善或辅助主体功能实现的一些功能点。

即菜单栏，工具栏的功能。

2）数据内容刷新：

对软件进行修改后无法及时更新，通过切换界面或执行某些软件操作后，软件刷新到正确状态。

a.数据刷新：

当存在数据联动时，修改其中一个数据，与之联动的其他数据未及时发生更新。

b.内容刷新：

多个界面都调用同一字段值，修改其中一个，其他界面未及时发生变动。

如：

在工程管理中对工程进行重命名，结果项目属性，报表中调用的仍然为旧值。

3）数据误差：

软件计算结果与实际计算结果存在误差。

如：

不同界面同一变量的数据精度控制不一致，如：

“材料费”在不同界面调用，控制的小数位数不一致，a界面为0.1234，b界面为0.123，最后导致同一变量含义在不同报表体现的值不一致；

数据四舍五入不正确。

如：

0.045≈0.04。

4）内容错误：

主要为字段内容读取错误，如：

工程名称，电压等级等字段内容读取错误。

软件中使用的模板，资源内容（代码，名称，单位等），编码（项目划分编码，WBS编码）错误。

5）输入控制错误。

需求中明确某个字段不能输入。

包括输入字符类型的控制，输入字节数的控制，如：

“比例”字段可以输入中文；小数位数可输入无限位。

6）性能指标无法达到。

性能达不到需求制定的指标，如：

打开有500条工程量的工程，花费30分钟，需求定义为10分钟。

7）软件安装卸载问题。

覆盖安装后无法进入程序或进入程序后报错；安装的控件版本错误；卸载过程中出现的问题，如：

卸载后用户工程被删除。

8）软件兼容性问题。

软件在不同系统下安装使用出错；与其他软件存在兼容性错误等。

9）稳定性问题。

软件长时间使用过程中，软件异常报错或者内存、GDI存在泄漏等。

如：

对软件不进行任何操作，内存或GDI数量一直增长。

10）功能异常操作，超出需求定义的范围，如添加10级项目划分，软件异常退出；手工断电，软件崩溃。

●轻微：

软件缺陷对软件质量的破坏程度轻微

主要包括以下几种情况：

1）信息提示框问题。

指提示框内的信息不正确，如：

输入空字符提示“数据录入不合法”，应提示为“***不能为空”。

2）界面显示问题。

包括按钮未对齐，图片无法加载，内容显示不全或者有错别字，界面刷新问题等。

在特定的系统下，无法显示完全。

3）建议性问题，功能不合理，功能操作易用性的建议。

如：

显示的内容建议进行排序；功能的快捷键实现。

4）软件默认值设置错误。

如：

工程税金默认值错误，实际结果为5，预期结果应为3.41。

注：

无法重现的缺陷，在原定等级的基础上下降一级

4.3缺陷的优先级

缺陷的优先级——解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。

确定软件缺陷优先级，更多的是站在客户使用的角度考虑问题，同时需要考虑问题修改的成本与时间。

主要包括以下情况：

●紧急——缺陷导致系统几乎不能使用或者测试无法继续，需要立即修复。

如：

点击新建工程软件报错

●高——软件功能没有实现或者没有正确实现，对软件的使用效果影响比较大。

必须修改，需确定在集成测试阶段内某个特定里程碑结束前修正。

如：

工程新建成功后，无法读取新建工程向导中输入的参数；

●中——软件功能实现不合理，对软件的使用效果影响一般。

必须修改，不一定马上修改，系统测试阶段之前必须修正。

如：

新建工程向导中，输入参数执行“下一步”，再执行“上一步”输入的参数未保存

●低——对软件的使用效果影响非常小，缺陷不解决的情况下不影响软件正常使用，在时间允许的情况下，考虑尽量解决。

如：

工程新建成功后，弹出的提示信息框显示不全

优先级设置说明：

1）在软件正常操作的情况下，软件出现的错误，缺陷的优先级可以定义为“中”及以上。

2）在软件异常操作的情况下，（如特殊字符的输入，超长字符的输入，文件格式或软件配置的任意更改），软件出现的错误，缺陷的优先级可以定义为“中”及以下。

3）一般来说，严重级别高的bug具有较高的优先处理级别，但是严重级别和优先级并不总是一一对应。

有时候严重级别高的Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。

例如，软件崩溃只在某种非常极端的条件下才会产生，那么此缺陷的优先级别可以定义为“低”。

4.4缺陷描述

1）缺陷描述简要法则

●检测人员：

WHO——描述缺陷的时候应该明确缺陷的检测者。

●检测结果：

WHAT——使用陈述句简明扼要的描述bug摘要。

●检测环境：

WHERE——检测到缺陷时所处的环境，包括操作系统以及当前系统中安装的其他软件；缺陷所属的模块或组件

●检测时间：

WHEN——检测到缺陷的时间。

●缺陷产生原因：

WHY——分析缺陷产生的原因，可以补充到注释中。

●操作步骤：

HOW——描述可重现bug的有效步骤。

可以图形表现缺陷的则必须采用附件的形式附上截图。

出错的工程则有必要附上工程。

2）缺陷描述说明

●单一准确。

每个报告只针对一个软件缺陷。

在一个报告中报告多个缺陷的弊端是缺陷常常只是部分被修复而不能得到彻底解决。

●可以再现。

提供缺陷产生的准确操作步骤，使开发人员容易看懂并能自己再现缺陷，开发人员只有看懂了才可能有效的解决缺陷。

●完整统一。

提供完整、前后统一的软件缺陷产生的步骤和信息，例如：

图片信息，LOG文件等。

考虑到网络数据传输效率，截图的文件格式须使用JPG格式在截图中建议使用三号粗线，颜色设置为红色将出错的地方标识出来。

●短小简练。

通过使用关键词，可以使软件缺陷的摘要短小简练又能准确的描述缺陷产生的现象。

如“PDA在上传下载的时候出现了死机的现象”中的“PDA”，“上传下载”，“死机”等是关键词。

描述的操作步骤，自己要先分析填写的操作步骤是否与提交的缺陷有关联，描述并不是越详细越好，而是要有效的信息。

●特定条件。

许多软件功能在通常情况下是没有问题而是在某种特定条件下才会产生缺陷。

所以软件缺陷的描述中不要忽视这些看似细节但又是必要的特定条件（如特定的操作步骤，特定的设置等条件），这些条件是帮助开发人员找到原因的线索。

●不做评价。

在描述软件的缺陷过程中不要带有个人的观点，不要对开发人员进行评价。

软件的缺陷报告只是针对产品，针对问题本身。

在报告缺陷的过程中只需要将事实或者现象客观描述出来即可，不需要任何评价。

●缺陷描述格式化。

所属模块或功能点=>缺陷现象=>测试步骤=>预期结果=>实际结果=>其它信息，可依实际情况调整。

测试步骤超过两个步骤时用序号分开描述；针对描述内容为功能名称或报表名称等，建议使用双引号括起来。

5.缺陷跟踪

5

5.1缺陷的生命周期

●新建：

提交缺陷的初始状态

●打开：

问题经确认后确实存在

●已解决：

被相关人员成功修复的缺陷

●无效bug：

根据事实依据，确认不是缺陷

●延期：

由于时间或者技术等方面的原因，同时考虑到修改此缺陷而带来的风险，需要延期解决

●重复：

该缺陷与缺陷管理系统中已有的缺陷含义相同

●不做处理：

由于技术或者其他原因无法修复

●重新打开：

已解决的缺陷依然存在或者未得到彻底解决，需要进一步修正

●关闭：

缺陷确认已经被成功修复，不再存在

●有争议：

对于缺陷的处理方式，检测者与确认者存在歧义

●无法重现：

确认缺陷的时候，无法重现缺陷中描述的现象

5.2缺陷状态的跟踪

●“新建”状态的bug，根据其缺陷类型，业务类型的bug由业务组长进行确认分配，所有非业务类型的bug由开发组长进行确认分配。

●开发组长判定为“延期”的bug，检测者根据项目实际情况可以“重新打开”。

●开发组长判定“打开”的bug，同时分配开发人员进行修正，修正完毕后由开发人员将其状态置为“已解决”。

●对于置为“无法重现”、“重复”、“不做处理”、“无效bug”的缺陷，检测者进行验证后，如意见一致，则在软件发布后将其置为“已关闭”，否则将其置为“有争议”。

●针对“有争议”的缺陷，测试组长提出处理方案，供项目组内参考。

●检测者对开发人员置为“已解决”的bug进行回归测试，确认问题解决后，根据“谁新建/重新打开bug，谁负责关闭”的原则，由检测者将bug置为“关闭”状态；回归测试中，发现问题没有解决或者解决不彻底时，将bug置为“重新打开”状态。

●确认缺陷“已解决”，“关闭”时应该标记解决的版本号。

●将缺陷设置为“无效bug”，“延期”，“不做处理”，“重新打开”，“有争议”，相关人员必须添加注释。

●分别在集成测试阶段结束时和系统测试阶段结束时，对于“有争议”、“不做处理”、“延期”的BUG，项目组需经过讨论后得出处理结果，由项目组长确定最终处理方式。

●已关闭的BUG，在后续版本中如果出现相同或者相似问题，可以“重新打开”，并相应的修改bug属性。

6.缺陷结果分析

通过缺陷的分析可以反映出项目测试的进展情况、项目流程中的薄弱环节，同时还可以对产品质量进行评估，确认测试是否达到结束的标准。

所以每个测试阶段结束后都需要在测试报告中针对当前项目的测试情况进行总结，分析，确定是否可以进入下一个阶段。

●按照“所属模块”进行分析

根据“所属模块”字段，分析具体模块的bug情况，找出影响产品质量的关键模块；测试经验表明，“发现bug越多的地方，遗留的bug也就越多”，所以发现bug比较多的模块在后期的测试中仍需加大力度进行测试，当前分析出来的数据可以作为历史数据供以后参照。

●按照“缺陷类型”进行分析

根据缺陷类型，统计出各缺陷类型所占的bug比例，最后分析出问题产生的最大根源。

●按照缺陷的“严重程度”进行分析

可以反映出开发设计完成后项目的质量，当严重程度为高的bug所占比例比较大时，说明项目的质量很低。

对于严重程度为高bug比较集中的模块需加大回归测试力度。

●按照不同检测者的缺陷进行分析

可以反映出测试人员的工作绩效。

如一个测试人员提交的bug量多，并且严重级别为高bug所占比例比较大，说明此测试人员的绩效好。

●按照缺陷发现阶段进行分析

主要说明在哪个阶段发现的bug比较多，如果系统测试阶段的bug比集成测试阶段多，那说明要重新进行集成测试。

●按照缺陷的状态进行分析

主要反映当前项目的情况，如：

bug修改情况，项目当前现状等。

如果“关闭”状态的bug所占比例达到90%以上，说明可以展开下一阶段的工作。

●按照bug数、测试总时间进行分析

系统测试报告中，针对项目的整个测试过程，统计提交的总bug数量，总的测试工日数量，最后通过“bug总数/测试总时间”公式反映整个项目的测试情况。

●根据客户反馈问题进行分析

每个月针对发布出去的项目，统计分析客户反馈的问题，分析每个问题产生的原因，总结不足，持续改进。

●每人每天产生缺陷

每人每天产生缺陷=项目提交的缺陷数量/测试时间（根据参与人员数量及参与测试时间折算成工作日），根据此项指标可以反映项目的研发质量情况。

●软件缺陷探测率

软件缺陷探测率=测试提交缺陷/（测试提交缺陷+用户反馈缺陷），根据此指标可以反映项目测试的有效率。