软件缺陷定义
指存在与软件（程序、数据、文档）中的那些不符合用户需求的问题。
- 软件未达到需求规格说明书表明的功能。
- 软件出现了需求规格说明书指明不会出现的错误。
- 软件的功能超出了需求规格说明书指明的范围。
- 软件未达到需求规格说明书虽未指明而应该达到的目标。
- 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户认为不好。
软件缺陷的表现形式
- 功能、特性没有实现或部分实现。
- 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
- 产品实际结果和所期望的结果不一致。
- 没有达到需求规格说明书所规定的性能指标等。
- 运行出错，包括运行中断，系统崩溃，界面混乱等。
- 数据不正确、精度不够、不完整或格式不统一。
- 用户不能接受的其他问题，如存取时间过长、界面不美观。
- 硬件或系统软件存在的其他问题。
软件缺陷分类——缺陷状态
| 缺陷状态 | 描述 |
|---|---|
| 提交Submited | 已提交的缺陷 |
| 打开Open | 确认“提交的缺陷”，等待处理 |
| 拒接Rejected | 拒绝“提交的缺陷”，不需要修复或不是缺陷、重复缺陷、无法重视 |
| 修复Resolved | 缺陷被修复 |
| 关闭Closed | 确认修复的缺陷，将其关闭 |
| 推迟Later | 可以在以后解决，但是确定修复日期或版本 |
软件缺陷的严重程度
| 严重等级 | 描述 |
|---|---|
| 5-Critical | 系统瘫痪、异常退出、死循环、严重的计算错误等 |
| 4-VeryHigh | 频繁死机、系统大部分功能不可用 |
| 3-High | a.功能点没有实现，或不符合用户需求 。 b.数据丢失 |
| 2-Medium | a.影响一个相对独立的功能。 b.仅仅在特定条件上发生。c.与产品需求定义不一致。 d.断断续续的出现问题 |
| 1-Low | 表面性错误（如错别字） |
软件缺陷的测试优先级
| 优先级别 | 描述 |
|---|---|
| 5-Urgent | 最高优先级，在这个错误影响下，系统几乎不可用。 |
| 4-VeryHigh | 高级优先级，错误对这套系统的能力产生严重影响。 |
| 3-High | 中优先级，如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它。 |
| 2-Medium | 低优先级，不会延迟发布但是会在以后修正这个错误。 |
| 1-Low | 最低优先级，时间和资源允许时修正。 |
软件缺陷的分类
| 缺陷类型 | 内容说明 |
|---|---|
| 系统缺陷 | 1.由于程序多引起的死机，异常退出。2.程序死循环。3.程序错误，不能执行正常工作或重要功能，使系统崩溃或资源不足。 |
| 数据缺陷 | 1.数据计算错误。2.数据约束错误。3.数据输入，输出错误。 |
| 数据库缺陷 | 1.数据库发生死锁。2.数据库的表、缺省值未加约束条件。3.数据库连接错误。4.数据库中的表有过多的空字段。 |
| 接口缺陷 | 1.数据通信错误。2.程序接口错误。 |
| 功能缺陷 | 1.功能无法实现。2.功能实现错误。 |
| 安全性缺陷 | 1.用户权限无法实现。2.超时限制错误(如长时间登录未使用一个网页，应该有超时限，超时后退出登录)。3.访问控制错误。4.加密错误。 |
| 兼容性缺陷 | 与需求规定配置兼容性不符合。 |
| 性能缺陷 | 1。未达到预期的性能目标。2.性能测试中出错，导致无法继续进行测试。 |
| 界面缺陷 | 1.操作界面错误。2.打印内容、格式错误。 3.删除操作未给出提示。 4.长时间操作未给出提示。5.界面不规范。 |
| 建议 | 1.功能建议。2.性能建议。（建议比照之前测试过的软件可以提出的建议） |
缺陷报告注意事项
- 尽量确保缺陷可以重现。(重现目的是确保不是因为自己的环境等因素在特定的环境下才会出现bug)
- 简洁、准确、完整。
- 一个缺陷一个报告（一个缺陷报告提交多个缺陷不便于将缺陷分配给开发人员，不便于验证）
缺陷书写规范
- 标题简洁、提供缺陷的本质信息即可。
- 复现(实际操作步骤)的步骤要详细，用数字编号。
- 实际结果要描述清楚复现后的结果。
- 列出期望结果。
- 提供附件(对缺陷的补充说明，可以是缺陷的症状的截图，测试使用的数据文件 )。
- 提供严重性属性以及公司需要填写的属性。
注意：要避免一些常见错误
（1）避免使用情绪化语言和强调标点符号(eg,!!!)
（2）避免使用模糊的词语。
（3）避免使用自认为幽默的语言，直接描述问题即可。
（4）避免提交不确定的缺陷。
缺陷处理流程
缺陷的跟踪
新提交的缺陷为 “新建” 状态，在确认有效后变为 ”打开“ 状态，开发人员修改之变为 ”已修复“ 状态，此时测试人员需要进行回归测试，如果验证问题已解决，状态为 ”已解决“ ，如果问题依然存在，状态为 ”打开“ ；如果开发人员任务此缺陷可以延期修改，状态为‘’延期“；注意此时必须由项目相关人员讨论确定后，才可以延期处理，否则状态继续为 ”打开“ 。
缺陷密度
每千行代码的缺陷数
缺陷密度 = 1000 * 缺陷个数 / 代码行数
版权声明：本文为weixin_44953554原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。