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