flowchart LR
N0["01 行为与策略"]
N1["02 单元与替身"]
N2["03 集成与容器"]
N3["04 接口与契约"]
N4["05 性能与故障"]
N5["06 回归与发布"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
测试与质量工程
现代 Java Backend Engineering 学习路线：测试与质量工程
0 子目录7 文档
CHAPTER OVERVIEW · 章节概览
先明确要保护的行为，再安排单元、集成和契约检查；通过真实依赖与故障演练形成发布证据。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
7测试与质量工程：从零开始的阶段导学改完一个方法，怎样知道没有弄坏登录、下单或数据保存？测试需要分层安排：小范围快速检查规则，真实依赖检查协作，再用少量端到端测试覆盖重要操作。先理解每层要发现什么问题，再讨论覆盖率。测试策略、JUnit 5 与 Mockito一个测试失败后，最好能直接告诉你哪条规则被破坏，而不是只显示两个很长的对象不相等。下面从业务行为出发写断言，再讨论什么时候使用 Mockito。替身用来隔离依赖，不是把所有真实逻辑都绕开。Spring 集成测试、Testcontainers 与契约测试单元测试通过，SQL 却在真实数据库上报错，这正是集成测试要补上的空缺。先选定要验证的边界，再决定使用 Spring 切片、Testcontainers 还是真实 HTTP 请求，避免每个测试都启动整套系统。API、UI 自动化与持续质量平台自动化脚本今天成功、明天随机失败，通常比没有脚本更让人困惑。下面围绕稳定的数据准备、元素定位和失败记录组织测试，让一次失败有信息可查，也让多条测试能互不干扰地运行。性能、稳定性测试与故障演练压测不只是把并发数调大。你需要先说清正常负载是什么、能接受多长的等待，以及资源是否会随时间增长。故障演练再回答另一个问题：某个依赖失效后，系统能否按预期恢复？Testing Portfolio：行为边界、回归与发布证据测试并不是越多越好，也不必严格凑出一个金字塔形状。更实际的做法是列出发布后最怕出错的几条路径，再安排反馈速度和成本合适的测试。下面把这组选择整理成可持续运行的回归方案。测试与质量工程推荐阅读挑测试资料时，可以跟着一次功能变更走：先测试业务规则，再测试数据库与接口，最后验证用户路径。下面的工具服务于不同层次，不需要把所有工具都塞进每个项目。