断言驱动测试概述

大家好，我是这门课的主讲人。今天咱们聊聊断言驱动测试——说白了，就是让断言成为测试用例设计的核心驱动力。

我刚开始做测试那会儿，写用例全凭感觉。想到什么测什么，测完就完事。结果呢？线上出bug了，回头一看，哦，那个场景我压根没覆盖到。后来我慢慢意识到，问题出在测试设计的方法论上。

什么是断言驱动测试

断言驱动测试，英文叫 Assertion-Driven Testing，简称 ADT。它的核心理念很简单：先定义“正确的结果应该是什么”，再围绕这个结果去设计测试步骤。

举个例子。你要测一个登录功能。传统做法是：先填用户名、填密码、点登录、看页面跳转。断言驱动呢？反过来想——登录成功后，系统应该返回一个 ，用户信息应该正确展示，session 应该建立。把这些断言先写下来，再倒推需要哪些输入和操作。

我个人习惯把断言分成三类：

• 状态断言：检查系统状态是否符合预期。比如“用户状态变为已登录”。
• 数据断言：检查数据内容是否正确。比如“返回的 user.name 等于输入的用户名”。
• 行为断言：检查系统行为是否发生。比如“登录成功后调用了埋点接口”。

嗯，这里要注意，三类断言不是互斥的。一个完整的测试用例，往往需要组合使用。

与传统测试的区别

传统测试用例设计，大家习惯用等价类、边界值、判定表这些方法。它们有用，但有个问题——太关注输入，不够关注输出。

我举个例子你就明白了。传统方式写一个购物车结算用例：

// 传统方式
步骤1：添加商品A到购物车
步骤2：添加商品B到购物车
步骤3：点击结算
步骤4：选择支付方式
步骤5：确认支付
// 然后呢？看一眼页面，嗯，成功了。

断言驱动的方式呢？

// 断言驱动方式
断言1：结算后，购物车中商品数量变为0
断言2：订单列表中新增一条记录，状态为“待支付”
断言3：库存系统中，商品A和B的库存各减1
断言4：支付接口被调用，参数包含正确的金额和商品ID
// 再设计步骤去触发这些断言

看出区别了吗？传统方式关注“我做了什么”，断言驱动关注“系统应该变成什么样”。

对比维度	传统测试	断言驱动测试
设计起点	输入和操作	预期结果（断言）
覆盖完整性	容易遗漏边界场景	断言倒逼覆盖所有关键结果
可读性	步骤多，意图不清晰	断言即文档，一目了然
维护成本	需求变更时，步骤全改	只改断言，步骤相对稳定
自动化友好度	需要额外提取断言点	天然适合自动化

说白了，传统测试像“摸着石头过河”，断言驱动像“先画好地图再出发”。

核心价值

断言驱动测试到底好在哪？我总结了几点：

1. 测试意图更清晰。断言就是测试的“灵魂”。别人看你的用例，不用读步骤，看断言就知道你要测什么。
2. 覆盖更全面。你想想看，如果你先写断言，是不是会逼着自己思考“这个功能到底会产生哪些影响”？很多隐藏的边界条件，就是这么被挖出来的。
3. 自动化更顺畅。断言驱动设计的用例，天然就是自动化脚本的骨架。断言写好了，剩下的就是填充步骤代码。
4. 回归更高效。需求变了？没关系，先改断言，再调整步骤。断言不变的部分，说明功能没变，用例可以复用。

适用场景

不是所有场景都适合断言驱动。我踩过坑，跟大家说说。

最适合的场景：

• 接口测试、API 测试——输入输出明确，断言好定义
• 业务逻辑复杂的模块——比如订单、支付、库存，结果状态多
• 自动化回归测试——断言稳定，脚本维护成本低
• 数据驱动测试——断言模板化，数据变化不影响断言结构

不太适合的场景：

• UI 视觉测试——断言“按钮是红色的”太脆弱，容易误报
• 探索性测试——你都不知道系统会怎么反应，怎么写断言？
• 性能测试——关注的是吞吐量和响应时间，不是单个断言

知识体系总览

下面这张图，是我对断言驱动测试整体知识结构的梳理。你可以把它当作这门课的“导航图”。

这张图展示了断言驱动测试的完整知识体系。从核心概念到设计方法，再到实践落地，环环相扣。后面的章节，我们会逐一深入每个模块。

好了，第一章就到这里。记住一句话：好的断言，胜过千行测试代码。下一章，我们聊聊如何写出高质量的断言。

---

可可精品资料库