1. 概述
本文主要讲述了软件测试的生命周期、bug的描述方法及状态，以及bug之间的状态转换。具体描述如下，首先是软件测试的生命周期。
2. 软件测试的生命周期
软件测试的生命周期可以总的划分为以下几个阶段：
需求分析
测试人员需要了解需求，对需求进行分解，得出测试需求。测试计划
根据要求编写测试计划书或方案测试设计
测试人员适当的了解设计，搭建测试用例框架测试执行
执行测试用例，找软件中存在的缺陷。测试评估
根据测试的结果，编写最终的测试报告以对软件的质量形成文字性说明与衡量。
3. bug的描述
bug的描述通常应该包含以下几个方面的内容，分别为：
发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等。如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。错误重现步骤
测试用例的最短操作步骤预期行为的描述
要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。（测试人员是懂需求的）错误行为的描述
可以上传日志或者截图。其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
一般来讲，bug的描述均以缺陷报告的形式给出，具体可以参考下图：
除此之外，缺陷报告的格式还可以参考缺陷管理工具(如禅道、QC等)的缺陷报告给出的格式，比如禅道中缺陷报告的格式如下图：
4. bug的状态(生命周期)和状态转换图
bug的生命周期是是指bug从New到Closed的所有状态，bug常见的状态有以下七个，具体如下：
New：发现的新bug，未经评审决定是否指派给开发人员进行修改。Open：确认是bug，并且认为需要进行修改，指派给相应的开发人员。Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。Rejected：如果认为不是bug，则拒绝修改。Delay：如果认为暂时不需要修改或者暂时不能修改，则延后修改。Closed：修改状态的bug经测试人员的回归测试验证通过，则关闭bug。Reopen：如果验证bug仍然存在，则需要重新打开bug，开发人员重新修改bug。
根据上面的描述，我们可以绘制出如下的bug的状态转换图：
注意：缺陷状态一般来讲就是上面的几种状态，不过每个公司依据自己的具体情况也会对bug的状态有所调整，有可能数量多余上面的状态数量，也有可能小于上面的状态数量。
