缺陷管理指南
北京博微广华科技有限公司
(版权所有，翻版必究）
变更记录
目录
1. 目的 . .......................................................................................................................................... 3
2. 适用范围 . .................................................................................................................................. 3
3. 缺陷定义 . .................................................................................................................................. 3
3.1.
3.2. 缺陷产生的原因 . .......................................................................................................... 3 缺陷的定义 . .................................................................................................................. 4
4. 缺陷报告 . .................................................................................................................................. 4
4.1.
4.2.
4.3.
4.4. 缺陷类型 . ...................................................................................................................... 5 缺陷的严重程度 . .......................................................................................................... 7 缺陷的优先级 . ............................................................................................................ 10 缺陷描述 . .................................................................................................................... 11
5. 缺陷跟踪 . ................................................................................................................................ 12
5.1.
5.2. 缺陷的生命周期 . ........................................................................................................ 12 缺陷状态的跟踪 . ........................................................................................................ 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 置为“重新打开”状态。
● 确认缺陷“已解决”，“关闭”时应该标记解决的版本号。
● 将缺陷设置为“无效bug ”，“延期”，“不做处理”，“重新打开”，“有争议”，
相关人员必须添加注释。
● 分别在集成测试阶段结束时和系统测试阶段结束时，对于“有争议”、“不做
处理”、“延期”的BUG ，项目组需经过讨论后得出处理结果，由项目组长确定最终处理方式。
● 已关闭的BUG ，在后续版本中如果出现相同或者相似问题，可以“重新打开”，
并相应的修改bug 属性。
6. 缺陷结果分析
通过缺陷的分析可以反映出项目测试的进展情况、项目流程中的薄弱环节，同时还可以对产品质量进行评估，确认测试是否达到结束的标准。所以每个测试阶段结束后都需要在测试报告中针对当前项目的测试情况进行总结，分析，确定是否可以进入下一个阶段。
● 按照“所属模块”进行分析
根据“所属模块”字段，分析具体模块的bug 情况，找出影响产品质量的关键模块；测试经验表明，“发现bug 越多的地方，遗留的bug 也就越多”，
所以发现bug 比较多的模块在后期的测试中仍需加大力度进行测试，当前分析出来的数据可以作为历史数据供以后参照。
● 按照“缺陷类型”进行分析
根据缺陷类型，统计出各缺陷类型所占的bug 比例，最后分析出问题产生的最大根源。
● 按照缺陷的“严重程度”进行分析
可以反映出开发设计完成后项目的质量，当严重程度为高的bug 所占比例比较大时，说明项目的质量很低。对于严重程度为高bug 比较集中的模块需加大回归测试力度。
● 按照不同检测者的缺陷进行分析
可以反映出测试人员的工作绩效。如一个测试人员提交的bug 量多，并且严重级别为高bug 所占比例比较大，说明此测试人员的绩效好。
● 按照缺陷发现阶段进行分析
主要说明在哪个阶段发现的bug 比较多，如果系统测试阶段的bug 比集成测试阶段多，那说明要重新进行集成测试。
● 按照缺陷的状态进行分析
主要反映当前项目的情况，如：bug 修改情况，项目当前现状等。如果“关闭”状态的bug 所占比例达到90%以上，说明可以展开下一阶段的工作。 ● 按照bug 数、测试总时间进行分析
系统测试报告中，针对项目的整个测试过程，统计提交的总bug 数量，总的测试工日数量，最后通过“bug 总数/测试总时间”公式反映整个项目的测试
情况。
● 根据客户反馈问题进行分析
每个月针对发布出去的项目，统计分析客户反馈的问题，分析每个问题产生的原因，总结不足，持续改进。
● 每人每天产生缺陷
每人每天产生缺陷=项目提交的缺陷数量/测试时间（根据参与人员数量及参与测试时间折算成工作日），根据此项指标可以反映项目的研发质量情况。 ● 软件缺陷探测率
软件缺陷探测率=测试提交缺陷/（测试提交缺陷+用户反馈缺陷），根据此指标可以反映项目测试的有效率。
缺陷管理指南
北京博微广华科技有限公司
(版权所有，翻版必究）
变更记录
目录
1. 目的 . .......................................................................................................................................... 3
2. 适用范围 . .................................................................................................................................. 3
3. 缺陷定义 . .................................................................................................................................. 3
3.1.
3.2. 缺陷产生的原因 . .......................................................................................................... 3 缺陷的定义 . .................................................................................................................. 4
4. 缺陷报告 . .................................................................................................................................. 4
4.1.
4.2.
4.3.
4.4. 缺陷类型 . ...................................................................................................................... 5 缺陷的严重程度 . .......................................................................................................... 7 缺陷的优先级 . ............................................................................................................ 10 缺陷描述 . .................................................................................................................... 11
5. 缺陷跟踪 . ................................................................................................................................ 12
5.1.
5.2. 缺陷的生命周期 . ........................................................................................................ 12 缺陷状态的跟踪 . ........................................................................................................ 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 置为“重新打开”状态。
● 确认缺陷“已解决”，“关闭”时应该标记解决的版本号。
● 将缺陷设置为“无效bug ”，“延期”，“不做处理”，“重新打开”，“有争议”，
相关人员必须添加注释。
● 分别在集成测试阶段结束时和系统测试阶段结束时，对于“有争议”、“不做
处理”、“延期”的BUG ，项目组需经过讨论后得出处理结果，由项目组长确定最终处理方式。
● 已关闭的BUG ，在后续版本中如果出现相同或者相似问题，可以“重新打开”，
并相应的修改bug 属性。
6. 缺陷结果分析
通过缺陷的分析可以反映出项目测试的进展情况、项目流程中的薄弱环节，同时还可以对产品质量进行评估，确认测试是否达到结束的标准。所以每个测试阶段结束后都需要在测试报告中针对当前项目的测试情况进行总结，分析，确定是否可以进入下一个阶段。
● 按照“所属模块”进行分析
根据“所属模块”字段，分析具体模块的bug 情况，找出影响产品质量的关键模块；测试经验表明，“发现bug 越多的地方，遗留的bug 也就越多”，
所以发现bug 比较多的模块在后期的测试中仍需加大力度进行测试，当前分析出来的数据可以作为历史数据供以后参照。
● 按照“缺陷类型”进行分析
根据缺陷类型，统计出各缺陷类型所占的bug 比例，最后分析出问题产生的最大根源。
● 按照缺陷的“严重程度”进行分析
可以反映出开发设计完成后项目的质量，当严重程度为高的bug 所占比例比较大时，说明项目的质量很低。对于严重程度为高bug 比较集中的模块需加大回归测试力度。
● 按照不同检测者的缺陷进行分析
可以反映出测试人员的工作绩效。如一个测试人员提交的bug 量多，并且严重级别为高bug 所占比例比较大，说明此测试人员的绩效好。
● 按照缺陷发现阶段进行分析
主要说明在哪个阶段发现的bug 比较多，如果系统测试阶段的bug 比集成测试阶段多，那说明要重新进行集成测试。
● 按照缺陷的状态进行分析
主要反映当前项目的情况，如：bug 修改情况，项目当前现状等。如果“关闭”状态的bug 所占比例达到90%以上，说明可以展开下一阶段的工作。 ● 按照bug 数、测试总时间进行分析
系统测试报告中，针对项目的整个测试过程，统计提交的总bug 数量，总的测试工日数量，最后通过“bug 总数/测试总时间”公式反映整个项目的测试
情况。
● 根据客户反馈问题进行分析
每个月针对发布出去的项目，统计分析客户反馈的问题，分析每个问题产生的原因，总结不足，持续改进。
● 每人每天产生缺陷
每人每天产生缺陷=项目提交的缺陷数量/测试时间（根据参与人员数量及参与测试时间折算成工作日），根据此项指标可以反映项目的研发质量情况。 ● 软件缺陷探测率
软件缺陷探测率=测试提交缺陷/（测试提交缺陷+用户反馈缺陷），根据此指标可以反映项目测试的有效率。