缺陷类型（Type）
按照软件缺陷产生的原因，可以对软件缺陷的类型进行划分，常见的属性值如下：
功能问题（Function
是指影响了重要的功能特性、用户界面、产品接口、硬件结构接口和全局数据结构，并且设计文档需要正式的变更，如指针循环、递归等缺陷。主要包括：功能错误、功能缺失、功能超越、设计的二义性、算法错误。
接口问题（Interface）
是指与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。主要包括：模块间接口、模块内接口、公共数据使用。
逻辑问题（Logic）
指修改缺陷需要进行逻辑分析、进行代码修改，如循环条件等。主要包括：分支不正确、重复的逻辑、忽略极端条件、不必要的功能、误解、条件测试错误、循环不正确、错误的变量检查、计算顺序错误、逻辑顺序错误。
计算问题（Computation）
指等式、符号、操作符或操作数错误，精度不够、不适当的数据验证等缺陷。主要包括：等式错误、缺少运算符、错误的操作数、括号用法不正确、精度不够、舍入错误、符号错误等。
数据问题（Assignment）
指需要修改少量代码，如初始化或控制块、声明、重复命名、范围、限定等缺陷。主要包括：初始化错误、存取错误、引用错误变量、数据应用越界、不一致的子程序参数、数据单位不正确、数据维数不正确、变量类型不正确、数据范围不正确、操作符数据错误、变量定位错误、数据覆盖、外部数据错误、输出数据错误、输入数据错误、数据检验错误。
用户界面问题（User Interface）
指人机交互特性，比如屏幕格式、确认用户输入、功能有特性、页面排版等方面的缺陷。主要包括：界面风格不统一、屏幕上的信息不可用、屏幕上的错误信息、界面功能布局和操作不合常规。
文档问题（Documentation）
指影响发布和维护，包括注释等缺陷。主要包括：描述含糊、描述不完善、描述不正确、缺少或多余、不能验证、不能完成、不符合标准、与需求不一致、文字排版错误、文档信息错误、注释缺陷。
性能问题（Performance）
是指不满足系统可测量的属性值，如：响应时间、事务处理速率、点击率等缺陷。
配置问题（Build、Package、Merge）
是指由于配置库、变更管理或版本控制引起的错误。主要包括：配置管理问题、编译打包缺陷、变更缺陷、纠错缺陷。
标准问题（Norms）
是指不符合各种标准的要求，如编码标准、设计符号等缺陷。主要包括：不符合编码标准、不符合软件标准、不符合行业标准、设计、编译环境。
环境问题（Environments）
是指由于设计、编译和运行环境引起的问题。主要包括：设计、编译环境和运行环境。
兼容问题（Compatibility）
是指软件之间不能正确的交互作用和共享信息的缺陷。比如：操作平台不兼容、浏览器不兼容、分辨率不兼容等问题。
其他问题（Others）
除以上 12 种类型的其他缺陷。
缺陷严重等级（Severity）
缺陷的严重等级是指因缺陷引起的故障对使用软件产品的影响程度。缺陷生来就不是平等的，有一些导致系统崩溃或死机的缺陷很明显比软件界面不友好更影响用户的使用。按照 CMM5 中定义的规范，缺陷的严重等级可分为 3~5 个等级，但也有的公司列到 10 个等级，而有的公司只有 3 个等级。这里我以 5 级为例来详细讲述，缺陷的严重等级是缺陷的一个非常重要的属性，故在每个等级中分别举一个例子来帮助读者理解。
1-致命缺陷（Fatal）
致命缺陷是指系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全的缺陷。或者系统所提供的功能或服务受到明显的限制，不能执行正常工作流程或实现重要功能。包括：
- 可能有灾难性的后果，如造成系统崩溃，造成事故的缺陷等；
- 数据库错误，如数据丢失、数据毁坏等；
- 安全性被破坏。
例如，一个导致死机的缺陷描述如下：
问题摘要：通过地址薄填写多个收信人时导致所有程序无法响应。 操作步骤：
- 建立新邮件，单击“收信人”按钮，查找电子邮件地址；
- 双击添加多个联系人地址； 预期结果： 成功通过地址薄添加多个联系人地址。 实际结果： 程序无法响应，同时也无法执行其他应用程序，必须重新启动机器
2-严重缺陷（Critical）
指可能导致系统不稳定，运行时好时坏，严重影响系统要求或基本功能实现的缺陷。比如：
- 造成数据库不稳定的错误；
- 在说明中的需求未在最终系统中实现；
- 程序无法运行，系统意外退出；
- 业务流程不正确等。
例如，一个异常退出的缺陷描述如下：
问题摘要：编辑邮件回复时系统异常退出。 操作步骤： 1.打开收件箱中的任意邮件，选择编辑 à 选中所有文字； 2.点击“回复”。 预期结果： 成功打开邮件编辑页面，并连带回复的内容。 实际结果： 系统异常退出。 备注： 直接点击“新建”按钮，创建新邮件也会出现同样的问题。
3-重要缺陷（Major）
指系统的次要功能没有完全实现，但不影响用户的正常使用，不会影响系统稳定性的缺陷。比如：
- 提示信息不太准确或用户界面差、操作时间长等一些问题；
- 过程调用或其他脚本错误；
- 系统刷新错误；
- 产生错误结果，如计算错误，数据不一致等；
- 功能的实现有问题，如在系统实现的界面上，一些可接受输入的控件带你点击后无作用，对数据库的操作不能正确实现；
- 编码时数据类型、长度定义错误；
- 虽然正确性、功能不受影响，但是系统性能和响应时间受影响。
例如，一个数据处理错误、但对系统的影响不大的缺陷描述如下：
问题摘要：查询发件箱中邮件数量统计结果不正确 操作步骤：
- 进入蓝桥企业邮箱 à 发件箱；
- 设置查询条件，点击查询按钮。 预期结果： 查询后的统计结果正确显示。 实际结果： 查询后的统计结果比实际结果少一条记录。
（4）4-一般缺陷（Minor）
是指使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题，重点指系统的 UI 问题，比如：
- 系统的提示语不明确，不简单明了；
- 滚动条无效；
- 可编辑区域和不可编辑区域不明显；
- 光标跳转设置不好，鼠标（光标）定位错误；
- 上下翻页，首尾页定位错误；
- 界面不一致，或界面不正确；
- 日期或时间初始值错误（起止日期、时间没有限定）；
- 出现错别字，标点符号错误，拼写错误，以及不正确的大小写等。
例如，一个界面显示的缺陷描述如下：
问题摘要：删除附件后界面显示不正确 操作步骤：
- 进入“案件办理 à 代办案件”，选择一条案件，点击“办理”进入案件信息页面；
- 点击“删除附件”删除案件原有的附件。 预期结果： 成功删除所选附件。 实际结果： 删除最后一个附件后，页面仍旧显示附件的说明信息，重新刷新后页面显示正确。
（5）5-改进意见（Enhancement）
是系统中值得改良的问题。比如容易给用户错误和歧义的提示；界面需要改进的；某个控件没有对齐等；测试人员可以对有疑虑的部分，提出修改建议。
例如，一个测试人员的建议描述如下：
问题摘要：建议可以增加已删除的用户 操作步骤：
- 使用系统管理员账号登录系统，进入权限管理 à 基本信息维护 à 用户信息维护；
- 执行增加功能，添加用户“test123”，保存；
- 执行删除操作，删除用户“test123”；
- 再次增加用户“test123”。 预期结果： 建议系统再次成功添加该用户。 实际结果： 系统提示“创建失败！数据库错误，请和管理员联系”，建议系统可以增加已删除的用户。
缺陷处理优先级(Priority)
在实际项目中，测试时间总是不足的，这是一种常态。那么除了在执行测试用例时选取优先级别比较高的先执行之外，修改软件缺陷也需要有所取舍，测试人员需要决定哪些缺陷需要优先解决，哪些缺陷可以在以后的版本中解决。
缺陷处理优先级表示开发人员修复缺陷的重要程度和紧迫程度，不同的项目可以划分成不同的级别，比如分成 2 级~~5 级。这里我以划分为 4 个等级为例，讲述不同优先级的定义描述，如下表所示。
| 缺陷处理优先级 | 描述 |
|---|---|
| 1-立即解决（Resolve Immediately） | 导致系统几乎不能使用或测试不能继续，需要立即修复的缺陷。 |
| 2-高优先级（High Priority） | 比较严重，影响测试，需要优先考虑的缺陷。 |
| 3-正常排队（Normal Queue） | 需要正常排队等待修复的缺陷。 |
| 4-低优先级（Low Priority） | 可以在开发人员有空余时间的时候被修正的缺陷。 |
一般地，严重程度级别高的软件缺陷具有较高的处理优先级，但这并不是绝对的。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理；而一些严重程度低的缺陷却需要及时处理，反而具有更高的处理优先级。比如：
- 只要一启动，程序就崩溃这样的缺陷其严重级别是 1 级-致命缺陷，优先级别也是 1 级-立即解决；
- 某按钮位置摆放不合理，其严重级别是 4 级-一般缺陷，优先级别也是 4 级-低优先级；
- 极少发生的数据毁坏缺陷严重级别为 1 级-致命缺陷，但优先级应该是 3 级-正常排队；
- 而导致用户求助的安装说明中的错别字这样的缺陷，严重级别是 4 级-一般缺陷，但优先级应该是 2 级-高优先级；
- 再比如如果公司的名字和 logo 被误用了，这样的缺陷严重级别应该是 4 级-一般缺陷，但处理优先级应该是 2 级-高优先级。
通常，功能性缺陷一般较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般比较低，优先级也较低。但这也不是绝对的。
比如在一款财务系统软件中，影响数字准确度的功能逻辑缺陷比较严重，具有较高的优先级；软件界面类缺陷优先级则比较低。但在一款游戏软件中，影响界面美观和执行速度的缺陷，则拥有较高的处理优先级。
当然，软件缺陷的优先级在项目期间也不是一成不变的，有时候也会发生变化。原来标记为高优先级的缺陷随着项目时间的流逝，可能变为优先级 4。但不管如何变动，作为发现该缺陷的测试人员，都需要继续监视缺陷的状态，确保自己能够同意对其所做的变动，并进一步提供测试数据，或者想办法说服开发人员去修复缺陷。
缺陷来源
缺陷的来源也是缺陷的属性之一，常见的有以下几种来源，如下表所示：
| 序号 | 缺陷来源 | 说明 |
|---|---|---|
| 1 | 需求 Requirement | 由于需求的问题引起的缺陷 |
| 2 | 架构 Architecture | 由于架构的问题引起的缺陷 |
| 3 | 设计 Design | 由于设计的问题引起的缺陷 |
| 4 | 编码 Code | 由于编码的问题引起的缺陷 |
| 5 | 测试 Test | 由于测试的问题引起的缺陷 |
| 6 | 集成 Integration | 由于集成的问题引起的缺陷 |
