CMMI支持QA缺陷管理规程V2.0

《CMMI支持QA缺陷管理规程V2.0》由会员分享，可在线阅读，更多相关《CMMI支持QA缺陷管理规程V2.0（15页珍藏版）》请在金锄头文库上搜索。

1、.缺陷管理规程文档编号：GZCY_DMG_PRS-V1.0文档信息：文档名称：文档类别：CMMI模板密 级：机密版本信息：V1.0建立日期：创 建 人：审 核 者：批 准 人：批准日期： 保 管 人：存放位置：编辑软件：Microsoft Office 2003 英文版CONFIDENTIAL精品.文档修订记录版本编号或者更改记录编号变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V1.0C初次创建CMM事业部*变化状态：C创建，A增加，M修改，D删除文档审批信息序号审批人角色审批日期签字备注精品.前 言软件缺陷是指那些使软件的行为方式与需求或客户要求不一致的东西。软件产品质量的

2、特性在实践中体现在缺陷上，缺陷管理的目标是提交缺陷尽量少的软件。如何计划和管理质量控制活动，作为质量特性的缺陷管理非常重要，它包括缺陷的估计、缺陷数据的采集、跟踪与分析。精品.目 录第一章 简介11.1 文档目的11.2 适用范围11.3 术语表11.4 参考资料1第二章 项目缺陷预测22.1 概述22.2 入口准则22.3 参与人员22.4 预测方法22.4.1 类似项目的质量目标预测22.4.2 新项目的质量目标预测32.4.3 里程碑阶段的缺陷级别预测3第三章 项目缺陷跟踪43.1 项目缺陷跟踪概述43.2 实际缺陷数据的记录43.3 缺陷解决43.4 缺陷跟踪53.5 产生实际缺陷数据

3、5第四章 缺陷分析64.1 质量目标分析64.2 测试用例分析6精品.第五章 附录75.1 缺陷类型75.2 缺陷严重程度7精品.第一章 简介1.1 文档目的本规程的目的是为了定义缺陷估计的内容和方法，缺陷跟踪过程以及缺陷分析内容和方法。1.2 适用范围本文档适用于公司的所有软件项目。1.3 术语表l 项目规模：代码行、功能点或工作量（人时），本规程指工作量。l 缺陷注入率：单位规模（人时）的缺陷数。l 里程碑阶段缺陷级别：里程碑阶段（需求、设计、编码、单元测试、集成测试、系统测试和验收测试阶段）的缺陷占总缺陷数的百分比。l 缺陷清除率：已发现的缺陷数占已预测的总缺陷数的百分比。l 缺陷出现时

4、机：在需求评审、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试识别缺陷。1.4 参考资料精品.第二章 项目缺陷预测2.1 概述量化质量管理的一种方法是通过预测缺陷进行管理，这种方法的关键事宜是设定质量目标，并预测里程碑阶段的缺陷级别，以此来量化监督项目向着质量目标前进，缺陷的预测在项目策划阶段，由SQA人员和项目经理共同完成。本规程确定质量目标为：预测在验收测试阶段可能出现的缺陷数，简称估计AT缺陷数（估计验收测试缺陷数）。2.2 入口准则l 立项报告已批准2.3 参与人员l SQA人员：进行数据分析的策划，项目质量数据的分析、总结；l 项目经理：进行数据分析的策划，进行一定的数据

5、分析工作。2.4 预测方法2.4.1 类似项目的质量目标预测1. 预测前提条件：有类似项目的数据，当前项目已经完成工作量估计2. 预测方法：当前项目（P）, 类似项目集（SP）精品.估计总缺陷数（P）= 总缺陷数（SP）* 工作量估计（P）/实际工作量（SP）估计AT缺陷数（P）= AT缺陷数（SP）*工作量估计（P）/ 实际工作量（SP）2.4.2 新项目的质量目标预测1. 预测前提条件： 项目过程库中已存在或估计了过程的缺陷清除率和缺陷注入率（x缺陷/人时） 当前项目已经完成工作量估计（人时）2. 预测方法：当前项目（P）估计总缺陷数（P）= 缺陷注入率 * 工作量估计（P）估计AT缺陷数

6、（P）= 估计总缺陷数（P）* 验收测试占总缺陷的百分比2.4.3 里程碑阶段的缺陷级别预测里程碑阶段预计的里程碑阶段缺陷级别（占总缺陷的百分比）需求评审15% - 20%设计评审 1030代码评审和单元测试50% - 70%集成测试和系统测试20% - 28%验收测试5% - 10%预计的里程碑阶段缺陷数 = 估计总缺陷数 * 预计的里程碑阶段缺陷级别项目经理在策划阶段和SQA人员一起确定项目的缺陷注入率，在项目估计基本完成的基础上，根据项目的总工时估计项目的缺陷。精品.精品.第三章 项目缺陷跟踪3.1 项目缺陷跟踪概述缺陷数据的跟踪贯穿整个软件生命周期，将实际发生的缺陷数据与预测的缺陷数据

7、进行比较、分析，获得各里程碑阶段的缺陷级别，达到预防缺陷的目的。3.2 实际缺陷数据的记录缺陷识别人将缺陷登记到项目问题日志中，同时确定问题的负责人，缺陷的状态变成已识别。 在项目的里程碑阶段通过里程碑评审识别缺陷，并由评审主持人记录缺陷。 在单元测试阶段通过单元测试识别缺陷，由开发人员识别并记录缺陷。 在集成、系统和验收测试阶段通过集成、系统和验收测试识别缺陷，由测试人员记录缺陷。 项目经理统计项目报告、项目会议中反映的问题。 SQA人员过程评审和产品审计中的问题。3.3 缺陷解决1. 项目经理或者缺陷解决负责人根据项目问题日志中的问题，经过讨论分析以后（管理类问题和重大问题一般要在项目会议

8、上讨论），分派处理人，缺陷状态变为已分析。2. 处理人接受任务后，缺陷状态变为正在处理。精品.3. 处理人缺陷修改完成以后，经过相应的检查以后，缺陷状态变为已处理。3.4 缺陷跟踪1. 缺陷处理人处理完缺陷后，提交给缺陷跟踪人进行验证，验证通过后提交给项目经理或SQA人员进行审批。2. 缺陷处理结果获得批准，审批完成后转给SCM人员纳入配置库。3. 缺陷处理结果纳入配置库后，该缺陷关闭3.5 产生实际缺陷数据项目结束时，项目经理统计项目的实际缺陷数据，产生实际缺陷级别和缺陷注入率。1、 产生实际的里程碑阶段缺陷级别 统计方法：实际的里程碑阶段缺陷级别 = 各里程碑阶段的实际缺陷数 / 实际总缺

9、陷数2、 产生实际的缺陷注入率 统计方法：实际的缺陷注入率 = 实际工作量 / 实际总缺陷数精品.第四章 缺陷分析当预测和实际的缺陷数据获得后，就可以进行缺陷分析。缺陷分析包括质量目标分析、测试用例分析等。4.1 质量目标分析质量目标分析是通过分析预测和实际缺陷数据来监控产品质量目标，了解不同阶段的缺陷指标，为未来项目的缺陷预测提供依据（缺陷注入率）。质量目标分析主要包括里程碑缺陷分布、测试阶段缺陷类型分布和缺陷严重程度分布。项目经理定期或者事件驱动地对项目质量进行统计分析，并记录到项目状态报告中：1. SQA人员统计里程碑各阶段的缺陷数据，分析各阶段的缺陷级别。2. 测试负责人统计测试阶段的

10、缺陷类型分布和缺陷严重程度分布并分析（参照附录中缺陷类型和严重程度分类）。3. 项目经理汇总处理项目中缺陷数据并分析。4. 产生项目的质量目标分析，作为项目总结报告中的一部分参加项目评审。4.2 测试用例分析测试负责人在集成测试阶段、系统测试阶段以及验收测试阶段，通过对用例符合程度和符合性进行对照，跟踪项目测试用例的执行情况，特别是测试情况的分析，总结项目前一阶段的开发工作。具体内容按照质量分析和缺陷报告模板中的测试用例分析执行。精品.附录4.3 缺陷类型目前针对软件开发项目中的缺陷主要分为管理类和技术类两大类，管理类缺陷主要包括过程类问题、项目管理问题和其他管理问题；技术类主要包括需求问题、

11、设计问题、数据错误、程序错误、输出问题、输入问题、报表问题和其他。缺陷类型说明管理类过程类项目过程、组织过程定义问题以及组织制度等问题。项目管理类项目管理中没有按照过程执行出现的问题。其他管理类其他方面的管理问题。技术类需求问题需求评审以及后续任务中发现的需求问题。设计问题设计评审以及后续任务中发现的设计中的问题。数据错误接口数据、调用参数等。程序错误程序方面的错误。输出问题格式、错误信息等输入问题用户输入、功能有效性和页面编排等方面的缺陷。报表问题报表方面的错误。其他技术方面的其他错误。4.4 缺陷严重程度在项目中将缺陷的严重程度划分为以下几种：致命缺陷、严重缺陷、一般缺陷和细微缺陷。严重程

12、度说明致命缺陷需求书中的重要功能未实现；造成系统崩溃、死机,并且不能通过其它方法实现功能；常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。精品.严重缺陷严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如：重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；重要功能不能按正常操作实现，但可通过其它方法可实现；错误的波及面广，影响到其它重要功能正常实现；密码明文显示；C/S、B/S模式下，

13、利用客户端某些操作可造成服务端不能继续正常工作的。一般缺陷程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如：次要功能不能正常实现；操作界面错误（包括数据窗口内列名定义、含义不一致）；打印内容、格式错误；查询错误，数据错误显示；简单的输入限制未放在前台进行控制；删除操作未给出提示；数据库表中有过多的空字段；因错误操作迫使程序中断；找不到规律的时好时坏；数据库的表、业务规则、缺省值未加完整性等约束条件；经过一段时间运行后，系统性能或响应时间会变慢；重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；硬件或通讯异常发生恢复后，系统不能自动正

14、常继续工作（需要过多的人工干预才行）；系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。细微缺陷程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如：界面不规范；辅助说明描述不清楚；输入输出不规范；长操作未给用户提示（或长操作结束后提示没有消失）；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志；界面存在文字错误；在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)如有侵权请联系告知删除，感谢你们的配合！