testing
No related notes
Outlinks (0)
No outlinks found
Backlinks (0)
No backlinks found
1 · testing#
S 软件开发中，测试长期被视为编码完成后由独立团队执行的独立活动。敏捷和 XP 运动改变了这一格局，将测试提升为开发核心环节。 C 但实践中仍存在诸多困惑：测试金字塔怎么分层？单元/集成/端到端边界在哪？Mock 和 Stub 有什么区别？自动化测试就够了吗？团队常在这些问题上争论不休却缺乏统一框架。 Q 如何构建一套完整、分层、可落地的测试体系？ A Martin Fowler 给出的答案是：以**自测试代码（Self-Testing Code）**为核心，围绕三个维度构建体系——测试组合策略、测试分类与实现技术、自动化之外的补充手段。
1.1 · 核心理念：Self-Testing Code#
编写全面的自动化测试套件，一条命令即可运行，通过即可发布。这既是质量保障，也是重构和持续交付的前提。TDD（测试驱动开发）是实现这一目标的核心实践。
1.2 · 1. 测试组合策略——怎么分层#
- 测试金字塔（Test Pyramid）：底层大量 Unit Test，顶层少量 Broad Stack Test（端到端），中间是 Component/Integration Test
- 实践落地（Practical Test Pyramid）：按粒度分桶，每层有明确的测试类型和数量比例
- 微服务场景：引入网络分区后，需要重新思考测试策略，用 Contract Test 等方式管理跨服务依赖
- 金字塔 vs 蜂巢之争：Fowler 指出争论的根源是”单元测试”和”集成测试”的定义本身不清晰
1.3 · 2. 测试分类与实现技术——怎么写#
分类体系：
| 分类 | 含义 |
|---|---|
| Unit Test | 对最小单元的快速测试，定义其实模糊 |
| Integration Test | 验证独立开发的单元连接后能否正确工作，可窄可宽 |
| Component Test | 限定范围到系统某一部分 |
| Broad Stack Test | 端到端/全栈测试 |
| Contract Test | 验证外部服务契约是否变化 |
| Story Test | 面向业务的验收测试 |
| Subcutaneous Test | 绕过 UI 直接测底层 |
| Threshold Test | 在部署流水线中设阈值监控 |
实现技术：
- Test Double：Dummy / Stub / Spy / Mock / Fake 的统一术语体系
- Mocks ≠ Stubs：Mock 验证行为（behavior verification），Stub 提供状态（state verification），两种不同的测试风格
- Page Object：封装 HTML 页面的应用级 API，隔离 UI 变化
- Humble Object：把逻辑从难测元素中抽出，使不可测对象”谦卑化”
- Object Mother / Self Initializing Fake / Clock Wrapper：创建测试数据、模拟远程服务、控制时间的实用模式
- 消除非确定性测试：隔离、异步、远程服务、时间、资源泄漏是五大元凶
- 测试覆盖率：用来发现未测代码的工具，而非衡量测试质量的指标
- Test Impact Analysis：通过调用图分析只运行受变更影响的测试，加速构建
1.4 · 3. 自动化之外的补充——还缺什么#
自动化测试是一张精细的捕虫网，但仍不够：
- 探索性测试（Exploratory Testing）：快速学习-设计-执行循环，发现自动化测试覆盖不到的盲区
- 生产环境 QA（QA in Production）：通过日志和监控在生产环境发现质量问题，配合持续交付
- 合成监控（Synthetic Monitoring）：在生产环境定期运行自动化测试子集，将结果推送到监控系统
- 面向领域的可观测性（Domain-Oriented Observability）：以业务语义而非技术指标来添加可观测性，保持代码整洁