软件测试（基础篇）

news2024/11/15 9:22:31

前言

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

软件测试的生命周期
如何描述一个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、测试的版本号（代码的版本信息）

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

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

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

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

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

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

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

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

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

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

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