在了解BUG之前,我们要先了解软件测试的生命周期,因为大多数BUG都是在软件测试的过程中被发现的

软件测试的生命周期

在了解 软件测试的生命周期 之前,我们要先了解 软件的生命周期 ,虽然他们之间只差了两个字,但是差距还是很大的

首先是 软件生命周期 ,这个是站在 软件 的角度而言的

其次是 软件测试的生命周期 ,这个是站在 测试 的角度来看的

接下来我将重点介绍软件测试的生命周期

将上面的流程图中的每一步进行详解:

需求分析

用户角度: 软件需求是否合适

技术角度: 技术上是否可行,是否有优化空间

测试角度: 是否存在业务逻辑错误、冗余、冲突等问题

测试计划

什么是进行开发测试,什么时候结束测试,测试耗时多久

测试设计与开发

参考需求文档、技术文档等编写测试用例

写测试文档,明确标注使用到的测试方法、测试工具,要测试哪些,进行什么样的测试

测试执行

利用测试用例和测试工具对项目进行尽可能全面的测试覆盖

测试评估

测试是否通过,是否还有遗留的BUG,最后测试人员产出一个测试报告

上线

项目测试结束后,将项目发布到线上环境,测试人员许需要跟踪上线并测试在线上环境下软件是否能正常运行

运行维护

测试人员需要参与项目的实施工作.要求测试人员要对项目的业务和操作非常了解,同时要求测试的沟通表达能力较强,能够参与用户使用软件的培训,在试运行项目时收集文图并及时给出反馈

BUG

概念

一个计算机BUG是指在计算机程序中存在的错误、缺陷、疏忽和故障,导致程序无法正确运行,一般产生于程序的源代码或者程序设计初期就存在的错误

所以: 程序和规格说明书之间不匹配的就是错误,但是当规格说明书里面没有提到一个功能,那么就要以最终用户为准: 当程序没有实现其最终用户合理预期的功能时,那就是软件错误 

描述BUG

在说明一个BUG的时候,往往要求详细且精确,所以在描述时就需要根据基本要素来描述

基本要素: 问题出现的版本、出现的环境、出现的步骤、预期结果、实际结果 

举个例子,当我的游戏无法进行登录时:

问题出现的版本: XXXX 3.1

问题出现的环境: Windows10

出现的步骤:

1.打开游戏,点击登录按钮,显示登录成果

2.点击进入游戏

预期结果:进入游戏大厅,弹出签到奖励,自动进行签到

实际结果:无法进入游戏大厅,画面卡住登录页面

BUG级别

在反馈BUG时,测试人员需要对BUG进行分级处理,来突出BUG的严重程度,以便开发人员能够按照BUG的级别来进行优先处理

还是举一个例子吧:

如果我们不使用分级策略

此时BUG1先出现: 用户登陆后,无法正常与某一接口进行交互

BUG2后出现: 已经注册过的用户发现自己的账号不存在了,手机号又可以重新注册了

如果不按照分级,开发人员可能就要按照先后顺序来处理,但是显然BUG2更严重,很可能是数据库出现了问题,所以此时就会造成更多的问题

那么具体要分为哪些级别呢?

BUG的级别一般分为: 崩溃、严重、一般、次要 

崩溃

阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,丧失主要功能,基本模块缺失等问题(代码错误、死循环、数据库发生死锁、重要的一级菜单无法使用等)

一旦出现这种级别的错误就要立即中断当前版本的测试,但是出现次数较少

严重

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等

该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试

一般

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等

该问题实际测试中存在最多

次要

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等

此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理

BUG的生命周期

既然软件测试和软件都有生命周期,那么BUG当然也有生命周期

测试人员在执行测试的过程中如果发现了BUG,需要在对应的BUG管理平台创建BUG(生命start),创建好之后要被开发人员修复,同时测试人员需要持续地跟进和测试

• New: 新发现的Bug，未经评审决定是否指派给开发人员进行修改。

• Open: 确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

• Fixed: 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

• Rejected: 如果认为不是Bug，则拒绝修改。

• Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改。

• Closed: 修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。

• Reopen: 如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug: open->closed open-rejected-closed

与开发产生争执怎么办?(这里必看!!)

在测试工作中,可能会与开发人员发生争执,比如认为不是BUG、关于级别的定义有不同的意见、BUG影响大不大?是否要立马进行修改

遇到这种情况要怎么解决呢?

• 先检查自己,是否描述准确

• 站在用户的角度来考虑并且抛出问题

• BUG的定级是否有理有据

• 提高自己的技术和业务水平,在提出问题的同时,最好要能够提出解决方案

• 进行BUG评审(如果的确是BUG,且沟通没有解决问题),由测试代表、开发代表和产品代表组成(项目组的每一个负责方面都要派出代表参加)

  • 决定如何处理BUG

  • 分析产生的原因,找出预防的对策