软件测试：关于Bug~

我们该如何去描述一个Bug之前我们首先要清楚一个概念，软件的生命周期。
软件的生命周期有如下五个阶段：需求分析——>测试计划——>测试设计、测试开发——>测试执行——>测试评估；
需求阶段
这是测试人员了解需求、对需求进行分解，得出测试需求；
计划阶段
根据需求编写测试计划、测试方案；
设计阶段
测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例；
编码阶段
测试人员一般不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
测试阶段
测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行过程中记录、管理缺陷、测试完成后编写测试 告；
运行维护
测试人员需要参与项目实施工作，测试人员对项目产品业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目是收集问题并及时反馈给相关的负责人。

描述Bug

我们在测试过程中，不可避免bug的出现，那么当其出现时，我们该如何正确的描述出并及时的反馈给开发人员呢r> 我们通常从以下几个方面进行描述：测试的平台（环境），测试数据、操作步骤、预期效果、实际结果对bug进行完整的描述。
一个合格的Bug应该包含以下几个部分：

• 发现问题的版本
  开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障，并且版本的标识也有利于统计和分析每个版本的质量；

• 问题出现的环境
  环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器的版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等，详细的环境描述有利于故障的定位；

• 错误重现的步骤
  描述问题重现的最短步骤；

• 错误行为的描述
  描述错误的现象，crash等上传log，UI问题可以有截图

• 其他
  某些公司会有一些其他的要求，例如故障的分类:功能故障、界面故障、兼容性故障等，有些优先级的分类，严重影响到测试需要开发人员优先修改的，可以设置优先级为高

• 不要把bug放到一起
  在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

Bug的级别

在开发和测试时，我们对Bug怎样去划分他们的程度等级呢r> 我们一般将Bug的级别划分为四类：崩溃、严重、一般、次要。每个公司对bug的定义都不一致，在定义级别之前需要查看公司规范。

• 崩溃（Block）
  阻碍开发或测试工作的问题；造成系统崩溃、司机、死循环，导致数据库或数据丢失，与数据库链接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用（此类问题在测试过程中很少遇到，一旦出现应当立即终止）
• 严重（Critical）
  系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用，关联程序间调用冲突，安全问题，稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本的测试）
• 一般（Major）
  功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统的稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表中字段过多等（该类问题在实际问题中占绝大部分）
• 次要（Minor）
  界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等，如：错别字、界面格式不规范、页面显示重叠、不该显示的要隐藏、描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度比较低；在测试后期出现较少，应及时处理）

Bug的生命周期

每个公司、每一个工具对bug的生命周期的定义都是不一致的

• 软件测试同样也存在二八原则，80%的故障集中于20%的模块，如果某部分问题比较多，加强测试广度和深度；
• 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug比较多，加强他开发模式块的测试广度和深度
• 多进行逆向思维和发散性的思维；
• 不要局限于测试用例和需求文档；
• 尽早的介入项目，不要等到开发的差不多了才介入项目