测试层次
§1摘要与结论
测试层次是按开发生命周期阶段组织并一起管理的测试活动分组，通常从组件级逐层上升到系统级与验收级；每个层次针对不同的测试对象与关注点，回答不同的问题，并对应不同的缺陷类型与执行主体。
别名：test level、test levels、测试层次、单元集成系统验收、测试阶段 | 英文：Test Levels | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
把测试划分为层次，是为了让不同种类的缺陷在各自最合适的位置被发现。层与层之间的区别主要在于测试对象的范围与关注的问题：组件级测试关注单个组件在隔离状态下的正确性，集成测试关注组件之间接口与协作是否成立，系统级测试关注整个系统端到端的行为与质量特性，验收测试关注系统是否满足用户与业务需要。不同层次揭示不同类别的缺陷：组件级善于发现逻辑与边界错误，集成级善于发现接口契约与数据传递问题，系统级善于发现跨组件的流程缺陷，验收级善于发现需求理解偏差。由于缺陷若在其引入的层次未被发现，往往会以更隐蔽的形式流向下游并抬高修复成本，因此层次划分同时是一种分层拦截策略。层次并非越细越好，其数量与命名可能随开发模式变化，关键是每一层都有明确的测试对象、关注点与责任归属。
§4机制 · 如何运作
测试层次沿开发生命周期向上组织，每一层是测试过程的一次实例。组件级（单元级）测试在隔离状态下运行单个组件，通常由开发者借助测试替身切断外部依赖，快速验证逻辑；集成测试把已开发的组件连接起来，验证它们能否正确协同，可从窄范围逐步扩展到较大范围；系统级测试面向完整系统或产品，评估整体行为与质量特性，常在接近真实的环境中执行；验收测试从用户与业务视角确认系统是否满足需要并达到部署就绪，形式包括用户验收、运维验收、合同验收与法规验收等。各层共享相同的测试设计技术，但侧重点与执行主体不同：底层多由开发者频繁执行、追求快速反馈，高层多由独立测试角色或在交付节点执行、追求真实与可信。层次之间存在信息流动：底层保证组件可信，中层保证组合可信，高层才可能在可接受的成本下验证整体可信。
§5工程 · 怎么落地
工程实践要为每个层次明确其目标与退出条件，避免层次混同或重复。组件级测试应快速、隔离、可重复，作为开发者的日常反馈工具；集成测试应聚焦接口契约与协作边界，可用消费者—提供者契约测试稳定跨团队接口；系统级测试应覆盖关键用户流程与重要质量特性，并在有代表性的环境中运行；验收测试应由业务方参与，以可执行的方式确认需求是否达成。分配测试数量时应考虑成本与保真度：低层测试便宜稳定，应承担大部分逻辑验证；高层测试昂贵且脆弱，应聚焦少数关键路径。每层都应明确失败时的处置方式与责任归属，使问题在尽可能低的层次被拦截。同时应避免层次间的重复：同一行为若已在低层充分验证，高层只需验证集成后的协同，而不是复制相同断言。各层测试应共享统一的结果与追溯口径，使一次失败能够快速定位到所属层次与责任边界，减少跨层排查的成本。跨层测试应共同维护同一份关键路径清单，避免遗漏与重叠。
§6权衡卡
测试层次划分并非没有代价。
层次越多，所需的测试基础设施、环境与协调成本越高；层次划分过细会导致测试重复与边界争执，过粗又会留下拦截缺口。
高层测试虽然更贴近真实，却慢、贵且易受环境影响，过度依赖会使反馈迟缓、维护负担沉重；低层测试虽快，却无法覆盖组件协同与真实使用中的缺陷，只测底层会漏掉大量集成与需求层面的问题。
因此层次划分应服务于快速反馈与有效拦截的平衡，按项目风险、团队结构与交付节奏调整各层的侧重与数量，而不是机械套用固定模板。
反例之一是把层次等同于阶段串行：要求底层测试全部完成才进入集成、集成完成才进入系统测试，这会在变更频繁时造成长时间的等待与反馈滞后。
反例之二是只保留一个层次，如仅做端到端测试或仅做单元测试，前者反馈慢而脆，后者无法验证系统价值。
- 关键在于让每一层都承担其最擅长的验证责任，而不是用层次数量或高层测试的比重来衡量质量投入。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§9信源与核验
核验结论：测试层次是按测试对象范围组织测试活动的分组，与开发阶段并非硬性串行；在敏捷与持续交付中，各层测试可并行存在，关键是每层有明确的目标与责任归属 [OFF-019]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依赖关联 | ← MTH-I-04 | 测试金字塔与反模式 E-491 | 测试金字塔按测试层次组织测试分布 |
| 依据推导 | → ESS-I-01 | 测试作为验证与反馈机制本质 E-485 | 测试层次以测试的验证与反馈本质为依据 |
| 实现 | ← TEC-I-03 | xUnit 测试框架族 E-818 | xUnit 框架族支撑组件级单元测试层次 |
| 前置依赖 | → MTH-I-02 | 测试类型 E-490 | 测试层次是应用测试类型的结构前提 |