CMMI支持QA缺陷管理规程Word下载.docx
《CMMI支持QA缺陷管理规程Word下载.docx》由会员分享，可在线阅读，更多相关《CMMI支持QA缺陷管理规程Word下载.docx（10页珍藏版）》请在冰豆网上搜索。
MicrosoftOffice2003英文版
CONFIDENTIAL
文档修订记录
版本编号或者更改记录编号
变化状态
简要说明（变更内容
和变更范围）
日期
变更人
批准日期
批准人
C
初次创建
CMM事业部
*变化状态：
C――创建，A——增加，M——修改，D——删除
文档审批信息
序号
审批人
角色
审批日期
签字
备注
前言
软件缺陷是指那些使软件的行为方式与需求或客户要求不一致的东西。
软件产品质量的特性在实践中体现在缺陷上，缺陷管理的目标是提交缺陷尽量少的软件。
如何计划和管理质量控制活动，作为质量特性的缺陷管理非常重要，它包括缺陷的估计、缺陷数据的采集、跟踪与分析。
第一章简介
一.1文档目的
本规程的目的是为了定义缺陷估计的内容和方法，缺陷跟踪过程以及缺陷分析内容和方法。
一.2适用范围
本文档适用于公司的所有软件项目。
一.3术语表
项目规模：
代码行、功能点或工作量（人时），本规程指工作量。
缺陷注入率：
单位规模（人时）的缺陷数。
里程碑阶段缺陷级别：
里程碑阶段（需求、设计、编码、单元测试、集成测试、系统测试和验收测试阶段）的缺陷占总缺陷数的百分比。
缺陷清除率：
已发现的缺陷数占已预测的总缺陷数的百分比。
缺陷出现时机：
在需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试识别缺陷。
一.4参考资料
第二章项目缺陷预测
二.1概述
量化质量管理的一种方法是通过预测缺陷进行管理，这种方法的关键事宜是设定质量目标，并预测里程碑阶段的缺陷级别，以此来量化监督项目向着质量目标前进，缺陷的预测在项目策划阶段，由SQA人员和项目经理共同完成。
本规程确定质量目标为：
预测在验收测试阶段可能出现的缺陷数，简称估计AT缺陷数（估计验收测试缺陷数）。
二.2入口准则
立项报告已批准
二.3参与人员
SQA人员：
进行数据分析的策划，项目质量数据的分析、总结；
项目经理：
进行数据分析的策划，进行一定的数据分析工作。
二.4预测方法
二.4.1类似项目的质量目标预测
1.预测前提条件：
有类似项目的数据，当前项目已经完成工作量估计
2.预测方法：
当前项目（P）,类似项目集（SP）
估计总缺陷数（P）=总缺陷数（SP）*工作量估计（P）/实际工作量（SP）
估计AT缺陷数（P）=AT缺陷数（SP）*工作量估计（P）/实际工作量（SP）
二.4.2新项目的质量目标预测
3.预测前提条件：
项目过程库中已存在或估计了过程的缺陷清除率和缺陷注入率（x缺陷/人时）
当前项目已经完成工作量估计（人时）
4.预测方法：
当前项目（P）
估计总缺陷数（P）=缺陷注入率*工作量估计（P）
估计AT缺陷数（P）=估计总缺陷数（P）*验收测试占总缺陷的百分比
二.4.3里程碑阶段的缺陷级别预测
里程碑阶段
预计的里程碑阶段缺陷级别
（占总缺陷的百分比）
需求评审
15%-20%
设计评审
10％－30％
代码评审和单元测试
50%-70%
集成测试和系统测试
20%-28%
验收测试
5%-10%
预计的里程碑阶段缺陷数=估计总缺陷数*预计的里程碑阶段缺陷级别
项目经理在策划阶段和SQA人员一起确定项目的缺陷注入率，在项目估计基本完成的基础上，根据项目的总工时估计项目的缺陷。
第三章项目缺陷跟踪
三.1项目缺陷跟踪概述
缺陷数据的跟踪贯穿整个软件生命周期，将实际发生的缺陷数据与预测的缺陷数据进行比较、分析，获得各里程碑阶段的缺陷级别，达到预防缺陷的目的。
三.2实际缺陷数据的记录
缺陷识别人将缺陷登记到《项目问题日志》中，同时确定问题的负责人，缺陷的状态变成已识别。
在项目的里程碑阶段通过里程碑评审识别缺陷，并由评审主持人记录缺陷。
在单元测试阶段通过单元测试识别缺陷，由开发人员识别并记录缺陷。
在集成、系统和验收测试阶段通过集成、系统和验收测试识别缺陷，由测试人员记录缺陷。
项目经理统计项目报告、项目会议中反映的问题。
SQA人员过程评审和产品审计中的问题。
三.3缺陷解决
5.项目经理或者缺陷解决负责人根据《项目问题日志》中的问题，经过讨论分析以后（管理类问题和重大问题一般要在项目会议上讨论），分派处理人，缺陷状态变为已分析。
6.处理人接受任务后，缺陷状态变为正在处理。
7.处理人缺陷修改完成以后，经过相应的检查以后，缺陷状态变为已处理。
三.4缺陷跟踪
8.缺陷处理人处理完缺陷后，提交给缺陷跟踪人进行验证，验证通过后提交给项目经理或SQA人员进行审批。
9.缺陷处理结果获得批准，审批完成后转给SCM人员纳入配置库。
10.缺陷处理结果纳入配置库后，该缺陷关闭
三.5产生实际缺陷数据
项目结束时，项目经理统计项目的实际缺陷数据，产生实际缺陷级别和缺陷注入率。
1、产生实际的里程碑阶段缺陷级别
统计方法：
实际的里程碑阶段缺陷级别=各里程碑阶段的实际缺陷数/实际总缺陷数
2、产生实际的缺陷注入率
实际的缺陷注入率=实际工作量/实际总缺陷数
第四章缺陷分析
当预测和实际的缺陷数据获得后，就可以进行缺陷分析。
缺陷分析包括质量目标分析、测试用例分析等。
四.1质量目标分析
质量目标分析是通过分析预测和实际缺陷数据来监控产品质量目标，了解不同阶段的缺陷指标，为未来项目的缺陷预测提供依据（缺陷注入率）。
质量目标分析主要包括里程碑缺陷分布、测试阶段缺陷类型分布和缺陷严重程度分布。
项目经理定期或者事件驱动地对项目质量进行统计分析，并记录到《项目状态报告》中：
11.SQA人员统计里程碑各阶段的缺陷数据，分析各阶段的缺陷级别。
12.测试负责人统计测试阶段的缺陷类型分布和缺陷严重程度分布并分析（参照附录中缺陷类型和严重程度分类）。
13.项目经理汇总处理项目中缺陷数据并分析。
14.产生项目的质量目标分析，作为项目总结报告中的一部分参加项目评审。
四.2测试用例分析
测试负责人在集成测试阶段、系统测试阶段以及验收测试阶段，通过对用例符合程度和符合性进行对照，跟踪项目测试用例的执行情况，特别是测试情况的分析，总结项目前一阶段的开发工作。
具体内容按照《质量分析和缺陷报告模板》中的测试用例分析执行。
第五章
附录
五.1缺陷类型
目前针对软件开发项目中的缺陷主要分为管理类和技术类两大类，管理类缺陷主要包括过程类问题、项目管理问题和其他管理问题；
技术类主要包括需求问题、设计问题、数据错误、程序错误、输出问题、输入问题、报表问题和其他。
缺陷类型
说明
管理类
过程类
项目过程、组织过程定义问题以及组织制度等问题。
项目管理类
项目管理中没有按照过程执行出现的问题。
其他管理类
其他方面的管理问题。
技术类
需求问题
需求评审以及后续任务中发现的需求问题。
设计问题
设计评审以及后续任务中发现的设计中的问题。
数据错误
接口数据、调用参数等。
程序错误
程序方面的错误。
输出问题
格式、错误信息等
输入问题
用户输入、功能有效性和页面编排等方面的缺陷。
报表问题
报表方面的错误。
其他
技术方面的其他错误。
五.2缺陷严重程度
在项目中将缺陷的严重程度划分为以下几种：
致命缺陷、严重缺陷、一般缺陷和细微缺陷。
严重程度
致命缺陷
需求书中的重要功能未实现；
造成系统崩溃、死机,并且不能通过其它方法实现功能；
常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。
严重缺陷
严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如：
重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-timeerror、文件操作异常、通讯异常、数据丢失或破坏等错误；
重要功能不能按正常操作实现，但可通过其它方法可实现；
错误的波及面广，影响到其它重要功能正常实现；
密码明文显示；
C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。
一般缺陷
程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；
次要功能运行不正常，如：
次要功能不能正常实现；
操作界面错误（包括数据窗口内列名定义、含义不一致）；
打印内容、格式错误；
查询错误，数据错误显示；
简单的输入限制未放在前台进行控制；
删除操作未给出提示；
数据库表中有过多的空字段；
因错误操作迫使程序中断；
找不到规律的时好时坏；
数据库的表、业务规则、缺省值未加完整性等约束条件；
经过一段时间运行后，系统性能或响应时间会变慢；
重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；
硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；
系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；
或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。
细微缺陷
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如：
界面不规范；
辅助说明描述不清楚；
输入输出不规范；
长操作未给用户提示（或长操作结束后提示没有消失）；
提示窗口文字未采用行业术语；
可输入区域和只读区域没有明显的区分标志；
界面存在文字错误；
在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；
（如用户名第一位用数字或特殊字符）
升级会员 