【软件测试】BUG篇 — 详解
目录
1. 软件测试的生命周期
2. BUG
2.1 BUG的概念
2.2 BUG的要素
2.3 BUG级别
2.4 BUG的生命周期
2.5 与开发人员发生争执怎么办
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，会怎么处理？
1. 我会先记录Bug发生的具体描述，发生bug的具体环境（那个版本的浏览器，网络环境是什么，发生的具体时间）和系统版本是什么，步骤是什么，将相关日志和发生的现象进行截图保存
2. 系统性的进行复现
- 设备方面：使用不同型号的设备
- 数据方面：使用新建账号/历史账号
- 环境方面：在不同的时间/不同的网络环境
- 并发维度：模拟多用户同时操作
3. 必要时会使用fiddle抓包工具对发送的网络数据包进行详细分析
4. 如果实在找不到，在关键的节点，添加实时监控和预警
5. 在编写测试报告的时候，将这一类问题单独存放起来，并说明自己是怎么处理的，提醒后续的测试人员在进行这一块测试的时候，注意一下
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的级别很低，可能在这次迭代中不修改更好。