目录
一、软件缺陷
1.1 缺陷定义
软件或者程序中存在的各种问题。
1.2 缺陷判定标准
- 软件没有达到需求说明书标明的功能。
- 软件出现了需求说明书指明不会出现错误的地方。
- 软件超出了需求说明书指明的范围。
- 软件出现了需求说明书虽未指明,但应该达到的目标。
- 软件难以使用,效率低下。
1.3 软件缺陷产生的原因
- 需求解释、记录或者定义错误。
- 设计文档说明存在错误或者拼写错误。
- 编码说明、程序代码有误。
- 硬件或者软件系统上存在错误。
1.4 软件缺陷产生的根源
- 需求变更
- 交流不充分
- 软件的复杂性
- 进度压力
1.5 软件缺陷信息
编号 | 属性名 | 描述 |
---|---|---|
1 | 缺陷ID | 唯一的缺陷ID,可根据该ID追踪缺陷。 |
2 | 缺陷状态 | 缺陷状态指缺陷通过跟踪修复的进展情况。 |
3 | 缺陷标题 | 描述缺陷标题 |
4 | 缺陷严重程度 | 对软件产品的影响程度,分致命、较严重、严重、一般、低 |
5 | 缺陷优先级 | 缺陷修复的先后顺序 |
6 | 缺陷所属模块 | 缺陷所属的项目和模块,要较能精准的定位至模块 |
7 | 缺陷记录者 | 提交缺陷的人员 |
8 | 缺陷提交时间 | 缺陷提交的时间 |
9 | 缺陷处理人 | 处理缺陷的处理人 |
10 | 处理结果描述 | 对处理结果的描述,描述处理情况和代码修改情况 |
11 | 缺陷处理时间 | 缺陷处理的时间 |
12 | 缺陷验证人 | 对被处理缺陷验证的验证人(回测者) |
13 | 验证结果描述 | 对验证结果的描述(通过、不通过) |
14 | 缺陷详细描述 | 缺陷的重现步骤 |
15 | 缺陷环境说明 | 对测试环境的描述 |
16 | 必要附件 | 如涉及到附件的火错误现象的图片等 |
1.5.1 缺陷状态
缺陷状态表 缺陷状态 描述 New(待提交) 缺陷刚被发现并报告,但还没有被分配或处理。 Open(待确认) 缺陷已被提交,并等待处理。 Fixed(已修复) 缺陷已被开发人员修复。 Cloesed(已关闭) 缺陷修复已完成,并确认不再需要进一步的处理。 Reopen(重新打开) 在经过验证后,缺陷再次出现或相关问题未解决,导致需要重新处理。 Postpone(延期处理) 缺陷修复的处理被延期,通常是由于优先级较低或其他原因导致。 Reject(被拒绝) 缺陷被测试团队或相关负责人员拒绝处理,通常是由于误报或不符合缺陷定义的情况。 Duplicate(重复缺陷) 已存在相同或类似的缺陷报告。 Abandon(放弃处理) 缺陷被认为无法或不必修复。
1.5.2 缺陷严重程度
缺陷严重程度表 严重等级 描述 致命错误(Critical) 缺陷导致的系统崩溃、数据丢失或不可用,以及严重的安全漏洞。 严重错误(High) 系统主要功能部分缺失,数据不能保存,系统所提供的功能或者服务受到明显影响。 一般错误(Medium) 系统次要功能没有完全实现,但不影响用户正常使用。(仅仅影响一个相对独立的功能,或者特定条件上发生) 较小(Low) 操作不方便或遇到麻烦,但不影响系统功能操作和执行(例如:错别字,文字排列不整齐等一系列小问题)
1.5.3 缺陷优先级
缺陷优先级表 优先级别 描述 立即解决(Urgent) 缺陷导致系统用不能使用或者测试不能继续,需立即修复。 高优先级(High) 缺陷严重,影响测试,需优先考虑。 正常排队(Medium) 缺陷正常排队等待修复。 低优先级(Low) 缺陷可以在有时间的时候被纠正。
1.6 缺陷报告模板
ID | 功能模块 | 严重程度 | 优先等级 | BUG类型 | 测试环境 | 状态 | 缺陷描述 | 预置条件 | 重现步骤 | 期望结果 | 实际结果 | 附件图片/日志 | 测试人员 | 开发人员 | 解决方案 | 创建日期 | 解决日期 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
QQLog_01 | 登录 | 致命 | 立即 | 功能错误 | win10 | new | QQ账号登录提示账号不存在 | QQ账号正确 | 1.打开QQ 2.输入账号密码 3.点击登录按钮 | QQ账号登录成功,进入QQ主界面 | 提示“账号不存在” | ||||||
... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
注意:不同公司对于缺陷的严重程度和优先级有不同的代码表示,例如:S1(致命缺陷),P0(立即修复)等。
1.7 缺陷报告注意事项
- 缺陷报告不能有缺陷
- 表达和描述简洁、准确
- 一个缺陷一个报告
- 缺陷一定是可重现的
- 避免出现模糊的词汇
- 不能有个人感情色彩
- 出现bug过程一定要详细
1.8 缺陷跟踪流程
- 新提交的缺陷为新建状态(New),确认有效后为待确认状态(Open),经过开发人员修改后,缺陷变为已修复(Fixed)状态,此时就需要测试人员对缺陷进行回归测试,验证问题是否修复。
- 如果问题已经修复,则测试人员将该缺陷的状态置为关闭状态(Closed),同时添加回测说明如“该缺陷已解决”。
- 如果已经关闭的问题再次出现,则测试人员将该缺陷状态修改为重新打开。
1.9 缺陷数据分析关注的问题
- 哪个模块问题最多
- 哪个测试工程师测试的缺陷最多
- 各个缺陷数量占比
- 开发是否可以及时修复缺陷
- 开发人员一次修复缺陷的占比
- 软件是否能正常发布