软件测试：缺陷管理制度

缺陷管理制度

编制部门：                时间：

编  制  人：                时间：

标  准  化：                时间：

审        核：                时间：

批        准：                时间：

---



第一章：总则

1、为了加强测试部门管理工作，建立规范的缺陷管理制度，提高工作水平及效率，根据公司和部门的相关规定与实际情况，制定本缺陷管理制度。

2、本缺陷管理制度适用于*******科技有限公司，各测试、研发人员等同行人员应当依据本制度的规定，规范工作内容，保证软件质量。

3、软件缺陷（Defect、Bug）在本公司统称为BUG，即为软件中存在的某种破坏正常运行能力的问题、错误，或者隐蔽的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

4、缺陷会存于软件产品的整个生命周期中，缺陷的标准定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

5、软件缺陷的管理分为四个阶段，包括：缺陷提交、明确指向、缺陷修复、缺陷回归验证。

第二章：范围

1、适用于软件的整个生命周期。

2、不限于测试过程发现的缺陷。评审、用户使用等过程中发现的缺陷都应按本制度进行登记跟踪管理。

第三章：职责

公司人员应对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到一定的标准，包括内容如下：

1、测试工程师：在这里主要指发现和报告缺陷的测试人员，在一般流程中，他需要对这个缺陷后续相关的状态负责，包括相关人员对这个缺陷信息的询问回答，以及验证测试；

2、开发工程师：在这里主要指对这个缺陷进行研究和修改的开发人员，同时他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行测试验证；

3、其他参与人：主要有项目负责人、产品经理、测试人员、研发、用户等组成，他们对缺陷进行优先级划分，负责人进行确认并调解争议；

第四章：缺陷类型

缺陷类型是根据缺陷的自然属性划分的缺陷种类。采用行业标准并结合公司情况共分为九类，包括：功能缺陷、性能缺陷、数据校验缺陷、查询统计缺陷、安全性缺陷、界面交互缺陷、设计缺陷、兼容性缺陷、配置缺陷。

缺陷分类	定义	描述
功能缺陷	功能缺陷是指影响软件要求或基本功能实现的缺陷。满足以下一种或多种情况：	1）功能无法实现 2）功能实现错误 3）业务流程错误 4）功能操作与数据库存储不一致 5）功能与辅助帮助不吻合
性能缺陷	性能缺陷是指产品性能不能满足需求规格中对性能需求的要求。满足以下一种或多种情况：	1）数据计算错误 2）数据约束错误 3）不同的操作之间数据逻辑校验错误 4）数据库发生死锁 5）数据库的表、缺省值未加完整性等约束条件 6）数据库链接错误 7）数据库中的表有过多空字段
数据校验缺陷	数据校验缺陷是指提示的错误信息，不适当的数据验证等缺陷。满足以下一种或多种情况：	1）数据计算错误 2）数据约束错误 3）不同的操作之间数据逻辑校验错误 4）数据库发生死锁 5）数据库的表、缺省值未加完整性等约束条件 6）数据库链接错误 7）数据库中的表有过多空字段
查询统计缺陷	查询统计缺陷是指条件设置不准确引起的查询统计结果不正确。满足以下一种或多种情况：	1）查询条件设置不准确 2）查询结果列表异常 3）同一查询条件得到的结果不一致
安全性缺陷	安全性缺陷是指产品不能满足需求规格中对安全性需求的要求。满足以下一种或多种情况：	1）用户登录用户名/口令校验不正确 2）口令没有掩码显示 3）用户权限分配错误 4）用户功能超权限
界面交互缺陷	界面交互缺陷是指接口通信和人机交互时产生的缺陷。满足以下一种或多种情况：	1）组件、模块之间数据通信错误 2）程序接口错误 3）硬件通信接口错误 4）界面不存在，界面不满足易用性要求，界面难以被用户理解，界面不协调不美观，提示信息没有使用业务词汇或者容易被用户理解的词汇而是使用计算机专业术语 5）界面风格不对应一致，不符合操作习惯 6）提示、警告、错误说明等友好信息表达模糊、失当 7）没有区别不同操作（增加、删除、修改、查询）对应界面的性质 8）没有提供辅助输入手段
设计缺陷	设计缺陷是指软件在最初设计时由于未全面考虑，而是软件在使用中存在一些潜在的缺陷（设计缺陷的存与产品需求、架构、编码、测试阶段中）。满足以下一种或多种情况：	1）需求分析阶段没有考虑和挖掘到隐式需求，导致的需求缺失 2）考虑不周、覆盖不全、频繁变更为记录、过于繁琐无法拓展 3）操作便捷性设计不符合大众操作习惯 4）空间功能设置不符合大众使用习惯 5）错误提示内容不符合大众阅读习惯 6）其他设计不合理引发的缺陷
兼容性缺陷	兼容性缺陷是指软件在使用中不能正确地交互和共享信息。满足以下一种或多种情况：	1）操作平台、系统不兼容 2）浏览器不兼容 3）分辨率不兼容
配置缺陷	配置缺陷是指由于配置库、变更管理或版本控制引起的错误。满足以下一种或多种情况：	1）独立安装部署不成功 2）配置文件或初始化数据错误 3）不同运行环境产生的错误

第五章：缺陷管理流程

阶段流程	描述
新提交	缺陷提交阶段需要提交详情，测试人员必须保证等级的缺陷信息可以被处置负责人员理解，缺陷报告必须详细描述缺陷内容。
定位	缺陷分析定位阶段需要根据缺陷报告的内容对缺陷进行分析和定位。缺陷分析和定位是相关人员根据缺陷报告中对缺陷的详细描述查找重现缺陷，确定缺陷产生的原因，明确缺陷所处的位置，以便修改缺陷。
解决	缺陷修复阶段需要对已经定位的缺陷进行修改。缺陷修复是开发人员对已经分析定位的缺陷进行修改并更改缺陷状态，修改后的软件需要实现预期的结果（缺陷记录中的预期结果）。
否决	如果开发人员发现该缺陷不可再现、重复、不是问题等情况，可以把缺陷状态设置成“已拒绝”。
挂起/延迟	如果按照开发计划、缺陷发生的功能不属于当前开发阶段必须完成的，可将缺陷状态设置为“挂起”，并在实际版本中添加具体版本或截止时间。
回归验证	回归验证阶段需要对已经修改的缺陷进行验证和回归测试。 缺陷回归验证是测试人员对已经修改的缺陷进行回归测试，根据缺陷记录中的操作步骤对缺陷重新进行测试，并对缺陷修改过程中可能影响到的组件、模块或功能进行重新测试，验证修改后的缺陷可以实现预期结果并对其他组件、模块或功能无影响。 同时，根据验证结果修改相应的缺陷状态为“内测完成”，通知相关人员拟定发布时间。
重新打开	验证测试不通过的缺陷，应当重新打开，状态更变为“重新打开”。 关闭了的缺陷再次出现时（通常因为解决缺陷的方法导致相同位置出现不同形式的缺陷时），测试人员需要重新打开缺陷，开发人员需要继续进行解决。公司各负责人应当关注“重新打开的缺陷”。
关闭	测试人员确认缺陷已经解决并发布生产后，关闭缺陷更改其状态为“已发布”，生产缺陷保留三个版本后进行归档。 对于否决的缺陷，测试人员需要和同行各负责人进行讨论，意见达到一致后可以关闭，如不同意的需要“重新打开”。

第六章：缺陷记录

6.1编号

缺陷的唯一标识，可以方便对特定缺陷记录的引用，由系统根据特征下自生成。

6.2标题

标题由问题产生的功能模块与现象组成，如：系统平台-频道/模块-功能：执行什么操作产生什么现象。

6.3实际版本

即缺陷是在什么版本中发现。

6.4缺陷描述

对该缺陷进行简短的描述，尽量使负责人能够理解。

步骤描述该缺陷出现的详细步骤，尽量做到步骤清楚、可再现。

预期结果中明确软件功能预期实现的要求（若测试人员无法定位到预期实现的效果，研发人员需在处置记录中进行修改后实现描述）。格式如：

操作人员账号（高级维修工程师岗-18100000000）

基本操作步骤：

1、服务商-工程师抢单时，因服务能力中未设置分类，导致抢单时能看到工单，但是无法抢单

目前实现：服务商-工程师抢单时，因服务能力中未设置分类，导致抢单时能看到工单，但是无法抢单

预期实现结果：去掉分类的拦截，有服务能力，能看到工单就能抢单

6.5严重程度

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

结合行业标准与公司实际情况分四类：致命、严重、一般、建议。

【申明：自行恢复指在不需要人工特别是程序员介入的情况下，通过自动化生成正确的修复包或处理机制来修复目标软件中存在的Bug的一种程序或处理方式（重新安装或重新启动该软件不属于更正办法）】

等级	定义	描述
致命	缺陷发生后，产品的主要功能会失效，业务会陷入瘫痪状态，关键数据损坏或丢失，且故障无法自行恢复。如下举例	1）产品主要功能失效或和用户期望不符，用户无法正常使用； 2）程序引起的死机、反复重启等、且故障无法自动恢复； 3）死循环、死锁、内存泄漏、内存重释放等； 4）系统存在严重的安全漏洞； 5）会引发用户关键数据损坏或丢失不可恢复；
严重	缺陷发生后，主要功能无法使用、失效，存在可靠性、安全性能等方面的重要问题，但是出现后一般可以自行恢复。如下举例：	1）产品重要功能不稳定； 2）有程序引起的非法退出、重启等，但是故障可以自行恢复； 3）产品难以理解和操作； 4）产品无法进行正常维护； 5）产品升级后功能出现丢失，性能下降等； 6）性能达不到系统规格； 7）产品不符合标准规范，存在严重的兼容性问题；
一般	缺陷发生后，系统存在功能、性能、可靠性、易用性、可维护性、可安装性等方面出现一般性问题。如下举例：	1）产品一般性的功能失效或不稳定； 2）产品未进行输入限制（未对正确值和错误值进行界定）； 3）一般性规范和兼容问题； 4）系统报表、日志、统计信息在显示出现错误； 5）系统调试信息难以理解或存在错误； 6）存在错别字，语句不通；
建议	缺陷发生后，对用户只会造成轻微影响，这些影响一般在用户可忍受的范围内。如下举例：	1）产品的输出正确，但不够规范； 2）提示信息不够清晰准确，难以理解； 3）需要较长时间的操作未给用户提供提示；

6.6优先级

缺陷优先级指缺陷必须被修复的紧急程度。结合行业标准与公司实际情况分五类：最高、较高、普通、较低、最低。

等级	定义	举例
最高	该缺陷导致系统几乎不能使用或测试不能继续，非常紧急，需立即或在8小时内修复。	如：主要业务无法绕过无法使用、应用程序包版本不对、无法安装导致无法测试、闪退、崩溃等；
较高	缺陷严重影响测试或产品目的，需优先考虑。	如：产品的商标未展示、版权未更正、技术性的内容不正确、主要业务实现的具体内容存在偏差等；
普通	对产品来说不是那么关键的场景或特性，正常排队即可。	如：在小标题上发现的错误、从历史版本中来的遗留bug等（非主要功能）
较低	对产品使用没有太大影响，如能修复这个缺陷会很好。	如：在低使用频率页面中发现的bug、很少被使用的功能等；
最低	对产品的影响非常小，可在开发人员有时间的时候再修复。	如：文字重叠、错别字等UI方面的缺陷，不易操作、建议性等；

6.7状态

缺陷状态只缺陷在跟踪修复过程中的进展状态。结合行业标准与公司实际情况分八类：新提交、未通过、重新打开、处理中、已修复、内测完成、已发布、挂起、已拒绝

状态	定义
新提交	已提交/首次提交的缺陷，等待处理；
未通过	验证后发现未修复的缺陷、修复后引发同位置不同类型的缺陷（新缺陷要进行提交，旧缺陷要进行打开）；
处理中	研发人员已确认缺陷，并按照约定进行处理；
已修复	缺陷被修复并告知测试工程师进行回归验证；
内测完成	确认被修复的缺陷并进行验证完毕；
已发布	确认验证完毕的缺陷已发布生产环境；
挂起	因研发版本冲突或操作不当、无法复现等原因导致缺陷暂缓修复或非缺陷问题转需求处理（需求建立后进行沟通并在版本结束时关闭此缺陷）
重新打开	版本发布后，还依然存在的缺陷，等待开发人员进一步修复；
已拒绝	程序按照既定设计正常运行，非缺陷原因引起；

6.8复现概率

必现：该软件缺陷总是能够复现，复现率为100%。

偶发：根据测试步骤执行，偶尔复现软件缺陷，复现率为40%~70%

极低：根据测试步骤执行，很少复现软件缺陷，复现率为10%~30%（包括提出者仅一次出现）

6.9负责人

负责处置解决缺陷的负责人：

对于功能缺陷，负责人应当具体开发人员（同步解决人）；

对于非功能缺陷，负责人应当是具体特征的构建者、提出者，由他重新分配解决人；

缺陷登记者不明确责任人时，可以指定公司相应部门领导为责任人，由他重新分配解决人；

6.10解决方案（研发人员填写）

解决方案是缺陷负责人对缺陷处置结果的简短描述，如：

解决方案项	定义
“按设计实现”	如缺陷既定功能不进行改变；
“已修复”	如缺陷无法按照原既定功能实现需要变动功能/逻辑/接口，或需处理数据；
“转需求”	缺陷的产生非系统实现问题，运行情况正常，需产品、设计人员参与；
“重复提交”	如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题一致；
“暂不修复”	部分不紧急的缺陷问题，可能会随着日后的产品迭代中进行修复。
“不是问题”	如果开发团队认为提交上来的缺陷并不是真正的缺陷，比如由于缓存，网络导致的部分文件加载失败导致的问题等，应将缺陷状态标记为“拒绝”并指派回测试团队。测试团队需要重新测试或者提供更多的缺陷信息；
“无法重现”	缺陷无法重现、无法追溯，但内外部有提出，将偶现类缺陷挂起三个版本进行观察（阶段状态应挂起进行，直到复现时激活，逾期后归档）；



6.11处理记录（研发人员填写）

处置记录通常是解决方法，填写时需结合解决方案并延伸阐述：

其中包括不限于简要阐述缺陷产生原因、所关联的业务功能是否会引起其他问题以及解决方法等。如：

原因：说明缺陷产生的原因，如：设计考虑不周、边界处理不颜面、逻辑判断不合理等；

解决方法：修改设计的文件、源代码、配置、脚本等；

概括：缺陷可能存在其他位置或引起其他问题，缺陷涉及如下业务功能等；

6.12修复

在实际项目中，不是所有的缺陷都会修改，具体见以下情况（标准见附录）：

1、市场的压力使得产品最终发行有时间限制；

2、测试人员错误理解或不正确操作引出的缺陷；

3、错误的修改影响的模块较多，带来的风险较大；

4、缺陷报告中提出的问题很难重现；

5、修改性价比太低；

6.13问题来源

根据缺陷产生或提出人所操作的环境进行定位。包括如下：

生产环境、测试环境、演示环境、本地dubbo

第七章：处罚机制

7.1奖惩

测试部门处罚、奖励进行总分制度增减，主要依据生产系统，主要如下：

1、处罚：

1）、对于测试过程中产生的BUG，未记录的，一旦发现，直接作为漏测BUG计算（除需求任务本身存在问题、配置问题、因修改引入未得到告知而产生的）；

2）、同时主管以上人员负主要责任，并按照严重级别与影响范围给与相应的绩效方面的扣分：

• 致命缺陷：适影响及程度确定不得低于6分

• 严重缺陷：适影响及程度确定不得低于3分

• 一般缺陷：超过版本发布要求的根据数量与影响程度确定不得低于1分

• 建议缺陷：不做要求

2、奖励：

1）、测试人员在日常工作中对缺陷管理工作认真积极，或工作水准有明显进步提升、效率提高的，且得到一致认同的不得低于2分；

2）、测试人员提前发现系统中已存在但未触发的缺陷，挽回公司口碑或效益视情况的给予奖励：

• 致命缺陷：适影响及程度确定不低于6分

• 严重缺陷：适影响及程度确定不低于3分

• 一般缺陷：适影响及程度确定不低于1分

• 建议缺陷：不做要求

补充内容：2022-12-1，经一个月周期试行通过，此内容进入规范施行：

1）、生产缺陷奖惩制度进一步明确：测试部门、研发部门、产品部门、技术设计部门共同实施以下内容：

• 测试部门按照缺陷管理制度执行；

• 研发部门缺陷解决责任人及上级主管：同类或同功能点问题已经在生产环境上出现过（从2022.3月开始）；

• 产品部门设计缺陷解决责任人及上级主管：同类或同功能点设计缺陷问题已经在生产环境上出现过（从2022.9月开始）；

• 技术设计部门设计缺陷解决责任人及上级主管：同类（含部署配置）设计缺陷问题已经在生产环境上出现过（从2022.9月开始），或明确方案和制度未执行导致的；

此内容实施后扣除分值按此公式执行： 【扣除分值=（出现次数-1）* 2 * 基础分值】	致命缺陷：适影响及程度确定不得低于6分 严重缺陷：适影响及程度确定不得低于3分 一般缺陷：超过版本发布要求的根据数量与影响程度确定不得低于1分 建议缺陷：不做要求

第八章：附录

1、测试团队中的任何人都有权利和义务提出缺陷并负责跟踪关闭。如本人无法跟踪和关闭，请委托上一级领导进行跟踪并关闭缺陷。

2、公司团队中的任何人都有权利和义务反馈并提出缺陷，并告知测试详情步骤进行多次验证，测试人员应在缺陷的各个阶段进行反馈。

3、缺陷的严重程度、优先级和状态均严格按照本制度执行

4、本制度审核通过起施行

5、版本内缺陷发布要求，如下：

一级错误（致命）	二级错误（严重）	三级错误（一般）	四级错误（建议）
无	无	<=3%	暂不做要求

6、生产缺陷修复要求，如下：

缺陷定位	严重程度	修复时间
1、特征性问题：功能缺陷、数据校验缺陷、查询统计缺陷 2、非特征问题：性能缺陷、安全性问题、设计缺陷、兼容性缺陷、配置缺陷、界面交互缺陷 结合第四章9类缺陷	致命缺陷	立即解决，所有资源偏移，最大时间区间6~8小时
	严重	快速解决，大部分资源偏移，最大时间区间8~12小时
	一般	按计划解决，小部分资源偏移，最大时间区间24~36小时或排并计划
	建议	记录内容转需求，随版本档期进行

7、流程图

8、缺陷的分类与严重程度的联系

缺陷分类的子类决定其严重程度的评估

9、缺陷严重程度与优先级的联系

缺陷的优先级由业务使用进行评估（严重以上等级优先级应与之匹配）

BUG的严重程度和优先级不一定成正比：BUG严重程度高优先级不一定高、严重程度低优先级不一定低。

10、缺陷分析

缺陷发布前最后一周进行分析，分析内容包括测试计划首次通过率，对通过率低于80%的计划进行缺陷检查，检查内容如下：

缺陷所在模块、缺陷的类型、缺陷关闭前执行的次数及状态

发版前一天检查：缺陷严重级别2级以上的状态是否关闭，3级缺陷存在量是否低于3%，所有用例是否均执行通过（如不通过需有描述）