缺陷定位基础：理解缺陷生命周期、Bug的严重等级与优先级、缺陷报告的核心要素
做测试这些年，我见过太多人一上来就闷头找Bug。
结果呢？找到的Bug要么说不清楚，要么开发看不懂，要么修好了又复现。
说白了，缺陷定位这件事，光靠蛮力不行。你得先搞清楚几个基础概念。
缺陷生命周期：Bug从生到死的完整旅程
一个Bug从被发现到最终关闭，会经历几个固定阶段。我个人习惯把这个过程叫做「Bug的七步路」。
- 新建（New）：测试人员提交缺陷报告。这时候Bug刚出生，状态是待确认。
- 已确认（Confirmed）：开发或测试负责人确认这是个有效Bug。嗯，这一步很关键，我见过不少「假Bug」在这里被拦下来。
- 已分配（Assigned）：Bug被指派给具体的开发人员。谁写的代码谁负责修，天经地义。
- 修复中（In Progress）：开发正在改代码。这时候你可以去喝杯咖啡，但别走太远。
- 已修复（Fixed）：开发提交了修复代码。注意，这不代表Bug真的没了。
- 已验证（Verified）：测试人员重新测试，确认Bug确实被修好了。我在项目中遇到过好几次「修复后反而引出新Bug」的情况，所以这步我从不跳过。
- 已关闭（Closed）：Bug确认无误，正式归档。如果后续又复现，那就重新打开。
核心要点：缺陷生命周期不是死流程。它是一套沟通机制。每个状态变化，都意味着有人需要做点什么。
我的小技巧：在Bug状态流转时，每次变更都附上一句简短说明。比如「已分配 - 这个Bug和登录模块的校验有关，建议优先处理」。开发看了心里有数，你也不用反复解释。
Bug的严重等级与优先级：别把「天塌了」和「指甲盖掉了」混为一谈
这两个概念，很多人搞混。我刚开始做测试时也犯过这个错。
严重等级，指的是Bug对系统造成的破坏程度。优先级，指的是Bug需要被修复的紧急程度。
你想想看，一个严重等级很高的Bug，如果它只在极端条件下出现，优先级可能并不高。反过来，一个严重等级很低的Bug，比如首页的Logo显示歪了，优先级可能非常高——因为老板明天要演示。
| 严重等级 | 定义 | 举例 |
|---|---|---|
| 致命（Critical） | 系统崩溃、数据丢失、核心功能不可用 | 用户支付后金额未扣除，但订单显示已支付 |
| 严重（Major） | 主要功能异常，但有临时替代方案 | 搜索功能无法使用，但可以通过分类导航找到商品 |
| 一般（Minor） | 功能可用，但体验或表现不符合预期 | 按钮颜色与设计稿不一致 |
| 轻微（Trivial） | 不影响功能，仅影响美观或易用性 | 某个提示文字有错别字 |
| 优先级 | 定义 | 适用场景 |
|---|---|---|
| 紧急（Urgent） | 立即修复，否则阻塞后续工作或发布 | 线上环境的核心流程崩溃 |
| 高（High） | 尽快修复，影响主要用户场景 | 新功能上线后发现严重逻辑错误 |
| 中（Medium） | 在正常迭代周期内修复 | 非核心页面的样式问题 |
| 低（Low） | 有时间再修，不影响当前版本 | 某个不常用功能的性能优化 |
避坑指南：我曾经把一个「严重等级为致命、优先级为低」的Bug直接标记为「高优先级」提交上去。结果开发团队连夜加班修复，第二天发现那个Bug只在特定浏览器版本下出现，而且用户占比不到0.1%。从那以后，我每次提交前都会问自己一句：「这个Bug真的需要现在修吗？」
缺陷报告的核心要素：让开发一眼看懂你的Bug
一份好的缺陷报告，应该像一份清晰的「犯罪现场报告」。开发拿到手，不需要再问你任何问题，就能直接开始排查。
我个人总结的「六要素法」：
- 标题：一句话说清楚问题。格式建议「模块名 - 具体现象」。比如「登录模块 - 输入正确密码后提示密码错误」。
- 前置条件：复现Bug需要满足哪些条件。比如「用户已注册但未激活邮箱」。
- 复现步骤：一步一步写清楚，从打开页面开始。别跳步，别省略。我见过有人写「点击按钮报错」，结果开发试了三次都没复现——因为漏了「先勾选同意协议」这一步。
- 实际结果：Bug发生后的真实表现。截图、日志、报错信息，能贴的都贴上。
- 预期结果：系统应该表现为什么样子。这个很重要，不然开发可能觉得「这样也行」。
- 环境信息：操作系统、浏览器版本、设备型号、网络环境等。同一个Bug在不同环境下表现可能完全不同。
一个合格的缺陷报告示例：
标题：【支付模块】使用支付时，点击「确认支付」后页面白屏
前置条件：用户已登录，账户余额充足，网络正常
复现步骤：
1. 打开商品详情页
2. 点击「立即购买」
3. 选择「支付」
4. 点击「确认支付」
实际结果：页面白屏，控制台报错：Uncaught TypeError: Cannot read property 'appId' of undefined
预期结果：跳转到支付二维码页面
环境：Chrome 120.0.6099.71，Windows 11，支付SDK版本 3.2.1我的经验：写复现步骤时，把自己当成一个「完全不懂这个功能的新人」。每一步都写清楚，包括「点击哪个按钮」「输入什么内容」「等待几秒」。这样开发复现时就不会因为「我以为你知道」而浪费时间。
本章知识体系
下面这张图，是我梳理的缺陷定位基础的核心逻辑。你可以把它当作一张「思维导图」来看。
这张图把三个核心知识点串在了一起。缺陷生命周期告诉你Bug怎么流转，严重等级与优先级告诉你Bug怎么分类，缺陷报告要素告诉你Bug怎么描述。三者缺一不可。
嗯，基础打牢了，后面讲定位技巧时你才能跟得上。
可可精品资料库