T06 测试与质量 ⭐⭐⭐ ⏱ 约 45 分钟

集成测试

Integration Test Plan

💡 适用场景: 系统验证、上线前检验

📄 T06: Integration Test Plan(集成测试规划) 其他

⭐⭐⭐ 中级 | 验证多个组件协同工作

💡 核心概念 核心概念

集成测试验证:

  1. 组件间的交互 - 各个模块能否正确通信
  2. 数据流 - 数据在系统中正确流转
  3. 外部集成 - 与数据库、API、消息队列等的集成
  4. 端到端流程 - 完整的业务流程能否执行

与单元测试的区别:

  • 单元测试:独立测试单个函数或类
  • 集成测试:测试多个组件协同工作
  • 端到端测试:从用户角度测试完整流程

最佳实践 最佳实践

🎯 原则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。