📚 课程目录第2章自动化测试基础

自动化测试基础：金字塔模型、分类与用例设计

各位同学好，我是老赵。今天咱们聊聊自动化测试的根基——测试金字塔、测试分类，还有用例设计原则。这些东西听起来基础，但我在团队里见过太多人栽跟头，说白了就是地基没打牢。

一、测试金字塔模型

先说说测试金字塔。这个概念是 Mike Cohn 在 2009 年提出的，到现在十几年了，依然管用。为什么？因为它揭示了测试投入的黄金比例。

核心思想：底层单元测试数量最多，中间集成测试适中，顶层 E2E 测试最少。越往上，执行成本越高，维护代价越大。

我个人的习惯是，一个新项目启动时，先画一张金字塔图贴在墙上。团队里每个人都能看到，我们到底该把精力花在哪。

我的经验：曾经有个项目，团队一上来就写 E2E 测试，结果每次 CI 跑 40 分钟，还经常因为环境问题挂掉。后来我强制要求先补单元测试，E2E 只保留核心流程。CI 时间降到 8 分钟，稳定性从 60% 升到 95%。

二、自动化测试分类

测试金字塔里的三层，对应三种自动化测试类型。咱们一个一个说。

1. 单元测试

单元测试测的是最小可测试单元——一个函数、一个方法、一个类。它不依赖外部环境，跑得飞快。

特点：执行快（毫秒级）、定位准、维护成本低
工具：JUnit（Java）、pytest（Python）、Jest（JavaScript）
我踩过的坑：曾经有人把数据库连接写进单元测试，结果测试跑一次要 3 秒。记住，单元测试里不要碰 IO。

// 一个合格的单元测试示例（Java + JUnit）
public class CalculatorTest {
    @Test
    public void testAdd() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 3);
        assertEquals(5, result);  // 不依赖任何外部资源
    }
}

2. 集成测试

集成测试测的是模块之间的交互。比如服务 A 调用服务 B，数据库读写，消息队列收发。

特点：需要轻量级环境（如 H2 内存数据库、Mock 服务）
工具：Spring Boot Test、Testcontainers、WireMock
注意：集成测试不是端到端，别把整个系统都启动起来

避坑指南：我曾经见过一个团队，集成测试里启动了完整的 Docker Compose 环境（MySQL + Redis + Kafka + 3 个微服务）。每次跑要 15 分钟，开发人员根本不愿意本地执行。集成测试应该轻量，能验证接口契约就行。

3. E2E 测试

端到端测试模拟真实用户操作，从 UI 点击到后端处理，再到数据库落盘，全链路验证。

特点：最接近用户视角、执行慢（秒级到分钟级）、环境依赖强
工具：Selenium、Cypress、Playwright
原则：只覆盖核心业务流程，别想着 100% 覆盖

维度	单元测试	集成测试	E2E 测试
执行速度	毫秒级	秒级	分钟级
定位粒度	精确到函数	精确到模块	精确到场景
维护成本	低	中	高
环境依赖	无	轻量	完整
推荐比例	70%	20%	10%

三、测试用例设计原则

写测试用例不是拍脑袋。我总结了几个原则，都是血泪换来的。

原则 1：FIRST 原则

这是单元测试的黄金法则，每个字母代表一个特性。

Fast（快速）—— 单个测试毫秒级完成
Isolated（隔离）—— 测试之间互不影响
Repeatable（可重复）—— 任意顺序执行结果一致
Self-validating（自验证）—— 不需要人工看结果
Timely（及时）—— 在代码提交前写好

举个例子：我见过有人写测试用例时，依赖前一个测试的执行结果。比如 testA 往数据库插了一条数据，testB 去查。结果 testA 失败了，testB 也跟着挂。这就是违反了 Isolated 原则。每个测试应该自己准备数据，自己清理。

原则 2：边界值分析

很多 Bug 出在边界上。比如一个输入框接受 1-100 的整数，你测试 1、100、0、101 就够了，不用测 2-99 每个数。

# 边界值示例（Python + pytest）
@pytest.mark.parametrize("input_val,expected", [
    (1, True),    # 下边界
    (100, True),  # 上边界
    (0, False),   # 下边界-1
    (101, False), # 上边界+1
])
def test_range_boundary(input_val, expected):
    assert is_in_range(input_val) == expected

原则 3：等价类划分

把输入数据分成几个等价类，每个类选一个代表值测试。比如年龄字段，有效等价类是 0-150，无效等价类是负数、大于 150、非数字。

等价类	代表值	预期结果
有效（0-150）	25	通过
无效（负数）	-5	拒绝
无效（超上限）	200	拒绝
无效（非数字）	"abc"	拒绝

原则 4：单一职责

一个测试用例只验证一个行为。别想着一个测试覆盖所有分支。

我的习惯：测试方法名就是我要验证的行为。比如 testLoginWithValidCredentials_shouldReturnToken，一看就知道测什么。如果测试失败了，看名字就知道哪里出了问题。

原则 5：可读性优先

测试代码是给未来的人看的（包括三个月后的你自己）。用 Arrange-Act-Assert（AAA）模式组织。

// AAA 模式示例
@Test
public void testWithdraw_balanceSufficient_shouldDeductAmount() {
    // Arrange（准备）
    Account account = new Account(1000);
    
    // Act（执行）
    account.withdraw(300);
    
    // Assert（验证）
    assertEquals(700, account.getBalance());
}

我曾经犯过的错：写了一个 200 行的测试方法，里面嵌套了 5 个 if 分支，还用了循环。后来需求变了，没人敢改那个测试，因为根本看不懂它在测什么。记住，测试代码的读者是维护者，不是编译器。

小结

这一章的内容，说白了就是三件事：

测试金字塔告诉我们，把精力花在底层，别在 E2E 上堆砌
三种测试各有分工，单元测逻辑、集成测交互、E2E 测流程
用例设计遵循 FIRST、边界值、等价类、单一职责、可读性

这些原则看起来简单，但真正坚持下来的人不多。我见过太多项目，一开始热情高涨写 E2E，三个月后维护成本爆炸，最后测试套件被废弃。嗯，希望你们能少走这些弯路。