1. 背景与核心战略
1.1 背景
随着公司测试资源的缩减，传统的“开发交付 -> QA 全量手工回归”模式已成为瓶颈，无法支撑业务的高频迭代。我们需要借鉴硅谷头部科技公司的工程文化，建立一套自动化、工具化、数据化的质量保障体系。
1.2 核心目标
- 质量左移 (Shift Left): 在代码合并（Merge）前发现 90% 的问题。
- 去人工化: 用代码（Unit Test）和快照（Snapshot）替代重复的人工 UI 验证。
- 风险控制: 建立针对 A/B 实验爆炸的自动化验证与线上熔断机制。
1.3 转型策略：止血优先 (Stop the Bleeding)
鉴于 App 历史包袱沉重，我们采取“新老划断、增量优先”的策略：
- 新业务 (The New World): 必须符合新标准（MVVM + Snapshot + DI），QA 不再进行地毯式功能验证。
- 老业务 (The Old World): 维持现状，依靠 QA 现有资源进行回归。
- 交互原则: 设立防腐层（Anti-Corruption Layer），避免新代码被老代码污染。遵循“童子军军规”，只对修改涉及的逻辑补全测试。
2. 技术架构：测试金字塔模型
我们将不再追求 100% 的手工测试覆盖，而是转向分层自动化策略：
L1: 单元测试 (70%) - 逻辑基石
- 覆盖对象: ViewModel, Helper, Service, Model。
- 原则: 必须 Mock 所有外部依赖（网络、数据库、A/B 配置）。
- 服务端协同: 严禁依赖客户端验证服务端逻辑，服务端需自行闭环业务逻辑测试。
L2: 快照/集成测试 (20%) - UI 验收核心
- 工具: pointfreeco/swift-snapshot-testing
- 痛点解决: 像素级比对，自动发现 UI 错位、漏展示、多展示等问题。
- 实施标准:
-
- 多状态覆盖: Default, Empty, Error, LongText。
- 条件展示: 针对 VIP/非 VIP 等逻辑注入 Mock 数据生成不同基准图。
- 多维度: 覆盖 Light/Dark Mode 及不同屏幕尺寸。
L3: E2E 链路测试 (10%) - 核心防线
- 工具: Maestro (黑盒巡检)。
- 覆盖对象: 核心业务主流程（如：登录 -> 首页 -> 下单）。
- 策略: 仅覆盖最关键路径，作为“冒烟测试”使用。
3. 复杂场景应对：A/B 实验与 AI 赋能
3.1 A/B 实验治理
- 代码层解耦: 严禁在 View 内部直接调用全局 AB Manager。必须通过 依赖注入 (Dependency Injection) 将配置传入 ViewModel。
- 矩阵测试 (Matrix Testing): CI 脚本根据代码变更，自动组合实验开关参数（如 Group A vs Control），驱动 Maestro 运行多轮测试。
- 线上熔断: 结合金丝雀发布（Canary Release），一旦核心指标异常自动回滚实验。
3.2 AI 赋能提效 (AI-Augmented)
- 代码生成: 利用 Cursor/Trae 生成 ViewModel 测试用例和 Snapshot 配置代码。
- 知识库 (RAG): 构建实验知识库，解决“上下文缺失”问题，让开发能查询“修改此模块会影响哪些在线实验”。
- Code Review: AI 机器人自动扫描 MR，提示未处理的实验分支和潜在风险。
4. 跨部门协作体系
质量转型不是客户端一家的事，需要服务端和 QA 团队的角色重构。
4.1 服务端 (Infrastructure Provider)
- 契约测试: 维护 Swagger/OpenAPI，CI 中加入契约验证，破坏兼容性禁止合并。
- 环境 SLA: 保证测试环境稳定性（99.9%），避免客户端自动化测试因环境问题误报。
- 造数能力: 提供 Seeding API，允许客户端在测试前通过接口生成特定状态（如 VIP 账号）的数据。
4.2 测试团队 (Quality Coach & Platform)
- 角色转型: 从“执行者”转变为“教练”和“平台建设者”。
- 基础设施: 维护 CI/CD 流水线、Device Farm、造数工具。
- 质量把关: Review 开发提交的测试代码，指出覆盖率盲区。
- 探索性测试: 释放人力专注于破坏性测试、弱网测试及复杂交互场景。
5. 基础设施与风险管理 (The Hidden Challenges)
为了确保方案落地，必须提前解决物理瓶颈和管理风险。
5.1 物理基础设施
- Git LFS: 强制配置 Git LFS 管理快照图片，防止代码仓库体积爆炸。
- CI 效能: 实施 Test Sharding (分片运行) 和 精准测试，确保 CI 运行时间控制在可接受范围（如 15 分钟内）。
- 成本核算: 提前计算机器成本（Mac mini 节点、云测服务）与节省的人力成本（Headcount）的 ROI，以获取管理层支持。
5.2 稳定性治理 (Flakiness)
- 自动重试: CI 允许失败用例自动重试 1-2 次。
- 隔离机制 (Quarantine): 建立“隔离区”，将连续失败的不稳定用例自动标记并移出主流程，避免阻塞业务合并，随后由专人修复。
5.3 流程与文化
- 准入机制: 设立“质量宪兵”，新业务代码无测试用例禁止 Merge。
- 破坏者修复 (You Break It, You Fix It): 无论修改新老代码，导致自动化测试失败的人必须负责修复。
- 开发者赋能: 编写 "Testing Cookbook"，手把手培训开发人员如何写可测试的代码。
6. 落地路线图 (Roadmap)
第一阶段：基建与试点
- 动作:
-
- 搭建 Git LFS 和 CI 分片环境。
- 引入 swift-snapshot-testing。
- 选取一个非核心但 UI 复杂的页面（如“设置页”）进行试点，跑通全流程。
- 服务端提供首个 Seeding API。
第二阶段：推广与规范
- 动作:
-
- 硬性规定: 所有新 UI 组件必须包含快照测试。
- 重构核心 ViewModel，剥离全局 A/B 依赖。
- 引入 Maestro 覆盖最简核心链路。
- QA 开始转型，停止对新模块的机械回归。
第三阶段：成熟与数据化
- 动作:
-
- CI 流程全面卡点，无测试不可合并。
- 建立 Dashboard，展示自动化拦截 Bug 数、CI 成功率。
- 完全移除专职手工 UI 回归环节，QA 专注于探索性测试。
7. 总结
本方案不仅仅是引入几个测试库，而是一场工程文化的变革。
通过 Snapshot Testing 解决 UI 验证难题，通过 依赖注入 解决 A/B 实验复杂度，通过 服务端契约 保证水源纯净，最终实现由开发主导的高效质量体系。这需要客户端、服务端、QA 三方在“新老划断”的共识下，共同维护这套新的规则。
