C17 · 测试体系与质量工程

这道题考察你是否理解「测试投入与反馈速度、缺陷发现成本之间的权衡」——而非背诵金字塔形状。核心是：为什么大量廉价快速的单元测试应占多数，而昂贵缓慢的 E2E 应极少？不同系统（单体/微服务/数据管道）的金字塔形状应如何调整？

测试成本曲线：单测构建快（毫秒级）、稳定、定位准；E2E 构建慢（分钟级）、脆弱、定位难。缺陷越靠下层发现，修复成本越低（IBM 经典数据：需求期修复成本为 1，生产期可达 100 倍）。金字塔本质是「用大量廉价测试覆盖逻辑，用少量昂贵测试覆盖关键链路」。

反三角的代价：E2E 占比过高会导致 CI 红频繁、反馈慢、团队放弃跑测试，反而降低质量。数据管道/算法系统可变形为「宽腰」结构（集成/校验为主），但「单元极少、E2E 极多」永远是反模式。

1. 按「缺陷成本 × 发生频率」给每层定预算，而不是拍脑袋定比例。
2. 把 E2E 限制在「核心资金/关键链路」上，其余用契约+集成替代。
3. 每层测试独立运行、独立报告，CI 中分层并行以缩短反馈环。
4. 定期审计金字塔形状（用测试执行时长与数量分布），防止悄悄反三角。

陷阱：用 E2E 覆盖所有分支，结果 CI 跑 40 分钟、 flakes 频发、开发者本地跳过测试。

金字塔不是「越多越好」，而是「对的测试在对的层」。把本应在单元层验证的业务规则拖到 E2E，既慢又易碎。真正的成熟度标志是：绝大多数逻辑在单元层被快速锁死，E2E 只验证「链路真的通」这一件事。

考察「可测性」是否被视为一等设计约束：难写的单测往往暴露了耦合、隐式依赖、全局状态。核心是先用可测性反向约束设计，再谈怎么写断言。

可测性三原则：① 依赖显式化（构造函数/方法参数注入，而非静态调用或 new 内部对象）；② 纯函数核心（业务规则与 IO 分离，核心无副作用）；③ 可观测输出（结果可断言，而非靠副作用或日志验证）。

AAA 结构：Arrange（准备）- Act（执行）- Assert（断言）三段清晰；一个测试只验证一个行为，命名表达「场景_输入_期望」。

1. 把「new Service() 内部依赖」改为构造注入，使测试可传入替身。
2. 把时钟、随机、网络、配置抽成可注入的端口（Port），单测用确定性实现。
3. 用 assertThrows 验证异常路径，不用 try-catch 吞掉。
4. 单测禁止连真实库/网络；需要时用替身或 Testcontainers 提升到集成层。

// 反例：隐式依赖，无法单测
public Order create(Req r){ var c = DB.connect(); ... }
// 正例：依赖注入，单测传 FakeDB
public Order create(Req r, DbPort db){ ... }

可测性差不是测试的问题，是设计的问题。当你为了测试不得不大量用 PowerMock 去mock私有/静态/构造时，信号是「该重构了」，而不是「该加更重的 mock」。

考察集成测试「测到哪一层边界」的判断力：到底是测代码装配，还是测真实中间件语义？Testcontainers 解决的是「没有真实依赖就无法验证」的鸿沟。

集成边界：集成测试应覆盖「模块间契约 + 中间件真实语义」（如事务回滚、索引命中、消息顺序），而非重复单测的逻辑。把 MySQL/Redis/Kafka 用 Testcontainers 拉起真实实例，比用内存假实现更接近生产。

代价：启动容器有开销，需用单例容器 + 复用 + 并行隔离（schema/queue 命名空间）控成本。

1. 单测层用替身；集成层才用 Testcontainers 起真实依赖。
2. 容器镜像版本必须锁定，且尽量贴近生产版本，避免「本地能过生产翻车」。
3. 用 @Container 静态单例复用，缩短 CI 时长。
4. 每个测试用独立数据集/事务回滚，避免相互污染。

判据：集成测试的价值 = 它验证了单测验证不了的真实语义。若只是验证「方法被调用」，那是单测用错了替身。

Testcontainers 不是银弹：它解决「依赖真实性」，但不解决「测试速度」。集成测试总量要受控，否则 CI 里容器拉起成为瓶颈。

考察在微服务规模化协作下，如何用「契约」替代「端到端联调」来保障接口兼容——这是解耦团队、提速交付的关键架构手段。

CDC（Consumer-Driven Contracts）：由消费者定义「我需要什么字段、什么状态码」，生成契约；提供者 CI 中校验「我是否满足所有消费者契约」。把接口耦合从「运行时联调」前移到「提交时验证」。

与 E2E 的区别：E2E 验证整条链路（慢、脆），CDC 只验证「接口契约」（快、稳），用契约替代 80% 的跨服务 E2E。

1. 消费者侧写契约（请求/响应样例 + 状态码 + 字段约束）。
2. 契约存入 Broker（如 Pact Broker），提供者拉取并自动校验。
3. 破坏契约的提交在 CI 直接失败，阻断不兼容发布。
4. 契约随接口演进版本化，废弃前先确认无消费者引用。

陷阱：契约只覆盖了happy path，关键错误码/边界字段未约定，生产才暴露不兼容。

CDC 的威力在于「把协作约束编码化」：团队无需开会对齐接口，契约即文档、即门禁、即回归保护。它解决的是组织规模化下的接口漂移，而非单服务内部逻辑。

考察 E2E 测试的「选哪些、怎么不脆弱、怎么进 CI」——E2E 最贵也最易碎，落地能力决定它能否活下来被持续维护。

少而精：E2E 只覆盖「跨服务的核心链路 + 关键业务结果」，用最少的用例锁定最大风险。脆弱性来自「过度断言细节」（DOM 结构、时序、数据顺序），应只断言「业务可见结果」。

稳定性：显式等待替代 sleep；用稳定选择器（data-testid）替代易变的 class；隔离测试数据避免串扰。

1. 按「用户旅程」而非「页面」组织 E2E，一条链路一个用例。
2. 重试只用于「已知 flaky 环境抖动」，且记录重试率作为稳定性指标。
3. E2E 放 CI 的「预发/准生产」阶段，不阻塞本地快反馈。
4. 建立 E2E 红警响应机制：定位是「产品 bug」还是「测试腐化」须快速区分。

E2E 的真正价值不是「覆盖全」，而是「给团队信心」：核心链路一旦断，E2E 必红。用例越少越精，团队越愿意信它、维护它。

考察是否把「故障」当作可主动验证的对象：混沌工程不是随机破坏，而是「先有稳态假设，再注入故障，验证系统是否如预期收敛」。

混沌闭环：定义稳态指标（如错误率、延迟、QPS）→ 假设注入故障后稳态维持 → 注入（kill 实例/丢包/延迟/资源耗尽）→ 观测 → 得出结论并修复。

游戏日（GameDay）：在受控环境按计划演练，比「生产随机炸」更可学习。注入强度从「只读探针」逐步升到「真实杀伤」。

1. 先在预发环境做混沌实验，稳态指标与告警先打磨清楚。
2. 优先注入「高概率真实故障」：实例宕机、依赖超时、消息积压。
3. 每次实验产出「假设是否成立 + 暴露的薄弱点 + 改进项」并跟踪闭环。
4. 与「可观测三支柱」绑定：没有指标，混沌就是盲炸。

陷阱：在没稳态指标、没熔断降级的情况下直接 kill 生产节点，等价于制造事故。

混沌工程的目的是「用可控的失败换取对系统的真实认知」。它的对手不是「不故障」，而是「对故障毫无准备」。

考察性能测试是否「有目标、有模型、有结论」：压测不是把流量打满看会不会挂，而是用业务画像验证容量与 SLO。

四类性能测试：负载（验证预期容量）、压力（找拐点）、容量（找最大可持续）、疲劳（长时间稳定性/内存泄漏）。目标须以 SLO 量化（P99<200ms、错误率<0.1%）。

流量模型：基于真实业务画像（读写比、热点 key、峰值倍数）构造，而非均匀随机。

1. 先定 SLO 与容量目标，再选压测类型与工具（如 JMeter/Gatling/k6）。
2. 加压梯度递增，记录吞吐/延迟/错误率/资源曲线，定位拐点。
3. 压测环境尽量等比，且隔离以免影响生产。
4. 结论产出「是否达标 + 瓶颈在哪 + 扩容/优化建议」，存入容量档案。

性能测试最易被滥用的是「只报 TPS 数字」。真正有用的是「在 X 并发下，P99 是否满足 SLO，拐点出现在哪里，根因是什么」。

考察安全是否「左移成自动化门禁」：安全测试不是上线前人工审计，而是 SAST/DAST/SCA 三件套嵌进流水线持续拦漏。

三层安全测试：SAST（静态，扫源码/依赖的已知漏洞模式）、DAST（动态，运行时扫暴露面/注入）、SCA（软件成分分析，扫三方库 CVE）。三者互补，缺一不可。

误报治理：安全扫描噪声大，须分级（阻断级/警告级/忽略级）并维护基线，否则团队会习惯性忽略全部告警。

1. SAST 接 PR 门禁，阻断级漏洞禁止合入。
2. SCA 定期跑，高危 CVE 设修复 SLA。
3. DAST 在预发环境对暴露接口主动探测。
4. 密钥/凭证扫描独立卡点，防止泄露进仓库。

判据：安全测试的有效性 = 它拦住的真实漏洞数 / 产生的无效噪声比。噪声过高会训练团队无视它。

安全测试的真正难点不是工具，是「把告警转化为可执行动作」。没有分级与责任人，再全的扫描也只是审计报告里的一行。

考察「哪些测试在什么阶段卡住交付」的策略设计：门禁是质量的最后一道闸，必须透明、可本地复现、且人机共决。

门禁分层：提交门禁（单测+静态）快而必过；合并门禁（集成+契约）中速；发布门禁（E2E+性能+安全+人工 Go/No-Go）重而审慎。每道门禁失败即阻塞，规则对全员透明。

可复现：门禁脚本须能在本地一键复现，避免「CI 红但本地不知道为什么」。

1. 门禁清单写进仓库（如 CI 配置），而非藏在平台 UI。
2. 发布前做 Go/No-Go 评审：门禁全绿 + 变更范围 + 回滚预案齐备才放行。
3. 为「紧急修复」预留明确例外通道，但须事后补测并复盘。
4. 门禁指标（时长/红率/flake率）纳入团队健康度看板。

门禁过严会逼团队绕过（跳过 CI、注释测试），过松则形同虚设。好的门禁是「刚好卡住真实风险，又不成为日常阻力」。

考察是否掉进「覆盖率数字崇拜」：高行覆盖不等于高质量，无效断言和过度 mock 能轻松刷出 90% 却测不出 bug。

覆盖率的盲区：行覆盖只说明「执行过」，不说明「断言过」。分支覆盖、变异覆盖（Mutul覆盖：故意改代码看测试能否抓到）才是有效信号。

有效断言：断言必须验证「业务不变量/输出契约」，而非「方法被调用一次」（后者用 verify 验证的是行为而非正确）。

1. 覆盖率设下限门禁（如增量行覆盖≥80%），但明确它只是底线不是目标。
2. 引入变异测试抽样，量化「测试抓 bug 的能力」。
3. Code Review 重点看「断言是否验证业务结果」而非「有没有写测试」。
4. 对核心模块要求分支/边界覆盖，普通模块行覆盖即可。

陷阱：用 assertEquals(true, service.run()) 或不写断言的「假测试」，覆盖率 100% 却零保护。

覆盖率回答「测了多少」，变异测试回答「测得好不好」。成熟度高的团队逐步从前者过渡到后者，而不是一直盯着行数。

考察替身（Test Double）的选择判断力与测试数据的可控性：用错替身会测成「自己和自己玩」，数据失控则会串扰与脆化。

替身谱系：Dummy（占位）→ Stub（返回 canned 值）→ Spy（记录调用）→ Mock（验证行为）→ Fake（轻量可用实现，如内存库）。原则是「能验证真实语义就用更真实的替身，只验证协作才用 Mock」。

测试数据：走「builder/fixture 工厂」而非散落魔法值；数据随用例自包含，不依赖全局共享状态。

1. 单测优先用 Fake/Stub 验证状态；只有验证「是否调用了依赖」才用 Mock。
2. 避免 Mock 私有方法/静态/构造（信号：该重构）。
3. 测试数据用工厂方法，关键字段显式、无关字段默认。
4. 集成测试用独立 schema/命名空间，确保可并行不串扰。

过度 Mock 的典型症状是「重构实现后，明明行为没变，测试却大片失败」——因为测的是「调用了哪个方法」而非「产出对不对」。

考察测试在 CI 中的「编排节奏」：分层不是为了好看，是为了让「快反馈」和「重保障」各得其所，既不拖慢开发者也不漏掉风险。

分层触发：PR 阶段跑单测+静态（秒~分钟级）；合并主干跑集成+契约；预发/发布阶段跑 E2E+性能+安全。每层并行分片以缩短时长。

缓存与复用：依赖缓存、测试容器单例、构建产物复用，避免每层重复冷启动。

1. 单测必须「开发者本地与 CI 同命令」，降低「仅 CI 红」。
2. 长尾测试（E2E/性能）用独立流水线，不阻塞日常合并。
3. 失败重试与 flake 隔离：flake 自动标灰并进入待修队列。
4. 测试时长设预算告警，超阈值触发优化。

CI 编排的成熟度 = 开发者对「红绿信号」的信任度。一旦经常误报或极慢，团队会用各种方式绕开，门禁价值归零。

考察质量工程的「时间轴」认知：左移把缺陷消灭在编码期，右移用生产探针与灰度验证弥补测试环境的盲区。

左移：单测/TDD/静态分析/契约在编码与 PR 阶段完成，缺陷修复成本最低。

右移：生产环境的金丝雀指标、影子流量、在线压测、真实用户监控（RUM）补足「测试环境≠生产」的鸿沟。右移不是放任，是「用生产数据做最后验证」。

1. 左移：把单测与静态门禁做成 PR 强制，TDD 用于核心复杂逻辑。
2. 右移：发布走金丝雀，用核心指标对比新旧版本再全量。
3. 生产探针（合成交易/探活链路）持续验证关键路径。
4. 线上发现的缺陷反向沉淀为回归测试，闭环。

判据：左移降成本，右移补盲区。只左不移则环境差距积累，只右不移则修复昂贵。

质量工程的终局是「缺陷在离产生最近的地方被拦下，极少数漏网的在生产被快速发现并转化为回归」——这是一个自学习闭环。

考察能否识别「让测试变脆弱/变无用」的设计习惯：识别反模式比写更多测试更能提升质量。

常见反模式：① 静态/全局状态依赖（测试间串扰）；② 时间/随机/网络硬编码（不可重复）；③ 一个测试多断言多路径（定位难）；④ 用 Mock 验证逻辑而非状态；⑤ 测试依赖执行顺序；⑥ E2E 断言 DOM 细节。

1. Code Review 设「可测性检查项」，反模式一票打回。
2. 用静态分析识别静态依赖/全局可变状态。
3. 测试命名与结构遵循「场景_输入_期望」，一个行为一测试。
4. 定期做「删测试练习」：删掉仍可绿的测试，说明它没在保护什么。

反模式的本质是「测试在验证错误的事物」：验证调用而非结果、验证细节而非契约、验证顺序而非不变量。把注意力从「数量」转向「验证对象」，质量才会真正上升。