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

上一篇 / 下一篇  2021-07-09 11:16:54 / 个人分类：测试

查看( 354 ) / 评论( 1 ) / 评分( 5 / 0 )
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的状态有所调整，有可能数量多余上面的状态数量，也有可能小于上面的状态数量。

收藏 举报

TAG:

引用 删除 LH058610   /   2021-07-10 17:19:31
评 5 分
 

评分：0

我来说两句

Open Toolbar