软件测试基础(描述Bug，Bug的生命周期)

软件测试的生命周期

需求分析——测试计划——测试设计——测试开发——测试执行——测试评估

 
 

如何描述一个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，开发人员重新进行修改