从Scrum迭代到测试闭环 —— 一个测试新人的完整执行笔记

前言：关于Scrum迭代开发模型

我们用的开发模式

我们团队用的是Scrum敏捷迭代开发模型。简单说就是：

• 每轮版本固定周期（我们一般是2周），规划好本次迭代要做的需求
• 需求拆成用户故事，排进迭代 backlog待办池
• 开发按故事点估时、领任务、按计划推进
• 每日站会同步进度、暴露风险、对齐预期
• 迭代结束交付可上线的产品增量

Scrum里最重要的三件事

1. 承诺

• 团队承诺本次迭代要完成哪些需求
• 每个成员承诺自己负责的任务按时交付
• 承诺不是嘴上说说，是对团队的责任——说好了做哪些，就要做到

2. 透明

• 进度透明：做到哪了、卡在哪了，所有人都知道
• 风险透明：有问题提前爆，不等最后才说
• 数据透明：bug数、完成率、通过率，全量可查

3. 检视与适应

• 每轮迭代结束要复盘：做得好不好？哪里能改进？
• 下一轮迭代针对问题调整
• 不重复踩同一个坑

Scrum团队里测试的角色

传统理解测试就是“最后一道把关”，但在Scrum里，测试不是最后一环等着接活的人——测试是质量信息的提供者。每轮迭代测试结束，我要给团队一个清晰结论：这个版本质量怎么样、能不能上、有什么风险。这个结论是团队决策上线与否的重要依据，所以我说的每句话、每个数据，都要经得起追问。

我们的工作方式：边开发边测试

我们不是等开发全部做完才提测，而是开发做完一个需求，我就测一个需求，不囤积。这样有几个好处：

• bug早发现早修，不堆积到后期
• 开发对刚写完的代码还有印象，修bug成本低
• 不会出现最后一周测不完的情况
• 每日站会我能同步真实的测试进度

对应的节奏是：

• 迭代第一周周四：用例评审
• 开发完成后：立即开始测该需求
• 迭代后半段：整体回归、收尾报告

理解了Scrum的运作方式和我们的工作节奏，就能理解我这套测试执行方法为什么这么设计：

• 承诺对应我“圈定版本范围、摸清开发进度”——先搞清楚团队承诺了什么，我才能承诺我测什么
• 透明对应我“中途爆风险、群里发摘要、@对人”——让所有信息流动起来，不藏不掖
• 检视与适应对应我“每轮结束复盘、生产bug沉淀”——这轮不好下轮改，闭环
• 边开发边测试对应我“开发做完就测、不等提测”——保证节奏不积压

下面就是我自己每轮迭代照着做的完整流程。不是什么高大上的理论，就是在这个框架下，一步一步把事情做踏实。

第一章 迭代开始——圈定范围，摸清家底

1.1 先搞清楚这个迭代到底做什么

• 禅道里拉一下本次迭代关联的需求列表
• 自己过一遍每个需求，知道大概什么功能、涉及哪个模块
• 一段话总结出来：这个迭代主要做了什么（写进报告里用）

1.2 摸清每个开发的开发进度

具体怎么摸：

• 不是等开发主动告诉你，而是主动去问、去盯
• 提测前1-2天，找每个开发确认：
  • 你负责的模块做完没有？
  • 有没有延期风险？
  • 有没有需求变更导致返工？
  • 有没有依赖别人的接口还没好？
• 在禅道里看任务状态：已完成/进行中/未开始
• 区分三件事记清楚：
  • 计划做的（迭代 backlog 里规划的）
  • 实际做完的（开发真的提交了的）
  • 没做完延期的（说了要做但没做完的）

为什么做这一步：

• 方便后续排测试计划——开发做完一个我就测一个
• 领导问“谁还没做完”能立刻答上来
• 知道自己要测的范围到底有多大
• 对应Scrum的承诺原则——团队承诺了什么，实际交付了什么，我心里要有数

1.3 迭代开始前自己建一个版本记录文档

记录以下信息：

• 版本号 / 迭代名称
• 提测日期 / 预期上线日期
• 本次涉及的需求列表（禅道需求ID）
• 涉及模块
• 模块对应开发责任人（谁写的代码找谁）
• 测试环境地址 / 账号 / 测试数据准备情况

第二章 用例编写与评审（迭代第一周周四）

2.1 用例编写

什么时候写：

• 迭代开始后，基于本次迭代的需求文档/用户故事编写测试用例
• 开发边写代码，我边写用例，两边并行

用例要写什么：

• 每条用例覆盖一个明确场景（正常流程 + 异常流程 + 边界值 + 权限/状态组合）
• 用例包含：前置条件、操作步骤、预期结果
• 关联禅道里的需求ID，保证可追溯

用例数量控制：

• 不贪多，覆盖全就行
• 核心功能写细一点，边缘功能写主干场景
• 时间紧的时候，先保证主流程和核心异常场景

2.2 用例评审（固定时间：迭代第一周周四）

评审的目的：

• 让产品、开发、测试三方对齐认知
• 确认我理解的需求是对的
• 确认我覆盖的场景没有遗漏
• 提前发现需求理解偏差，不等测完才发现“咱们理解不一样”

评审前自己先过一遍：

• 每条用例我自己能讲清楚“为什么这么写”
• 对照需求文档，确保覆盖了所有验收标准
• 标注出自己拿不准的场景，评审时重点问

评审时怎么做：

• 按模块逐条过用例
• 产品确认需求理解是否正确
• 开发确认实现逻辑是否符合预期
• 有争议当场讨论清楚，不把疑问留到测试执行阶段
• 评审过程中发现的遗漏当场补

评审后的动作：

• 更新用例（根据评审意见修改/补充）
• 禅道里维护好最终版本
• 评审结论同步到群里（@所有团队成员）

同步格式：
用例评审已完成，本次迭代共X条用例，覆盖X个需求，评审意见已修改，用例已更新到测试用例文档/禅道。

2.3 为什么用例评审这么重要

• 不评审，自己理解错了需求，测了也白测
• 不评审，开发按自己的理解写代码，测试按自己的理解写用例，两边对不上
• 不评审，漏了场景没人发现，等测完了才说“这个怎么没测”
• 评审不是走过场，是测试质量的第一道防线

第三章 测试执行——边开发边测试，开发完一个测一个

3.1 工作节奏

不等全部提测，开发做完一个需求我就测一个。

具体操作：

• 每日站会关注开发进度，谁的任务状态变成“已完成/待测试”，主动问一句“这个可以测了吗？”
• 开发说可以了，马上开始测这个需求
• 测完出bug，提禅道，@对应开发
• 开发修好了，马上回归验证
• 验证通过，这个需求就算测完了

为什么要这样：

• bug早发现早修，开发对刚写完的代码还有印象，修得快
• 不会出现最后一周bug成堆、测不完的情况
• 迭代后半段时间留给整体回归，而不是还在测新功能
• 每日站会我能说出准确的测试进度

3.2 每天做的事

早上（站会前）：

• 看禅道bug列表，有哪些修好了待回归
• 优先回归已修复的bug，关掉确认修复的
• 没修好的问开发今天能不能好
• 准备好站会要同步的内容

站会上同步：

• 昨天测了什么模块、出了几个bug
• 今天计划测什么
• 有没有阻塞/风险需要同步

白天：

• 按用例执行测试
• 新bug提禅道
• 开发做完了新需求，马上开始测
• 遇到阻塞立刻处理（不能等）

下班前：

• 估算一下整体进度（大概测了百分之多少）
• 明天要测什么模块，心里有数

3.3 风险提前说

什么算“风险”：

• 进度风险：按当前速度，可能赶不上上线时间
• bug风险：出了严重/致命bug，功能整个走不通
• 环境问题：测试环境挂了、数据没了、连不上了
• 开发延期：该完成的没完成，导致我积压了测试任务
• 需求变更：临时改了需求，用例要重写，评审要重开

怎么同步：

• 不等收尾才说，中途就在群里同步
• 格式：

  同步一个风险：XXX模块目前发现XX问题/进度滞后XX天/环境XXX异常
  影响：会导致XXX没法测
  已找XXX开发确认，预计XXX时间恢复
  有进展再同步

目的就一个：让所有人知道当前真实情况，别到最后一天才说“测不完”。透明不是等别人问，是主动同步。

3.4 不照搬需求文档

• 需求文档/用户故事是“计划要做成什么样”
• 实际开发做出来的可能不一样（有偏差、有遗漏、有变更）
• 测试过程中实时更新自己心里那本账：实际做完的到底是哪些
• 报告里只写实际测了的，不写计划要做但实际没做的

第四章 禅道bug管理——提bug、追修复、做闭环

4.1 提bug的规范

一条合格的bug记录包含：

• 标题：[模块名] 一句话描述问题
• 严重程度：致命/严重/一般/建议（自己先打个标）
• 优先级：紧急/高/中/低
• 复现步骤：别人照着能做出来（1. 2. 3. 一步步写清楚）
• 实际结果：现在是什么样
• 预期结果：应该是什么样
• 截图/录屏：有就贴，一图胜千言
• 所属模块：选对模块，方便统计和分配
• 指派给：对应的开发责任人
• 关联需求：关联禅道里的需求/故事ID，方便追溯

提bug的潜规则：

• bug描述清楚，开发不用来回问“怎么复现”，节省大家时间
• 复现步骤写详细，不是为了开发，是为了以后自己回来再看也能想起来

4.2 bug跟进流程

每天看禅道：

• 今天新提了多少bug
• 开发已解决多少
• 待验证多少
• 已关闭多少

跟进节奏：

分模块划责任人：

• 禅道里每个bug都有模块字段
• 每个模块绑定对应开发责任人
• 模块bug、模块责任人、具体整改跟进@对应开发人员
• 责任到人，不模糊

4.3 待办闭环

• 谁修什么bug → 修好我回归
• 修好了就关闭
• 遗留bug记录跟踪，不丢不忘
• 每轮结束清理一遍禅道bug状态，确保没有悬空的

第五章 迭代结束出报告——数据化、风险说透、@对人

5.1 报告结构（固定模板，每轮套用）

第一部分：迭代范围

• 一段话总结：这个迭代主要做了什么
• 涉及哪些需求（列需求ID/模块名和完整需求描述）
• 计划做的 vs 实际做完的 vs 没做完延期的（三列对比）

第二部分：测试结果（全部数据化）

第三部分：迭代bug风险

根据模块列出所有bug的风险等级，其中包含：

• 必须马上修复的bug：列出来，说明为什么
• 可以后续迭代优化的：列出来，说明为什么可以放
• 我自己的专业测试意见：这个版本能不能上？有什么顾虑？建议怎么决策？

第四部分：回归情况

• 本次回归了哪些老模块（列出来）
• 哪些模块没回归、原因是什么
• 没回归的模块存在什么潜在风险（要如实写）

第五部分：待办闭环

• 待修复bug清单（谁修什么、计划什么时候修好）
• 修复后由我回归验证
• 遗留bug持续跟踪计划

5.2 群里发报告（固定@人）

操作方式：

1. 完整报告上传附件
2. 群里发重点摘要，不贴全文

@规则固定：

• @项目leader、@管家master、@产品经理pm：版本范围、整体进度、测试结果、版本风险、整体结论
• @开发a、@开发b：模块bug、模块责任人、具体整改跟进

摘要范例：

@项目leader、@管家master、@产品经理pm 本次迭代测试报告已出，摘要如下：

【范围】本次迭代主要覆盖XX、XX模块，计划需求X个，实际完成X个，X个延期
【结果】用例X条，发现bug X个（致命X严重X一般X），通过率X%
【风险】X个bug建议上线前修复（已列清单），X个可后续迭代
【结论】我的建议是XXX

@开发a @开发b 模块bug已分责任人，待修复清单见报告附件，请今天确认修复计划

完整报告见附件

第六章 上线当天——冒烟验证，快速响应

6.1 上线后立刻做的事

• 上线后半小时内，走一遍核心流程冒烟
• 核心流程怎么定：登录 → 核心功能入口 → 新增/编辑/提交 → 数据落库
• 确认主流程能通，再深入看关键模块

6.2 同步线上情况

没问题时：

线上冒烟已过，核心流程（登录→XX→XX）验证通过，无异常。

有问题时：

线上冒烟发现XXX异常，现象是XXX，影响范围XXX，已通知开发XXX紧急处理，有新进展同步。

6.3 线上问题处理流程

• 确认现象、影响范围、影响用户
• 同步给开发紧急修复
• 修复后验证
• 同步修复结果

第七章 生产bug管理

7.1 所有线上bug全部记录

• 不管大小、不管是不是自己的漏测、不管是不是环境问题
• 全部记录在一个地方（我单独建了一个“线上bug沉淀表”）

记录字段：

• 发现日期
• 本次迭代版本号
• bug所属模块
• bug现象描述
• 影响范围
• 根因（开发原因/测试漏测/需求问题/环境问题）
• 发现渠道（用户反馈/监控告警/自己发现）
• 反思总结
• 举一反三设计该场景测试用例

7.2 每条生产bug必须自己复盘总结

复盘的思考路径：

1. 这个bug是怎么出去的？我的测试为什么没拦截到？
2. 是这个场景我没考虑到？还是考虑到了但没写用例？还是写了用例但执行漏了？
3. 这个场景属于哪一类遗漏？（边界值/异常场景/数据状态/并发/权限/接口超时/配置项/历史数据兼容……）
4. 我的测试用例里有没有覆盖这个场景？
5. 如果有，为什么没测到？如果没有，马上补上

输出物：

• 补的用例（更新到测试用例文档/禅道用例库）
• 补的场景（加到后续迭代回归清单）
• 同类场景排查（检查其他模块有没有类似盲区）

7.3 生产bug必须沉淀

• 每条线上bug都是自己的“踩坑记录”
• 每轮迭代结束翻一遍
• 同类坑不踩两次就是进步
• 沉淀多了，自然知道哪些场景容易漏，下次优先覆盖

第八章 自动化工作（空闲时间做）

8.1 做什么

• 不要贪多，不吹要做全量
• 挑一个最常回归的模块，把核心用例转成自动化
• 做就做完整一个模块，不半途而废

8.2 做完主动展示

• 跑通了发群里给开发看、给leader、给测试组长看
• 问一句：有没有优化建议？
• 接收专业意见，持续优化

8.3 稳步成长

• 不画大饼，不说“我要把全部用例自动化”
• 只做实事，一个模块一个模块来
• 每轮迭代复盘时记录自动化新增进度

第九章 每轮迭代结束必须复盘

9.1 复盘问题清单

1. 本次测试哪里不足？
2. 哪些场景考虑不全？
3. 踩了什么坑？
4. 自动化新增进度？
5. 生产漏测问题整改优化？

9.2 复盘产出

• 下轮迭代要改进的点（写下来，下轮迭代开始前看一遍）
• 用例库更新
• 回归测试清单更新

第十章 自己的避雷针

• 不找借口、不说自己只会手工测试
• 不吹牛、不瞎承诺大目标
• 客观说事，不甩锅
• 不止堆数据，必须有自己的判断
• 所有问题走完完整流程：发现→同步→跟进→复盘→闭环

写在最后

❗❗❗向上管理很重要，它不是谄媚，也不是讨好，而是完整展示自己的工作量与能力，目的是让领导看见：
✅我靠谱
✅我用心
✅我在进步
✅我有思考
✅我有价值
✅不是只会点点点测试的小白

对应到Scrum：承诺的事我做到，透明同步所有信息，每轮检视与适应改进自己。

每轮对着过一遍，保证不漏事、不被动、心里有数。

一句话总结：把整套事情闭环做好，让领导看到你的进步。 这套东西不高级，就是踏实做。

❌ 很多新人误以为向上管理就是拍马屁。
⬆️向上管理的本质：你埋头干活，但领导不会时时刻刻盯着你的全部工作。向上管理，就是把你实实在在做过的事、遇到的困难、取得的进步有效传递出去，争取资源、规避风险，不是虚的客套。