缺陷管理指引讲解

缺陷管理指南北京博微广华科技有限公司（版权所有，翻版必究）

变更记录版本修改条款修改内容修改人/日期批准人/日期1.0.0正式版郝海凤20141128第1页共18页目录TOC\o"1-5"\h\z\o"CurrentDocument"目的 3\o"CurrentDocument"适用范围 3\o"CurrentDocument"缺陷定义 3缺陷产生的原因 3缺陷的定义 4\o"CurrentDocument"缺陷报告 4\o"CurrentDocument"缺陷类型 5\o"CurrentDocument"缺陷的严重程度 7\o"CurrentDocument"缺陷的优先级 10\o"CurrentDocument"缺陷描述 11缺陷跟踪 12缺陷的生命周期 12\o"CurrentDocument"缺陷状态的跟踪 14\o"CurrentDocument"缺陷结果分析 15第2页共18页1.目的本文对规范缺陷上报、缺陷的处理流程及缺陷分析进行详细说明 ，以提高测试效率，确保软件测试目的的实现。.适用范围1）软件项目集成测试阶段（即软件开发阶段的测试）、系统测试阶段和系统维护阶段。2）能验证阶段。3）客户反馈的问题。.缺陷定义缺陷产生的原因1）软件项目自身问题引起的软件需求定义不够清晰，导致设计目标偏离客户的需求。软件系统结构非常复杂而又无法构造成一个有序的层次结构或者组件结构，从而导致很多意想不到的问题。新技术的应用导致涉及技术和兼容性的问题事先没有考虑周到。2）软件项目管理的问题项目计划不够完善，对质量、资源、任务、成本的平衡性把握不好，容易压缩需求分析、评审、测试的时间从而遗留较多缺陷。项目流程不够完善，存在较多的随机性和缺乏严谨的内审和评审机制。沟通不够流畅，导致不同阶段、不同团队的开发人员对问题的理解不一致。第3页共18页

缺陷的定义从产品内部看，软件缺陷是软件产品在需求定义，开发设计过程中所存在的错误。从外部看，缺陷就是软件项目在某种程度上不能满足用户的需要。.缺陷报告为了准确、清楚地描述缺陷，现定义软件缺陷的属性，如下表所示:类别属性名称是否必填含义并简要说明可跟踪信息缺陷ID自动生成缺陷的唯一标识，用于识别、跟踪、查询、排序、存储管理等。一般使用数字序号表示基本描述信息摘要必填对缺陷的概括性描述，方便列表、浏览、管理等详细描述必填包括测试前提、操作步骤、预期结果和实际结果等测试环境必填缺陷发现时所处的测试环境，包括操作系统和IE所属模块必填缺陷所属模块，以及模块下的组件，方便缺陷统计分析检测版本必填缺陷发现于产品的哪个版本状态自动默认缺陷默认为“新建”状态，根据缺陷的修改情况，更改为相应的状态测试阶段必填测试所处的阶段，包括功能验证、集成测试、第4页共18页

系统测试、系统维护修正所需信息严重程度必填指的是缺陷对软件质量的破坏程度，一般分为“严重”，“一般”，“轻微”三种程度优先级必填指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。一般分为“紧急”，“高”，“中”，“低”四种级别缺陷类型必填属于哪方面的缺陷。如功能、需求、数据内容错误、用户界面、建议性、刷新问题、性能、安装兼容性、稳定性问题、安全性问题可重现频率必填缺陷产生的频率。包括每次、较局、较低创建者自动默认新建缺陷的人员，根据缺陷管理系统的登录用户名自动默认检测者必填检测确认缺陷的人员。检测者默认为创建者，如需重新打开缺陷，则将检测者修改为当前人员分配给可选指派给缺陷下一操作的人员检测时间自动默认默认为提交缺陷时的当前系统时间关闭于版本可选确认缺陷已经被成功解决时的版本信息缺陷类型描述功能功能实现错误或者未实现，功能控制错误第5页共18页

需求需求规格说明书中存在的问题1）需求设计有误2）软件中使用的模板，资源，编码（项目划分编码，WBS编码）错误3）需求设计不完备4）软件默认值设置错误5）小数位数控制数据内容错误软件中动态读取的值错误，如数据计算错误，数据误差，变量调用错误，报表数据错误建议性提出关于软件功能实现不合理，提高软件易用性的建议性意见刷新问题数据刷新，内容刷新，界面刷新等问题用户界面软件界面布局/、合理软件中静态读取的值错误，如界面错别字界面信息显示不全安装兼容性1）安装过程中出现的问题，如：安装向导问题，安装义件问题2）卸载过程中出现的问题，如：卸载后用户工程被删除3）成功安装后与软件环境或硬件环境不兼容引起的问题，如：需求中明确要求兼谷win/系统，但是软件不能在win7下安装成功；在特定的配饰下软件崩溃。第6页共18页稳定性问题软件长时间使用过程中，软件异常退出内存、GDI存在泄漏等安全性问题软件锁权限控制问题，如：资源控制，节点数量控制用户权限控制问题数据安全问题，如用户密码显示为明文；性能不满足系统提出的性能指标，如：右键功能响应时间超出需求制止的指标；生成报表时间超出需求制止的指标“缺陷类型等级”的概念，当一个缺陷同时符合几个缺陷类型的特征时， 其缺陷类型以“缺陷类型等级”较高的类型为准。建议缺陷类型等级如下（' >'左侧表示等级高）：安全性问题>稳定性问题>性能>需求>数据内容错误>安装兼容性>刷新问题>用户界面>建议性>功能缺陷的严重程度Bug的严重级别指的是软件缺陷对软件质量的破坏程度严重：软件缺陷对软件质量的破坏程度严重。主要包括以下几种情况：体功能正常操作实现错误或者未实现。主体功能即系统的本质特征，是必不可少的。即主界面各模块内包含的功能。2）需求设计错误或不完备：需求规格说明书中设计或者考虑不全面导致的错误，如：业务流程不正确，需求逻辑错误等。3）数据错误：主要为数据读取错误，数据计算错误，如：变量数据，报表第7页共18页数据调用错误或计算错误。录入的资源数据错误（原价，单价，单重等） 。4）权限及安全问题。用户密码是否泄漏，权限控制是否得当。一般：软件缺陷对软件质量的破坏程度一般主要包括以下几种情况：1）辅助功能正常操作实现错误或者未实现。辅助功能即完善或辅助主体功能实现的一些功能点。即菜单栏，工具栏的功能。2）数据内容刷新：对软件进行修改后无法及时更新，通过切换界面或执行某些软件操作后，软件刷新到正确状态。a.数据刷新：当存在数据联动时，修改其中一个数据，与之联动的其他数据未及时发生更新。b.内容刷新：多个界面都调用同一字段值，修改其中一个，其他界面未及时发生变动。如：在工程管理中对工程进行重命名，结果项目属性，报表中调用的仍然为旧值。3）数据误差：软件计算结果与实际计算结果存在误差。如：不同界面同一变量的数据精度控制不一致，如：“材料费”在不同界面调用，控制的小数位数不一致，a界面为0.1234,b界面为0.123,最后导致同一变量含义在不同报表体现的值不一致；数据四舍五入不正确。如：0.045枳.04。4）内容错误：主要为字段内容读取错误，如：工程名称，电压等级等字段内容读取错误。软件中使用的模板，资源内容（代码，名称，单位等），编码（项目划分编码，WBS编码）错误。5）输入控制错误。需求中明确某个字段不能输入。包括输入字符类型的控第8页共18页制，输入字节数的控制，如：“比例”字段可以输入中文；小数位数可输入无限位。6）性能指标无法达到。性能达不到需求制定的指标，如：打开有500条工程量的工程，花费30分钟，需求定义为10分钟。7）软件安装卸载问题。覆盖安装后无法进入程序或进入程序后报错； 安装的控件版本错误；卸载过程中出现的问题，如：卸载后用户工程被删除。8）软件兼容性问题。软件在不同系统下安装使用出错；与其他软件存在兼容性错误等。9）稳定性问题。软件长时间使用过程中，软件异常报错或者内存、 GDI存在泄漏等。如：对软件不进行任何操作，内存或GDI数量一直增长。10）功能异常操作，超出需求定义的范围，如添加10级项目划分，软件异常退出；手工断电，软件崩溃。轻微：软件缺陷对软件质量的破坏程度轻微主要包括以下几种情况：1）信息提示框问题。指提示框内的信息不正确，如：输入空字符提示“数据录入不合法”，应提示为“***不能为空”。2）界面显示问题。包括按钮未对齐，图片无法加载，内容显示不全或者有错别字，界面刷新问题等。在特定的系统下，无法显示完全。3）建议性问题，功能不合理，功能操作易用性的建议。如：显示的内容建议进行排序；功能的快捷键实现。4）软件默认值设置错误。如：工程税金默认值错误，实际结果为 5,预期结果应为3.41第9页共18页注：无法重现的缺陷，在原定等级的基础上下降一级缺陷的优先级缺陷的优先级一一解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。确定软件缺陷优先级，更多的是站在客户使用的角度考虑问题，同时需要考虑问题修改的成本与时间。主要包括以下情况：紧急一一缺陷导致系统几乎不能使用或者测试无法继续， 需要立即修复。如:点击新建工程软件报错高一一软件功能没有实现或者没有正确实现，对软件的使用效果影响比较大。必须修改，需确定在集成测试阶段内某个特定里程碑结束前修正。如：工程新建成功后，无法读取新建工程向导中输入的参数；中一一软件功能实现不合理，对软件的使用效果影响一般。必须修改，不一定马上修改，系统测试阶段之前必须修正。如：新建工程向导中，输入参数执行“下一步”，再执行“上一步”输入的参数未保存缺一一对软件的使用效果影响非常小，缺陷不解决的情况下不影响软件正常使用，在时间允许的情况下，考虑尽量解决。如：工程新建成功后，弹出的提示信息框显示不全优先级设置说明：1）在软件正常操作的情况下，软件出现的错误，缺陷的优先级可以定义为“中”及以上。2）在软件异常操作的情况下，（如特殊字符的输入，超长字符的输入，文件格式或软件配置的任意更改），软件出现的错误，缺陷的优先级可以定义为“中”及以下第10页共18页一般来说，严重级别高的bug具有较高的优先处理级别，但是严重级别和优先级并不总是一一对应。有时候严重级别高的 Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。例如，软件崩溃只在某种非常极端的条件下才会产生，那么此缺陷的优先级别可以定义为“低” o缺陷描述1）缺陷描述简要法则检测人员：WHO——描述缺陷的时候应该明确缺陷的检测者。检测结果：WHAT——使用陈述句简明扼要的描述bug摘要。检测环境：WHERE——检测到缺陷时所处的环境，包括操作系统以及当前系统中安装的其他软件；缺陷所属的模块或组件检测时间：WHEN——检测到缺陷的时间。缺陷产生原因：WHY——分析缺陷产生的原因，可以补充到注释中。操作步骤：HOW——描述可重现bug的有效步骤。可以图形表现缺陷的则必须采用附件的形式附上截图。出错的工程则有必要附上工程。2）缺陷描述说明单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个缺陷的弊端是缺陷常常只是部分被修复而不能得到彻底解决。可以再现。提供缺陷产生的准确操作步骤，使开发人员容易看懂并能自己再现缺陷，开发人员只有看懂了才可能有效的解决缺陷。完整统一。提供完整、前后统一的软件缺陷产生的步骤和信息，例如：图片信息，LOG文件等。考虑到网络数据传输效率，截图的文件格式须使用JPG第11页共18页格式在截图中建议使用三号粗线，颜色设置为红色将出错的地方标识出来。短小简练。通过使用关键词，可以使软件缺陷的摘要短小简练又能准确的描述缺陷产生的现象。如“PDA在上传下载的时候出现了死机的现象”中的“PDA”，“上传下载”，“死机”等是关键词。描述的操作步骤，自己要先分析填写的操作步骤是否与提交的缺陷有关联，描述并不是越详细越好，而是要有效的信息。特定条件。许多软件功能在通常情况下是没有问题而是在某种特定条件下才会产生缺陷。所以软件缺陷的描述中不要忽视这些看似细节但又是必要的特定条件（如特定的操作步骤，特定的设置等条件），这些条件是帮助开发人员找到原因的线索。不做评价。在描述软件的缺陷过程中不要带有个人的观点，不要对开发人员进行评价。软件的缺陷报告只是针对产品，针对问题本身。在报告缺陷的过程中只需要将事实或者现象客观描述出来即可，不需要任何评价。缺陷描述格式化。所属模块或功能点=>缺陷现象=>测试步骤=>预期结果=>实际结果=>其它信息，可依实际情况调整。测试步骤超过两个步骤时用序号分开描述；针对描述内容为功能名称或报表名称等，建议使用双引号括起来。.缺陷跟踪缺陷的生命周期新建：提交缺陷的初始状态打开：问题经确认后确实存在第12页共18页已解决：被相关人员成功修复的缺陷无效bug:根据事实依据，确认不是缺陷延期：由于时间或者技术等方面的原因，同时考虑到修改此缺陷而带来的风险，需要延期解决重复：该缺陷与缺陷管理系统中已有的缺陷含义相同不做处理：由于技术或者其他原因无法修复重新打开：已解决的缺陷依然存在或者未得到彻底解决，需要进一步修正关闭：缺陷确认已经被成功修复，不再存在有争议：对于缺陷的处理方式，检测者与确认者存在歧义无法重现：确认缺陷的时候，无法重现缺陷中描述的现象第13页共18页缺陷状态的跟踪开发人员「所有业务类型的bug全部由业务组长确认分配类型的bug全部由开发组长确认分配1F业务诅长进彳TBU型理蓝线一一开发人员处理红线一一业务人员处理黑线一一开发人员「所有业务类型的bug全部由业务组长确认分配类型的bug全部由开发组长确认分配1F业务诅长进彳TBU型理蓝线一一开发人员处理红线一一业务人员处理黑线一一测试人员处理黑粗线一一主要流程检测者所有非业R开发组长进行BU型理测与认意不一检者确者见统归试陷底修

一回测缺彻被重新打开■宏强以外是ug开人旃该陷b-测员为须理

检人认必处“新建”状态的bug,根据其缺陷类型，业务类型的bug由业务组长进行确认分配，所有非业务类型的bug由开发组长进行确认分配。开发组长判定为“延期”的bug，检测者根据项目实际情况可以“重新打开”开发组长判定“打开”的bug,同时分配开发人员进行修正，修正完毕后由开发人员将其状态置为“已解决”。对于置为“无法重现”、“重复”、“不做处理”、“无效bug”的缺陷，检测者进行验证后，如意见一致，则在软件发布后将其置为“已关闭”，否则将其置为“有争议”。针对“有争议”的缺陷，测试组长提出处理方案，供项目组内参考第14页共18页检测者对开发人员置为“已解决”的bug进行回归测试，确认问题解决后，根据“谁新建/重新打开bug,谁负责关闭”的原则，由检测者将bug置为“关闭”状态；回归测试中，发现问题没有解决或者解决不彻底时，将bug置为“重新打开”状态。确认缺陷“已解决”，“关闭”时应该标记解决的版本号。将缺陷设置为“无效bug”，“延期”，“不做处理”，“重新打开”，“有争议”，相关人员必须添加注释。分别在集成测试阶段结束时和系统测试阶段结束时，对于“有争议”、“不做处理”、“延期”的BUG,项目组需经过讨论后得出处理结果，由项目组长确定最终处理方式。已关闭的BUG,在后续版本中如果出现相同或者相似问题，可以“重新打开”，并相应的修改bug属性。.缺陷结果分析通过缺陷的分析可以反映出项目测试的进展情况、项目流程中的薄弱环节，同时还可以对产品质量进行评估，确认测试是否达到结束的标准。所以每个测试阶段结束后都需要在测试报告中针对当前项目的测试情况进行总结，分析，确定是否可以进入下一个阶段。按照“所属模块”进行分析根据“所属模块”字段，分析具体模块的bug情况，找出影响产品质量的关键模块；测试经验表明，“发