软件测试- 基础篇 && 用例篇铺垫案例

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

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

---

 

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

其实就是一个实战案例：QQ登录测试用例

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