📢博客主页：https://blog.csdn.net/2301_779549673
📢博客仓库：https://gitee.com/JohnKingW/linux_test/tree/master/lesson
📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
📢本文由 JohnKi 原创，首发于 CSDN🙉
📢未来很长，值得我们全力奔赴更美好的生活✨
文章目录
🏳️🌈一、软件测试的生命周期
软件测试贯穿于软件的整个生命周期，针对这句话我们一起来看一下软件测试是如何贯穿软件的整个生命周期。
软件测试的生命周期是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物
各阶段具体内容:
软件开发测试流程表
| 阶段 | 用户角度 | 技术角度 | 测试角度 |
|---|---|---|---|
| 需求分析 | 软件需求是否合理 | 技术可行性及优化空间 | 是否存在业务逻辑错误、冗余、冲突等问题 |
| 测试计划 | 制定测试时间规划 | 确定测试阶段起止时间 | 编写测试计划文档 |
| 测试设计与开发 | 参考需求文档编写测试用例 | 明确测试方法、工具和形式 | 产出测试文档并标注测试工具 |
| 测试执行 | 充分利用测试用例和工具 | 项目全方面测试覆盖 | 验证测试通过率及遗留BUG |
| 测试评估 | 确认项目测试结果有效性 | 最终测试耗时统计 | 检查遗留BUG并生成测试报告 |
| 上线 | 跟踪线上环境发布 | 确保软件运行正常 | 监控线上环境稳定性 |
| 运行维护 | 参与用户培训 | 收集用户反馈 | 持续跟踪问题并反馈负责人 |
各阶段核心任务
需求分析阶段
- 三方同步确认需求合理性
- 建立业务逻辑检查机制
测试计划阶段
- 制定测试时间轴（含压力测试时段）
- 规划回归测试周期
测试开发阶段
- 编写自动化测试脚本
- 搭建测试环境沙箱
测试执行阶段
- 每日构建（Daily Build）验证
- 缺陷生命周期管理
上线部署阶段
- 蓝绿部署验证
- 监控告警配置
运维阶段
- 建立用户反馈闭环系统
- 制定应急预案手册
🏳️🌈二、BUG
2.1 bug的概念
定义: 一个计算机bug指在计算机程序中存在的一个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。
准确的来说:
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
2.2 描述bug的要素
为什么描述bug还有要素要求?
在心理学上说，人们在编写文档的时候，经常会出现自己想表达的和写出来的内容往往南辕北辙
bug描述:浏览器打开链接失败
该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发人员来说无法捕捉到更多有效的信息，会造成沟通效率低下，工作质量低下等问题。
描述bug的基本要素: 问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
2.3 bug级别
通过定义bug的级别，能够明确看出问题的严重程度。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发人员的开发质量。
案例:
男朋友多看了几眼美女 :次要
男朋友跟美女加微信聊天:一般
男朋友跟美女私下去吃饭:严重!!!
男朋友跟美女去做头发:崩溃!坚决踹了!!!
bug级别一般分为: 崩溃、严重、一般、次要
软件问题等级分类表
| 问题等级 | 定义描述 | 典型场景案例 | 处理优先级 |
|---|---|---|---|
| 崩溃 | 阻碍开发/测试工作，导致系统崩溃、死循环、数据库数据丢失等严重后果 | - 代码错误导致死循环 - 数据库死锁 - 程序自动退出 - 模块无法启动调用 |
立即中止版本测试，需紧急修复 |
| 严重 | 系统主要功能部分丧失，存在数据库错误、功能设计缺陷等 | - 数据保存后数据库显示错误 - 用户数据丢失 - 核心功能模块缺失 |
影响其他功能测试时允许继续测试，但需版本更新前修复 |
| 一般 | 功能未完全实现但不影响使用，存在稳定性缺陷 | - 边界条件错误 - 删除操作无确认提示 - 字段冗余 |
测试初期优先处理，后期需根据剩余时间选择性修复（该等级问题出现频率最高） |
| 次要 | 界面/性能等优化类问题，不影响功能执行 | - 错别字/排版问题 - 页面显示重叠 - 查询响应时间过长 |
测试初期优先级低，后期需及时处理（该等级问题在测试后期出现率低于5%） |
2.4 bug的生命周期
测试人员在执行测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug(bug生命起源)，创建好的bug需要被开发人员修复，以及测试人员的持续跟踪和测试。
New: 新发现的Bug，未经评审决定是否指派给开发人员进行修改。
Open: 确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
Fixed: 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
Rejected: 如果认为不是Bug，则拒绝修改。
Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed: 修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
Reopen: 如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的 bug: open - rejected - closed
2.5 与开发产生争执怎么办(高频考题)
在测试工作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度质量。作为一名测试人员，一般会遇到以下几种情况:
2.5.1 先检查自身，是否bug描述不清楚
- 如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的
信息。- 但是总有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发
现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，
就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而
不要等待开发人员找自己了解更多的信息。
2.5.2 站在用户角度考虑并抛出问题
站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句:如果你是用户，你可以接受么?
2.5.3 BUG定级要有理有据
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。
2.5.4 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗?
注意:可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修改。
2.5.5 bug评审
如果确实是bug，友好沟通不能解决问题，那么就召开bug评审。
bug评审主要解决两个问题:
1)决定如何处理bug
2)分析缺陷产生的原因，找出预防的对策
bug评审至少需要项目组各个方面的代表参加:
- 测试代表
测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。 - 开发代表
开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。 - 产品代表
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见
👥总结
本篇博文对 【测试开发】BUG篇 - 从理解BUG到如何处理 做了一个较为详细的介绍，不知道对你有没有帮助呢
觉得博主写得还不错的三连支持下吧！会继续努力的~