目录
一、软件缺陷(Bug)
1.1 缺陷的判定标准
1.2 缺陷的生命周期
1.3 软件缺陷的描述
1.3.1 提交缺陷的要素
1.3.2 Bug 的级别
1.4 如何发现更多的 Bug?
1.5 缺陷的有效管理
1.5.1 缺陷的编写
1.5.2 缺陷管理工具
1.5.2.1 缺陷管理
1.5.2.2 用例管理
一、软件缺陷(Bug)
1.1 缺陷的判定标准
Bug的概念:当且仅当规格说明是存在的并且正确,当程序没有实现其最终用户合理预期的功能要求就是软件错误。
判断标准以最终用户为准(站在用户的角度看是否实现用户的需求)
案例如下:
-
软件未实现需求规格说明书中明确要求的功能-->少功能
-
软件出现了需求规格说明书中指明不应该出现的错误-->功能错误
-
软件实现的功能超出需求规格说明书指明的范围-->多功能
-
软件未实现需求规格说明书中虽未明确指明但应该实现的要求-->隐性功能错误
-
软件难以理解,不易使用,运行缓慢,用户体验不好-->不易使用
缺陷产生的原因:
需求阶段:需求描述不易理解,有歧义、错误等
设计阶段:设计文档存在错误或者缺陷
编码阶段:代码出现错误
运行阶段:软硬件系统本身故障导致软件缺陷
1.2 缺陷的生命周期
注意事项:
-
delay的 bug 不是说不修复,只是当前版本不修复,但是未来一定要修复。
-
如果出现了delay 和 Rejected 这种Bug,QA质量保证 一定要将这些 Bug 告知给相关人员以及项目相关 Leader
-
发送测试报告的时候也要指出 delay 和 rejected 这种 bug
-
缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。
1.3 软件缺陷的描述
-
缺陷的标题:描述缺陷的核心问题(操作数据描述+预期+实际)
-
发现问题的版本:开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
-
问题出现的环境:环境分为硬件环境和软件环境,详细的环境描述有利于故障的定位。
-
软件环境:
-