缺陷管理指南
编 号 | |
版 本 | |
编 制 | |
审 核 | |
批 准 | |
发布日期 | |
修订历史记录
序号 | 更改单号 | 更改位置 | 修订人 | 生效日期 | 现行版次 |
1 | |||||
| resolved是什么状态 | |||||
1.0目的
通过建立物理配置库的设立，规范各配置库目录的设立原则，确保配置库的统一与规范，确保项目产品得到有效的管理与运用，提高资源的共享与利用。
缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。细分为：
1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；
2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；
3）在已收集到的缺陷数据的基础上进行统计分析。总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。
本指南规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。
2.0参考文件
无
3.0定义
无
4.0职责
角 | 职责 |
软件总工 | 评审缺陷，审核测试报告 |
测试负责人 | 提交缺陷、评审缺陷，进行缺陷的统计分析，编制测试报告 |
测试工程师 | 提交缺陷，对缺陷进行验证测试 |
项目组成员 | 修改缺陷 |
配置管理员 | 在缺陷管理中受控已解决的配置项 |
5.0资历及培训
无
6.0入口
6.1 入口准则
●缺陷发生时
6.2 输入
无
7.0 主要活动
7.1定义缺陷
定义缺陷的要素，如下表（其中*为必选项）：
缺陷要 | 描述 |
Bug ID (*) | 唯一的缺陷ID，可以根据该ID追踪缺陷，由缺陷管理工具自动生成。 |
bug状态 (*) | 缺陷的状态，分为Active、Resolved、Closed |
Bug 标题(*) | 描述缺陷的标题。为包含关键词的简单问题摘要，要有利于其他人员进行搜索或通过标题快速了解问题。 |
项目名称/模块路径(*) | 指定问题出现在哪个系统产品的哪个软件。Bug处理过程中，需要随时根据需要修改项目或模块，方便跟踪 |
指派给(*) | Bug的当前处理人。如果不知道Bug的处理人，可以指派给Active，项目或模块负责人再重新分发、指派给具体人员。如果设定了邮件通知，被指派者会收到邮件通知。此外，状态为Closed的Bug，默认会指派给Closed，表示Bug生命周期的结束 |
严重程度(*) | 描述缺陷的严重程度，一般分为四种： 灾难性、严重、一般、微不足道 |
优先级 (*) | 描述缺陷的优先级：高、中、底、下阶段修正 |
Bug类型(*) | bug问题的分类，分为710类，具体见下面定义。 |
如何发现(*) | 描述缺陷是在何时发现的，分为8个阶段，具体见下面定义。 |
最后修改者 | 缺陷问题最后修改人员（系统自动记录） |
最后修改日期 | 缺陷问题最后修改时间（系统自动记录） |
创建者 | 缺陷的提交人（系统自动记录） |
创建日期 | 缺陷首次提交的时间（系统自动记录） |
创建Build (*) | Bug是在哪个版本被发现的，即填写发现bug的软件版本 |
解决者 | 解决缺陷的人员（系统自动记录） |
解决日期 | 缺陷解决的时间（系统自动记录） |
解决Build(*) | Bug是在哪个版本被解决的，即填写bug解决对应的软件版本。如果不是通过修改软件解决的，统一填写“解决说明”，将解决方案以附件形式上传 |
解决方案(*) | Bug的8中解决方案。具体见下面定义。 |
重复bug | 如果解决方案为Duplicated，需要指定重复Bug的Bug编号。 |
关闭者 | 缺陷关闭人员（系统自动记录） |
关闭日期 | 缺陷关闭时间（系统自动记录） |
机器配置 | 问题产生时运行的硬件环境、软件环境扼要说明 |
关 键 词 | 主要用于自定义标记，方便查询。关键词之间用逗号分隔 |
相关 Bug | 填写与当前问题相关系的问题的bugid |
上传附件 | 上传Bug的屏幕截图，Log日志，非软件问题的解决方法等 。其中图片统一要求使用.jpg格式文件，并且上传附件不要大于2M |
复现步骤(*) | [步骤]要描述清晰，简明扼要，步骤数尽可能少； [结果]说明Bug产生的错误结果； [期望]说明正确的结果。 可以在[备注]提供一些辅助性的信息，例如，这个bug在上个版本是否也能复现，方便处理人员。 [问题分析]由解决人员说明对此问题的分析 [解决方法]由解决人员说明对此问题的解决方法 |
注释 | 1、描述评审的意见 2、跟踪、维护缺陷的沟通信息记录 |
严重程度：
Bug4种严重级别 | |
灾难性 | 系统崩溃，数据丢失，由于程序所引起的死机、非法退出，死循环，数据库发生死锁，错误操作导致的程序中断 ，严重的计算错误，与数据库连接错误，数据通讯错误 |
严重 | 操作出错，系统功能错误或遗漏；程序接口错误 、数据流错误 、轻微数据计算错误 |
一般 | 错误操作提示，界面错误，打印内容、格式错误，简单的输入限制未放在前台进行控制，删除操作未给出提示，数据输入没有边界值限定或不合理 |
微不足道 | 不影响系统功能，更好的操作方式，罕见的错误，辅助说明描述不清楚，显示格式不规范，系统处理未优化，时间操作未给用户进度提示，提示窗口文字未采用行业术语 |
优先级：
Bug的4种优先级 | |
高 | （立即修证）—停止测试，立即修证，修证完毕后进行测试 |
中 | （尽快修证）—在版本发布之前必须修改BUG |
底 | （短期内修证）—在项目允许时间范围内修证（项目经理确认） |
下阶段修正 | BUG推迟到下一阶段修证 |
Bug类型：
Bug的10种问题类型 | |
功能错误 | 以需求说明书为参照，未达到或未完成需求说明书所描述的功能即为功能错误。A. 重复的功能 B. 多余的功能 C. 功能实现与设计要求不相符 D. 功能使用性、方便性、易用性不够 |
编码错误 | 在系统运行中出现各类系统报错以及出现死机、不能工作、没有反应的现象即为编码错误。 |
数据错误 | 系统中各类查询数据、插入数据、更新数据时出现的数据库中表结构，视图、索引等不对引起的错误。 |
可操作性错误 | 可操作性，应用方面的错误 |
界面问题 | 窗口各控件布局，字体显示等界面不美观，界面、消息提示不友好、不准确等。A. 界面不美观 B. 控件排列、格式不统一 C. 焦点控制不合理或不全面 |
合理化建议 | 提交者认为有更好的实现方法，或合理的建议。 |
其它 | 各类文档、帮助的错误。 |
配置相关 | 在系统运行时，由于配置设置的疏忽导致的错误 |
安装部署 | 由于安装部署环境导致的系统错误 |
性能压力 | 性能压力测试导出的bug |
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论