缺陷分类

定义

描述

功能缺陷

功能缺陷是指影响软件要求或基本功能实现的缺陷。满足以下一种或多种情况：

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）不同运行环境产生的错误

阶段流程

描述

新提交

缺陷提交阶段需要提交详情，测试人员必须保证等级的缺陷信息可以被处置负责人员理解，缺陷报告必须详细描述缺陷内容。

定位

缺陷分析定位阶段需要根据缺陷报告的内容对缺陷进行分析和定位。缺陷分析和定位是相关人员根据缺陷报告中对缺陷的详细描述查找重现缺陷，确定缺陷产生的原因，明确缺陷所处的位置，以便修改缺陷。

解决

缺陷修复阶段需要对已经定位的缺陷进行修改。缺陷修复是开发人员对已经分析定位的缺陷进行修改并更改缺陷状态，修改后的软件需要实现预期的结果（缺陷记录中的预期结果）。

否决

如果开发人员发现该缺陷不可再现、重复、不是问题等情况，可以把缺陷状态设置成“已拒绝”。

挂起/延迟

如果按照开发计划、缺陷发生的功能不属于当前开发阶段必须完成的，可将缺陷状态设置为“挂起”，并在实际版本中添加具体版本或截止时间。

回归验证

回归验证阶段需要对已经修改的缺陷进行验证和回归测试。

缺陷回归验证是测试人员对已经修改的缺陷进行回归测试，根据缺陷记录中的操作步骤对缺陷重新进行测试，并对缺陷修改过程中可能影响到的组件、模块或功能进行重新测试，验证修改后的缺陷可以实现预期结果并对其他组件、模块或功能无影响。

同时，根据验证结果修改相应的缺陷状态为“内测完成”，通知相关人员拟定发布时间。

重新打开

验证测试不通过的缺陷，应当重新打开，状态更变为“重新打开”。

关闭了的缺陷再次出现时（通常因为解决缺陷的方法导致相同位置出现不同形式的缺陷时），测试人员需要重新打开缺陷，开发人员需要继续进行解决。公司各负责人应当关注“重新打开的缺陷”。

关闭

测试人员确认缺陷已经解决并发布生产后，关闭缺陷更改其状态为“已发布”，生产缺陷保留三个版本后进行归档。

对于否决的缺陷，测试人员需要和同行各负责人进行讨论，意见达到一致后可以关闭，如不同意的需要“重新打开”。

等级

定义

描述

致命

缺陷发生后，产品的主要功能会失效，业务会陷入瘫痪状态，关键数据损坏或丢失，且故障无法自行恢复。如下举例

1）产品主要功能失效或和用户期望不符，用户无法正常使用；

2）程序引起的死机、反复重启等、且故障无法自动恢复；

3）死循环、死锁、内存泄漏、内存重释放等；

4）系统存在严重的安全漏洞；

5）会引发用户关键数据损坏或丢失不可恢复；

严重

缺陷发生后，主要功能无法使用、失效，存在可靠性、安全性能等方面的重要问题，但是出现后一般可以自行恢复。如下举例：

1）产品重要功能不稳定；

2）有程序引起的非法退出、重启等，但是故障可以自行恢复；

3）产品难以理解和操作；

4）产品无法进行正常维护；

5）产品升级后功能出现丢失，性能下降等；

6）性能达不到系统规格；

7）产品不符合标准规范，存在严重的兼容性问题；

一般

缺陷发生后，系统存在功能、性能、可靠性、易用性、可维护性、可安装性等方面出现一般性问题。如下举例：

1）产品一般性的功能失效或不稳定；

2）产品未进行输入限制（未对正确值和错误值进行界定）；

3）一般性规范和兼容问题；

4）系统报表、日志、统计信息在显示出现错误；

5）系统调试信息难以理解或存在错误；

6）存在错别字，语句不通；

建议

缺陷发生后，对用户只会造成轻微影响，这些影响一般在用户可忍受的范围内。如下举例：

1）产品的输出正确，但不够规范；

2）提示信息不够清晰准确，难以理解；

3）需要较长时间的操作未给用户提供提示；

等级

定义

举例

最高

该缺陷导致系统几乎不能使用或测试不能继续，非常紧急，需立即或在8小时内修复。

如：主要业务无法绕过无法使用、应用程序包版本不对、无法安装导致无法测试、闪退、崩溃等；

较高

缺陷严重影响测试或产品目的，需优先考虑。

如：产品的商标未展示、版权未更正、技术性的内容不正确、主要业务实现的具体内容存在偏差等；

普通

对产品来说不是那么关键的场景或特性，正常排队即可。

如：在小标题上发现的错误、从历史版本中来的遗留bug等（非主要功能）

较低

对产品使用没有太大影响，如能修复这个缺陷会很好。

如：在低使用频率页面中发现的bug、很少被使用的功能等；

最低

对产品的影响非常小，可在开发人员有时间的时候再修复。

如：文字重叠、错别字等UI方面的缺陷，不易操作、建议性等；

状态

定义

新提交

已提交/首次提交的缺陷，等待处理；

未通过

验证后发现未修复的缺陷、修复后引发同位置不同类型的缺陷（新缺陷要进行提交，旧缺陷要进行打开）；

处理中

研发人员已确认缺陷，并按照约定进行处理；

已修复

缺陷被修复并告知测试工程师进行回归验证；

内测完成

确认被修复的缺陷并进行验证完毕；

已发布

确认验证完毕的缺陷已发布生产环境；

挂起

因研发版本冲突或操作不当、无法复现等原因导致缺陷暂缓修复或非缺陷问题转需求处理（需求建立后进行沟通并在版本结束时关闭此缺陷）

重新打开

版本发布后，还依然存在的缺陷，等待开发人员进一步修复；

已拒绝

程序按照既定设计正常运行，非缺陷原因引起；

解决方案项

定义

“按设计实现”

如缺陷既定功能不进行改变；

“已修复”

如缺陷无法按照原既定功能实现需要变动功能/逻辑/接口，或需处理数据；

“转需求”

缺陷的产生非系统实现问题，运行情况正常，需产品、设计人员参与；

“重复提交”

如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题一致；

“暂不修复”

部分不紧急的缺陷问题，可能会随着日后的产品迭代中进行修复。

“不是问题”

如果开发团队认为提交上来的缺陷并不是真正的缺陷，比如由于缓存，网络导致的部分文件加载失败导致的问题等，应将缺陷状态标记为“拒绝”并指派回测试团队。测试团队需要重新测试或者提供更多的缺陷信息；

“无法重现”

缺陷无法重现、无法追溯，但内外部有提出，将偶现类缺陷挂起三个版本进行观察（阶段状态应挂起进行，直到复现时激活，逾期后归档）；

此内容实施后扣除分值按此公式执行：

【扣除分值=（出现次数-1）* 2 * 基础分值】

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

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

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

建议缺陷：不做要求

一级错误（致命）

二级错误（严重）

三级错误（一般）

四级错误（建议）

无

无

<=3%

暂不做要求

1、特征性问题：功能缺陷、数据校验缺陷、查询统计缺陷 2、非特征问题：性能缺陷、安全性问题、设计缺陷、兼容性缺陷、配置缺陷、界面交互缺陷

结合第四章9类缺陷