缺陷管理规程.docx

缺陷管理规程 文档编号：JOYINTECH_PRDE_DEFECT 缺陷管理规程文档修订记录：版本编号或者更改记录编号变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V0.1C初次创建2010-08-23吴小敏V0.2U增加了：7缺陷填写规范、 9.3缺陷优先级、9.4缺陷状态、9.5解决方案、9.6发现阶段（应发现阶段）2011-03-16吴小敏V0.3U1.将“应发现阶段”改成“缺陷注入阶段” 2.将缺陷填写规范章节移到缺陷跟踪章节之前 3.将附录的“缺陷类型”给去掉2011-03-17吴小敏*变化状态：C创建，A增加，M修改，D删除文档审批信息序号审批人角色审批日期签字备注目录1 概述12 目的13 适用范围14 缺陷预测14.1 缺陷预测概述14.2 预测方法25 缺陷填写规范26 缺陷跟踪36.1缺陷流程图36.2实际缺陷数据的记录36.4缺陷解决46.5缺陷跟踪47 缺陷分析47.1缺陷注入-发现矩阵47.2利用QC查看缺陷分布67.3质量目标分析88 裁剪定义89 附录89.1缺陷严重程度89.2缺陷优先级109.3缺陷状态109.4解决方案109.5发现阶段（缺陷注入阶段）10第11页1 概述软件缺陷是指那些使软件的行为方式与需求或客户要求不一致的东西。软件产品质量的特性在实践中体现在缺陷上，缺陷管理的目标是提交缺陷尽量少的软件。如何计划和管理质量控制活动，作为质量特性的缺陷管理非常重要，它包括缺陷估计、缺陷数据的采集、跟踪与分析。2 目的本规程的目的是为了定义缺陷跟踪过程以及缺陷分析内容和方法。3 适用范围本文档适用于公司的所有软件项目。4 缺陷预测4.1 缺陷预测概述量化质量管理的一种方法是通过预测缺陷进行管理，这种方法的关键事宜是设定质量目标，并预测里程碑阶段的缺陷级别，以此来量化监督项目向着质量目标前进，缺陷的预测在项目策划阶段，由QA(assurance)人员和项目经理共同完成。本规程确定质量目标为以下指标：测试缺陷密度（每千行代码出现的bug数）=bug数/KLOC。评审缺陷密度=评审发现的缺陷数/评审对象的规模评审的通过准则：未发现问题-直接通过某指标范围内-修正后通过超出指标-需要再评审4.2 预测方法1. 预测前提条件：有类似项目的数据；但因公司目前还未积累历史数据，因而暂时采用行业标准。2. 预测方法：采用行业标准。5 缺陷填写规范下表罗列了缺陷包含的字段，绿色字体由测试人员填写，蓝色字体由开发人员填写，红色字体由测试人员和开发人员共同填写字段说明测试人员缺陷的发现者，自动生成发现日期缺陷提交时间，自动生成发现版本缺陷提交时的版本简要描述简要描述下缺陷的现象详细描述详细描述缺陷的步骤、实际结果、预期结果，格式举例如下：步骤：1.进入个人理财中心；2.点击导航栏我的资产二级菜单我的资产，进入我的资产页面；3.核对我的基金资产的基金简称是否正确；实际结果：1.页面上取值为基金名称期望结果：1.应取基金简称；分配给指定给相应的解决人员严重级别缺陷的严重程度：致命、严重、一般和细微，参考附录优先级修改缺陷的优先级别：高、中、低，参考附录状态缺陷的状态：New、Open、Rejected、Fixed、Reopen 、Closed，参考附录缺陷发现方式TC(用例测试)、ET(探索性测试)功能模块模块划分，不同项目自定义浏览器B/S系统运行的浏览器版本发现阶段缺陷实际发现的阶段，具体参考附录缺陷注入阶段缺陷应该发现的阶段，具体参考附录解决方案解决缺陷的方案：不是缺陷、不做修改、改代码、改需求或设计文档、缺陷可以接受、数据问题、推迟到下一阶段、重复缺陷，参考附录实际修复时间修复缺陷所花时间，单位为：分种缺陷原因描述引发缺陷的原因-以Comments形式填写缺陷修复对策描述修复缺陷的对策-以Comments形式填写关闭日期缺陷关闭日期关闭版本缺陷关闭时的版本6 缺陷跟踪缺陷数据的跟踪贯穿整个软件生命周期，对实际发生的缺陷数据进行比较、分析，获得各里程碑阶段的缺陷级别，达到预防缺陷的目的。6.1缺陷流程图6.2实际缺陷数据的记录测试人员将缺陷登记到缺陷管理系统QC中，缺陷的状态变成“New”。 6.4缺陷解决1. 项目经理或者缺陷解决负责人根据QC中的问题，经过讨论分析以后（管理类问题和重大问题一般要在项目会议上讨论），分派处理人，缺陷状态变为“Open”。项目经理或缺陷解决负责人分配缺陷的活动对于资源少或时间紧的项目可以裁减。2. 开发人员根据缺陷严重程度依次解决。处理完后将缺陷状态变为“Fixed”，并要填写上解决方案、缺陷原因、缺陷修复对策等。3. 缺陷解决负责人及时跟踪缺陷状态。对于“Open”或“Reopen”状态超过预期时间（预期时间根据各项目而定）的缺陷，督促开发人员处理。6.5缺陷跟踪1. 测试人员对“Fixed”的缺陷在发布新版本后进行验证。经检验，缺陷已经不存在的，状态改为“Closed”；缺陷仍然存在的，状态改为“Reopen”。2. 对于解决方案设置为“不做修改”、“缺陷可以接受”、“推迟到下一阶段修”状态的缺陷，测试人员得需要和开发人员讨论，并请QA/PM/TL去审查。3. 缺陷解决负责人及时跟踪缺陷状态。对新版本“Fixed”状态超过预期时间（预期时间根据各项目而定）的缺陷，督促测试人员验证。7 缺陷分析7.1缺陷注入-发现矩阵 缺陷有注入阶段和发现阶段两个重要指标，注入阶段和发现阶段可以是软件生命周期的各个阶段。根据这两个阶段可以绘制出一个“缺陷注入-发现矩阵”，从中分析出软件开发各个环节的质量，找到最需要改进的环节（见下表）缺陷注入阶段缺陷发现阶段需 求设 计编 码发现总计需求阶段44设计阶段136275编码、单元测试阶段2111629系统测试阶段2397102验收测试阶段002121注入总计2176134231本阶段缺陷移除率19%82%12%矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。缺陷移除率=（本阶段发现的缺陷数/本阶段注入的缺陷数）* 100%。上表的需求阶段的缺陷移除率 4/21*100%=19%。它反映的是该活动阶段的缺陷清除能力。即：阶段缺陷移除率可以有效的衡量测试用例是否充分，测试效率是否充足。相应的还有一个概念就是缺陷泄漏率，即有多少本阶段注入的缺陷没有在本阶段发现而是被泄漏到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）* 100%。显然，它等于（1 - 缺陷移除率）。它反映的是本阶段质量控制措施落实的成效。 从例子里我们可以看到：编码过程缺陷大部分是依赖系统测试发现的，显然单元活动测试开展不够深入，可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代；另外，需求阶段注入的缺陷绝大部分是在设计阶段发现的。这大概是目前国内公司大部分项目的现实，需求不稳定、不明确引起的。实际规划缺陷注入-发现矩阵时，可以依据自己的管理要求，对缺陷的发现活动和注入阶段进行细分或粗分，并且在Bug系统中提交时，需要准确地填写这些属性字段。7.2利用QC查看缺陷分布利用缺陷管理系统QC提供的数据表格、条形图、饼形图可以很明显的看出缺陷在分配者、检测者、缺陷注入阶段、系统模块、缺陷状态、严重程度等方面的分布。 下面是显示各阶段注入缺陷的分布，可以用数据表格、条形图、饼形图形式表示。从上例可以很明细的看到编码阶段注入的缺陷最多，这就需要我们进一步加强编码阶段活动以及代码走查等。 还可以显示各阶段缺陷出现的严重程度分布，如下图：从上图可以看到各阶段严重程度较高的缺陷分布范围都比较大，说明系统还很薄弱，还需进一步完善系统以及加强测试等。总之，可以利用QC系统查看缺陷在各个方面的分布，从而进行分析。7.3质量目标分析质量目标分析是通过分析预测和实际缺陷数据来监控产品质量目标，了解不同阶段的缺陷指标，为未来项目的缺陷预测提供依据。质量目标分析主要包括里程碑缺陷分布、测试阶段缺陷类型分布和缺陷严重程度分布以及缺陷密度。项目经理定期或者事件驱动地对项目质量进行统计分析，并记录到项目状态报告中：1. QA人员统计里程碑各阶段的缺陷数据，分析各阶段的缺陷级别，提交阶段缺陷分析报告。2. 测试负责人统计测试阶段的缺陷类型分布和缺陷严重程度分布并分析（参照附录中缺陷类型和严重程度分类）。并根据缺陷密度是否满足条件来分析，如果缺陷密度过小，可能需要采取些措施，如：提高测试用例质量、加强测试力度等。并提交测试阶段缺陷分析报告3. 项目经理汇总处理项目中缺陷数据并分析，并提交质量目标分析报告。4. 产生项目的质量目标分析，作为项目总结报告中的一部分参加项目评审。8 裁剪定义对于资源少或时间紧的项目，【6.4 缺陷解决】的第一步（项目经理或缺陷解决负责人分配缺陷的活动）可以裁减。9 附录9.1缺陷严重程度在项目中将缺陷的严重程度划分为以下几种：致命缺陷、严重缺陷、一般缺陷和细微缺陷。严重程度说明致命需求书中的重要功能未实现；造成系统崩溃、死机,并且不能通过其它方法实现功能；常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。严重严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，如：重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；重要功能不能按正常操作实现，但可通过其它方法可实现；错误的波及面广，影响到其它重要功能正常实现；密码明文显示；C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。一般程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如：次要功能不能正常实现；操作界面错误（包括数据窗口内列名定义、含义不一致）；打印内容、格式错误；查询错误，数据错误显示；简单的输入限制未放在前台进行控制；删除操作未给出提示；数据库表中有过多的空字段；因错误操作迫使程序中断；找不到规律的时好时坏；数据库的表、业务规则、缺省值未加完整性等约束条件；经过一段时间运行后，系统性能或响应时间会变慢；重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。细微程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如：界面不规范；辅助说明描述不清楚；输入输出不规范；长操作未给用户提示（或长操作结束后提示没有消失）；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志；界面存在文字错误；在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)9.2缺陷优先级优先级说明低在某个时间段内修改完毕即可中根据实际情况尽快修改高必须马上修改9.3缺陷状态状态说明New测试人员提交该缺陷，但需要验证缺陷是否有效Open测试组长复查缺陷，并认定为有效缺陷，开发人员开始修复此类缺陷Rejected测试组长复查缺陷，并认定为非有效缺陷，直接打回Fixed缺陷已经被修复，测试人员需要确认（在缺陷被开发人员置Fixed时，需要设置解决方案）Reopen测试人员确认该缺陷后，认为问题没有解决Closed测试人员确认缺陷，并填写解决方案后，关闭此缺陷9.4解决方案解决方案说明不是缺陷提交的缺陷非该项目缺陷，一般为测试人员理解误差不做修改