软件缺陷
定义
软件在使用的过程中存在的任何问题(错误,异常等),都叫做软件缺陷,简称BUG
软件缺陷的判定标准
- 软件未实现需求说明书中明确要求的功能
- 软件出现了需求说明书中指明的不应该出现的错位
- 软件实现了超出需求说明书中的功能
- 软件未实现需求文档中未指明但是又应该实现的功能
- 用户体验不好,界面不漂亮,易用等
软件缺陷出现的原因
编码
代码出错
运行系统
软硬件系统本身故障导致的软件缺陷
设计问题
设计文档出现错误或者缺陷
需求阶段
需求描述有歧义
软件本身很复杂
软件缺陷的核心内容(重点)
标题 描述软件缺陷的基本信息,例如(用户名5位,只展示3位)
前置条件 描述缺陷出现依赖的相关基础条件
复现步骤 测试用例里的执行步骤
实际结果 执行测试用例的执行步骤,系统给出的结果
预期结果 参照需求说明书,在测试用例中设计的预期结果
附件 BUG截图或者出错的日志信息,方便定位BUG的
缺陷的基本要素(重点)
- ID 唯一
- 模块:根据产品进行具体的划分、支付模块,订单模块等
- 缺陷状态
new | 新建 |
open | 打开 |
postpone | 延期 |
Reject | 拒绝 |
fix | 已经修复 |
close | 关闭 |
reopen | 重新打开 |
- 缺陷的严重程度
从技术上衡量BUG的破坏力
致命 | 5 | critical |
非常高 | 4 | major |
高 | 3 | medium |
中 | 2 | minor |
低 | 1 | tiny |
- 缺陷的优先级
处理缺陷的优先程度
紧急 | 5 |
非常高 | 4 |
高 | 3 |
中 | 2 |
低 | 1 |
- 缺陷类别
功能错误
UI界面错误
兼容性错误
易用性
改进意见
- 提交缺陷的注意事项
- 唯一性,一个缺陷只需要提交一次
- 保证可复现性
- 规范性
描述需要准确,有细节真实
- 缺陷跟踪流程
场景1
测试new——开发open——开发fix——测试close
场景2
测试new——开发open——开发fix——测试reopen
场景3
测试new——开发open——开发postpone
场景4
测试new——开发open——开发reject