集成测试用例的核心目标
集成测试不是验证单个模块能不能跑通，而是看多个模块拼在一起后，数据能不能正确流转，接口能不能正常交互。比如你开发一个电商系统，下单、扣库存、生成订单这三个功能分别由不同人完成，集成测试就是检查当你点击“提交订单”时，库存是不是真的减了，订单表里是不是多了条记录。
明确测试范围和接口边界
写用例前先搞清楚哪些模块要集成。常见的有：前端与后端、服务与数据库、微服务之间的调用。画一张简单的调用图，标出输入输出。比如用户登录功能，前端传 token 给订单服务，订单服务再调用户服务验证权限，这条链路里的每个交接点都是测试点。
设计测试场景的常见类型
正常流程必须覆盖，但更要关注异常情况。比如两个服务通过 HTTP 通信，除了测试返回 200 的成功场景，还得模拟 404、500 或超时的情况，看看调用方会不会卡死或抛出合理错误。
另一个典型例子是数据库事务。假如支付成功后要更新订单状态和记账流水，这两个操作必须在同一个事务里。测试用例就得验证：如果记账失败，订单状态是否也回滚，而不是只改了一半。
输入组合与数据流向验证
模块集成后，数据可能被修改、转换或丢失。比如 A 模块传的是时间戳（1678886400），B 模块期望的是日期字符串（"2023-03-15"），中间有没有格式转换？测试用例要检查 B 模块收到的数据是不是正确转换后的值。
用代码示例说明结构
以下是一个 Python + pytest 的集成测试用例片段，模拟用户创建订单并与库存服务交互：
def test_create_order_decreases_inventory(client, mock_inventory_service):
# 模拟库存服务返回成功
mock_inventory_service.decrease.return_value = {"status": "success"}
order_data = {
"user_id": 123,
"product_id": 456,
"quantity": 2
}
response = client.post("/orders", json=order_data)
assert response.status_code == 201
assert mock_inventory_service.decrease.called
assert response.json["status"] == "confirmed"
这里 client 是测试用的 HTTP 客户端，mock_inventory_service 替代真实服务避免依赖。重点是验证调用是否发生、参数对不对、结果是否符合预期。
别忘了环境和配置问题
很多集成问题其实出在配置上。比如测试环境里数据库连接池设得太小，一并发就卡住；或者微服务注册中心地址写错了，根本连不上。测试用例可以不直接测这些，但在执行前要确保环境一致，否则跑出来的结果没意义。
持续集成中的实践建议
把集成测试加入 CI 流程，每次代码提交自动跑一遍。如果某个提交导致订单服务无法调通用户服务，立刻报警。这样问题能第一时间暴露，不至于堆到上线前才发现。
用例本身要尽量独立，不要依赖上一个用例的执行结果。比如测试“删除用户”之前先“创建用户”，而不是假定数据库里已经有个用户。这样即使单独运行某一条也能通过。