# 测试驱动开发（TDD）示例
<div style="margin:24px 0;border:1px solid #E3F2FD;border-radius:8px;background:#FAFAFA;overflow:hidden;"><div style="display:flex;align-items:center;gap:12px;padding:12px 20px;background:linear-gradient(135deg,#E3F2FD,#BBDEFB);"><span style="width:36px;height:36px;background:#2196F3;color:#fff;border-radius:50%;display:inline-flex;align-items:center;justify-content:center;font-weight:bold;font-size:16px;flex-shrink:0;">第一步：</span><span style="font-size:17px;font-weight:700;color:#1565C0;">写测试用例</span></div><div style="padding:16px 20px;"><p>def test_calculate_discount():</p>
<p>assert calculate_discount(100, 10) == 90  # 满100减10</p>
<p>assert calculate_discount(50, 10) == 50   # 不满100不减</p>
<p>assert calculate_discount(200, 20) == 180 # 满200减20</p>
<h1 id="第二步写实现代码" style="color:#1565C0;border-bottom:2px solid #E3F2FD;padding-bottom:8px;margin-top:32px;">第二步：写实现代码</h1>
<p>def calculate_discount(amount, discount):</p>
<p>if amount >= 100:</p>
<p>return amount - discount</p>
<p>return amount</p></div></div>
## 02 Scrum中的测试角色：你不是“质检员”，你是“质量教练”

很多测试人员进Scrum团队，第一件事是抱怨：“开发代码质量太差了，我天天加班测Bug。”

错了。你的角色不是“擦屁股的”，而是“教人上厕所的”。

### 测试在Scrum中的3个核心角色

**角色1：用户代言人**
- 你比开发更懂用户需求
- 你写的测试用例就是用户行为
- 你拒绝接受“技术实现没问题但用户用不了”的功能

**角色2：质量教练**
- 教开发写单元测试
- 教产品经理写可测试的用户故事
- 教团队做代码审查

**角色3：流程守护者**
- 监控Sprint速率
- 跟踪缺陷密度
- 推动持续改进

### 面试话术：一句话让你脱颖而出

面试官：“你在Scrum团队里主要做什么？”

普通回答：“我负责测试所有功能，写测试用例，提Bug。”

优秀回答：“我负责确保团队在Sprint结束前交付可用的增量。我会参与每日站会，在Sprint计划会上评估用户故事的可测试性，在Sprint评审会上验证演示功能。我的目标是让Bug在开发阶段就被发现，而不是等到测试阶段。”

<blockquote style="margin:16px 0;padding:12px 20px;background:#F5F5F5;border-left:4px solid #9E9E9E;color:#616161;font-style:italic;border-radius:0 6px 6px 0;">**你不是在找Bug，你是在帮团队不制造Bug。**</blockquote>

### 数据对比：角色转变的效果

某互联网公司转型敏捷测试后，数据如下：

| 指标 | 转型前 | 转型后 | 变化 |
|------|--------|--------|------|
| 缺陷密度 | 5.2个/KLOC | 1.8个/KLOC | 下降65% |
| 测试周期 | 10天 | 3天 | 缩短70% |
| 回归测试时间 | 40小时 | 8小时 | 减少80% |
| 上线后Bug | 12个/月 | 3个/月 | 减少75% |

你不需要背这些数字，但你需要理解：角色转变带来的不是更多工作，而是更少Bug、更快交付。

---

## 03 Scrum测试流程：从Sprint计划到回顾的每一步

面试官问“Scrum测试流程”，不是让你背Sprint的5个会议。他要知道：你在每个环节具体做什么。

### Sprint计划会：测试介入的起点

**你的任务：**
- 评估用户故事的可测试性
- 估算测试工作量
- 识别测试风险

**面试话术：**
“在Sprint计划会上，我会检查每个用户故事是否满足INVEST原则（Independent, Negotiable, Valuable, Estimable, Small, Testable）。如果故事不可测试，我会要求产品经理补充验收标准。”

### 每日站会：测试的15分钟战争

**你的任务：**
- 汇报测试进度
- 暴露测试阻塞
- 同步测试发现

**面试话术：**
“我每天站会回答三个问题：昨天我完成了哪些测试？今天我要测试什么？我遇到了什么阻碍？如果开发提交的代码破坏了之前的测试，我会立刻在站会上提出。”

### Sprint评审会：测试的“验收时刻”

**你的任务：**
- 演示测试结果
- 展示自动化测试报告
- 验证功能是否满足DoD（Definition of Done）

**面试话术：**
“在评审会上，我会运行自动化回归测试，展示通过率。如果功能有缺陷，我会现场演示Bug复现步骤。我的目标是让产品经理和干系人看到真实的质量状态。”

### Sprint回顾会：测试的“改进引擎”

**你的任务：**
- 分析缺陷根因
- 提出流程改进建议
- 制定下个Sprint的测试策略

**面试话术：**
“回顾会上，我会用鱼骨图分析缺陷根因。如果发现80%的Bug来自同一个模块，我会建议开发对该模块进行重构，并增加单元测试覆盖率。”

<blockquote style="margin:16px 0;padding:12px 20px;background:#F5F5F5;border-left:4px solid #9E9E9E;color:#616161;font-style:italic;border-radius:0 6px 6px 0;">**回顾不是为了追责，是为了让下个Sprint更轻松。**</blockquote>

### 流程图：Scrum测试流程全貌

---

## 04 面试官最想听的3个敏捷测试关键词

### 关键词1：自动化测试

**为什么重要：**
Scrum的Sprint只有2-4周，手动测试根本来不及。自动化测试是敏捷测试的基石。

**面试话术：**
“我负责搭建自动化测试框架，使用Selenium做UI测试，使用pytest做API测试，使用Jenkins做持续集成。每次代码提交，自动化测试在15分钟内跑完，覆盖80%的回归用例。”

**代码示例：自动化测试框架**