1. 概述
2. 软件测试的生命周期
软件测试的生命周期可以总的划分为以下几个阶段：
测试人员需要了解需求，对需求进行分解，得出测试需求。
测试计划
根据要求编写测试计划书或方案
测试设计
测试人员适当的了解设计，搭建测试用例框架
测试执行
执行测试用例，找软件中存在的缺陷。
测试评估
根据测试的结果，编写最终的测试报告以对软件的质量形成文字性说明与衡量。
3. bug的描述
bug的描述通常应该包含以下几个方面的内容，分别为：
发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
问题出现的环境
错误重现步骤
测试用例的最短操作步骤
预期行为的描述
要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。（测试人员是懂需求的）
错误行为的描述
可以上传日志或者截图。
其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
一般来讲，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的状态有所调整，有可能数量多余上面的状态数量，也有可能小于上面的状态数量。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
