讨论测试最容易吵起来的从来不是要不要写,而是这条用例到底该放在哪一层。有人觉得端到端跑通了才算数,有人认为凡是能在函数级别覆盖的就不该拖到界面层。分层测试(Layered Testing Approach)这个说法听着有点学院气,但它要解决的其实是一个非常具体的问题:在工程时间和机器资源都有限的前提下,怎么把验证这件事的成本和收益对齐。它不是什么新框架,也不是某个工具的名字,而是一套关于哪类验证放在哪一层、各层之间怎么分工、边界靠什么守住的工程约定。这篇文章面向的是已经有一定测试基础、但团队里测试体系开始变慢变脆的开发者、测试工程师和技术负责人。我会从分层的动机讲起,把主流模型的取舍、目录与流水线的落法、每一层的职责红线、判断分层是否健康的指标,以及一次真实的分层塌陷与重建过程都摊开说,尽量给到可以直接抄的配置和判断清单。1. 分层的真正难点不在分几层,而在谁来守边界1.1 架构分层有编译器兜底,测试分层只有约定做过一段时间后端的人对架构分层都不陌生:controller 不能直接调 mapper,领域逻辑不能依赖 Web 框架,这些规则通常有依赖注入、包扫描、架构校验工具来强制。你要是把 service 的注解塞到 controller 上,编译或者启动扫描阶段就会报错。测试分层完全是另一回事。你在端到端目录里塞一条只验证字符串拼接的用例,没有任何工具会拦你,CI 照样绿,代码评审时也很容易被放过去,因为它看起来也是个测试。三个月之后,没人说得清哪一层到底有多少条用例、每层的执行预算是多少。这就是分层测试落地时最反直觉的地方:模型设计只占两成工作,剩下八成是给边界装物理护栏。护栏可以是目录结构、标签体系、流水线分阶段触发、评审检查项,甚至是新增端到端用例必须写明为什么下层无法覆盖这样的显式约定。没有护栏,分层就只是一张画在白板上的漂亮图。1.2 反馈速度与真实度是一对硬性矛盾越靠下的层,跑得越快、越便宜、定位问题越准,但它验证的真实度越低。纯单元测试里的依赖都是替身,你验证的是我以为依赖会这样返回,而不是依赖真的会这样返回。越靠上的层越接近真实,但慢、脆、贵。这条矛盾没法消除,只能按比例分配。我习惯用一个具体数字来让团队有体感。假设单元测试平均 5 毫秒,集成测试平均 2 秒,端到端平均 90 秒。如果按 1000 条单测、200 条集成、100 条端到端来排,总耗时大约是 5 秒 400 秒 9000 秒,合起来不到 2.6 小时。如果把分布倒过来,变成 100 条单测、200 条集成、1000 条端到端,总耗时是 0.5 秒 400 秒 90000 秒,也就是 25 小时上下。同样数量的用例,只是放错了层,执行代价差了将近十倍。这个差距不是理论上的,它直接决定了一条流水线是十分钟出结果,还是没人愿意在合并前等它跑完。1.3 分层的经济学:把缺陷拦在修复成本最低的那一层缺陷发现得越晚,修复成本越高,这个结论在行业里被反复验证过。需求评审阶段改一句话的事,编码阶段改几行,进了 CI 要改代码加回归,流到生产就得算上排查、热修、数据订正和用户沟通的成本。分层测试的经济学含义就是:在成本最低的那一层,把只有它能拦的缺陷拦住;把成本高的层,留给真正只有它才能验证的东西。所以判断一条用例该放哪层,我通常只问一个问题:这条用例想验证的行为,下面那一层能不能等价验证?折扣金额计算,满 300 减 50 再叠加会员 9 折,这是纯逻辑,单元层完全能验,放上去就是浪费。订单写库之后,库存服务收到了扣减消息,单测里只能 mock 消息发送,验证不了真实的消息序列化和消费端解析,这必须下沉到集成层。用户在小程序里点提交,页面提示下单成功并跳转到订单详情,这里包含了渲染、路由、鉴权、网络重试等一整套链路,只有端到端能覆盖,那就理直气壮地放上去。2. 金字塔、奖杯、甜筒:四种模型各自对应什么样的团队现实2.1 金字塔模型的成立前提经常被忽略测试金字塔几乎是这个领域里传播最广的一张图,出处可以追溯到 Mike Cohn 在 2009 年的著作,后来被大量团队简化成单元七成、服务两成、界面一成这样的经验比例。它的逻辑很清晰:越往下写越多,越往上写越少。但金字塔有一个经常被忽略的前提:业务逻辑主体能够在单元层被完整表达,界面只是一层很薄的外壳。在传统的服务端渲染应用里,这个前提基本成立,核心规则都在服务层,页面只是把数据摆出来。一旦换成前端单页应用,或者后端有大量编排逻辑压在网关层,这个前提就松动了。你会发现很多东西能拆成纯函数去测,但拆完之后剩下的那部分组合行为,恰恰是最容易出问题的部分,而它落在单元和端到端之间的真空地带。这时候硬套金字塔,会出现单测覆盖率很漂亮、线上照样出问题的尴尬局面。2.2 绝大多数团队会不自觉地滑向冰淇淋甜筒倒金字塔,也就是冰淇淋甜筒反模式,是这个领域最经典的现象:上层用例最多,下层几乎空着。滑向甜筒的路径几乎是可预测的,我见过太多团队走出同一串脚印:上层用例所见即所得。写完点一下,页面跳转了、提示出来了,成就感立刻到位。写一条单测,尤其是纯逻辑单测,短期看不出任何直接产出。需求压缩时,写单测最容易被砍掉。它不产出可见功能,而端到端至少能证明这个功能能跑。写用例的人如果对代码内部结构不熟,只能从界面入手。这条对外包和新人尤其明显。上层用例是黑盒的,不需要读源码,上手门槛看起来更低。问题在于代价是延迟出现的。用例数涨上去之后,执行时间先涨,接着失败原因越来越难定位,然后开始出现不稳定的用例,团队的第一反应是加重试,重试掩盖掉真正的缺陷,最后没人敢动这套用例。与此同时,被反复透支的单元层继续萎缩,形成恶性循环。2.3 测试奖杯与钻石模型:针对前端和微服务的修正针对金字塔在前端场景的水土不服,社区里出现过一些修正模型,传播比较广的是测试奖杯,由 Kent C. Dodds 在 2018 年前后提出。它的结构是:静态检查打底,单元测试适量,集成测试作为主体,E2E 少量收口。这个模型对组件化前端特别贴切。一个表单组件的校验规则、状态流转、错误提示,用测试库渲染真实组件、模拟用户输入去验证,比把校验逻辑抽成纯函数单独测更接近用户真实遇到的情况,又不至于像端到端那样把整个后端都拖进来。微服务场景下,更常见的是钻石结构:单元测试和契约测试是两侧,端到端收敛到极少的几条。契约测试在这里是独立的一层,消费者端定义期望,提供者端验证实现,任何一方改了接口,不匹配会在各自流水线里立刻暴露,不需要把所有服务都拉起来跑一遍全链路。多团队并行开发时,这一层的价值尤其高,因为它把接口会不会炸这件事从端到端里剥离出来了。2.4 四种模型的横向对比模型分布特征适用场景主要风险金字塔单测最多,集成次之,端到端最少业务逻辑集中在服务端,界面较薄界面层组合行为覆盖不足冰淇淋甜筒上层最多,下层几乎空无,属于反模式慢、脆、贵,失败难定位测试奖杯静态检查打底,集成为主体前端单页应用、组件化系统集成环境搭建成本较高钻石单元与契约分层,端到端极少微服务、多团队并行契约版本与兼容性维护成本选哪个模型,判断依据不是哪个更先进,而是你们团队的钱花在哪里。如果大部分缺陷来自服务之间的接口理解偏差,那契约层就是性价比最高的一层;如果大部分缺陷来自页面上的状态组合,那就该把资源压在组件级集成测试上。3. 从目录到流水线:把分层变成可执行的物理约束3.1 目录结构与命名约定先行分层要落地,第一件事是让层在文件系统里可见。看不见的东西没法管理。服务端我通常这样组织,以 Java 项目为例:src/test/java/com/example/order/ unit/ # 纯逻辑,不启动 Spring 上下文 integration/ # 启动部分容器,连真实中间件 contract/ # 契约定义与验证 e2e/ # 从入口到出口的完整链路前端项目我更倾向把单元测试和组件放在一起,把集成和端到端单独拎出来:src/components/CheckoutForm/__tests__/CheckoutForm.test.tsx tests/integration/checkout-flow.spec.tsx tests/e2e/checkout.spec.ts命名上还有一个容易被忽略的细节:文件名和后缀要能自解释。OrderServiceTest和OrderServiceIntegrationTest一眼就能区分,比靠目录猜更可靠。我曾经接手过一个项目,所有测试都在同一个包下,只能靠打开文件读注解才知道跑起来是不是要连数据库,那种体验非常糟糕。3.2 标签体系:让同一份代码按层调度目录解决的是在哪,标签解决的是怎么跑。同一批测试代码,需要在不同场景下被不同地调用:提交前只跑受影响的单测,合并前跑全量单测加集成,每晚跑端到端。主流测试框架都有对应的机制。pytest 用 marker:# pytest.ini [pytest] markers unit: 无外部依赖的纯逻辑测试 integration: 依赖真实中间件的测试 e2e: 端到端链路测试 slow: 单条执行超过 10 秒Java 侧用 JUnit 5 的标签:Tag(integration) class OrderRepositoryIT { }前端如果用 Jest,可以用 projects 配置把不同目录拆成不同项目,一次命令只跑其中一部分:// jest.config.js module.exports { projects: [ { displayName: unit, testMatch: [rootDir/src/**/__tests__/**/*.test.tsx] }, { displayName: integration, testMatch: [rootDir/tests/integration/**/*.spec.tsx] } ] };标签体系最大的好处是让跑哪一层变成一个显式决定,而不是默认全跑。默认全跑是很多流水线变慢的根源。3.3 流水线的分层编排与时间预算分层的价值只有接进流水线才真正兑现。我一般按下面这个节奏编排:触发时机执行内容目标时长本地提交前静态检查、受影响单测30 秒内发起合并请求全量单测、集成测试10 分钟以内合并到主干上述全部加契约测试15 分钟以内每日定时端到端全量、稳定性重跑45 分钟以内时间预算是这套方案里最容易被执行偏的部分。很多团队会设定目标,但没人盯着,几个月后端到端从 20 分钟涨到 70 分钟,也没人吭声。我的做法是把预算写进流水线配置的注释里,并且加一条简单的校验:如果某层耗时超过预算的 120%,在合并请求上打一个警告标签,不阻断,但让所有人都看到。3.4 一份可以照着改的流水线骨架下面这段是常见的组合方式,思路比具体语法更重要:name: layered-tests on: [pull_request, push] jobs: static-and-unit: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - run: npm run lint npm run typecheck - run: npm run test:unit -- --coverage integration: needs: static-and-unit runs-on: ubuntu-latest services: postgres: image: postgres:16 env: POSTGRES_PASSWORD: test options: - --health-cmd pg_isready --health-interval 5s steps: - uses: actions/checkoutv4 - run: npm ci - run: npm run test:integration e2e: if: github.event_name push || github.event.schedule needs: integration runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - run: npm run test:e2e关键点是needs形成的依赖链,以及端到端只在合并后或定时触发。把端到端从每个合并请求里摘出去,是很多团队提升开发体验最快的一刀,前提是集成层足够扎实,能接住大部分回归。4. 各层的职责红线:什么样的用例不该出现在这一层4.1 单元层只测逻辑分叉,不测框架行为单元层该写的是:条件分支的每个出口、边界值、异常路径、算法结果。不该写的是:框架自身的行为、纯取值和赋值方法、替身返回替身这种自我循环的验证。我在评审里最常拦下的一类用例是这样的:// 不推荐:验证的是 mock 自己的行为 when(repo.findById(1L)).thenReturn(Optional.of(order)); assertThat(repo.findById(1L)).isPresent();这条断言跑绿了说明不了任何问题,它只证明了替身按照你写的方式返回。有价值的单元测试应该断言被测对象在给定输入下的输出或状态变化,而不是断言你刚刚配置的替身。还有一类常见误区是把所有依赖都替身化。如果一个类有七个依赖,全部 mock 之后测试里全是when(...).thenReturn(...),那通常说明这个类的职责太杂。测试写起来别扭,往往是被测代码设计有问题的信号,这时候应该改设计,而不是继续加替身。4.2 集成层要把真实的中间件拉进来集成层的核心价值是验证代码和真实外部组件的配合。这里的第一个大坑是用内存数据库替代真实数据库。我亲身踩过一次:项目里集成测试跑在内存数据库上,全绿。上线之后,一个基于行锁的并发扣减逻辑在高并发下出现了超卖。原因是内存数据库对某些锁语义和查询语法的支持与真实数据库不一致,测试里那条语句根本没被真正执行。后来全面换成容器化的真实数据库实例:Testcontainers class OrderRepositoryIT { Container static PostgreSQLContainer? pg new PostgreSQLContainer(postgres:16); DynamicPropertySource static void props(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, pg::getJdbcUrl); } }容器化之后启动会慢一些,单条用例多几百毫秒到一秒,但这个代价远小于生产事故。集成层最不该省的就是环境的真实性,省下来的时间会在排查线上问题时加倍还回去。4.3 契约层是服务边界上最便宜的保险当系统拆成多个服务之后,大部分线上故障其实来自接口理解偏差:消费者以为某个字段永远不为空,提供者某次改动把它变成了可空;消费者按字符串解析,提供者换成了数字。契约测试把这件事提前了。消费者端定义期望并生成契约文件,提供者端在流水线里验证契约。任何一方改动导致不匹配,在各自的流水线里立刻暴露,不需要把整套链路拉起来。这一层的红线是:契约要覆盖字段的可空性、类型、枚举取值范围,而不只是能调通。只验证状态码为 200 的契约几乎没有价值,因为绝大多数接口不兼容问题都发生在响应体结构上。4.4 端到端层的数量必须是刻意稀缺的端到端用例要覆盖的是用户完成一件完整事情的旅程,比如注册、登录、下单、退款、核心导航。它不是用来补集成层覆盖率的。数量上我一般建议控制在几十条以内。这个数字看起来很激进,但只要集成层和契约层做扎实,端到端完全可以只守住最关键的那几条主干路径。判断标准是:如果这条端到端用例挂了,业务是否真的不可用?如果答案是否定的,它就该往下层迁移。迁移的方法也很直接:把用例里通过界面完成的操作,换成直接调用接口,就变成集成层用例。我做过一次统计,两百多条端到端里,有一百多条实际只验证了接口返回值和数据库状态,界面操作只是到达那里的手段,这些全部可以下沉,迁移之后单次执行时间从五十多分钟降到十几分钟。4.5 一条用例该去哪一层:判断清单下面这张表是我在评审时实际在用的,分享出来供参考:问题回答结论验证的是纯逻辑分支吗是单元层需要真实数据库或消息队列吗是集成层验证的是两个服务之间的接口约定吗是契约层必须通过真实界面操作才能验证吗是端到端层下面三层都能等价验证吗是往下沉挂了是否代表核心业务不可用否重新考虑必要性这张表最大的作用不是分类,而是让往上层写变成一个需要说明理由的决定。默认往下走,才能抵抗住往端到端堆用例的天然惯性。5. 分层健康度:五个能提前预警塌陷的指标5.1 分层占比与执行时长分布第一个要看的是各层用例数量占比和各层耗时占比。这两个数字经常对不上,而对不上的地方往往就是问题所在。一个健康的分布大概是:单元层数量占八成以上,耗时占两成以内;集成层数量占一到两成,耗时占三到五成;端到端数量占个位数百分比,耗时控制在一到两成。如果端到端数量只占一成,但耗时占了六成,说明单条用例太慢,可能是每次都在重建环境,或者用例里塞了太多无关步骤。如果端到端数量占比超过一成五,基本可以判断已经滑向甜筒了。5.2 不稳定用例率与重试掩盖不稳定用例率(同一份代码重跑结果不一致的比例)是最灵敏的预警指标。它通常在质量明显下滑之前就开始抬头。我的经验阈值是这样:指标健康预警危险不稳定用例率低于 1%1% 到 5%高于 5%单测总时长2 分钟以内2 到 5 分钟5 分钟以上端到端耗时占比20% 以内20% 到 40%40% 以上端到端用例占比5% 以内5% 到 15%15% 以上这里要点名批评一个做法:自动重试。流水线里加一条失败自动重试三次看起来能减少误报,实际上把真实缺陷的概率稀释了。一条用例每三次才失败一次,重试之后大概率是绿的,但它每次都失败的那三分之一,可能对应着真实的并发问题或者时序问题。我见过的处理方式是把重试作为诊断手段而不是修复手段:允许重试,但被重试救回来的用例要记入不稳定清单,限期治理。5.3 缺陷逃逸归因要定期做上面几个指标反映的是测试体系的内部状态,缺陷逃逸归因反映的是它的实际效果。做法不复杂:生产环境每修一个缺陷,顺手记两个字段,一个是缺陷类型,一个是本该被哪一层拦住。攒一两个月之后就能看出规律。如果大量缺陷被标记为本该由单元层拦住,说明单元覆盖不够。如果大量缺陷落在本该由集成层拦住,通常是环境真实性不够或者集成用例太少。如果大量缺陷落在本该由端到端拦住,那要小心,因为端到端本身就是最后一道,它的设计目标不是拦住所有缺陷,而是守住主干路径,把拦截责任全压给它,说明下面的层有洞。5.4 覆盖率必须分层看整体覆盖率是一个很容易骗人的数字。一个项目整体覆盖率 78%,听起来不错,但如果拆开看,单元层 85%、集成层 12%、端到端 3%,那这个 78% 很可能全部来自单元层,集成层实际上是裸奔的。我一般按层设定目标:单元层对核心业务模块要求 80% 以上,集成层覆盖所有对外接口和关键持久化路径,契约层覆盖所有跨服务调用,端到端不设覆盖率指标,只设数量上限和耗时上限。端到端不设覆盖率指标这一点很关键。一旦给它设了覆盖率目标,团队就会为了数字去堆用例,而这恰恰是甜筒形成的主要推力。5.5 门禁阈值怎么设才不会被绕过设阈值容易,让人不绕过难。我见过太多覆盖率不达标就跳过检查的情况。比较有效的做法是分档处理:低于硬性下限直接阻断,比如核心模块单元覆盖率低于 70% 不允许合并;介于下限和目标之间只警告不阻断,但会记录到周报里;不稳定用例率超过阈值时冻结端到端新增,先治理再扩容。还有一点,阈值要定期回顾。项目初期设的阈值到中期可能完全不合适,长期不调整的阈值会慢慢变成摆设,大家看一眼就过去了。6. 三个月的塌陷与重建:一次真实的分层退化复盘6.1 塌陷是怎么开始的我参与过一个中等规模项目的测试体系重建,过程挺典型,记录下来当参考。项目起点其实是健康的:单元测试一千八百条,集成测试两百二十条,端到端四十五条,单测跑两分钟,集成跑六分钟,端到端跑九分钟。合并请求十分钟出结果,开发体验很好。转折点是第二轮大重构。因为接口签名调整,大约六百条单元测试直接编译不过。当时的决定是先删掉,后面补,这个决定本身不算离谱,但后面没有来。第四周开始,需求进入密集交付期。评审会上,写单元测试的工时被压缩,而端到端用例因为能直观展示功能确实能跑,被保留下来作为交付凭证。到第六周,端到端涨到一百八十条,单次执行五十五分钟。6.2 数据上的信号其实早就出现了回头看,预警信号在第五周就很明显了,只是当时没人系统看这些数字。第八周开始出现不稳定用例。最初的应对是加重试,失败自动重跑三次。重试之后流水线确实稳定了,但同一批用例每周仍然有七八条需要重试才能过。第十周,端到端涨到两百四十条,其中有大约十五条长期失败,处理方式是加跳过标记。到第十二周,第二波重构到来时,问题彻底暴露:没人知道那两百多条用例里哪条在验证什么,因为命名是test_order_flow_1这种,也没有任何注释。改任何一处界面,都可能连带挂掉十几条用例,修复它们的时间比改功能本身还长。当时端到端耗时七十多分钟,不稳定率超过 12%。6.3 重建的顺序:先冻结,再分类,最后设预算重建花了大约六周,顺序很关键,搞反了会反复。第一步是冻结端到端新增。所有新功能一律先补单元和集成用例,端到端只允许修改已有用例,不允许新增。这一刀切下去很疼,但没有它,一边治理一边增长,永远治不完。第二步是分类。我们把两百四十条用例逐条过了一遍,记录它实际验证的行为和依赖的层级。结果是:一百三十条实际只验证接口返回值和数据库状态,界面操作只是到达手段;四十条验证的是组件级交互,可以下沉到组件测试;三十条是重复覆盖;真正需要端到端的不到四十条。第三步是迁移。这一百三十条改成直接调接口,保留原有断言,执行时间从平均四十秒降到两秒左右。这一步工作量不小,但收益立刻可见。第四步才是设预算和门禁:端到端数量上限六十条,单次执行上限十五分钟,不稳定率超过 3% 冻结端到端新增,每周做一次缺陷逃逸归因。6.4 重建后的状态和仍然存在的问题重建完成后,单测从六百条恢复到一千五百条(不是简单补数量,而是按核心模块补),集成测试从两百二十条涨到三百八十条,端到端稳定在五十二条。合并请求的执行时间回到十二分钟。但有几个问题一直没完全解决,也值得说清楚。一是单元测试的重建速度慢于预期,因为补测试需要先理解当时的业务规则,而有些规则的原作者已经转岗了,只能靠读代码和翻需求文档反推。这说明测试用例同时也是业务规则的一种文档,删掉它的隐性成本比想象中大。二是契约层始终没建立起来,服务间调用只能靠集成测试覆盖。当时的理由是服务数量不多,后来服务拆到十一个,再想补契约测试,工作量已经翻了数倍。三是不稳定用例的治理是个长期活儿,最终稳定在 1.5% 左右,没有降到 1% 以下。后来复盘发现,剩下那部分主要来自几个涉及异步消息的用例,跟测试体系本身关系不大,属于系统设计层面的时序问题。如果你现在所在的项目正处于端到端越写越多、跑得越来越慢的阶段,我个人建议的动作顺序是:先统计各层的数量和耗时,再查一遍不稳定用例率,然后挑一批只验证接口和数据的端到端用例做下沉迁移。这三个动作不需要任何新工具,一周之内就能做完,做完之后你会对现状有一个完全不同的判断。至于要不要引入契约层、要不要调整模型,等这三步做完再说,那时候你手里的数据足够支撑决定了。