缺陷管理指南北京博微广华科技有限公司(版权所有，翻版必究）变更记录目录1.目的 (3)2.适用范围 (3)3.缺陷定义 (3)3.1.缺陷产生的原因 (3)3.2.缺陷的定义 (4)4.缺陷报告 (4)4.1.缺陷类型 (5)4.2.缺陷的严重程度 (7)4.3.缺陷的优先级 (10)4.4.缺陷描述 (11)5.缺陷跟踪 (12)5.1.缺陷的生命周期 (12)5.2.缺陷状态的跟踪 (14)6.缺陷结果分析 (15)1.目的本文对规范缺陷上报、缺陷的处理流程及缺陷分析进行详细说明,以提高测试效率，确保软件测试目的的实现。
2.适用范围1）软件项目集成测试阶段（即软件开发阶段的测试）、系统测试阶段和系统维护阶段。
2）能验证阶段。
3）客户反馈的问题。
3.缺陷定义3.1缺陷产生的原因1）软件项目自身问题引起的●软件需求定义不够清晰，导致设计目标偏离客户的需求。
●软件系统结构非常复杂而又无法构造成一个有序的层次结构或者组件结构，从而导致很多意想不到的问题。
●新技术的应用导致涉及技术和兼容性的问题事先没有考虑周到。
2）软件项目管理的问题●项目计划不够完善，对质量、资源、任务、成本的平衡性把握不好，容易压缩需求分析、评审、测试的时间从而遗留较多缺陷。
●项目流程不够完善，存在较多的随机性和缺乏严谨的内审和评审机制。
●沟通不够流畅，导致不同阶段、不同团队的开发人员对问题的理解不一致。
3.2缺陷的定义●从产品内部看，软件缺陷是软件产品在需求定义，开发设计过程中所存在的错误。
●从外部看，缺陷就是软件项目在某种程度上不能满足用户的需要。
4.缺陷报告为了准确、清楚地描述缺陷，现定义软件缺陷的属性，如下表所示：4.1缺陷类型“缺陷类型等级”的概念，当一个缺陷同时符合几个缺陷类型的特征时，其缺陷类型以“缺陷类型等级”较高的类型为准。
建议缺陷类型等级如下（’>’左侧表示等级高）：安全性问题>稳定性问题>性能>需求>数据内容错误>安装兼容性>刷新问题>用户界面>建议性>功能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.1缺陷的生命周期●新建：提交缺陷的初始状态●打开：问题经确认后确实存在●已解决：被相关人员成功修复的缺陷●无效bug：根据事实依据，确认不是缺陷●延期：由于时间或者技术等方面的原因，同时考虑到修改此缺陷而带来的风险，需要延期解决●重复：该缺陷与缺陷管理系统中已有的缺陷含义相同●不做处理：由于技术或者其他原因无法修复●重新打开：已解决的缺陷依然存在或者未得到彻底解决，需要进一步修正●关闭：缺陷确认已经被成功修复，不再存在●有争议：对于缺陷的处理方式，检测者与确认者存在歧义●无法重现：确认缺陷的时候，无法重现缺陷中描述的现象5.2缺陷状态的跟踪●“新建”状态的bug，根据其缺陷类型，业务类型的bug由业务组长进行确认分配，所有非业务类型的bug由开发组长进行确认分配。
●开发组长判定为“延期”的bug，检测者根据项目实际情况可以“重新打开”。
●开发组长判定“打开”的bug，同时分配开发人员进行修正，修正完毕后由开发人员将其状态置为“已解决”。
●对于置为“无法重现”、“重复”、“不做处理”、“无效bug”的缺陷，检测者进行验证后，如意见一致，则在软件发布后将其置为“已关闭”，否则将其置为“有争议”。
●针对“有争议”的缺陷，测试组长提出处理方案，供项目组内参考。
●检测者对开发人员置为“已解决”的bug进行回归测试，确认问题解决后，根据“谁新建/重新打开bug，谁负责关闭”的原则，由检测者将bug置为“关闭”状态；回归测试中，发现问题没有解决或者解决不彻底时，将bug 置为“重新打开”状态。
