软件测试（ 基础篇）

前言

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

软件测试的生命周期
如何描述一个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了。
大家都是出来打工的，没必要计较！ 

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

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

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