缺陷管理指南北京博微广华科技有限公司（版权所有，翻版必究）变更记录版本修改条款修改内容修改人/日期批准人/日期1.0.0正式版郝海凤20141128目录1. 目的 32. 适用范围 33. 缺陷定义 33.1. 缺陷产生的原因 332 缺陷的定义 44. 缺陷报告 44.1. 缺陷类型 54.2. 缺陷的严重程度 74.3. 缺陷的优先级 104.4. 缺陷描述 115. 缺陷跟踪 125.1. 缺陷的生命周期 125.2. 缺陷状态的跟踪 146. 缺陷结果分析 151. 目的本文对规范缺陷上报、缺陷的处理流程及缺陷分析进行详细说明，以提高测 试效率，确保软件测试目的的实现2. 适用范围1） 软件项目集成测试阶段（即软件开发阶段的测试）、系统测试阶段和系统维 护阶段2） 能验证阶段3） 客户反馈的问题3. 缺陷定义3.1 缺陷产生的原因1） 软件项目自身问题引起的软件需求定义不够清晰，导致设计目标偏离客户的需求软件系统结构非常复杂而又无法构造成一个有序的层次结构或者组件结构，从而导致很多意想不到的问题新技术的应用导致涉及技术和兼容性的问题事先没有考虑周到2） 软件项目管理的问题项目计划不够完善，对质量、资源、任务、成本的平衡性把握不好，容易压缩需求分析、评审、测试的时间从而遗留较多缺陷。
项目流程不够完善，存在较多的随机性和缺乏严谨的内审和评审机制沟通不够流畅，导致不同阶段、不同团队的开发人员对问题的理解不一致3.2缺陷的定义从产品内部看，软件缺陷是软件产品在需求定义，开发设计过程中所存在的错误从外部看，缺陷就是软件项目在某种程度上不能满足用户的需要4. 缺陷报告为了准确、清楚地描述缺陷，现定义软件缺陷的属性，如下表所示:类别属性名称是否必填含义并简要说明可跟踪信息缺陷ID自动生成缺陷的唯一标识，用于识别、跟踪、查询、 排序、存储管理等一般使用数字序号表示基本描述信息摘要必填对缺陷的概括性描述，方便列表、浏览、管理等详细描述必填包括测试前提、操作步骤、预期结果和实际结果等测试环境必填缺陷发现时所处的测试环境，包括操作系统和IE所属模块必填缺陷所属模块，以及模块下的组件，方便缺 陷统计分析检测版本必填缺陷发现于产品的哪个版本状态自动默认缺陷默认为“新建”状态，根据缺陷的修改情况，更改为相应的状态测试阶段必填测试所处的阶段，包括功能验证、集成测试、系统测试、系统维护修正所需信息严重程度必填指的是缺陷对软件质量的破坏程度，一般分为“严重,，，“一般,，，“轻微，，三种程度优先级必填指解决软件缺陷的先后顺序，即哪些缺陷需要 优先解决，哪些缺陷可以稍后解决。
一般分为 “紧急”，“高”，“中”，“低”四种级别缺陷类型必填属于哪方面的缺陷如功能、需求、数据内 容错误、用户界面、建议性、刷新问题、性 能、安装兼容性、稳定性问题、安全性问题可重现频率必填缺陷产生的频率包括每次、较周、较低创建者自动默认新建缺陷的人员，根据缺陷管理系统的登录用户名自动默认检测者必填检测确认缺陷的人员检测者默认为创建者，如需重新打开缺陷，则将检测者修改为当前人员分配给可选指派给缺陷下一步操作的人员检测时间自动默认默认为提交缺陷时的当前系统时间关闭于版本可选确认缺陷已经被成功解决时的版本信息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 7）.044） 内容错误：主要为字段内容读取错误口：工程名称，电压等级等字段内容 读取错误软件中使用的模板，资源内容（代码，名称，单位等），编码（项目划分 编码，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置为“重新打开”状态确认缺陷“已解决”，“关闭”时应该标记解决的版本号将缺陷设置为“无效bug”，“延期”，“不做处理”，“重新打开”，“有争 议”，相关人员必须添加注释分别在集成测试阶段结束时和系统测试阶段结束时，对于“有争议”、“不做处 理”、“延期”的BUG，项目组需经过讨论后得出处理结果，由项目组长确定最 终处理方式已关闭的BUG，在后续版本中如果出现相同或者相似问题，可以“重新打开”， 并相应的修改bug属性6. 缺陷结果分析通过缺陷的分析可以反映出项目测试的进展情况、项目流程中的薄弱环节，同时还可 以对产品质量进行评估，确认测试是否达到结束的标准所以每个测试阶段结束后都 需要在测试报告中针对当前项目的测试情况进行总结，分析，确定是否可以进入下一 个阶段。
按照“所属模块''进行分析根据“所属模块''字段，分析具体模块的bug情况，找出影响产品质量的关键模 块；测试经验表明，“发现bug越多的地方，遗留的bug也就越多”，所以发现bug比较多的模块在后期的测试中仍需加大力度进行测试，当前分析出来的 数据可以作为历史数据供以后参照按照“缺陷类型”进行分析根据缺陷类型，统计出各缺陷类型所占的 bug比例，最后分析出问题产生 的最大根源按照缺陷的“严重程度''进行分析可以反映出开发设计完成后项目的质量，当严重程度为高的bug所占比例比较大 时，说明项目的质量很低对于严重程度为高bug比较集中的模块需加大回归测试力 度按照不同检测者的缺陷进行分析可以反映出测试人员的工作绩效如一个测试人员提交的 bug量多，并且严重级别为高bug所占比例比较大，说明此测试人员的绩效好按照缺陷发现阶段进行分析主要说明在哪个阶段发现的bug比较多，如果系统测试阶段的bug比集成测试阶 段多，那说明要重新进行集成测试按照缺陷的状态进行分析主要反映当前项目的情况，如：bug修改情况，项目当前现状等如果“关闭” 状态的bug所占比例达到90%以上，说明可以展开下一阶段的工作。
按照bug数、测试总时间进行分析系统测试报告中，针对项目的整个测试过程，统计提交的总 bug数量，总的测试工日数量，最后通过“ bug总数/测试总时间”公式反映整个项目的测试 情况根据客户反馈问题进行分析每个月针对发布出去的项目，统计分析客户反馈的问题，分析每个问题产生的原因，总结不足，持续改进每人每天产生缺陷每人每天产生缺陷=项目提交的缺陷数量/测试时间（根据参与人员数量及参与测 试时间折算成工作日），根据此项指标可以反映项目的研发质量情况软件缺陷探测率软件缺陷探测率=测试提交缺陷/ （测试提交缺陷+用户反馈缺陷），根据此指标可以 反映项目测试的有效率。