软件测试和bug的生命周期以及bug的状态与描述

1. 概述

本文主要讲述了软件测试的生命周期、bug的描述方法及状态，以及bug之间的状态转换。具体描述如下，首先是软件测试的生命周期。

2. 软件测试的生命周期

软件测试的生命周期可以总的划分为以下几个阶段：

1. 需求分析
   测试人员需要了解需求，对需求进行分解，得出测试需求。
2. 测试计划
   根据要求编写测试计划书或方案
3. 测试设计
   测试人员适当的了解设计，搭建测试用例框架
4. 测试执行
   执行测试用例，找软件中存在的缺陷。
5. 测试评估
   根据测试的结果，编写最终的测试报告以对软件的质量形成文字性说明与衡量。

3. bug的描述

bug的描述通常应该包含以下几个方面的内容，分别为：

1. 发现问题的版本
   开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2. 问题出现的环境
   环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等。如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3. 错误重现步骤
   测试用例的最短操作步骤
4. 预期行为的描述
   要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。（测试人员是懂需求的）
5. 错误行为的描述
   可以上传日志或者截图。
6. 其他
   某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

一般来讲，bug的描述均以缺陷报告的形式给出，具体可以参考下图：

除此之外，缺陷报告的格式还可以参考缺陷管理工具(如禅道、QC等)的缺陷报告给出的格式，比如禅道中缺陷报告的格式如下图：

4. bug的状态(生命周期)和状态转换图

bug的生命周期是是指bug从New到Closed的所有状态，bug常见的状态有以下七个，具体如下：

1. New： 发现的新bug，未经评审决定是否指派给开发人员进行修改。
2. Open： 确认是bug，并且认为需要进行修改，指派给相应的开发人员。
3. Fixed： 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
4. Rejected： 如果认为不是bug，则拒绝修改。
5. Delay： 如果认为暂时不需要修改或者暂时不能修改，则延后修改。
6. Closed： 修改状态的bug经测试人员的回归测试验证通过，则关闭bug。
7. Reopen： 如果验证bug仍然存在，则需要重新打开bug，开发人员重新修改bug。

根据上面的描述，我们可以绘制出如下的bug的状态转换图：

注意： 缺陷状态一般来讲就是上面的几种状态，不过每个公司依据自己的具体情况也会对bug的状态有所调整，有可能数量多余上面的状态数量，也有可能小于上面的状态数量。