T06
测试与质量
⭐⭐⭐
⏱ 约 45 分钟
集成测试
Integration Test Plan
💡 适用场景: 系统验证、上线前检验
📄 T06: Integration Test Plan(集成测试规划) 其他
⭐⭐⭐ 中级 | 验证多个组件协同工作
💡 核心概念 核心概念
集成测试验证:
- 组件间的交互 - 各个模块能否正确通信
- 数据流 - 数据在系统中正确流转
- 外部集成 - 与数据库、API、消息队列等的集成
- 端到端流程 - 完整的业务流程能否执行
与单元测试的区别:
- 单元测试:独立测试单个函数或类
- 集成测试:测试多个组件协同工作
- 端到端测试:从用户角度测试完整流程
✅ 最佳实践 最佳实践
🎯 原则1: 分层测试
- API层:测试各个端点
- 业务层:测试业务逻辑
- 数据层:测试数据库操作
- 外部集成:测试第三方服务集成
🎯 原则2: 使用测试数据库
- 不要用生产数据库
- 使用轻量级数据库(SQLite、H2)或Mock
- 每个测试运行前重置数据
🎯 原则3: 测试关键流程
- 重点测试核心业务流程
- 边缘情况用单元测试
- 不需要测试所有组合
🎯 原则4: 保持测试速度
- 避免真实网络调用,使用Mock
- 使用内存数据库
- 并行执行测试
📄 集成测试场景 其他
场景1: API集成测试
场景: 测试REST API的完整请求-响应流程
Prompt:
为我的Spring Boot应用设计集成测试套件。
应用:用户管理系统
API端点:
1. POST /api/users - 创建用户
2. GET /api/users/{id} - 获取用户
3. PUT /api/users/{id} - 更新用户
4. DELETE /api/users/{id} - 删除用户
要测试的场景:
1. 成功创建用户
2. 用户已存在时创建失败
3. 获取不存在的用户返回404
4. 更新用户成功
5. 删除用户后无法获取
要求:
1. 使用@SpringBootTest
2. 使用MockMvc或RestTemplate
3. 每个测试使用独立的测试数据库
4. 测试数据在每个测试前重置
请生成完整的集成测试类。
场景2: 数据库集成测试
场景: 测试DAO/Repository层与数据库的交互
Prompt:
为我的数据访问层编写集成测试。
实体:
- User (id, name, email, created_at)
- Order (id, user_id, amount, status)
Repository需要测试:
1. save(User) - 保存用户
2. findById(long) - 查询用户
3. findByEmail(String) - 按邮箱查询
4. delete(User) - 删除用户
5. findUserOrders(long) - 查询用户订单
要求:
1. 使用[数据库]作为测试数据库
2. 每个测试前初始化数据
3. 测试成功和失败的场景
4. 验证外键关系
请提供:
1. 测试数据的初始化脚本
2. 完整的测试用例
场景3: 业务流程集成测试
场景: 测试完整的业务流程
Prompt:
为电商订单处理流程设计集成测试。
流程:
1. 用户选择商品 → 加入购物车
2. 用户结账 → 检查库存
3. 库存充足 → 创建订单
4. 订单创建后 → 扣减库存
5. 支付成功 → 更新订单状态
6. 发送订单确认邮件
需要Mock的服务:
- PaymentService (真实调用太贵)
- EmailService (避免发真实邮件)
- 保持 InventoryService 真实(关键业务)
要测试的场景:
1. 正常流程(成功下单)
2. 库存不足(应该失败)
3. 支付失败(应该回滚)
4. 邮件发送失败(不应该影响订单)
请给出:
1. 测试数据准备脚本
2. 完整的测试代码
3. Mock配置
场景4: 外部服务集成测试
场景: 测试与第三方API的集成
Prompt:
为支付服务集成设计测试。
集成的服务:Stripe Payment API
要测试的场景:
1. 成功扣款
2. 卡被拒绝
3. API超时
4. 网络错误
要求:
1. Mock Stripe API(使用WireMock或Testcontainers)
2. 测试成功路径
3. 测试各种失败场景
4. 验证重试逻辑
5. 测试幂等性(同一个请求不会多次扣款)
使用[框架]的WireMock模拟Stripe。
📄 集成测试工具 其他
| 工具 | 用途 | 特点 |
|---|---|---|
| WireMock | Mock HTTP服务 | 强大灵活,支持复杂场景 |
| Testcontainers | Docker容器测试 | 真实环境,可靠性高 |
| MockServer | Mock API | 易于配置,好用 |
| Selenium | 端到端Web测试 | 模拟真实用户 |
| RestAssured | REST API测试 | 简洁的断言DSL |
📄 集成测试执行策略 其他
测试金字塔:
- 单元测试 70% - 快速反馈
- 集成测试 20% - 覆盖关键场景
- 端到端测试 10% - 验证核心流程
执行频率:
- 提交前:关键路径集成测试
- CI流程:所有集成测试
- 夜间:完整集成+端到端测试
- 上线前:完整测试套件
📄 🎓 下一步 其他
- 集成测试失败 → T03: Bug Diagnosis
- 集成测试代码质量 → T07: Code Review
- 端到端测试 → T06 的进一步扩展
💬 Prompt 模板 (4)
集成测试 - Prompt 1
为我的Spring Boot应用设计集成测试套件。
应用:用户管理系统
API端点:
1. POST /api/users - 创建用户
2. GET /api/users/{id} - 获取用户
3. PUT /api/users/{id} - 更新用户
4. DELETE /api/users/{id} - 删除用户
要测试的场景:
1. 成功创建用户
2. 用户已存在时创建失败
3. 获取不存在的用户返回404
4. 更新用户成功
5. 删除用户后无法获取
要求:
1. 使用@SpringBootTest
2. 使用MockMvc或RestTemplate
3. 每个测试使用独立的测试数据库
4. 测试数据在每个测试前重置
请生成完整的集成测试类。
集成测试 - Prompt 2
为我的数据访问层编写集成测试。
实体:
- User (id, name, email, created_at)
- Order (id, user_id, amount, status)
Repository需要测试:
1. save(User) - 保存用户
2. findById(long) - 查询用户
3. findByEmail(String) - 按邮箱查询
4. delete(User) - 删除用户
5. findUserOrders(long) - 查询用户订单
要求:
1. 使用[数据库]作为测试数据库
2. 每个测试前初始化数据
3. 测试成功和失败的场景
4. 验证外键关系
请提供:
1. 测试数据的初始化脚本
2. 完整的测试用例
集成测试 - Prompt 3
为电商订单处理流程设计集成测试。
流程:
1. 用户选择商品 → 加入购物车
2. 用户结账 → 检查库存
3. 库存充足 → 创建订单
4. 订单创建后 → 扣减库存
5. 支付成功 → 更新订单状态
6. 发送订单确认邮件
需要Mock的服务:
- PaymentService (真实调用太贵)
- EmailService (避免发真实邮件)
- 保持 InventoryService 真实(关键业务)
要测试的场景:
1. 正常流程(成功下单)
2. 库存不足(应该失败)
3. 支付失败(应该回滚)
4. 邮件发送失败(不应该影响订单)
请给出:
1. 测试数据准备脚本
2. 完整的测试代码
3. Mock配置
集成测试 - Prompt 4
为支付服务集成设计测试。
集成的服务:Stripe Payment API
要测试的场景:
1. 成功扣款
2. 卡被拒绝
3. API超时
4. 网络错误
要求:
1. Mock Stripe API(使用WireMock或Testcontainers)
2. 测试成功路径
3. 测试各种失败场景
4. 验证重试逻辑
5. 测试幂等性(同一个请求不会多次扣款)
使用[框架]的WireMock模拟Stripe。