目录
1. 软件测试的生命周期
2. 描述 BUG
2.1 为什么要进行描述
2.2 如何描述一个 BUG
练习描述 BUG:邮箱登录不上去
练习描述 BUG:ie下界面显示异常,界面文字有重叠
3. BUG 的级别
4. BUG 的生命周期
1. 软件测试的生命周期
软件的生命周期:
需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护
软件测试的生命周期:
需求分析 -> 测试计划 -> 测试设计、测试开发 -> 测试执行 -> 测试评估
那么,每个阶段具体是做什么呢?
需求分析 | 测试人员了解需求、对需求进行分解,得出测试需求 |
测试计划 | 根据需求编写测试计划/测试方案 |
测试设计 | 设计测试用例 |
测试开发 | 开发测试工具/开发自动化测试用例 |
测试执行 | 提交 BUG、验收 |
测试评估 | 产出测试报告 |
也就是说,在测试的过程最后,是需要产出测试报告的。那么测试报告具体包括哪些内容呢?通过查找资料可知,一般的测试报告主要包括以下内容:
测试报告 | |
---|---|
项目名称 | |
项目 ID | |
测试人员 | |
开发人员 | |
产品人员 | |
测试时间 | |
开发时间 | |
BUG 数量(解决的/未解决的) | |
项目上线风险 | |
测试用例 | |
文档(软件规格说明书 & 技术文档) |
2. 描述 BUG
2.1 为什么要进行描述
测试人员需要向开发人员描述 BUG,从而修复 BUG。那么为什么要描述 BUG 呢?
2.2 如何描述一个 BUG
在描述 BUG 时,需要包括以下几点:
- 发现问题的版本
- 问题出现的环境
- 错误重现的步骤(描述问题出现的最短步骤)
- 预期行为的描述
- 错误行为的描述
- 其他(功能障碍、界面故障、兼容性故障等)
- 不要将多个 BUG 放在一起(在无法确认是同一段代码造成的 BUG 时)
练习描述 BUG:邮箱登录不上去
版本 | V 1.0 |
环境 | Windows 11 HONOR PC chrome 浏览器版本111.0 |
操作步骤 | 打开 https://mail.163.com/ 输入账号密码 |
数据 | 账号:**** 密码:*** |
错误行为描述 | 登录失败(截图/录屏) |
预期结果 | 登录成功 |
... | ... |
练习描述 BUG:ie下界面显示异常,界面文字有重叠
故障发现版本 |
VPS20180226_01
|
故障类别 | 兼容性 |
故障优先级 | 中 |
故障标题 |
ie
下界面显示异常,界面文字有重叠
|
测试环境 |
win7+IE8
|
测试步骤 |
打开
vps
首页,点击
“
通知
”
链接,进入通知页面
|
预期结果 |
通知页面显示正确,一页显示
10
条通知,按时间顺序倒序排列
|
实际结果
|
页面显示
10
条通知,通知顺序正确,但是页面文字有重叠
|
附件
|
上传截图
|
3. BUG 的级别
BUG 的级别在不同公司可能是不同的定义。一般来说,BUG 分为以下级别:
- Blocker(崩溃) 系统崩溃、死机、死循环,导致数据库数据丢失等。
- Critical(严重) 系统主要功能部分丧失。
- Major(一般) 功能没有完全实现,但是不影响使用。如操作时间长等。
- Minor(次要) 界面、性能缺陷,建议类问题,不影响操作功能的执行。如错别字等。
需要注意的是,当出现 Blocker 级别的 BUG 时,需要记录 BUG,告知项目相关人员,然后停止测试。
4. BUG 的生命周期
测试人员应该跟踪一个 Bug 的整个生命周期,从 Open 到 Closed 的所有状态。
每个公司、每一个工具对
bug
生命周期的定义都是不一致的。一般来说,BUG 的生命周期如下表所示:
BUG 的生命周期 | |
---|---|
new | 新发现的 BUG,未经评审决定是否指派给开发人员进行修改 |
open |
确认是 BUG,并且认为需要进行修改,指派给相应的开发人员
|
fixed |
开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证
|
closed |
修改状态的
BUG
经测试人员的回归测试验证通过,则关闭
BUG
|
reopen |
如果经验证 BUG
仍然存在,则需要重新打开 BUG
,开发人员重新修改
|
rejected |
如果认为不是 BUG,则拒绝修改
|
delay |
如果认为暂时不需要修改或暂时不能修改,则延后修改(在未来的某一天一定要修复)
|
无效的bug:
- open->closed
- open-rejected-closed
注意:当 BUG 处于 rejected 状态 和 delay 状态时,需要周知相关的人员。
Bug
的跟踪以及状态变更应该遵循一些基本原则:
-
测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行 回归测试 ,确保相同的问题不再出现,才能关闭缺陷。
-
对于拒绝修改和延迟修改的 Bug ,需要经过包含测试人员代表和开发人员代表、用户方面的代表 (或代表用户角度的人)的评审。