7.3-05 软件缺陷管理规定.docx

软件缺陷管理规定

QMI-7.3-05

受控状态：FORMCHECKBOX受控FORMCHECKBOX非受控

版本号：A/00

发放编号：

编写/日期

审核/日期

批准/日期

软件缺陷管理规定

文件编号

QMI-7.3-05

版本号

A/00

共SECTIONPAGES\*Arabic7页第PAGE2页

文件修改控制页

序号

版本

更改内容概述

编制人/日期

审核人/日期

批准人/日期

1

A/00

初次编制

目的

确定软件缺陷评估、软件缺陷修复、回归测试、风险管理、配置管理、评审等活动要求，保证对软件在整个生命周期进行规范化管理，保障软件服务质量与网络安全，增强客户满意度。

适用范围

本规定适用于公司医疗器械软件。

职责

软件缺陷分析人员负责软件缺陷分析。

定义

缺陷：系统开发过程中发现的问题统称为缺陷，包括测试及评审过程发现的所有问题。

缺陷状态(Status)：指缺陷通过一个跟踪修复过程的进展情况，包括Active（激活），Resolved（已解决），Closed（已关闭）。

缺陷严重程度(Severity)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定，包括Blocker（崩溃），Critical（严重），Major（一般），Minor（次要）。

缺陷优先级(Priority)：指缺陷必须被修复的紧急程度，包括Immediate（立刻），Urgent（优先），High（高度重视），Normal（正常），Low（稍缓）。

程序

项目负责人要组织相关人员按缺陷记录规范和处理原则来记录和处理规范，并且对软件缺陷进行评估、针对缺陷进行修复，针对修复的影响情况，必要时要组织进行回归测试，进行风险管理分析，同时缺陷需利用缺陷管理工具进行管控。软件缺陷管理要涵盖现成软件缺陷。最后形成“软件缺陷分析报告”并组织评审。

软件缺陷记录规范及处理原则

开发和测试人员要按照规范去记录缺陷，并按照相关处理原则处理缺陷。

缺陷记录规范

缺陷内容要求

信息完整，清晰，易懂。

描述需要包括问题发生的模块，标题，操作步骤，实际结果，期望结果，前提条件，复现几率，软硬件版本信息等。

缺陷记录模板

标题：

用一句话描述缺陷，中间最好不要有逗号（缺陷类型或模块信息加到标题最前面）

如：性能问题：长时间运行系统崩溃。

易用性问题：错误提示信息不清晰。

实际结果：缺陷发生的实际现象。

期望结果：期望发生的现象

前提条件：复现此缺陷时进行操作之前的前提条件，主要包括特殊的测试环境及一些设置。

复现步骤：在此描述具体的复现步骤，要求具体而没有歧义，不熟悉此项目的人按照此步骤能够复现出缺陷。

备注：

主要用于有几种不同现象时，如果没有需要此项可以不写。

复现几率：

以百分比形式来表示。如果是不能重现的缺陷可以直接写成n/m，表示测试m次，复现n次。

版本信息：

机型_软件版本_固件版本号

缺陷状态记录规范

分为三种状态，分别为Active（激活），Resolved（已解决），Closed（已关闭），本部分对不同状态的缺陷处理规范做了规定。

Active（激活）：Active状态时，测试人员可根据需要编辑缺陷内容，模块路径，指派人，严重程度，优先级等信息，加注释。

Resolved（已解决）：

Closed：Closed状态时，可执行“编辑”操作，可加注释。无特殊情况，不要更改其他信息，尤其是缺陷内容。

如果经过验证，此缺陷再次复现，可以执行“激活”操作。

缺陷处理记录规范

在每个测试版本发布时，相关测试人员应该验证当前Resolved的缺陷。

开发人员需要对状态为“Active”“Postponed”的缺陷进行处理。

处理后的状态应该是“Resolved”。

测试人员处理原则

Resolved状态可执行的操作说明：

编辑：可编辑模块路径，指派人，严重程度，优先级。因为开发人员已经对此缺陷进行处理，所以不要编辑缺陷内容，如果有需要补充或修改的内容，在注释中说明即可。

关闭：经过确认，缺陷可以关闭时，可执行关闭操作。

激活：经过确认，此缺陷未解决且需解决，可执行激活操作。

不同解决方案的处理方法

（Resolved）ByDesign

ByDesign属于缺陷拒绝修改的情况，根据“产品需求规格书”和“软件需求分析”等相关文档应能找到相关依据。

ByDesign的缺陷需要根据注释中的说明确认是否和相关文档中的方案一致。如果没有相关文档支持，则需要测试人员判断拒绝修改的理由是否可以接受。

如果能够接受，即可关闭；

如果不能接受，则可激活；

如果不能确定，且经过