构建之法阅读笔记05

阅读内容
《构建之法》第二版 第13章～第15章（软件测试、质量保障、稳定和发布阶段）

核心概念摘要
软件测试不是"开发做完之后才开始的阶段"，而是贯穿整个软件生命周期的质量活动。书中区分了多种测试类型：单元测试验证单个模块的正确性，集成测试验证模块间交互，系统测试验证端到端业务流程，验收测试验证是否满足用户期望。一个关键概念是测试的"杀虫剂悖论"：同一组测试用例反复运行后，发现新 bug 的能力会逐渐衰减——就像害虫会产生抗药性——因此测试用例需要不断更新和扩充。

稳定和发布阶段是软件从"能用"到"敢发布"的最后一公里。书中介绍了版本管理（分支策略、tag 规范）、发布检查清单（Release Checklist）、以及灰度发布和回滚机制。核心思想是：发布不是一次性事件，而是一个可以被控制节奏、可以被监控、可以在必要时安全回退的过程。狗粮文化（Dogfooding）——团队自己先在日常工作中使用自己的产品——是发现可用性问题最廉价有效的手段。

书中还讨论了一个常被忽视的事实：软件项目的后期并不是"越改越稳定"的线性收敛过程。每修一个 bug 都有一定概率引入新的 bug，收敛速度取决于代码的可维护性和团队的测试覆盖率。没有自动化测试护体的老项目，后期的每一次修改都是在赌博。

个人感受
1、我过去是怎么做的

我以前对测试的态度可以概括为两个字：抵触。写完代码之后，我顶多在浏览器里手动跑一遍"快乐路径"——输入正确的数据、点正确的按钮，看到结果出来了就觉得"好了，没问题"。我从来没有写过单元测试，也从来没有故意输入过非法数据去看系统会不会崩。我甚至觉得写测试是在"浪费时间"，因为"功能都跑通了还测什么？"

到了项目要交的前一天晚上，代码一股脑把所有功能合到一起，简单测几条就提交了，从来没有发布检查清单这种东西。"发布"就是：把最新代码部署到服务器上，重启一下，如果首页能打开就算发布成功。完全不知道灰度发布是什么意思，更不用说回滚预案了——出了问题就是紧急改，改了再覆盖部署。

2、结合书中所讲，说明为什么这样不好

书中用一个数据让我彻底改变了对测试的看法：缺陷发现的阶段越晚，修复成本越高。 需求阶段发现一个问题的修复成本如果是 1 块钱，编码阶段发现就是 10 块，测试阶段是 100 块，发布到生产环境之后就是 10000 块。我之前把发现 bug 的责任全部推后到手动点两下的步骤，实际上每一次手动测试都是拿生产环境的修复成本在赌博。

更深层的问题在于：没有自动化测试的代码等于是没有安全网的走钢丝。 书中指出，在有一定规模的项目中，修改一处代码而不引发其他位置故障的概率，随着代码量增长而急剧下降。我之所以觉得"改动不大测一下就行"，是因为我一直在做小项目。一旦代码量超过万行，任何一次修改都有可能触发远端模块的连锁反应——而手动测试根本覆盖不了那个远端。这恰恰解释了为什么我参与的大项目总是在后期越改越烂：每一次"小修小补"都在引入新 bug，而这些新 bug 没有任何自动化机制来捕获。

关于发布，书中的"狗粮文化"概念让我意识到一个我们团队的经典错误：我们做的系统自己根本不用。如果团队自己每天都要用它来处理真实事务，我们早就会发现那个审批流程的交互设计有多么反人类，根本不会等到交给用户才被抱怨。

3、解决办法

测试金字塔策略：从下到上构建——底层大量单元测试（覆盖所有核心函数和边界条件），中层适量集成测试（覆盖关键 API 和数据库交互），顶层少量 UI 端到端测试（只覆盖核心业务流程）。每次提交代码自动运行单元测试和集成测试，红色不合并。
"破坏性测试"习惯：每个功能完成后，在写测试用例时故意设计至少 3 个异常输入场景——空字符串、超长文本、并发请求、网络超时——确保系统在这些情况下不会崩，至少不会静默失败。把这个习惯固化为 Definition of Done 的一项。
发布三件套：每次正式发布前强制准备三样东西——（1）发布检查清单（功能项逐条确认 + 非功能指标如 P95 响应时间、错误日志量）；（2）灰度方案（先对 10% 用户开放，观察 30 分钟无告警再全量）；（3）回滚脚本（一键回到上一个稳定版本，不限于是代码回滚，数据库 schema 变更也要有回滚 SQL）。