第一章 总则
为了加强部门管理，建立规范的缺陷管理制度，提高工作标准，根据公司、部门的有关规定，制定了缺陷管理制度。
本缺陷管理制度适用于工程技术部，全体测试人员及研发人员均应按照本制度的规定规范工作，确保软件质量。
软件缺陷又称bug。所谓软件缺陷，是指软件中存在损害正常运行能力的问题、错误或隐藏的功能缺陷。缺陷的存在将导致软件产品在一定程度上不能满足用户的需求。IEEE729-1983对缺陷有标准定义：从产品内部角度看，缺陷是软件产品在开发或维护过程中出现的错误、故障等各种问题；从产品的外部角度看，缺陷是系统需要实现的某项功能的失败或违背。
软件缺陷的管理分为四个阶段，包括：缺陷提交、明确指出缺陷类型、缺陷修复、缺陷回归验证。
第二章 职责
项目人员应对每个阶段测试发现的缺陷进行跟踪和管理，确保各级缺陷修复率达到一定的标准。内容如下：
2.1 测试人员在提供的缺陷模板中创建或重新打开一个缺陷。
2.2 测试人员提交的缺陷将会反馈给项目负责人，由项目负责人安排开发人员修复缺陷。
2.3 开发人员修复缺陷后，应记录处理时间及结果，并及时反馈文档给测试人员核实。
2.4 测试人员验证缺陷后，应记录验证时间和结果，并提交给项目负责人。
第三章 缺陷类型
缺陷类型是指按照缺陷的自然属性划分的缺陷种类，共分为九类，包括：文档缺陷、设计缺陷、配置缺陷、界面交互缺陷、数据验证缺陷、查询统计缺陷、功能缺陷、性能缺陷、安全缺陷。
3.1 文档缺陷
文档缺陷是指软件相关文档不满足完整性、正确性、一致性、可理解性、可导航性的要求。
满足下列一个或多个条件：
（1）对发布和维护的影响，包括评论。
（2）文件中的术语不一致。
（3）文件中的词语、句子表达不清楚，造成歧义。
（4）文档内容缺失，结构不完整。
（5）文件准备过程中出现的错误。
（6）文件中发现的其他错误。
3.2 设计缺陷
设计缺陷是指由于软件在初始设计时考虑不周，导致软件在使用过程中可能出现的缺陷。设计缺陷可能满足下列一种或多种情况：
（1）需求分析阶段没有考虑和发现的隐性需求，导致需求缺失。
（2）操作便捷性设计不符合广大民众的操作习惯。
（3）控制功能设计不符合大众的使用习惯。
（4）错误提示不符合社会大众的阅读习惯。
（5）由于设计不合理造成的其他缺陷。
3.3 配置缺陷
配置缺陷是由配置存储库、变更管理或版本控制导致的错误。它们可能由以下一个或多个原因导致：
（1）独立安装部署失败。
（2）配置文件或初始化数据不正确。
（3）由于运行环境不同而引起的错误。
3.4 界面交互缺陷
界面交互缺陷是指在界面通讯和人机交互过程中出现的缺陷，满足以下一种或多种情况：
（1）组件、模块间数据通讯错误。
（2）程序接口错误。
（3）硬件接口通讯错误。
（4）界面不存在、界面不符合可用性要求、界面用户难以理解、界面不协调、不美观，提示信息未使用业务术语或用户容易理解的词语而是使用计算机专业术语。
（5）界面风格不太一致，不符合操作习惯。
（6）提示、警告、错误信息等友好信息表述模糊或者不恰当。
（7）不同操作（增加、删除、修改、查询）对应的接口的属性没有区分。
（8）没有提供辅助输入手段。
3.5 数据验证缺陷
数据验证缺陷是指错误消息、不适当的数据验证等缺陷，满足以下一种或多种情况：
（1）数据计算错误。
（2）数据约束错误。
（3）不同操作之间的数据逻辑验证错误。
（4）数据库发生死锁。
（5）数据库表和默认值不受完整性约束。
（6）数据库连接错误。
（7）数据库中的表有太多空字段。
3.6 查询统计缺陷
查询统计缺陷是指由于条件设置不准确，导致查询统计结果不正确。满足以下一种或多种情况：
（1）查询条件设置不正确。
（2）查询结果列表异常。
（3）对于相同的查询条件，得到的结果不一致。
3.7 功能缺陷
功能缺陷是指影响软件需求或基本功能实现的缺陷，满足下列一种或多种情况：
（1）该功能无法实现。
（2）功能实现错误。
（3）业务流程错误。
（4）功能操作与数据库存储不一致。
（5）功能与辅助帮助不一致。
3.8 性能缺陷
性能缺陷是指产品性能不能满足需求规范中的性能要求。满足以下一种或多种情况：
（1）业务处理效率低。
(2)查询统计效率低。
（3）响应速度不能满足需求规范的要求。
3.9 安全漏洞
安全缺陷是指产品不能满足需求规范中的安全要求。它满足以下一个或多个条件：
（1）用户登录用户名/密码验证错误。
（2）密码不带掩码显示。
（3）用户权限分配错误。
（4）用户操作超越其权限的。
第四章 缺陷管理流程
4.1 新建（提交）
缺陷提交阶段需要提交缺陷报告，测试人员需要确保登记的缺陷信息能够被负责处理的人员理解，因此缺陷报告必须详细描述缺陷内容，详情请参见缺陷记录。
4.2 定位
缺陷分析与定位阶段需要根据缺陷报告的内容对缺陷进行分析与定位。缺陷分析与定位是相关人员根据缺陷报告中对缺陷的详细描述，查找并重现缺陷，确定缺陷产生的原因，明确缺陷的位置，以便对缺陷进行修改。
4.4 解决方案
缺陷修复阶段要求对已定位的缺陷进行修改。缺陷修复是开发人员对已经分析定位到的缺陷进行修改，改变缺陷状态的过程。修改后的软件需要达到预期的结果（缺陷报告中的预期结果）。
4.5 否决
如果开发人员发现缺陷不可重现，重复，不是问题等，则可以将缺陷状态设置为“Rejected”。
4.6 延迟处理
如果根据开发计划，出现缺陷的功能不是当前开发阶段必须完成的功能，则可以将缺陷状态设置为“延期处理”。
4.7 回归验证
缺陷回归验证阶段需要对修改后的缺陷进行验证和回归测试。缺陷回归验证是测试人员对修改后的缺陷进行回归测试，按照缺陷报告中的操作步骤对缺陷进行重新测试，对缺陷修改过程中可能受影响的组件、模块或功能进行重新测试，以验证修改后的缺陷能够达到预期的效果，并且不会对其他组件、模块或功能产生影响。同时根据验证结果修改相应的缺陷状态，并提交新产生的缺陷。
4.8 重新开放
验证测试失败的缺陷应重新打开，状态改为“重新打开”。当已关闭的缺陷再次出现时（通常是解决缺陷的方法在同一位置导致不同形式的缺陷），测试人员重新打开缺陷，开发人员需要继续解决它。项目负责人应关注“重新打开”的缺陷。
4.9 关闭
测试人员确认缺陷解决后，缺陷关闭。对于被拒绝的缺陷，测试人员需要和项目负责人商量，如果项目负责人同意，缺陷可以关闭。如果项目负责人不同意，缺陷需要“重新打开”。
第五章 缺陷记录
5.1 编号
缺陷的唯一标识符可以轻松引用特定的缺陷记录。
5.2 项目
5.3 版本
也就是说，在哪个版本中发现了缺陷。
5.4 功能模块
5.5 缺陷描述
以责任方尽可能容易理解的方式提供缺陷的简要描述。
5.6 复现步骤
描述缺陷发生的详细步骤，尽量使步骤清晰，有例子，可重现。
5.7 严重性
缺陷的严重程度是指缺陷导致故障对软件产品的影响程度，分为致命、严重、一般、轻微、迅速五种级别。
（1）致命：无法执行正常工作功能或重要功能。
（2）严重：严重影响系统要求或基本功能的实现，造成系统错误或关机，且无法纠正。（重新安装或重启软件不属于纠正方式）
（3）一般：严重影响系统要求或基本功能的实现，导致系统提示错误，但有合理的修正方法。（重新安装或重启软件不构成修正方法）
（4）轻微：给操作人员带来不便或麻烦，但不影响工作功能或重要功能的履行。
（5）提示：其他错误。
5.8 优先级
缺陷优先级是指缺陷修复的紧急程度。它分为四类：紧急、严重、一般和轻微。
（1）紧急：除非缺陷得到纠正，否则无法继续测试。
（2）严重：缺陷必须立即解决。
（3）一般：缺陷需要排队修复，或者纳入软件发布列表中。
（4）建议：在方便的时候可以纠正缺陷。
5.9 状态
缺陷状态是指缺陷在跟踪和修复过程中的进展情况，分为五类，包括：新建、打开、重新打开、否决、解决、延迟、关闭。
（1）新：已提交缺陷。
（2）Open：确认“已提交的缺陷”，等待处理。
（3）重新打开：验证后发现未修复的缺陷。
（4）拒绝：拒绝“已提交的缺陷”公司软件管理制度，该缺陷不需要修复或不是缺陷。
（5）解决：缺陷已修复。
（6）延误：缺陷修复被推迟。
（7）关闭：确认需要修复的缺陷并关闭。
5.10 负责人
负责处理和解决缺陷的人员。对于功能性缺陷公司软件管理制度，责任人应为具体开发人员；对于文档性缺陷，责任人应为具体文档的作者。如果缺陷登记者没有明确指明责任人，可以指定项目负责人为责任人，项目负责人将重新指定责任人。
5.11 处理意见
处理意见是缺陷owner对缺陷处理结果的简单描述，如“已更正”、“重复提交”、“没问题”等。
5.12 处理记录（解决方案）
处置记录通常包括解决方案，包括但不限于缺陷原因的简要描述、解决方案、是否会导致其他问题等。
第六章 附录
测试团队中任何人都有权利和义务提出缺陷并负责跟踪关闭，若自己无法跟踪关闭，请委托上级领导跟踪关闭缺陷。
缺陷的严重程度、优先级、状态严格按照此体系执行。
