软件测试( 基础篇)

前言

从这篇博文开始,我们将作为一名刚刚加入测试团队的菜鸟,开始一次测试之旅。
在这里我们将讨论以下问题:

软件测试的生命周期
如何描述一个bug
如何定义bug的级别
bug的生命周期
产生争执怎么办

软件测试的生命周期

先回顾一个点:软件开发的生命周期

1、需求分析
2、计划【时间,人员,功能的方向和范围】
3、设计【功能,框架,算法】
4、编码
5、测试
6、运行维护

那么,软件测试的生命周期包含哪几个部分?

1、需求分析

验证需求的正确性,以及合理性接着便是细化需求,找出测试项,方便后面写测试用例

2、测试计划(部分)

        确定测试的人数
        确定测试的环境

        确定测试的时间

        确定测试的设备

3、测试设计 / 测试开发
根据需求,写出测试用例

4、测试执行
此时开发已经完成,执行测试用例,验证功能,
在验证功能的过程中,可能会遇到 软件功能与需求不相符的七情,也就是出BUG了。
于是,测试人员就会把这个BUG 交给 开发人员。
等到开发人员处理好了之后,我们测试人员又要对其进行验证。

5、测试评估
        1、写了多少测试用例,执行了多少测试用例。
        2、剩余的测试用例,为什么不把它执行完。

        3、BUG数量。
        4、已解决的BUG数量
        5、遗留的BUG,以及解决方案。

        6、此次测试的范围和测试功能都要说清楚。

如何描述一个BUG

首先,我们要理解一件事:为什么要描述一个 BUG ??

为了给开发人员看。
文字 和 口头 描述,都是存在的。

但实际上,我们是有专门的 BUG管理工具。
这个工具里面,它会把 BUG需要描述的地方,讲得非常清楚。

下面我们来看一下具体如何描述一个 BUG

1、测试的版本号(代码的版本信息)

软件测试( 基础篇)_第1张图片

2、测试环境

软件测试( 基础篇)_第2张图片

比如:QQ音乐的播放界面,在360浏览器上支持,在IE浏览器上不支持。
连操作都不能,更别提放音乐了。


3、测试数据
测试数据,往往是能让开发人员更加快速的复现问题因为数据出现错误的概率,比前面环境出错的概率更大

4、测试步骤
就是怎么去操作,会出现BUG,帮助开发人员更快的复现问题。

5、测试的实际结果
不看到结果,我们怎么知道验证的软件功能是否正确?
拿着预期结果 与 实际结果 进行比较,如果匹配,表示软件功能实现完成,反之,则软件功能实现失败。
这样开发人员就知道,他需要关注的地方在哪里

6、附件:错误日志,错误截图等等。。。
还是一样的,为了更好的辅助开发人员复现 BUG,早日解决bug。

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

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

BUG的级别 - 仅了解

对于BUG的级别,每个公司都不一样,这里只是讲典型的,普遍的情况

崩溃:
系统无法正常执行:出现崩溃,操作死锁,死循环,黑屏。。。
出现以上这些情况会严重阻碍测试人员的工作,应立即反馈给开发人员进行修改

另外,我们再来思考一个问题: 如果线上出现这种 崩溃级别的BUG,该如何 处理/补救?

最简单直效的方式就是:回退到一个稳定版本。[回退版本:你要知道上一个稳定运行版本的版本号,然后通过Bit来实现回退,

严重
系统可以运行,但是不稳定,继续运行下去会造成严重的损失。
一般都是 重要的功能没有实现,或者功能和需求不匹配。
还有就是 用户数据存储错误

一般用户数据都是存储在数据库中的,如果存储用户的信息错误,尤其是还是和钱有关的,事情就大发了而且严重时,会威胁到用户的安全(信息,财产) ! ! !
注意!我这里说的是存储信息错误,可能是存储信息有偏差,也可能就是信息存到别的地方去了。如果是后者,这个存储地方是一个公开的,这个信息又包含了用户的敏感信息,被别人一抓包拿到了,那就GG了[比如: 用户的操作日志]

一般
次要的功能没有实现,或者有错误,但是不影响系统,系统可以稳定的运行

建议
这种类型的bug,可能需求上没有写。只是会影响到用户的体验。
比如:
1、界面排版很挫,不符合大众的审美、
2、显示的信息没有进行换行处理...


BUG的生命周期

BUG的生命周期:从发现这个bug 到 解决这个bug,整个的一个流程。
简单来说:BUG的生命周期 就是 BUG 的 各种生存状态。

● New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
● Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
● Rejected:如果认为不是Bug,则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
● Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
● Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
无效的bug:open->closed open-rejected-closed

软件测试( 基础篇)_第3张图片

BUG状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用

例如,测试人员新发现的Bug,必须由测试组长评审后才决定是否Open并分派给开发人员。
测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人,也可以要求都先统一提交给开发主管,由开发主管审核后再决定是否分派给开发人员进行修改。

Bug的跟踪以及状态变更应该遵循一些基本原则:
测试人员对每一个BUG的修改必须重新取一个包含更改后的代码的新版本进行回归测试,确保相同的问题不再出现,才能关闭缺陷。
对于拒绝修改和延迟修改的Bug,需要经过包含测试人员代表和开发人员代表、用户方面的代表(或代表用户角度的人)的评审。

如果因为 BUG 和 开发人员产生冲突,该如何处理?- 面试问题

1、检查,查看自己对BUG的描述是否清楚
2、从用户的角度去说服开发人员

应该让开发人员了解到Bug对用户可能造成的困扰,这样才能促使开发人员
更加积极地、高质量地修改Bug。
因为有些时候,真的有些bug可改可不改。
但是改了的,用户的体验会非常好。
而且,有些bug产生的原因是因为 在需求文档中没有描述的很清楚!
虽然 软件需求 是 用户需求 的进一步细化,但是有些时候,产品经理也考虑的不是很周全。
又或者说,没有产品经理该怎么办?
下面我们来看一个例子 

软件测试( 基础篇)_第4张图片

3、BUG定级要有理有据【根据公司的规范】
如果只是你自己觉得这个BUG很严重,人家开发人员肯定不干!
人家是为公司打工,又不是为你。

4、要不断提升 自己的 业务水平,和 技术水平。
不但能够发现BUG,并且能够定位。
还能够提出解决方案
【这些能力,工作久了,自然也就具备了】

5、开发人员不接受时,不要争吵,
可能你已经经过了多轮沟通,但是开发人员仍然拒不接受。此时可以发起Bug评审。
找产品经理讨论,后面就会开展一个三方会议、
测试人员,开发人员,产品经理会一起讨论这个bug的最终解决方案。

也就是说:遇到bug不要慌!有人比更着急!你只需要做好你本分的工作就OK了。
大家都是出来打工的,没必要计较! 

为下一篇用例篇博文做铺垫

实战案例:QQ登录测试用例

软件测试( 基础篇)_第5张图片

下面,我们来看一下,具体的测试点有哪些?
我只对难理解的部分,做出注释。

你可能感兴趣的:(软件测试,单元测试)