【软件测试】BUG篇 — 详解

[1. 软件测试的生命周期](#1. 软件测试的生命周期)

[2. BUG](#2. BUG)

[2.1 BUG的概念](#2.1 BUG的概念)

[2.2 BUG的要素](#2.2 BUG的要素)

[2.3 BUG级别](#2.3 BUG级别)

[2.4 BUG的生命周期](#2.4 BUG的生命周期)

[2.5 与开发人员发生争执怎么办](#2.5 与开发人员发生争执怎么办)

[2.6 BUG评审](#2.6 BUG评审)

1. 软件测试的生命周期

需求分析

判断软件需求是否合理
技术上是否可行，有没有优化空间
是否存在业务逻辑错误（先登录用户后创建用户 X）

测试计划

说明什么时候开始测试，什么时候结束测试

测试设计与开发

根据需求文档，技术文档编写测试用例。
编写测试文档，说明使用到的测试方法和测试工具

测试执行

根据测试文档和测试工具，尽可能做到全方面的测试
严格记录实际结果（截图/日志）

测试评估

对进行的测试用例进行评估
评估：本次测试是否通过，测试是否有遗留的bug，是否解决
最终需要编写出一个测试报告

上线

项目测试结束后，将项目发布到线上环境
线上环境和线下环境不一样，线上环境非常复杂
测试人员需持续跟踪程序线上运行状态，查看运行是否正常
测试人员还需要在线上进行手动测试，还要关注有没有错误日志。

运行维护

测试工作执行完，不能认为项目100%的问题都被发现并解决，问题是不可能被完全发现的，
需要测试人员在运行期间做到实时监测，收集运行时产生的问题并及时解决。

实际工作中，项目的上线被分为多个步骤：沙盒，小流量，全流量

沙盒：企业内部的线上环境，供内部人员进行测试。
小流量：部分线上正式的用户可以使用到。
全流量：所有的真实用户可以使用到

因为在实际情况中，线上环境和线下环境并不是完全一样，线下测试没有问题，可能线上会存在问题，如果一次性全部上线，可能会造成无可挽回的损失

2. BUG

2.1 BUG的概念

如果是需求文档提到的功能并是正确的，程序实现的和需求文档中描述的不匹配，那就是bug

如果需求文档没有提到的功能，判断标准以用户为准，程序没有实现用户的合理预期，那也是bug

bug举例：

在测试文档中说明，文字为百度一下，这里却是百度五下。这就是bug

2.2 BUG的要素

bug要素的作用就是描述bug

如果你发现了这个bug，告诉开发人员，百度五下，开发人员会问你百度五下什么信息。

如果没有一个标准来规定，会出现描述不清晰，不准确，无法快速定位问题

描述bug的基本要素：问题出现的版本，问题出现的环境，bug的级别，问题出现的步骤，预期结果，实际结果（不限于这些）

比如刚刚的模拟百度bug编写一个描述：

bug编号：1

版本：IE浏览器版本 9.0.6.7021（正式版本）（64 位）

环境：Windows 11

步骤：1. 打开IE浏览器 2.输入网址 https://baidu.com 3.找到搜索按钮

预期结果：搜索按钮中的文字为百度一下

实际结果：搜索按钮中的文字为百度五下

给出具体的信息是为了让开发人员可以还原bug，才能更好的解决bug

如果在测试时，遇到无法复现的Bug，会怎么处理？

我会先记录Bug发生的具体描述，发生bug的具体环境（那个版本的浏览器，网络环境是什么，发生的具体时间）和系统版本是什么，步骤是什么，将相关日志和发生的现象进行截图保存
系统性的进行复现

设备方面：使用不同型号的设备
数据方面：使用新建账号/历史账号
环境方面：在不同的时间/不同的网络环境
并发维度：模拟多用户同时操作

必要时会使用fiddle抓包工具对发送的网络数据包进行详细分析
如果实在找不到，在关键的节点，添加实时监控和预警
在编写测试报告的时候，将这一类问题单独存放起来，并说明自己是怎么处理的，提醒后续的测试人员在进行这一块测试的时候，注意一下

2.3 BUG级别

通过定义bug的级别，能够明确看出问题的严重程度。工作中开发人员会通过bug级，决定优先处理哪个bug。同时bug级别也可以体现出开发人员的开发质量

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

**崩溃：**会阻碍开发或测试工作，会导致系统崩溃，死机，主要功能缺失，基本功能丧失，数据库连接异常等。

严重： 系统主要功能部分丧失，数据库的调用错误，程序接口错误。程序自动退出，功能设计与需求文档中的严重不符等

**一般：**功能没有完全实现，但不影响使用。功能设计与需求文档中的一般不符，响应时间过长等

**次要：**建议类问题，不影响操作功能的执行，无界面格式不规范，显示重叠，性能缺陷等

2.4 BUG的生命周期

测试人员在执行测试的过程中发现bug，需要在对应的bug管理平台创建bug，创建好的bug需要被开发人员修复，以及测试人员的持续跟踪和测试。

在工作中测试人员创建的bug并不一定是有效的，可能由于误操作导致的无效bug。

测试人员创建出一个bug（表示bug的生命周期开始。）
开发人员拿到bug会先判断这个bug是否是有效bug（如果为无效bug，则生命周期结束。）
开发人员承认这个bug才会打开bug，
根据bug的优先级和时间，判断是否立即修改这个bug，如果bug优先级很高则必须要修改。
开发人员将bug修改完后，开发人员会对这个bug进行验证，如果验证不通过则会被打回，开发人员再次修复，如果验证通过则结束（表示bug的生命周期终止）
如果bug的优先级很低或者时间不够，来不及修改，且这个bug不会对系统功能造成任何影响，则会进入延迟在下一个迭代修改（最终肯定是要修复）

2.5 与开发人员发生争执怎么办

首先分析自己提出的bug是否合理，是不是由于自己的误操作导致的bug
检查bug的描述是否清楚，根据自己的描述尝试复现bug
检查确实存在bug，并且根据描述成功复现出了bug。
如果开发人员觉得这算不上一个bug，尝试站在用户的角度考虑并抛出问题。
如果对bug的定级不满意，拿出企业的bug定级文档。将bug的表现和定级描述文档中进行匹配说服开发人员
提高自己的技术和业务水平，在提出bug的同时，并能给出一定的解决方案，更像是一种建议（不能命令的口吻）
如果开发人员就是不承认这是一个bug，就需要进行bug评审。

2.6 BUG评审

Bug评选需要三个代表：测试代表，开发代表，产品代表

Bug评审主要解决两个问题。

决定如何处理bug。
分析缺陷产生的原因，找出预防的对策。

修改可能会带来回归测试的风险，如果剩下的时间不够做一次有效的回归测试且bug的级别很低，可能在这次迭代中不修改更好。