测试中的Bug

软件测试的生命周期

有人看完上面这个图就会想，这不是和前面说过的软件生命周期差不多吗？没错，就是因为软件测试贯穿软件的整个生命周期，所以在软件开发的每个阶段，对应的都有测试需要干的工作

软件测试的各个阶段

阶段	内容
需求分析	看看软件需求设计上是否存在业务逻辑错误、冗余、冲突等问题
测试计划	制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久
测试设计与开发	编写测试用例 确定测试方法，测试工具，测试形式等等
测试执行	充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖
测试评估	产出一个测试报告
上线	测试线上环境
运行维护	由于测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人

线上环境

实际在工作中，上线要分成多个步骤：沙盒、小流量、全流量、全线上。
为什么又要细分这几个阶段呢？因为上线的过程中也可能会存在问题，即使线下测试没有问题，如果直接推到线上可能会发现问题。

• 沙盒：企业内部的线上环境，可以供内部人员进行测试；
• 小流量：部分线上真实的用户可以使用到，测试人员要在线上手动测试，还要观察有没有错误日志，还要接收用户在使用过程中发现的问题；
• 全线上：所有的真实用户都可以使用到

线上环境和线下测试环境并不是完全一样的，因此每一步都需要跟进测试。

测试中的BUG

测试中的BUG和我们开发中的BUG有些不一样

1. 首先，如果你程序中实现的功能和软件需求中提到的功能不一样，那不管它有没有报错，它就是BUG！
2. 如果用户用的不舒服，即使程序完全符合软件需求，这也是BUG
   比如下面这个例子，软件需求中没有规定按钮的大小，但是用户看着不好看，这也算BUG
   

描述测试BUG

描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果

举个例子，看下面的网页，在谷歌浏览器上呈现出来，它的二维码会被登录界面遮住。这个问题应该怎么描述呢？

BUG的级别

为啥要定义BUG的级别？

1. 同时存在多个BUG，我要优先修复级别更高的BUG
2. 评价一个程序员的绩效，不仅要看他工作中出现BUG的数量，还要看他搞出来的BUG的级别，搞出BUG越严重，那他就越菜

BUG有哪些级别呢？

bug级别一般分为：崩溃、严重、一般、次要

BUG的生命周期

测试与开发发生争执怎么办？

测试与开发会发生啥争执？

• 测试说：你这个BUG的级别是崩溃级别
• 开发说：我觉得我这个BUG不至于级别那么高

为啥会发生这样的争执？

• 测试找的BUG越多，绩效越高
• 开发出现的BUG越多，绩效越少

测试与开发发生争执怎么办呢？

1. 先反思自己BUG描述得清不清楚
2. 从用户使用感受的角度说明问题
3. 根据公司BUG定级文档，给出自己BUG定级的依据
4. 不仅指出问题，最好还要给出解决方案
5. 如果前面四条不管用，就发起BUG评审，让第三方来评判

BUG评审

BUG评审的三个代表

1. 测试代表
2. 开发代表
3. 产品代表

BUG评审要解决的两个问题

1. 如何解决这个BUG
2. 如何预防这个BUG