冒烟测试:先确认「它根本没炸」

名字的由来:通电,不冒烟

「冒烟测试」这个词不是软件发明的。硬件工程师组装好一块电路板,第一件事不是测每个功能,而是通上电,看它冒不冒烟。要是一通电就冒烟(短路、元件烧了),后面所有测试都不用做了 —— 先把这个致命问题解决。管道工也有类似的:新装的管道里打进烟雾,看哪儿漏。

软件里的冒烟测试长什么样

它是从你所有测试里,精心挑出的一小撮(通常几十个),特点是:

一个 Android App 的冒烟套件可能就这么几条:

// 冒烟:每一条都是「这条路彻底断了 = 版本报废」
@Test fun `App 能冷启动不崩`() { launchActivity<MainActivity>().use { /* 起来了 */ } }
@Test fun `登录页能渲染`()      { compose.onNodeWithText("登录").assertIsDisplayed() }
@Test fun `正常账号能登录进首页`() { /* 一条最短的登录旅程 */ }
@Test fun `首页能加载出列表`()   { /* 主数据流通了 */ }

对比一下:一个功能可能有 50 个测试覆盖它的各种边界(单元),但冒烟套件里只放那 1 个「它的核心能用」。冒烟不是要测得全,是要测得快、广、命中要害。

守门员:先冒烟,再全量

冒烟测试最大的价值,在 CI 流水线里 —— 它让整条流水线快速失败(fail fast)。下面这个 Demo 就是 CI 的分层结构:每个阶段跑哪些测试、要多久。切换阶段看看。

注意「冒烟」在每一个阶段都跑,而且跑在最前面。这是它的核心用法:

冒烟 vs 回归 vs 全量:别搞混

这几个词常被混着用,理一下:

特别说一下回归测试:它不是一种独立写法,而是一个习惯 —— 每修一个 bug,就补一个「专门复现这个 bug」的测试。这个测试从此留在套件里,守着这个 bug永不复活。

AI 时代:冒烟是巨型改动的第一道闸

AI 让「大改动」变得廉价 —— 它可能一次重构几十个文件、生成一整个新模块。改动越大,「从根上就搞坏了」的概率越高(某个依赖没接上、某个初始化顺序乱了)。

冒烟在流水线里长什么样

把「先冒烟再全量」落成具体的 CI 配置。用 GitHub Actions 举例,关键是让冒烟成为后续任务的前置依赖:

jobs:
  smoke:                      # 第一关:又快又致命
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew smokeTest    # 只跑打了 @Tag("smoke") 的那几十个
    # ~30 秒

  full:                       # 全量:必须等冒烟绿了才开始
    needs: smoke              # ← 关键:冒烟红,这一关根本不启动
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew test         # 上千个单元 + 集成
    # ~几分钟

那句 needs: smoke 就是守门员的具体形态:冒烟这关红了,后面那个跑几分钟的全量任务压根不会启动 —— 省下的机器时间和你的等待,都是白赚的。在 Gradle/JUnit5 里,「哪些算冒烟」通常用一个 @Tag("smoke") 标注,再配一个只跑这个 tag 的任务。

「冒烟」这个词,在不同语境下

冒烟的思想到处都是,只是换了名字。理解这一点,你会在很多地方认出它:

尤其是部署后的冒烟(健康检查)值得单说:代码测试全绿,不代表部署成功 —— 配置错了、环境变量漏了、依赖的服务连不上,都会让一个"测试全过"的版本在生产环境起不来。部署完立刻跑一小撮真打生产环境的冒烟(登录能进吗、首页接口 200 吗),是把「部署事故」和「代码事故」分开的关键一步。这也是为什么金丝雀发布总是「先切 1% 流量,冒烟通过,再逐步放大」。

回归测试:一个 bug,一个永久哨兵

上面提了回归是「习惯」而非「写法」,这里把它讲透,因为它是性价比最高的测试类型之一。每一个被修复的 bug,都该留下一个测试,像哨兵一样站在原地:

// 线上事故:某优惠券在金额正好等于门槛时不生效
// 修复的同时,留下这个哨兵。名字里最好带上工单号,方便追溯。
@Test fun `regression PROJ-1234 券在金额等于门槛时生效`() {
    val result = applyCoupon(total = 100, coupon = "SAVE20")   // 边界:正好 100
    assertEquals(80, result)   // 修复前这里是红的
}

第二幕收尾。你现在有了完整的测试地形图:单元(底盘)、集成(接缝)、端到端(旅程)、冒烟(守门员)。第三幕转向手艺 —— 同样是这些测试,写好和写坏差十倍。第一课最基础也最关键:怎么挑输入,才抓得到 bug。