Mock Server在联调阶段能解决什么问题

2023年3月记录，分类「接口测试」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。

联调痛点

Mock Server 不是为了逃避真实联调，而是在下游未完成、异常场景难构造时，先把前端和主流程推进起来。

我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。

Mock边界

• 按接口契约返回固定成功、失败、超时三类响应。
• Mock 数据和契约文件一起维护，避免口头约定。
• 联调通过后尽快切回真实服务做一次完整回归。

{
  "code": 0,
  "data": {"orderId": "MOCK-10001", "status": "created"}
}

维护方式

• Mock 字段和真实接口字段一致。
• 异常码、错误文案、空列表都有样本。
• 不会把 Mock 环境的结果当成上线依据。

执行时最好把截图、请求、响应、日志时间点放在一起，后面复盘会省很多事。

适用场景

Mock 的价值是提高联调效率，但最终质量判断一定要回到真实链路。后面遇到类似需求，可以先按这个结构跑一遍手工验证，再决定是否自动化。