<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testing on Luca's Blog</title><link>https://wlj.me/tags/testing/</link><description>Recent content in Testing on Luca's Blog</description><generator>Hugo</generator><language>zh</language><lastBuildDate>Mon, 04 May 2026 20:43:41 +0800</lastBuildDate><atom:link href="https://wlj.me/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>冒烟测试这个名字是怎么来的</title><link>https://wlj.me/posts/where-smoke-test-name-comes-from/</link><pubDate>Mon, 04 May 2026 20:43:41 +0800</pubDate><guid>https://wlj.me/posts/where-smoke-test-name-comes-from/</guid><description>&lt;p>写代码的人都听过冒烟测试（smoke test）：部署完之后跑一组最基础的用例，看核心功能能不能开机，主接口返不返回 200。挡掉最低级的爆炸，过了再谈别的。&lt;/p>
&lt;p>但&amp;quot;冒烟&amp;quot;这个词从哪儿来的？&lt;/p>
&lt;p>最早的版本来自水管工。管道装完之后往里灌烟，看哪里漏。漏烟的地方就是漏水的地方。先堵漏，再谈通水。&lt;/p>
&lt;p>第二个版本来自电子电路。电路板焊完通电，如果哪儿短路了、元件烧了，会冒烟。冒烟说明连基本通电都过不了，更别谈跑功能。不冒烟才轮得上下一步。&lt;/p>
&lt;p>软件圈把这个比喻搬过来。微软 1990 年代把它写进开发流程：每日构建配冒烟测试，build 完先跑一遍最基础的用例，挂了直接 fail，过了再让 QA 接手。后来传开。&lt;/p>
&lt;p>所以冒烟测试的逻辑一直没变：先验证它没冒烟，再验证它能干活。&lt;/p></description></item></channel></rss>