测试体系（QA / Quality Engineering）
目标：让质量前移、让缺陷止于发布之前
P0（测试基础）
├── 测试平台
├── 测试用例管理
├── 测试环境管理
P1（自动化）
├── 自动化测试（API / UI / E2E）
├── 测试数据平台
├── Mock / 虚拟服务
P2（规模化）
├── 性能 / 全链路压测
├── 缺陷管理 & 质量分析
├── 测试左移 / 右移
P3（质量工程）
├── 灰度实验 / A/B 测试
├── 质量度量 & 门禁
├── 测试资产复用
相关开源项目：
数据工厂：https://github.com/houbb/data-factory
性能压测：https://github.com/houbb/junitperf
chat
下面我将 Mock / 虚拟服务（Service Virtualization）作为一个企业级基础设施能力来完整展开，而不是停留在“造几个假接口”的层面。
整体目标只有一句话：
通过服务虚拟化，让测试从“依赖真实系统”升级为“可编排、可控的系统行为模拟”。
一、Mock / 虚拟服务的核心定位
1️⃣ 一句话定义
Mock / 虚拟服务 = 可配置、可编排、可观测的“系统行为替身”
它模拟的不是“返回值”，而是：
- 协议行为
- 时序行为
- 异常行为
- 性能行为
2️⃣ 它解决的根本问题
| 真实问题 | Mock / 虚拟服务的解法 |
|---|---|
| 下游系统未完成 | 提前模拟 |
| 下游系统不稳定 | 测试解耦 |
| 复杂异常难复现 | 行为注入 |
| 测试成本高 | 本地/测试替身 |
一句话总结：
让测试不再被“别人系统的节奏”牵着走。
二、Mock 与 Stub 的本质区别（必须澄清）
| 维度 | Stub | Mock / 虚拟服务 |
|---|---|---|
| 返回 | 固定 | 可规则化 |
| 状态 | 无状态 | 有状态 |
| 场景 | 单接口 | 业务流程 |
| 异常 | 不支持 | 可注入 |
| 管理 | 脚本级 | 平台级 |
真正的 Mock 是“行为模拟”，不是“假数据返回”。
三、Mock / 虚拟服务在测试体系中的位置
自动化测试
├── API / UI / E2E
│
├── 测试数据平台（控制内部状态）
│
└── Mock / 虚拟服务（控制外部行为）
分工非常清晰：
- 测试数据平台：我系统内部“长什么样”
- Mock 服务：外部系统“怎么对我反应”
四、Mock / 虚拟服务的核心能力拆解
1️⃣ 协议级模拟（Protocol Virtualization）
支持的协议类型：
- HTTP / REST
- gRPC
- Dubbo
- MQ（Kafka / RocketMQ）
- WebSocket
能力点
- 协议一致性校验
- Header / Metadata 模拟
- 编码格式一致（JSON / Protobuf）
2️⃣ 请求匹配与响应规则引擎（Rule Engine）
匹配维度
- URL / Method
- Header
- Body 字段
- 上下文状态
响应能力
- 静态响应
- 动态模板（变量替换）
- 条件响应（if / else）
示例
if order.amount > 1000:
return "REVIEW_REQUIRED"
else:
return "PASS"
3️⃣ 状态机与场景编排（Stateful Mock）
这是区分“玩具 Mock”和“工程级虚拟服务”的核心能力
示例场景
请求1 → 返回处理中
请求2 → 返回成功
请求3 → 返回已完成
能力
- 状态迁移
- 状态持久化
- 状态重置
4️⃣ 异常与故障注入（Fault Injection）
可注入的行为
- 超时
- 慢响应
- 错误码
- 非法数据
价值
- 覆盖真实线上故障
- 提前暴露容错问题
5️⃣ 性能行为模拟（Performance Simulation）
- 固定延迟
- 随机抖动
- 限流
- 并发限制
用于：
- 性能测试前置
- 超时 / 重试策略验证
6️⃣ 场景版本与环境切换
- 场景版本化
- 不同环境使用不同 Mock 行为
- 灰度 / AB 场景支持
五、Mock 平台的系统架构设计
1️⃣ 逻辑架构
Mock / 虚拟服务平台
├── 协议适配层
├── 请求匹配引擎
├── 场景 & 状态管理
├── 故障注入模块
├── 行为脚本引擎
├── 管理控制台
└── API / SDK
2️⃣ 与真实服务的切换机制（非常关键）
| 方式 | 说明 |
|---|---|
| 配置开关 | 推荐 |
| 服务发现路由 | 进阶 |
| 网关拦截 | 企业级 |
原则
Mock 的启停不能改代码。
六、Mock / 虚拟服务的典型使用场景
场景 1：自动化测试
- 下游未完成
- 只验证本系统逻辑
场景 2：并行开发
- 前后端解耦
- 多团队协作
场景 3：异常演练
- 验证降级 / 重试
- 提升系统韧性
七、治理与工程规范（否则必乱）
1️⃣ 场景治理
- 命名规范
- 负责人
- 生命周期管理
2️⃣ 防止 Mock 漂移
- 定期与真实服务对齐
- 合约测试（Contract Test）
八、成熟度分级
| 等级 | 特征 |
|---|---|
| L1 | 本地 Stub |
| L2 | 接口 Mock |
| L3 | 场景 Mock |
| L4 | 故障注入 |
| L5 | 行为级虚拟化 |
九、总结一句话
Mock / 虚拟服务不是为了“假”，而是为了“可控的真实”。
