第 8 周｜主打科目：综合知识 + 论文｜对应知识域：软件实现与测试、系统运行与维护
｜主打基本问题：Q4 —— 系统上线是终点还是起点？”可维护性”在什么时候买最便宜？
｜本阶段产出：测试策略 + SQA 计划 + 配置管理方案
项目宪法与四问表述见 00-课程总纲.md；三科题型与选做策略见 02-考点地图.md。
一、情境开场（Hook）
系统上线前一周，测试组丢过来一份报告：回归测试跑了 4 小时，发现 23 个缺陷，其中 7 个是三个月前就修过、这次又复现的。
你翻开缺陷单，看到这样一条：
「缺陷 #1042：修改检验标准后，历史追溯结果随之改变（应为历史快照）」
状态：已修复（2024-05-11） → 重新打开（2024-08-27）
再往下翻，修复记录里写着”已在 QualityTraceService.java 第 214 行修正”——但你记得那份代码在 6 月的一次”性能优化”里被整个重写过。你查版本库，发现那次重写没有走变更评审，是开发为了赶进度直接推上去的。
更糟的是，QA 问你：”这 23 个缺陷里，哪些属于必修？”你答不上来，因为从来没有人定义过”什么算可上线”的质量标准。
你意识到，前面 7 周建的每一份文档——需求、模型、架构、数据——最终都要靠这一周的验证与治理来兜底。而没有配置管理、没有回归基线、没有发布标准，前面所有的严谨都会在最后一周漏光。
于是本周的问题浮出水面：系统上线到底是终点还是起点？”可维护性”这个属性，究竟在什么时候买最便宜？
二、为什么学这一周（Where & Why）
- 测试层次与覆盖强度：综合知识 4–6 题，年年考。尤其”语句覆盖 / 判定覆盖 / 条件覆盖 / 判定-条件覆盖 / 条件组合覆盖 / 路径覆盖”的强度排序与用例数计算，是典型的送分题，不背等于白丢。
- 黑盒与白盒方法：综合知识 3–4 题，常考”等价类划分与边界值分析的区别””因果图适用于什么场景”。
- SQA 与 QC 的区别、软件评审：综合知识 2–3 题；审查（Inspection）的四种角色是冷门但稳定的考点。
- CMMI 五级与 Scrum 三三五：综合知识 3–5 题，且是论文”信息系统开发及应用”方向的重要素材。
- 配置管理与基线：综合知识 2–3 题，与 S09 的变更控制直接衔接。
- 系统转换方式与维护四类型：综合知识 3–4 题纯记忆，维护四类型的判定是必拿分。
- 论文价值：「测试策略 / 质量保证 / 配置管理」是论文”信息系统开发及应用”里最容易写出真实细节的三块——因为你一定经历过缺陷复现、版本混乱、上线回滚。
三、核心讲义（Equip）
3.1 软件测试的层次
定义：测试是按照由小到大、由内到外的顺序逐步验证系统的过程。
| 层次 | 测试对象 | 依据文档 | 主要执行者 | 回答的问题 |
|---|---|---|---|---|
| 单元测试 | 模块 / 函数 / 类 | 详细设计说明书、源程序 | 开发人员 | 这个模块自己是否做对了？ |
| 集成测试 | 模块间的接口与调用 | 概要设计说明书、架构文档 | 开发 / 测试 | 模块拼起来是否还能工作？ |
| 确认测试（有效性测试） | 整个软件 | 需求规格说明书 | 测试人员 + 用户 | 是否满足需求规格？ |
| 系统测试 | 软硬件整体 | 系统需求、非功能需求 | 测试人员 | 在真实环境下是否达标（性能、安全、压力、恢复）？ |
| 验收测试（α / β 测试） | 面向用户的最终系统 | 用户需求、合同 | 用户（α 在开发方场地，β 在用户场地） | 用户是否接受？ |
为什么需要这个层次结构：缺陷发现得越晚，修复成本越高（需求阶段 1×，设计 5×，编码 10×，测试 20×，运维 100×+）。分层测试的本质是把缺陷拦截在廉价的阶段。
真题级例子：”某系统在与外部支付网关联调时发现金额字段精度丢失”→ 这是集成测试问题（接口层面）；”用户反映查询报表要等两分钟”→ 这是系统测试中的性能测试问题。
3.2 静态测试与动态测试；黑盒与白盒
| 分类维度 | 类别 | 说明 |
|---|---|---|
| 是否运行程序 | 静态测试 | 不运行：代码审查、代码走查、静态分析、文档评审 |
| 动态测试 | 运行程序：构造测试数据、执行、比对实际与预期 | |
| 是否看内部结构 | 黑盒测试 | 不看内部结构，只依据规格说明书验证功能 |
| 白盒测试 | 看程序内部逻辑，依据代码结构设计覆盖 |
黑盒方法（依据 SRS，不看代码）：
| 方法 | 核心思想 | 适用场景 |
|---|---|---|
| 等价类划分 | 把输入域划分为若干等价类，每类取一个代表值 | 输入条件可以分类（有效/无效等价类） |
| 边界值分析 | 取正好等于、刚大于、刚小于边界的值 | 错误最常见于边界（常与等价类配合使用） |
| 因果图 / 判定表 | 分析输入条件（因）与输出动作（果）的组合关系 | 条件组合多、动作明确的复杂逻辑 |
| 错误推测法 | 凭经验猜测可能出错的地方 | 补充手段，不能单独依赖 |
| 正交试验设计法 | 用正交表挑选有代表性的组合 | 组合爆炸时减少用例数 |
白盒覆盖强度（从弱到强，必须背下来）：
| 覆盖准则 | 要求 | 强度 |
|---|---|---|
| 语句覆盖 | 每条语句至少执行一次 | 最弱 |
| 判定覆盖（分支覆盖） | 每个判定的真、假分支至少各执行一次 | ↓ |
| 条件覆盖 | 每个判定中每个条件的真、假值至少各出现一次 | ↓ |
| 判定-条件覆盖 | 同时满足判定覆盖与条件覆盖 | ↓ |
| 条件组合覆盖 | 每个判定中所有条件的所有取值组合至少出现一次 | ↓ |
| 路径覆盖 | 覆盖程序中所有可能的执行路径 | 最强（含循环时通常不可达） |
注意：判定覆盖与条件覆盖互不包含——满足其中一个不一定满足另一个。这是常考的辨析点。
条件组合覆盖 ⊇ 判定-条件覆盖 ⊇ 判定覆盖/条件覆盖 ⊇ 语句覆盖。
真题级演算：
if (A > 1 && B == 0) { X = X / A; }
if (A == 2 || X > 1) { X = X + 1; }- 语句覆盖：1 个用例（取 A=2, B=0, X=4，走完全部语句）。
- 判定覆盖：2 个用例（两个判定各取一次真、一次假）。
- 条件覆盖：覆盖 A>1、B==0、A==2、X>1 四个条件的真假各一次。
- 条件组合覆盖：第一个判定中 (A>1, B==0) 有 4 种组合，第二个判定中 (A==2, X>1) 有 4 种组合，共需 8 个用例（实际因短路求值可合并）。
3.3 测试类型辨析
| 类型 | 目的 | 关键特征 |
|---|---|---|
| 回归测试 | 验证修改没有引入新缺陷 | 复用已有用例集，是变更的守门人 |
| 冒烟测试 | 快速验证版本是否值得进入正式测试 | 只跑核心流程，不通过就打回 |
| 负载测试 | 在预期负载下验证系统表现 | 正常到峰值 |
| 压力测试 | 在超出极限下找系统的崩溃点与恢复能力 | 破坏性 |
| 性能测试 | 验证响应时间、吞吐量、并发数等指标 | 需事先定义可度量的指标 |
| 安全测试 | 发现漏洞（注入、越权、XSS 等） | 常用渗透测试与扫描工具 |
| 恢复测试 | 验证故障后的恢复能力 | 与 RTO/RPO 关联 |
调试（Debugging）与测试（Testing）的区别：测试是发现缺陷，调试是定位并修复缺陷。测试可以由第三方做，调试只能由理解代码的人做。
3.4 软件质量保证 SQA
定义：SQA（Software Quality Assurance）是一套有计划、有组织、贯穿整个生命周期的活动，目的是保证产品与过程满足既定要求。
SQA 与 QC 的区别（高频辨析）：
| 质量保证 QA | 质量控制 QC | |
|---|---|---|
| 关注对象 | 过程 | 产品 |
| 时机 | 全过程的预防性活动 | 事后检查 |
| 手段 | 评审、审计、过程定义与改进 | 测试、检查、度量 |
| 回答的问题 | “我们的做法对吗？” | “做出来的东西对吗？” |
软件评审（Review）的四种形式
| 形式 | 正式程度 | 特点 |
|---|---|---|
| 临时评审 / 走查（Walkthrough） | 低 | 作者讲解，参与者提问 |
| 轮查（Pass-around） | 低 | 分发材料，各自审读后反馈 |
| 审查（Inspection） | 高 | 有明确角色、阶段与检查表，正式记录缺陷 |
| 技术评审（Technical Review） | 中 | 侧重技术方案的评估 |
审查的四种角色（冷门考点）：主持人（Moderator，组织与主持，不评审自己的材料）、作者（Author，提供材料并答疑）、评审员（Reviewer，发现并记录缺陷）、记录员（Recorder，记录缺陷与决议）。
另有”讲解员”（Reader）角色用于逐段朗读材料，保证评审覆盖一致。
3.5 过程改进模型：CMM / CMMI 与敏捷
CMMI 五级（阶段式表示法，从低到高）
| 等级 | 名称 | 核心特征 |
|---|---|---|
| 1 | 初始级 | 过程无序，成功依赖个人英雄 |
| 2 | 已管理级 | 项目级的过程已计划、已执行、可跟踪（需求管理、项目计划、配置管理、质量保证） |
| 3 | 已定义级 | 过程被标准化并在组织级统一，有组织过程资产 |
| 4 | 量化管理级 | 过程与质量被量化管理，用统计方法控制 |
| 5 | 优化级 | 基于量化反馈持续过程改进，主动引入创新 |
CMMI 两种表示法：阶段式（五级，逐级过级）与连续式（按过程域各自评能力等级 0–5）。
Scrum 三三五
| 类别 | 内容 |
|---|---|
| 三角色 | Product Owner（定价值与优先级）、Scrum Master（守流程、清障碍）、开发团队（自组织交付增量） |
| 三工件 | 产品待办列表（Product Backlog）、Sprint 待办列表（Sprint Backlog）、增量（Increment） |
| 五事件 | Sprint、Sprint 计划会、每日站会（15 分钟）、Sprint 评审会、Sprint 回顾会 |
3.6 软件配置管理
配置项（SCI）：需求文档、设计文档、源代码、测试用例、数据字典、构建脚本等一切需要受控的工作产品。
基线的三种类型（必背）
| 基线 | 何时建立 | 内容 |
|---|---|---|
| 功能基线 | 系统分析与软件定义阶段结束时 | 系统需求规格说明书 |
| 分配基线 | 需求分析阶段结束时 | 软件需求规格说明书 |
| 产品基线 | 软件组装与系统测试阶段结束时 | 全部配置项 + 测试报告 |
配置管理的四项活动：配置标识 → 变更控制 → 配置状态报告 → 配置审计。
其中配置审计分功能审计（验证配置项是否符合需求）与物理审计（验证交付物是否齐全、版本是否一致）。
版本控制策略
| 策略 | 特点 | 适用 |
|---|---|---|
| 主干开发（Trunk-based） | 频繁集成到主干，短分支 | 持续交付、要求高集成频率 |
| GitFlow | master / develop / feature / release / hotfix 多分支 | 有明确版本发布节奏 |
| 特性开关（Feature Toggle） | 代码合入但功能关闭 | 解耦”部署”与”发布” |
3.7 系统转换方式与维护类型
系统转换四种方式
| 方式 | 做法 | 风险 | 成本 | 适用 |
|---|---|---|---|---|
| 直接转换 | 某时刻旧系统停机、新系统启用 | 最高 | 最低 | 小系统、可容忍中断 |
| 并行转换 | 新旧系统并行运行一段时间 | 最低 | 最高（双份工作量） | 关键业务系统 |
| 分段转换 | 分阶段、分模块逐步切换 | 中 | 中 | 大型系统的常见选择 |
| 试点后转换 | 先在一个部门/厂区试点，成功后再推广 | 较低 | 中 | 多厂区、多网点 |
本项目有 3 个厂区，最适合的是试点后转换（先在一个厂区跑通）配合分段转换（先质量追溯、后生产执行）。
维护四类型（纯记忆送分题，必须一字不差）
| 类型 | 触发原因 | 本项目例子 |
|---|---|---|
| 正确性维护 | 修 bug | 修复”修改检验标准后历史追溯结果随之改变”的缺陷 |
| 适应性维护 | 适应环境变化 | 操作系统 / 数据库升级、信创改造 |
| 完善性维护 | 加功能、提性能（用户主动提出） | 增加”按供应商维度统计质量”的报表 |
| 预防性维护 | 为将来可维护性改造 | 把 12 年老 MES 的存储过程重构成可测试的服务 |
判定口诀：修 bug = 正确性；换环境 = 适应性；加功能 = 完善性；为将来 = 预防性。
考题常给”为适应新的操作系统而修改”→ 适应性；”用户要求增加报表”→ 完善性。
可维护性子特性（ISO/IEC 25010）：易分析性、易改变性、稳定性、易测试性、可维护性的依从性。
四、典型考法
4.1 综合知识怎么考
例 1 下列关于白盒测试覆盖准则的说法，正确的是（ ）。
A. 判定覆盖一定包含条件覆盖
B. 条件覆盖一定包含判定覆盖
C. 条件组合覆盖一定包含判定-条件覆盖
D. 语句覆盖是最强的覆盖准则
答案：C。 判定覆盖与条件覆盖互不包含——判定覆盖只要求每个判定的真假分支各执行一次，不保证判定内每个条件的真假都出现；反之亦然。条件组合覆盖要求每个判定内所有条件的取值组合都出现，因此必然满足判定覆盖与条件覆盖，即包含判定-条件覆盖。语句覆盖是最弱的。
例 2 某系统在升级数据库后对程序进行了修改，该维护属于（ ）。
A. 正确性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护
答案：B。 关键词”升级数据库后”——为适应变化的运行环境而修改，是适应性维护。若是”修 bug”选 A，”加功能”选 C，”为将来重构”选 D。
例 3 软件质量保证（SQA）与质量控制（QC）的主要区别是（ ）。
A. SQA 关注产品，QC 关注过程
B. SQA 关注过程，QC 关注产品
C. 两者没有区别
D. SQA 在编码阶段，QC 在测试阶段
答案：B。 QA 是预防性的、面向过程（评审、审计、过程改进）；QC 是检查性的、面向产品（测试、检查）。
例 4 正式的技术审查（Inspection）中，负责主持会议、分发材料、确保缺陷被记录的角色是（ ）。
A. 作者 B. 评审员 C. 主持人 D. 记录员
答案：C。 主持人（Moderator）组织与主持会议；记录员只负责记录；作者提供材料；评审员发现缺陷。
例 5 某银行核心系统切换时，新旧系统并行运行三个月，确认无误后停用旧系统。该转换方式是（ ）。
A. 直接转换 B. 并行转换 C. 分段转换 D. 试点后转换
答案：B。 关键信号是”并行运行”。并行转换安全性最高但成本最高（要同时维护两套系统并做结果比对）。
4.2 案例分析怎么考
案例： 系统上线前的质量问题（20 分）
某系统在上线前一周的回归测试中发现 23 个缺陷，其中 7 个是三个月前已修复、本次又复现的缺陷。
经查，其中一次”性能优化”的代码重写未经过变更评审，直接提交到版本库。
此外，项目组从未定义过”什么算可以上线”的质量标准。
问题 1（8 分）：请分析导致”已修复缺陷复现”的可能原因，并给出改进措施。
问题 2（6 分）：请给出本项目的配置管理方案，需覆盖配置项识别、基线、变更控制与审计。
问题 3（6 分）：请为本项目定义系统测试的出口准则（即”什么算可以上线”），并说明理由。
采分点拆解
| 问题 | 采分点 | 分值 |
|---|---|---|
| 1 | ①未建立回归测试基线，修复后的用例没有固化进回归集 | 2 |
| ②代码重写未走变更评审，缺少影响分析 | 2 | |
| ③缺少需求—设计—用例的双向追溯，改动未同步更新用例 | 2 | |
| ④改进：建立回归基线并自动化、强制变更评审与影响分析、建立 RTM 追溯、缺陷修复必须附用例 | 2 | |
| 2 | ①配置项识别（文档、源码、脚本、配置、数据字典） | 1.5 |
| ②三条基线（功能/分配/产品基线）及其建立时点 | 1.5 | |
| ③变更控制流程（提出 → 影响分析 → CCB 审批 → 实施 → 验证 → 发布） | 2 | |
| ④配置审计（功能审计与物理审计）与状态报告 | 1 | |
| 3 | ①给出可量化的出口准则（缺陷密度、遗留缺陷等级、覆盖率、性能指标、回归通过率） | 3 |
| ②说明准则必须由干系人事先共同确认，而不是上线前临时定 | 2 | |
| ③指出出口准则应与验收标准一致，可追溯到需求 | 1 |
标准作答范例（问题 1）
可能导致已修复缺陷复现的原因有四点。其一，项目未建立回归测试基线，缺陷修复后新增的验证用例没有固化到回归用例集中，后续改动无法自动验证这些场景。其二，6 月的代码重写未执行变更控制流程，既未做变更影响分析，也未经过 CCB 审批，导致改写时遗漏了此前修复引入的约束。其三，项目缺少需求—设计—测试用例的双向追溯（RTM），代码改动无法确定应同步更新哪些用例与设计文档。其四，缺陷修复没有强制要求附带回归用例，导致修复不可持续。
改进措施：①建立回归测试基线并将回归用例集自动化，每次提交触发执行；②所有变更必须走变更控制流程，包含影响分析与 CCB 审批，未经批准不得合入；③建立并维护需求跟踪矩阵，实现需求、设计、代码、用例的双向追溯；④规定”缺陷修复必须同时提交对应的回归用例”，否则不予关闭。
标准作答范例（问题 3）
系统测试的出口准则建议定义为：①致命与严重级缺陷清零，一般级缺陷遗留数不超过 5 个且均有书面规避方案；②需求跟踪矩阵中需求用例的**执行通过率达 100%；③核心业务用例的语句覆盖率不低于 95%、判定覆盖率不低于 85%**；④性能指标达到需求约定（追溯查询响应 ≤ 8 秒、车间大屏刷新 ≤ 5 秒、并发 500 用户下 95 分位响应时间不退化）；⑤回归测试通过率 100%；⑥安全扫描中高危漏洞清零；⑦用户手册、运维手册、应急预案等交付物齐备并通过配置审计。
理由：出口准则必须与需求规格中的验收标准保持一致并可追溯，且必须由建设单位、业务部门与运维方在测试开始前共同确认并书面签字。若上线前才临时商定，各方必然从自身立场出发，导致标准被反复拉扯，失去作为判定依据的意义。
五、易错点（Rethink）
| 错误认知 | 为什么错 | 正确理解 |
|---|---|---|
| “判定覆盖一定包含条件覆盖” | 两者互不包含 | 判定覆盖管分支真假，条件覆盖管每个条件的真假，谁也不包含谁 |
| “路径覆盖是最常用、总能达到的” | 含循环时路径数爆炸 | 路径覆盖最强但通常不可达，实际用基本路径覆盖（圈复杂度）替代 |
| “测试能证明软件没有缺陷” | 测试只能证明存在缺陷 | 测试是采样，永远不能证明无缺陷（Dijkstra 名言） |
| “QA 就是测试” | QA 面向过程，测试面向产品 | QA 包含评审、审计、过程改进；测试只是 QC 的一种手段 |
| “配置管理就是版本控制” | 版本控制只是其中一环 | 配置管理 = 配置标识 + 变更控制 + 状态报告 + 配置审计 |
| “基线一旦建立就不能动” | 基线可以变，但必须受控 | 基线是受控的稳定点，变更必须走变更控制流程并重新评审 |
| “并行转换最省钱” | 并行要同时维护两套系统 | 并行转换风险最低但成本最高 |
| “修 bug 属于完善性维护” | 修 bug 是正确性维护 | 正确性=修 bug；适应性=换环境；完善性=加功能；预防性=为将来 |
| “CMMI 五级越高越好，所有项目都要五级” | 过级要有投入产出判断 | 组织应按业务需要选择成熟度目标，等级不是质量本身 |
六、GRASPS 推进（Experience）
本周往交付物里加三份内容：
- 测试策略（约 800 字）：明确测试层次与各自负责方、黑盒与白盒方法的选择、覆盖率目标（语句 ≥95%、判定 ≥85%）、性能与安全测试指标、回归测试基线的建立方式。
- SQA 计划（约 600 字）：列出本项目的评审活动（需求评审、设计评审、代码审查）及其时点、参与角色与检查表；说明 QA 与测试的分工。
- 配置管理方案（约 800 字）：配置项清单、三条基线的建立时点、分支策略（推荐 GitFlow 或主干开发 + 特性开关）、变更控制流程与 CCB 组成、配置审计安排。
验收标准：把测试策略给开发负责人看，他能回答”我提交代码后会发生什么”；把配置管理方案给新人看，他能回答”我要改一个已基线化的文档该走什么流程”。
七、自测
- 测试层次由小到大依次是（ ）
A. 单元→集成→确认→系统→验收 B. 单元→系统→集成→确认→验收
C. 集成→单元→确认→系统→验收 D. 单元→集成→系统→确认→验收 - 黑盒测试中，最适合处理”多条件组合决定多个动作”的方法是（ ）
A. 等价类划分 B. 边界值分析 C. 因果图/判定表 D. 语句覆盖 - 下列覆盖准则中，最强的是（ ）
A. 语句覆盖 B. 判定覆盖 C. 条件组合覆盖 D. 路径覆盖 - 关于调试与测试，正确的是（ ）
A. 测试定位缺陷，调试发现缺陷 B. 测试发现缺陷，调试定位并修复缺陷
C. 两者是同一活动 D. 调试由测试人员完成 - 质量保证 QA 主要面向（ ）
A. 产品 B. 过程 C. 代码 D. 用户 - CMMI 阶段式表示法中，”过程已被标准化并在组织级统一”属于（ ）
A. 已管理级 B. 已定义级 C. 量化管理级 D. 优化级 - Scrum 中负责”定价值与优先级”的角色是（ ）
A. Scrum Master B. Product Owner C. 开发团队 D. 项目经理 - 需求分析阶段结束时建立的基线是（ ）
A. 功能基线 B. 分配基线 C. 产品基线 D. 测试基线 - 用户要求在系统上线后增加一个新报表，该维护属于（ ）
A. 正确性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护 - 多厂区系统切换时，先在一个厂区验证成功后再推广，属于（ ）
A. 直接转换 B. 并行转换 C. 分段转换 D. 试点后转换
答案与解析
| 题 | 答 | 解析 |
|---|---|---|
| 1 | A | 单元→集成→确认（有效性）→系统→验收（α/β） |
| 2 | C | 因果图与判定表专门处理”条件组合 → 动作”的复杂逻辑 |
| 3 | D | 路径覆盖最强；条件组合次之。注意路径覆盖在含循环时通常不可达 |
| 4 | B | 测试发现缺陷，调试定位并修复 |
| 5 | B | QA 面向过程（预防），QC 面向产品（检查） |
| 6 | B | 已管理级=项目级可跟踪；已定义级=组织级标准化；量化管理级=统计控制；优化级=持续改进 |
| 7 | B | PO 定价值与优先级；SM 守流程清障碍 |
| 8 | B | 功能基线=系统需求；分配基线=软件需求；产品基线=全部配置项定版 |
| 9 | C | 用户主动提出的新功能 → 完善性维护 |
| 10 | D | 先试点后推广 = 试点后转换；分模块逐步切换 = 分段转换 |
八、分档任务（Tailor）
- 保底 45：背下覆盖强度排序、测试层次顺序、维护四类型判定口诀、CMMI 五级名称、系统转换四方式。
- 冲 60：完成测试策略与配置管理方案；能独立计算语句/判定/条件组合覆盖所需用例数。
- 冲 70：再加 SQA 计划；给本项目设计一份”上线出口准则”并由他人评审其可度量性；把”缺陷 #1042”这个复现缺陷写成一段论文素材（含数字：23 个缺陷、7 个复现、4 小时回归）。
九、本阶段回答基本问题
Q4：系统上线是终点还是起点？”可维护性”在什么时候买最便宜？
上线当然不是终点，它是系统生命周期中成本最高的那一段的起点——统计上，运维期的维护成本通常占到整个生命周期总成本的 60%–70%。
至于可维护性什么时候买最便宜，答案是在它被写下来的时候最便宜，越往后越贵：
- 需求阶段就把”什么算可上线”写成可度量的出口准则，成本接近零；等到上线前一周再商议，各方必然从自身立场拉扯，而且已经没有时间改。
- 需求、设计、代码、用例之间建立双向追溯（RTM），成本是写文档的时间；没有它，一次”性能优化”的重写就能让三个月前修好的缺陷静默复现——缺陷 #1042 就是这个价。
- 强制变更评审与回归基线，成本是每次几分钟的流程；省掉它，代价是 7 个复现缺陷和上线前一周的 4 小时回归。
- 配置管理与基线，成本是建库与流程；省掉它，代价是你无法回答”线上跑的到底是哪一版”。
一句话：可维护性不是上线后才去”提升”的属性，它是前面每一步是否守规矩的累计结果。治理不是事后补救，而是把每一次变更都变贵一点点，从而让后期的每一次事故都便宜一大截。
下一周（S09）把”变更可控”这件事放到进度、成本与风险的框架里继续追问。
