软件项目缺陷跟踪和持续改进.docxVIP

1.1转测质量

1.1.1交付要求

产品开发或修改准备提交测试版本在做转测试前需要开发设计工程师完成必要的自检并输出自测报告或调试报告

产品开发版本必须满足各阶段测试输入质量要求，并在对其自检并输出自测报告或调试报告审核后给出结果；

对于产品设计开发验证各阶段各类型缺陷Bug要求开发设计工程师必须给出明确清晰的问题分析原因和改善解决对策，并在Buglist和缺陷回馈体现！并自检其有效性！

对于满足提交标准的测试版本必须在提交测试申请同时配备软/硬件程序版本配置清单说明！

交付件必须完成过程审查与归档；

1.1.2测试标准

1.1.2.1测试开始准入标准

首次测试准入标准：硬件环境可用并要求标准，软件正确安装且可执行；核心和关键业务功能100%实现；提供产品功能调试报告或自检报告；并配备软硬件程序配置清单；

里程碑版本要满足阶段的质量要求。里程碑版本必须提交调试报告；

版本测试前需提交完整的产品软件包（不能是单个软件）

版本软/硬件测试申请、程序配套表和系统配套表（配置清单）

版本回归测试标准：致命缺陷修复率必须为100%，重要缺陷修复率不低于85%，缺陷总修复率必须不低于80%的情况下，才能提交新版本测试申请。

版本回归测试标准：对于提交的版本缺陷报告中的CRI、MAJ、MIN缺陷问题分析原因和改善解决对策描述不清晰或无描述；

对于设计变更或缺陷修复后的验证版本需要提供必要的测试申请说明和操作步骤指导说明，包括：环境、条件、配置、步骤、方法、达成目标等。

1.1.2.2测试中断标准

测试环境无法达到标准或无法满足测试的一致性，安装无法正确完成；

产品关键业务功能、性能、可靠性发现致命缺陷导致后续测试活动无法继续开展或测试结果不可靠；

已修复致命缺陷重现和新发现的致命缺陷导致后续功能无法连续实现或后续测试用例无法实施或测试结果不可靠；

对于提交的版本缺陷报告中的CRI、MAJ、MIN缺陷问题分析原因和改善解决对策描述不清晰或无描述；

基本用例有缺陷，中断测试打回。

1.1.2.3测试完成标准

除因缺陷导致无法实施的测试用例之外，测试覆盖率达到95%；

除因缺陷导致无法实施的测试用例之外，测试有效性和准确性评审达到95%；

达到各阶段测试质量目标。

1.2缺陷修复质量和及时性

软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。

1.2.1缺陷定义

软件未达到需求规格说明书的功能。

软件出现了需求规格说明书指明不会出现的错误。

软件功能超出需求规格说明书的范围。

软件未达到需求规格说明书未指出但应达到的目标。

测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

1.2.2缺陷生命周期

1.2.2.1缺陷生命周期图

1.2.2.2缺陷状态说明

缺陷状态

状态说明

激活状态

缺陷的初始状态，或者重新被激活的状态。

激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合适的工程师处理。

解决状态

缺陷被解决之后的状态。

激活状态的缺陷经过成功修复以后，由开发工程师操作为解决状态，系统将自动指派回创建者。

关闭状态

解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期结束。

如果验证未修复或者新版本又发生，则重新激活，缺陷状态重新变为激活。

1.2.3缺陷处理过程

1.2.3.1正常处理过程

（1）创建问题

在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项。

（2） 指派问题

创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。

（3） 确认问题

通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。

当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。

（4） 解决问题

此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。如果Bug无法解决或修改影响比较大，可申