回顾上篇博客软件测试 – 概念篇

1、什么是需求

1、满足用户的期望【用户需求】
2、满足合同规定的文档（标准，规范，合同）所需要的条件和权限【软件需求】
软件需求，是用户需求的进一步细化，是具体的实现和规范。

2、什么是BUG？

1、只有但软件测试需求存在并且合理，如果软件功能和软件规格说明书（软件需求文档）不匹配，就是软件错误（BUG）。
2、如果软件需求规格说明书（软件需求文档）不存在，就以用户需求为基准，但同样是在存在并合理的前提下，如果软件功能和用户需求不匹配，则视为软件错误（BUG）。

3、什么是测试用例

测试用例，就是向被测试的系统发起的一组集合。
这组集合包含了测试环境，测试数据，测试步骤，预期结果。【主要记住这4个】
【其实这组集合，还有很多其他的东西，比如：测试的功能模块，优先级（先测试那个），是否手动测试（手动测试，还是自动化测试）】

这里我们再来复习一下：测试环境是什么？
测试环境：被测系统所在主机上的操作系统，以及具体版本，而且被测系统，还可能嵌套在某个系统执行，比如浏览器。此时浏览器的内核，以及版本号都需要提供。
测试用例是我们测试的依据

4、软件开发的五大模型

1、瀑布模型

2、螺旋模型

3、增量模型 && 4、迭代模型
这两个模型的抗风险能力也不错！
简单来说：
假设我们要实现一个系统，该系统需要 4个模块 ABCD。
增量模型：将4个模块分为两个部分【AB，CD】，先完成 AB 模块，然后再来完成 CD 模块。【使每部分的开发联系起来】
迭代模型：先将4个模块的基础框架搞定，然后在这个基础上，继续完善4个部分的一些代码。【你可以理解为盖房子，先打好基础，然后再一层层完善。】

5、敏捷模型

核心思想：轻流程，轻文档，重目标，重产出，响应变化，

软件测试的两大模型

V模型

W模型

基础篇

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

软件测试的生命周期
如何描述一个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 ??

为了给开发人员看。
文字和口头描述，都是存在的。
除此之外，还有禅道，jira，tapd。

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

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

1、测试的版本号（代码的版本信息）

2、测试环境

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

3、测试数据

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

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

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

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

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

总之，我们对于BUG的描述越详细，越招同事待见。
开发人员都会抢着和你合作！

BUG的级别 – 仅了解

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

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

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

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

建议
这种类型的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了。
大家都是出来打工的，没必要计较！