测试过程模型与左移右移

一句话：本页回答"测试在流程里放哪儿 "------从 V/W 模型的阶段对齐，到敏捷的迭代内闭环，再到把质量活动推到需求阶段（左移）、**延伸到生产环境（右移）**的两次位移。

定位：通用知识第 2 页。先区分"测试活动本身"（七活动）与"测试在生命周期中的位置"（模型与位移），避免把两者混谈。

上游：测试基础理论（测不完 → 所以要做抽样与位移取舍） · 下游：测试层级与测试类型（每个活动落在哪一层）、测试设计（分析与设计活动的展开）

一、先固定"测试过程"本身：七个活动

#	活动	回答	主要产物	主要责任人
1	测试计划	目标、范围、风险、资源、进度	测试计划	测试负责人
2	测试监控与控制	偏离了吗？怎么纠偏？	进度/质量报告、控制动作	测试负责人
3	测试分析	测什么（测试条件）	测试条件清单、风险覆盖矩阵	测试分析者
4	测试设计	怎么测（用例骨架、覆盖项）	用例集骨架、覆盖项与优先级	测试设计者
5	测试实现	让用例能跑	脚本、数据、环境、执行顺序	测试/自动化工
6	测试执行	跑并判定	执行结果、缺陷报告	全体测试者
7	测试完成	收口与沉淀	总结报告、经验教训、归档	测试负责人

这七个活动与流程模型无关 ------瀑布、V 模型、敏捷、DevOps 都要做，区别只在频率、节奏与并行度。把"敏捷测试"理解成"取消文档"是常见误读：活动不减，只是产物载体与颗粒度变化。

二、V 模型：线性模型的代表

2.1 对应关系

左侧（开发）	右侧（对应测试层级）
需求分析	验收测试
概要设计	系统测试
详细设计	集成测试
编码	组件/单元测试

2.2 被普遍误读的一点

V 模型不是说"测试只在右侧发生" 。它的核心主张恰恰是：每个开发活动的测试计划与用例设计应在同一阶段完成（即左侧下沉）。也就是说，2000 年代流行的"测试左移"，在 V 模型里已有一半。

被 V 模型真正约束的是：

阶段冻结假设（需求在设计前基本稳定）
文档驱动（每级必须有可对照的规格）

2.3 适用判断（它不是"过时模型"）

场景	适配性	原因
安全关键 / 受监管（航空、医疗、汽车功能安全）	✅ 高	需要可审计的双向追溯与阶段交付物
硬件 / 固件 / 协议栈	✅ 高	变更成本高、验证周期长、需求相对稳定
需求快速变化的互联网业务	❌ 低	阶段冻结假设不成立

本库对应场景：存储/芯片类产品的固件与协议测试（如 SSD测试方法与体系的 V&V 交付物）更接近 V 模型世界；业务系统更接近敏捷世界。同一个测试工程师的职业生涯里两种都要会。

三、W 模型与 H 模型

3.1 W 模型：把"评审"正式纳入测试

W 模型 = 开发 V + 与每一阶段平行的测试 V：

开发阶段	W 模型中的平行测试活动
需求	需求测试：评审需求的完备性、一致性、可测性
设计	设计测试：评审设计是否可测、是否满足需求
编码	单元测试 + 代码评审 + 静态分析
集成	集成测试
系统	系统测试
交付	验收测试

核心贡献：确认了"验证开发产物本身"就是测试活动（静态测试正式化），与测试基础理论 §四的四象限一致。

局限：仍假设阶段序列；对频繁变更的需求，平行 V 的两条腿会同时失稳。

对照	V 模型	W 模型
测试的起点	需求阶段规划用例	需求阶段测试需求本身
静态测试地位	隐含	明确列为独立测试活动
额外成本	低	需要具备"能评审需求"能力的测试人员

3.2 H 模型：测试成为独立、可反复触发的流程

H 模型把测试活动从开发序列中完全独立出来，核心结构是：

markdown 复制代码

  测试准备活动（分析/设计/实现）
            │
            ▼  测试条件成熟（某交付物就绪、风险点触发）
  测试执行活动 ──▶ 结果评估与反馈
            ▲
            └──── 可在生命周期不同点被反复触发

核心主张：

测试准备与执行分离------准备是持续的，执行是事件式的
不绑定固定阶段；需求、设计、代码任一交付物达到可测条件，即可触发一次测试执行
测试是与开发并行而非"尾随"的独立流程

优点	缺点
体现测试独立性；响应灵活，适应迭代与变更	对测试团队的自组织与专业能力要求高
避免"等系统出来才开始"的空窗	缺少计划约束时，执行节奏易碎片化

V/W/H 三模型的关系：V 模型解决"测试与开发怎么对齐"，W 模型补上"静态测试也是测试"，H 模型补上"测试是独立流程、可多次触发"。国内教材常并列三者；其原始出处与严格定义在不同资料中表述不一。

四、迭代与敏捷：测试被"折叠"进迭代

4.1 敏捷测试四象限（Brian Marick）

	支持团队（引导正确实现）	批判产品（发现实现问题）
业务导向	Q2：故事测试、验收标准、实例化需求、原型验证	Q3：探索式测试、场景测试、UAT、Beta
技术导向	Q1：单元测试、组件测试、TDD	Q4：性能、安全、可靠性、兼容性（非功能）

价值：四格都要填。只做 Q1 会漏掉"需求理解错"（Q2/Q3）；只做 Q3 会在发布前才发现大量低级缺陷（Q1 缺位）。

4.2 分层策略：金字塔 / 冰淇淋筒 / Trophy

模式	比例直觉	优点	风险
测试金字塔（Mike Cohn）	单元 ≫ 集成 ≫ E2E	快、稳、定位准、成本低	被简化为"多做单测"，忽略业务层
冰淇淋筒（反模式）	E2E ≫ 单元	覆盖"像用户"	慢、脆、维护贵、失败归因难
Testing Trophy（Kent C. Dodds，前端社区）	集成测试为重心	平衡信心与成本	前端语境，不宜直接移植到后端/系统软件

判据：能下沉到低层的验证，不要放到高层做；高层只保留"只有全链路才能验证"的部分。

4.3 敏捷下的真实代价（不是唱衰，是取舍）

代价	机制	缓解
迭代内测试时间被压缩	周期短，测试成为"最后一环"	用例资产复用 + 自动化分层 + 探索式配比
自动化债务累积	赶迭代写"能跑就行"的脚本	明确分层与维护责任人
DoD 形同虚设	验收标准不含质量门槛	DoD 写入质量条款（覆盖类型、性能基线、静态检查）
flaky 用例侵蚀信任	不稳定用例多 → 团队忽略红灯	flaky 隔离与归因治理（→ FlakyTest治理）
回归成本随功能线性增长	缺分层与选择执行	基于变更影响的选择性回归

4.4 持续测试与 DevOps：从迭代闭环到流水线闭环

持续测试（continuous testing） = 把测试内建为交付流水线的一部分，在每次变更时自动获取质量反馈------测试不再是发布前的独立阶段，而是贯穿交付全程的持续活动。DevOps 则是它的组织载体：开发、测试、运维在同一流水线与同一组质量目标上协作。

一条典型的流水线质量轨道：

markdown 复制代码

提交 → 静态检查 + 单元测试（分钟级）
     → 制品构建 + 集成/契约测试
     → 预发环境 E2E + 非功能抽检
     → 质量门禁（自动判定出口判据）
     → 灰度发布 + 生产观测（→ §六 右移）

关键要素	内容
质量门禁自动化	出口判据写进门禁规则，不满足即阻断流转（不靠人工签字）
测试环境即代码	环境与数据通过配置自动拉起、用完即毁，缩小环境漂移
左移与右移汇合	左移产出的测试资产在流水线中自动运行；右移观测数据回流为新测试条件
统一反馈视图	缺陷、构建、覆盖率、SLO 在同一链路可追溯

与前述模型的关系：金字塔回答"测试资产怎么分层"，四象限回答"四类活动别缺位"，持续测试回答"这些资产以什么节奏运行"。

常见误区：自动化 ≠ 持续测试。有脚本但无门禁、无反馈闭环、红灯无人响应，只是"自动化了的测试"，不是持续测试。持续测试真正的前提仍是 §4.3 的那些纪律：DoD、flaky 治理、分层与选择执行。

五、左移（Shift-Left）：把质量活动推向前

5.1 四个可落地动作

动作	具体做法	前置条件
① 需求侧	可测性评审、Given-When-Then 验收标准、实例化需求	测试人员具备需求评审能力
② 设计与编码侧	静态分析、代码评审清单、可测性设计（观测点/依赖注入）	开发接受质量门槛
③ 测试侧	单元/契约/组件测试下沉（金字塔）	低层测试有稳定运行环境
④ 流水线侧	提交即跑快速测试，分钟级反馈	CI 基础设施与测试性能预算

5.2 收益（可论证的部分）

修复成本随阶段后移而放大（成本放大曲线见测试度量与质量成本）
返工减少：需求歧义在评审阶段消除，远便宜于在验收阶段消除
反馈周期缩短：缺陷在"作者还记得上下文"时被发现，定位时间显著降低（经验判断）
整类缺陷被拦截：静态检查挡住空指针、资源泄漏、并发误用等成类问题

5.3 真实代价（重点：左移常被当作零成本口号）

代价	说明	反制
测试维护成本转嫁	单测/契约测数量爆炸后，一次重构批量失效（brittle tests）	面向行为而非实现断言；行为不变则测试不变
虚假覆盖率	覆盖率变 KPI → 写无断言测试（古德哈特定律，见测试度量与质量成本）	变异测试 / 断言有效性抽检
TDD 的初期减速	学习曲线与设计反思成本，短期交付速度下降	高风险模块先行，不搞全量强制
职责虚化	"左移"被执行成"把测试交给开发" → 测试团队反而失去质量掌控	质量目标共担 + 明确门禁与出口判据
静态分析噪声	告警过载 → 团队整体静音	门禁只拦增量、按严重级分级
伪需求评审	评审流于形式（"签字会"）	用可测性提问清单驱动评审

5.4 什么情况下左移收益最高

需求歧义多、返工频繁 → 需求侧左移
回归成本高、发布频繁 → 自动化与流水线左移
缺陷复现难、线上修复代价高 → 低层测试左移

反之：一次性原型、需求高度不确定的探索期产品，过早建设完整测试体系是过度投资。

六、右移（Shift-Right）：把验证延伸到生产

6.1 手段清单

手段	做什么	典型用途
灰度 / 金丝雀发布	小比例放量观察	降低发布爆炸半径
特性开关（feature flag）	代码发布与功能开启解耦	快速回退、按用户分流
生产流量回放 / 影子流量	用真实请求验证新版本	兼容性与性能验证
合成监控（synthetic monitoring）	脚本化模拟核心用户旅程	持续可用性验证
RUM / 真实用户监控	真实设备与网络下的性能	环境漂移类问题
混沌工程	主动注入故障	容错与恢复能力验证
SLO / 错误预算	用可量化目标约束发布	发布决策依据

6.2 收益

唯一能覆盖"环境漂移"的手段：预发环境永远无法完全复制生产（数据分布、网络、第三方依赖、真实负载）
对"预发不可信"的团队，右移替代部分预发环境投入，降低维护成本
用真实数据分布替代人工抽样，提高长尾输入的缺陷发现效率
支撑"小步发布 + 快速回滚"，把质量风险变成可管理的时间窗口

6.3 真实代价

代价	说明	反制
爆炸半径	生产实验直接影响真实用户	逐步放量 + kill switch + 自动回滚阈值
数据与隐私合规	用真实用户数据测试存在边界	脱敏、合成数据、最小化采集（合规优先于测试便利）
依赖可观测能力	缺指标/日志/链路追踪时，右移只是"盲测"	先建可观测，再谈右移
告警疲劳	合成监控与真实告警混杂	分级 + 归因，只对"可行动告警"值班
特性开关组合爆炸	N 个 flag 的交互状态难穷举	flag 生命周期管理，验证后按期清理
成本后置	看似省了测试环境，实际转移到运维与事故成本	计入外部失效成本（→ 测试度量与质量成本）

6.4 边界判断

场景	右移适用性
不确定性高、无法本地复现的问题（长尾输入、并发时序、真实网络）	✅ 高
快速迭代的在线服务（可量化、可回滚）	✅ 高
强合规 / 不可试错（医疗、核心清算、安全控制）	⚠️ 谨慎，需受控实验与合规审查
硬件 / 固件（物理交付物）	❌ 大部分不可右移（回滚成本极高）

七、两次位移的取舍总表

维度	左移	右移
本质	把质量活动提前	把验证活动延后到真实环境
主要成本	前期投入（工具/规范/培训）、测试资产维护	生产风险、可观测建设、数据合规
主要收益	早期拦截、返工减少	环境真实性、真实分布覆盖
失效模式	虚假覆盖率、脆性测试、职责虚化	线上事故、告警疲劳、开关债
关键前置条件	需求可测、CI 快速反馈	可观测、可回滚、可灰度
最适合的团队	需求歧义多、发布频繁	线上环境复杂、预发不可信

一句话判据 ：左移解决"缺陷造得太贵 "，右移解决"环境永远不一样"。二者不替代------左移做不了的（真实环境、真实分布）交给右移；右移能发现的（低级逻辑缺陷）不该浪费在生产。

同时做两者的代价是组织能力 ：一个团队同时推左移与右移，等于同时要求"开发写测试"与"运维级可观测"，很容易两头都做不到位。常见务实路径是先左移补基础，再右移扩视野。