-
1 电子教材
-
2 PPT
开发人员需要去修复排除软件缺陷，但不是每个软件缺陷都需要开发人员紧急修复呢？这需要定义软件缺陷属性，以提供给开发人员作为参考，按照优先等级、严重程度去修复软件缺陷，不至于遗漏严重的软件缺陷。对于测试人员，利用软件缺陷属性可以跟踪软件缺陷，保证产品的质量。下面列出软件缺陷属性。
软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷来源、产生缺陷的原因等内容。
缺陷标识是标记一个缺陷的唯一标识，可以用数字序号或数字与字母组合来表示。
软件缺陷表现的形式有多种，不仅仅体现在功能的失效方面，还体现在其他方面。缺陷类型是根据缺陷的自然属性划分缺陷种类的，如表3-1所示。
表3-1 软件缺陷类型列表
| 缺陷类型 | 描述 |
| 功能 | 影响了各种系统功能、逻辑的缺陷 |
| 用户界面 | 影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等 |
| 文档 | 影响发布和维护、包括注释、用户文档、设计文档 |
| 软件包 | 由于软件配置库、变更管理或版本控制引起的错误 |
| 性能 | 不满足系统可测量的属性值，如执行时间、事务处理速率等 |
| 系统/模块接口 | 与其他组件、模块或设备驱动程序、调用参数、控制块或参数类表等不匹配、冲突 |
软件缺陷一旦被发现，无论哪种类型的都要设法找出引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”指的是在测试条件下，一个错误在系统中的绝对影响，如表3-2所示。
表3-2软件缺陷严重等级列表
缺陷在产品中发生的可能性，通常可以使用频率来表示，如表3-3所示。
表3-3 软件缺陷产生可能性列表
| 缺陷产生可能性 | 描述 |
| 总是(Always) | 总是产生这个软件缺陷，其产生的频率是100% |
| 通常(Often) | 按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%-90% |
| 有时(Occasionally) | 按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30-50% |
| 很少(Rarely) | 按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%-5% |
缺陷优先级指缺陷必须被修复的紧急程序。“优先级”的衡量抓住了严重性中没有考虑的重要程度因素，如表3-4所示。
表3-4 软件缺陷优先级列表
| 缺陷优先级 | 描述 |
| 立即解决（P1级） | 缺陷导致系统几乎不能使用或测试不能继续，须立即修复 |
| 高优先级（P2级） | 缺陷严重，影响测试，需要优先考虑 |
| 正常排队（P3级） | 缺陷需要正常排队等待修复 |
| 低优先级（P4级） | 缺陷可以在开发人员有时间的时候进行修复 |
一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。
缺陷状态指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如表3-5所示。
表3-5 缺陷修复状态列表
| 缺陷状态 | 处理人 | 说明 |
| 新建 | 测试 | 测试人员已提交，但还未做任何处理 |
| 打开 | 测试 | 测试人员已提交，经过组长确认问题存在 |
| 待验证 | 开发 | 开发人员已经在测试环境中修改，但是测试人员还没有进行验证 |
| 待确认 | 开发\客户 | 需要客户人员参与确认此问题是否需要修改等客户确认问题，并在备注里面说明原因 |
| 重新打开 | 测试 | 问题验证未通过 |
| 关闭 | 测试 | 问题验证通过 |
| 紧急版本 | 测试\开发\客户 | 根据问题级别或者相关人员共同商议决定问题不能遗留，必须马上处理并发布版本 |
| 遗留 | 测试\开发\客户 | 根据问题级别或者相关人员共同商议决定问题可以遗留 |
| 其他 | 测试\开发\客户 | 详细原因在备注里面说明 |
缺陷来源指缺陷所在的地方，如文档、代码等，如表3-6所示。
表3-6 软件缺陷来源列表
| 缺陷来源 | 描述 |
| 需求说明书 | 需求说明书的错误或不清楚引起的问题 |
| 设计文档 | 设计文档描述不准确，和需求说明书不一致的问题 |
| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 |
| 数据流（库） | 由于数据字典、数据库中的错误引起的缺陷 |
| 程序代码 | 纯粹在编码中的问题所引起的缺陷 |
缺陷的根源是指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表3-7所示。
表3-7 软件缺陷根源列表
| 缺陷根源 | 描述 |
| 测试策略 | 测试的测试范围，误解测试目标、超越测试能力等 |
| 过程、工具和方法 | 无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算过程，无效的变更控制过程等 |
| 团队/人 | 项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气等 |
| 缺乏组织和沟通 | 缺乏用户参与、职责不明确，管理失败等 |
| 硬件 | 硬件配置不正确、缺乏或处理器导致缺陷算术精度丢失，内存溢出等 |
| 软件 | 软件设置不正确、缺乏或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等 |
| 工作环境 | 组织机构调整，预算改变，工作环境恶劣，如噪声过大 |
