BUG 篇：从"怎么测"到"怎么提"，再到"怎么关"
软件测试不只是"点点点找问题"，更重要的是：用一套可复用的流程，把问题稳定、清晰、可追踪地送到修复闭环里 。来看这篇文章的主线：先讲软件测试生命周期（测试怎么贯穿项目），再讲什么是 Bug、怎么把 Bug 写清楚、Bug 的级别怎么定、Bug 的生命周期怎么走，最后聊一个高频现实题：跟开发产生争执怎么办。
1）软件测试生命周期：测试到底"贯穿"在哪些环节？
来看流程图，软件测试贯穿软件的整个生命周期，测试的生命周期（也就是测试流程）是一系列按顺序执行的活动，用来保证产品质量符合需求；每个阶段都有不同目标与交付物。
下面按阶段把"做什么 + 产出什么"说清楚：
1.1 需求分析
来看三种视角的检查点：
- 用户角度：软件需求是否合理
- 技术角度：技术上是否可行，是否还有优化空间
- 测试角度：是否存在业务逻辑错误、冗余、冲突等问题
这一步的价值是"提前排雷"：很多后期难修的大坑，根儿其实在需求阶段就能看出来。
1.2 测试计划
来看测试计划要回答的问题：**什么时候开始测、什么时候结束测、测多久、怎么测（测试形式）**等。
常见产出物就是测试计划（范围、资源、排期、风险、里程碑、准入准出等）。
1.3 测试设计与开发
来看核心动作：参考需求文档、技术文档等编写测试用例，并编写测试文档，明确使用到的测试方法、测试工具、测试数据准备等。
你可以把这一步理解为：把"怎么验证质量"变成可执行的清单与脚本。
1.4 测试执行
来看目标：充分利用测试用例和测试工具，对项目尽可能做到全方面覆盖，并持续提交与跟踪缺陷。
1.5 测试评估
来看要回答的关键问题：
- 本次测试是否通过
- 是否有遗留的 Bug
- 最终需要产出一份测试报告（总结风险、缺陷分布、结论、建议）
1.6 上线
项目测试结束后发布到线上环境，测试人员通常需要跟踪上线并验证线上环境下软件运行是否正确。
1.7 运行维护
测试人员对业务和操作非常了解，且沟通表达能力通常较强，所以在运行维护阶段常会参与：
- 项目实施工作
- 用户使用培训
- 试运行期间收集问题并及时反馈给相关负责人
一句话总结：测试不是"最后一道门"，而是"全程的质量合伙人"。
2）什么是 Bug：不是"我觉得不对"，而是有标准的
来看定义：计算机 Bug 指程序中存在的错误（error）、缺陷（flaw）、疏忽（mistake）或故障（fault），使程序无法正确运行；Bug 往往产生于源代码或设计阶段的疏忽/错误。
再来看两个更"可落地"的判定标准（非常关键）：
- 当且仅当规格说明存在且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没提到某功能时，判断标准以最终用户为准：当程序没有实现最终用户的合理预期功能要求时，就是软件错误。
这两条的意义是：
- 有规格就按规格对齐；
- 没规格就看"合理预期"，避免陷入"文字游戏"。
3）怎么写 Bug：写不清楚的 Bug ≈ 没提
很多团队争执的根源不是"要不要修"，而是"你到底说的是啥"。来看一个典型坏例子：
Bug 描述：浏览器打开链接失败
这句话的问题是：没说哪个浏览器、失败表现是什么、怎么复现------开发拿不到有效信息，沟通效率和质量都会掉。
3.1 为什么 Bug 描述要有要素？
来看一个很真实的现象：人在写文档时，经常出现"脑子里想表达的"和"写出来的"南辕北辙。Bug 不写清楚，等于把成本转移给别人（开发/测试二次沟通、来回拉扯、甚至漏修）。
3.2 描述 Bug 的五要素（最小完备集）
来看一份合格 Bug 报告必须包含的基本要素：
- 问题出现的版本
- 问题出现的环境
- 问题出现的步骤（复现步骤）
- 预期结果
- 实际结果
你可以把它当成"让任何人都能复现"的说明书。
3.3 来看一个完整示例（把"现象"写成"证据链"）
来看示例的表达方式（要点是：信息足够、可复现、可对比）：
- 问题出现的版本：谷歌浏览器版本 123.0.6312.123（正式版本）（64 位）
- 问题出现的环境：Windows 家庭版
- 问题出现的步骤 ：
1）打开谷歌浏览器，输入网址 https://www.101eduyun.com/
2）等待首页页面渲染完成 - 预期结果：二维码与登录模块不会出现遮挡，二维码可正常扫描
- 实际结果：二维码被登录模块遮挡，二维码扫描失败
看出来了吗？这已经不是"我觉得不对"，而是"在某版本某环境按某步骤必现，预期/实际对比明确"。
实战建议：标题也要信息化。比如把"扫码失败"改成"【首页】Chrome 123 / Win 家庭版：登录模块遮挡二维码导致无法扫描"。
4）Bug 级别：严重程度要"可解释"，而不是"拍脑袋"
通过定义 Bug 级别，可以清楚反映问题严重程度；开发通常也会根据级别来安排处理优先级；同时级别分布也能侧面反映开发质量。
来看常用四级：崩溃、严重、一般、次要。
下面把每一级"典型特征"再压缩成好记版本：
4.1 崩溃（Crash）
- 阻碍开发或测试工作
- 系统崩溃/死机/死循环
- 数据库数据丢失、数据库连接错误、死锁
- 主要功能丧失、核心模块缺失
出现这类问题通常建议：立即中止当前版本测试（风险太大，继续测价值不高）。
4.2 严重（Major）
- 系统主要功能部分丧失
- 数据保存/调用错误、用户数据丢失
- 一级功能菜单不可用但不影响其他功能测试
- 功能与需求严重不符、模块无法启动或调用
- 程序重启/自动退出、接口错误、数值计算统计错误
这类问题：如果不影响其他功能测试，通常仍可继续测试，但要尽快推动修复。
4.3 一般（Normal）
- 功能未完全实现但不影响使用
- 菜单存在缺陷但不影响系统稳定性
常见例子：操作/查询时间长、格式错误、边界条件错误、删除无确认框、表字段过多等。
（这类在真实测试中出现最多）
4.4 次要（Minor）
- 界面/体验/性能细节缺陷、建议类问题
- 不影响功能执行，可优化
常见例子：错别字、界面格式不规范、页面重叠、提示语丢失、排列不齐、光标位置不正确等。
测试初期较多、优先级相对低；测试后期出现较少，发现后应及时处理以免影响交付体验。
重要补充：级别不是"情绪表达"，而是"影响范围 + 业务链路 + 风险后果"的结论。定级要能讲出理由。
5）Bug 生命周期：一个 Bug 从出生到入土，都会经历什么状态？
测试过程中发现 Bug，一般需要在缺陷管理平台创建（Bug 生命周期起源），之后由开发修复、测试回归验证，并持续跟踪直至关闭。
来看状态流转图，非常直观：
常见状态定义如下（按实际协作口径解释）：
- New：新发现的 Bug，尚未评审决定是否指派给开发修改
- Open：确认是 Bug，且认为需要修改，已指派给相应开发
- Fixed：开发已修改并标记为已修复，等待测试回归验证
- Rejected：认为不是 Bug，拒绝修改
- Delay：暂时不需要修改或暂时不能修改，延后处理
- Closed：回归验证通过，关闭 Bug
- Reopen：回归未通过，Bug 仍存在，重新打开交给开发继续修复
还要认识两类"无效 Bug"的典型链路（实际工作里很常见）：
- open → closed
- open → rejected → closed
实战建议：每次从 Fixed 到 Closed，中间那次回归验证是关键动作；回归失败要有证据（复现步骤、环境、日志/截图），否则容易陷入"你那边的问题"。
6）与开发产生争执怎么办：高频现实题的"可操作打法"
测试工作里最常遇到的是和开发的"PK"；更进一步，测试负责人还会与项目经理、产品经理在进度与质量上产生拉扯。遇到争执不要怕，关键是：理性分析 + 有证据地反馈。
下面给出一套从低成本到高成本的处理路径。
6.1 先检查自身：是不是 Bug 描述不清楚？
如果能正确、高质量地录入一个 Bug，基本上已经成功沟通了一大半信息。但总有"书难达意"的时候。
来看建议：当你发现单靠文字很难表达清楚时，提交 Bug 后应尽快主动找相关开发当面/即时沟通，解释刚录入的 Bug，确保开发真正理解，而不是等对方来问。
6.2 站在用户角度抛问题：让对方看到"影响"
争执时，最有效的不是"你必须修"，而是让对方意识到对用户的困扰。来看一句高质量提问：
如果你是用户，你可以接受吗？
这句话的力量在于：把讨论从"我觉得"拉回到"用户影响"。
6.3 Bug 定级要有理有据：不仅看级别，还看链路
定级时不仅参考级别定义，还要考虑 Bug 是否影响流程。并且要注意：用户感知的严重度与团队内部定义可能不同，定级时要站在用户角度综合判断。
6.4 提高技术与业务水平：最好能给出解决思路
资深测试工程师和初级测试工程师的差别之一是：前者往往不仅能指出问题，还能给出解决问题的思路（比如定位方向、可能原因、建议验证方式），更容易建立权威性。
注意边界：可以给思路，但别"喧宾夺主"用命令式要求开发按你的想法修改------否则容易引发对抗。
6.5 仍无法解决：召开 Bug 评审
如果确实是 Bug，友好沟通不能解决，那么就进入成本更高但更"定锤"的方式：Bug 评审。
Bug 评审主要解决两个问题：
1）决定如何处理 Bug
2）分析缺陷产生原因，找出预防对策
评审至少需要项目组多方代表参加：
-
测试代表：提供 Bug 表现、严重程度等信息，并提出处理意见
- 重要提醒：测试不应一味要求修改，因为修改带来回归风险与回归工作量；若时间紧迫且不足以做有效回归，"不修改"有时反而更明智。
-
开发代表：从修改难度与风险出发，评估代价、影响范围、可能引发的风险；若决定修改，需要提出初步方案。
-
产品代表：从整体计划与用户要求出发，给出修改必要性、修改时间点与版本安排建议。
7）总结
- 提 Bug 前：来看五要素是否齐全（版本/环境/步骤/预期/实际）
- 定级时：来看影响是否阻塞流程、是否影响核心功能、用户是否可接受
- 修复后：来看是否回归通过；不通过就 Reopen，并补齐复现证据
- 产生争执：先自查描述 → 用用户影响对齐 → 有理有据定级 → 提供解决思路（不命令） → 必要时评审定锤