软件测试的生命周期
需求分析——测试计划——测试设计——测试开发——测试执行——测试评估
如何描述一个Bug
一个合格的bug描述应该包括以下几个部分:
一.发现问题的版本
开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障,并且版本的标识也有利于统计和分析每个版本的质量
二.问题出现的环境
环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需要描述机型,分辨率,操作系统版本等。详细的环境描述有利于故障的定位
三.错误重现的步骤
描述问题重现的最短步骤
四.预期行为的描述
需要让开发人员知道怎样的行为是正确的,尤其要以用户的角度来描述程序的行为是怎么样的。
五.错误行为的描述
描述错误的现象,如UI问题可以截图展示
六.不要将多个bug放在一起
在无法确认是同一段代码造成的故障时,不要将bug放在一起提交
如何定义Bug的级别
bug的定义每个公司标准不一样,在定义级别之前需要查看公司规范
举个例子:
1.Blocker(崩溃)
2.Critical(严重)
3.Major(一般)
4.Minor(次要)
Bug的生命周期
每个公司对bug生命周期的定义都是不一致的,大致为
新建-提交-分配-确认-修复-检验-关闭
测试人员应该跟踪一个Bug的整个生命周期,从Open到Closed
例子: Bug状态转换图:
1.New 新发现的Bug,未经评审决定是否指派给开发人员进行修改
2.Open 确认是Bug,并且认为需要进行修改,指派给相关的开发人员
3.Fixed:开发人员进行修改后标识成修改状态,有待测试人员进行回归测试验证
4.Rejected: 如果认为不是Bug,则拒绝修改
5.Delay: 如果认为暂时不需要进行修改或者暂时不能修改,则延后修改
6.Closed:修改状态的Bug经过测试人员的回归测试验证通过,则关闭Bug
7.Reopen:如果验证Bug仍然存在,则需要重新打开Bug,开发人员重新进行修改