Day 2 —— 测试流程与缺陷管理

 

一、软件测试的完整流程

一个标准测试流程走 6 步：

步骤	做什么	产出
1. 需求分析	读懂需求、找出歧义	需求疑问清单
2. 制定测试计划	定范围、排期、人力	测试计划
3. 设计测试用例	按方法写用例	用例文档
4. 执行测试	跑用例、提 Bug	缺陷记录
5. 回归测试	验证修复、查影响	回归结果
6. 测试报告	汇总结果、给结论	测试报告

口诀：析、划、设、行、回、报（分析、计划、设计、执行、回归、报告）。

二、测试计划写什么

核心要素（记住"六定"）：

• 定范围：测什么、不测什么
• 定策略：用什么方法测（功能/接口/性能）
• 定人员：谁负责哪块
• 定进度：什么时候开始、什么时候结束
• 定环境：用什么环境、什么数据
• 定风险：有哪些风险、怎么应对

三、测试用例的要素（背熟）

要素	说明
用例编号	唯一标识，如 TC-LOGIN-001
用例标题	一句话说清测什么
优先级	P0/P1/P2/P3
前置条件	执行前要满足什么
测试步骤	一步步操作
测试数据	用什么账号/输入
预期结果	应该看到什么

口诀：编号标题优先级，前置步骤加数据，最后一条预期果。

好用例的标准：完整、清晰、可执行、可维护。别人照着你的用例能跑出一样的结果，就是好用例。

四、测试用例优先级

级别	含义	例子
P0	核心功能，不通就不能上线	登录成功、下单支付
P1	重要功能，影响主要流程	购物车增删改
P2	一般功能，异常分支	输入校验提示文案
P3	边角功能，次要提示	特殊字符展示

原则：P0 必须 100% 通过，P3 可以用例少一些。

五、什么是缺陷（Bug）

缺陷 = 实际结果 ≠ 预期结果，且是软件本身的问题。

缺陷常见来源：

• 功能没实现 / 实现错了
• 需求理解偏差
• 界面与设计不符
• 性能/安全问题
• 兼容性问题

六、缺陷的生命周期（重点）

新建(New) → 指派(Assigned) → 已修复(Fixed) → 待验证(Resolved)
   → 验证通过 → 关闭(Closed)
   → 验证不通过 → 重新打开(Reopened) → 再修复...
   → 开发认为不是 Bug → 拒绝(Rejected) → 讨论/挂起

口诀：新建指派到修复，待验证来验真假；通过关闭不通过，打回重开再修它；拒绝要拿证据说。

七、缺陷报告怎么写

一份好 Bug 报告要素（六要素）：

要素	要求
标题	简明、概括：模块+现象
复现步骤	一步一步，能照着复现
预期结果	应该是什么
实际结果	实际是什么
环境信息	版本、浏览器、账号
附件	截图/日志/录屏

好标题示例：

• ❌ 差：登录有问题
• ✅ 好：【登录页】输入正确账号密码后点击登录，页面无响应

口诀：标题要有现象，步骤能照着放；预期实际要对上，截图日志附上。

八、缺陷严重程度 vs 优先级

这两个不一样，别混！

概念	含义	例子
严重程度	缺陷本身有多严重	崩溃=致命，文案错=轻微
优先级	多紧急要修	首页崩溃=高，某设置页崩溃=低

 

典型组合：严重程度高、优先级低——比如"修改头像功能崩溃"，崩了很严重，但很少有人用，可以先放着；反过来"首页错别字"，不严重但很显眼，优先级高，马上改。

严重程度	定义	例子
致命	系统崩溃、数据丢失、安全漏洞	下单后钱扣了订单没生成
严重	主功能不可用	无法登录
一般	次要功能异常或结果不对	搜索结果排序错
轻微	界面、文案、提示问题	按钮文字错别字

优先级	含义
高	本轮必须修，不修不能上线
中	本版本内修复
低	可下版本修，或看情况

口诀：严重看影响，优先看紧急；崩溃不一定急，错字也可能急。

九、缺陷统计的常见维度

做测试报告、复盘时经常要统计：

• 按模块：哪个模块 Bug 最多（找重灾区）
• 按严重程度：致命/严重/一般/轻微各多少
• 按状态：已修复/未修复/拒绝/挂起
• 按发现阶段：需求/开发/测试/上线后（越早发现越好）

缺陷收敛趋势：随着版本迭代，Bug 数应该越来越少并趋于稳定——如果一直不收敛，说明质量有问题或改动太大。

十、缺陷处理中的沟通原则

• 提 Bug 前先自查：是不是自己操作错、环境问题、理解偏差
• 描述要客观、有证据：截图、日志、复现步骤
• 开发说"不是 Bug"时，拿需求文档/设计稿说话，不情绪化
• 争议大时拉产品/主管定夺，别自己硬扛
• 修好后及时回归验证并关闭，别让 Bug 挂着

---

📋 小结表（Day 2）

主题	核心要点
测试流程	析、划、设、行、回、报
测试计划	六定：范围/策略/人员/进度/环境/风险
用例要素	编号、标题、优先级、前置、步骤、数据、预期
优先级	P0 必须 100% 通过
缺陷定义	实际 ≠ 预期
生命周期	新建→指派→修复→验证→关闭/重开/拒绝
Bug 报告	标题、步骤、预期、实际、环境、附件
严重 vs 优先	严重看影响，优先看紧急

🔑 口诀

流程六步记：析划设行回报；计划六定全，用例七要素；缺陷生命走一圈，新建修复到关闭；严重优先两回事，报告六项不能少。

一句话记：用例可执行、Bug 可复现、流程可追溯。

---

✍️ 练习题（Day 2）

1. 软件测试流程有哪 6 个步骤？
2. 一条完整的测试用例包含哪 7 个要素？
3. 判断题：严重程度高的 Bug，优先级一定也高。（对/错？举例说明）
4. 把下面这个差标题改写成好的 Bug 标题，并补全预期/实际结果：

   购物车有问题

5. 简答：开发认为你提的 Bug 不是 Bug，你会怎么处理？（说 3 步）

---