质量是一笔预算：四十七个缺陷、八十六小时与三条红线

一个人做不了完整测试，只能决定先测哪一段。

一、一个删除动作与三条红线

2026 年 9 月 16 日下午，客户在项目设置里点了「删除项目」。界面只问了一次「确定吗」，他点了确定。四秒后，项目下的 12 条任务、31 条评论和 4 个附件一起消失——projects 的级联删除写的是 ON DELETE CASCADE，半年前建表时他觉得这样「比较干净」。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

客户在电话里没有发火，只问了一句：能不能恢复。他从凌晨的备份里找回前一晚的快照，恢复了 3.5 小时，仍然丢了 6 小时内的评论。那天夜里他把事故写成三行：数据没了、钱算错了、人进不来——任何一行成立，都算事故。

这三行后来成了红线。红线的作用不是分级，而是排除：只要触线，不管改动多小、工期多紧，都必须走完整验证；没触线，才有资格讨论「这次改动很小，跳过吧」。

第二周他没有补测试，而是先改默认值：删除改成软删除，保留 30 天，恢复入口放在项目列表的筛选器里；批量删除要求输入项目名。这三处改动的验证只花了 40 分钟，却把同一条路径从「不可逆」降成了「可逆」。

三条红线也不是从框架里抄的，而是从客服邮箱里最贵的三类工单倒推出来的。过去 12 个月，凡是让客户连续追问三天以上的问题，最后都能归进这三类；其余的工单平均两轮往返就结束了。

一年后回看，47 个线上缺陷里有 31 个落在这三类路径上，占 66.0%。这个比例说明一件事：一个人的测试时间不该平均分配。

他把这次事故的复盘写在发布记录里，只有 11 行：时间、影响、根因、修复、验证、下次怎么提前发现。11 行足够，因为复盘不是文档工程，而是给下一次改动留一个路标。

二、四阶段成本倍数：一、五、十五、一百

他给缺陷成本定了一组教学倍数：需求阶段发现是 1，开发自测是 5，发布前是 15，线上是 100。倍数不是精确测量，而是用来排序的粗略刻度。

倍数 100 的那一格不是夸张。一次线上数据事故要花的时间包括定位、恢复、逐客户沟通、补一份事故说明，还要算上那几天不敢发布的机会成本。

发布前是 15，原因是这一段的动作最重：造一份接近真实的数据、把路径完整走一遍、等一次构建、再确认预发环境和生产环境的配置没有漂移。同样是点一次删除，开发自测 5 分钟，发布前要 25 分钟。

倍数只能用来比较同一个缺陷在不同阶段被发现时的成本，不能用来比较两个不同缺陷。拿「P3 文案错字」和「P0 数据丢失」比倍数没有意义，它们的绝对成本差了两个数量级。

30 个前移也不是全部都能再提前。19 个开发自测发现的缺陷里，有一部分本来就依赖真实数据才会暴露；能提前的是那些「只要想到就会去点一下」的路径，比如删除、导出、改权限。

一年里他记录了 77 个缺陷：开发自测发现 19 个，发布前发现 11 个，线上 47 个。前两段合计 30 个，占 39.0%。如果把这 30 个再往前挪半步——每个多花 0.5 小时写一条可复现的自测步骤——成本是 15 小时，占全年修复工时 86.5 小时的 17.3%。

这笔账的关键不在 15 小时，而在「前移」可不可重复。写一条自测步骤只需要知道怎么点到那个页面，不需要搭建完整测试体系，这是一个人负担得起的动作。

77 = 19 + 11 + 47 这个加法看起来平常，但它要求每次发现都记一笔。他从第 5 个月才开始记，前 4 个月的 19 个自测缺陷里有 6 个是事后补的；补记的时间不准，只能按天估。

三、四十七个缺陷与八十六点五小时

47 个线上缺陷按严重度分成四档：P0 3 个、P1 9 个、P2 21 个、P3 14 个。修复工时不按数量平均，而按每档的单件成本累加。

P0 每件 2.5 小时，3 件共 7.5 小时；P1 每件 4 小时，9 件共 36 小时；P2 每件 1.5 小时，21 件共 31.5 小时；P3 每件 0.5 小时，14 件共 7 小时。四项相加 82 小时，再加回归验证与客户沟通的 4.5 小时，全年修复总工时 86.5 小时。

86.5 小时放在 1,920 小时（48 周 × 每周 40 小时）里，占 4.5%。这个数字看起来不大，但它只统计「修」的时间，不包含被打断的下午、推迟的发布和折损的信任。

中位修复时间比平均更能说明体感：P0 1.2 小时，P1 18 小时，P2 4.6 天，P3 23 天。P1 的 18 小时不是写代码的 18 小时，而是「找原因、写补丁、验证、发布」串起来跨越的两个工作日。

P2 的 4.6 天和 P3 的 23 天来自队列，不来自难度。它们的单件成本只有 1.5 小时和 0.5 小时，之所以拖过一周，是因为每次都被「今天先处理 P1」挤到队尾；这是排序的必然结果，不是执行问题。

86.5 小时摊到 12 次发布，大约每月 7.2 小时，接近一个完整工作日。把它当成每月固定支出，比当成「出事了再说」的意外支出更容易安排。

修复之外还有一笔账没被记录：每次线上缺陷平均要回 2 到 3 封邮件，其中大部分没有计入 4.5 小时的沟通成本。真实的隐性成本比账面高，但账面上只能先记能记的部分。

把 86.5 小时和 192 小时的验证预算放在一起看，前者是后者的 45%。这说明即使修完所有线上缺陷，验证投入仍然不到修复成本的一半；真正贵的是「修」，不是「测」。

按时限达标的情况是 38/47，即 80.9%：P0 3/3、P1 7/9、P2 17/21、P3 11/14。没达标的 9 个里有 7 个是 P2 与 P3——低级别缺陷的拖延不是态度问题，而是一个人的注意力必然被更贵的事情占走。

四、三条红线：丢数据、收错钱、进不去

红线不按影响面定，而按「用户能否自己恢复」定。丢数据、收错钱、进不去，这三类里用户都没有自救手段，只能等你。

三条红线对应 31 个线上缺陷，占 47 个的 66.0%。拆开看是丢数据 8 个、收错钱 11 个、进不去 12 个；其余 16 个是体验、文案和性能问题，可以排队、可以下个版本、可以在周末前修。

红线有例外，但例外必须提前写下来。计划内维护造成的「暂时进不去」不算事故，条件是提前 48 小时在状态页和站内通知里说清楚，并且给出恢复时间；没有提前通知的维护，仍然按事故处理。

验证预算的算法很直接：1,920 小时的 10% 是 192 小时，摊到 48 周是每周 4 小时。4 小时不足以跑完整套测试，但足够每周把三条红线各走一遍，再留一小时处理新发现的边界。

为什么是 10% 而不是 20%：前 4 小时的边际收益最高，能覆盖全部红线；再加 4 小时只能多覆盖一部分体验路径，而一个人的时间必须留给功能开发。这个比例是可执行的上限，不是理论上限。

每周 4 小时可以固定成节奏：周一 1 小时走三条红线，周三 1 小时补上周新增的边界，周五 2 小时留给当周改动的受影响路径。固定下来之后，预算才不会被功能开发悄悄吃掉。

把这一年的账摊开，逐项加总，结果如下。

复算：3×2.5 + 9×4 + 21×1.5 + 14×0.5 = 7.5 + 36 + 31.5 + 7 = 82.0 h
含沟通：82.0 + 4.5 = 86.5 h
前移收益：30 × 0.5 = 15 h；15 ÷ 86.5 = 17.3%
修复占比：86.5 ÷ 1,920 = 4.5%
验证预算：1,920 × 10% = 192 h；192 ÷ 48 = 4 h/周
红线占比：31 ÷ 47 = 66.0%

86.5 小时里有 4.5 小时不属于任何一档缺陷，它花在「让客户知道发生了什么」上。这部分最容易被省略，也最容易被低估。

复算的意义不是得到一个漂亮的百分比，而是给下一年的排序提供一个可以反驳的起点：如果 31 个红线缺陷里有一半其实可以前移，那 15 小时就不是成本，而是从修复工时里省出来的。

五、行动清单与复算验收

• 把一年内的线上缺陷按 P0–P3 归档，算出四档数量与修复工时。
• 用四阶段倍数标注最近 10 个缺陷分别在哪一段被发现。
• 写下三条红线在本产品里的具体判定，不抄通用定义。
• 给每条红线配一条最小验证路径，能在 15 分钟内走完。
• 在日历上固定每周 4 小时验证预算，写进日程而不是待办。
• 统计过去 12 个月的缺陷里红线类占比，低于 50% 就重划红线。
• 为每个 P1 记录从发现到发布的实际小时数，不只记「已修复」。
• 每季度重算一次 86.5 小时，看修复成本是在升还是在降。

验收标准：任取一个线上缺陷，都能在 5 分钟内说出它属于哪一档、是否触红线、本该在哪一段被发现。

前四条是「把账算出来」，后四条是「让账每个月自动更新」。如果只有一周，先做第一条和第三条；没有基线，后面的预算和红线都只是口号。

清单不要一次全做。第一个月只做前三项，第二个月加上日历预算，第三个月才开始记录 P1 的实际小时数；一次加太多，第四周就会停更。

使用边界与实操验收

预算是上限，不是目标。 192 小时的意思是「最多花这么多」，不是「必须花完」。某周没有改动，这 4 小时可以用来还测试债，也可以不用。

倍数只用于排序。 1/5/15/100 不是行业基准，换一个产品、换一个人，刻度就会变；它的用途是让你在「现在测还是上线后修」之间做一个不自欺的选择。

红线要少，而且要随阶段重划。 三条刚好，超过五条就等于没有红线，因为每一条都触线时，你会开始给红线本身排优先级。产品只有 120 个付费用户时，进不去的影响是几十人；等到有企业客户，同一条红线的判定还要加上合同里的可用性条款。

工时与比例是教学假设。 344 个账号、120 个付费用户、47 个缺陷都取自本组统一基线，不构成对任何产品修复成本或事故概率的预测，也不构成质量承诺。

关键参考与核验范围

• Martin Fowler: The Practical Test Pyramid ：用于说明分层测试的成本差异，不用于推导本文的 1/5/15/100 倍数。
• OWASP ASVS ：用于核对不可逆操作与权限变更应覆盖的验证项。
• PostgreSQL: EXPLAIN ：用于说明删除与级联操作前的预演手段。
• Stripe Testing ：用于说明计费路径如何在测试环境复现，实际行为以官方文档为准。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

上述文档只用于核对概念与操作入口；47 个缺陷、86.5 小时、192 小时与全部比例均取自本组教学基线，与文档内容无对应关系。本文只讨论一个人的质量预算与红线划分，不讨论团队分工、测试框架选型与合规审计。

系列导航

• 上一篇：无，本文是系列第一篇
• 下一篇：关键路径清单：十二条不能坏的路径
• 回到目录：一个人的质量守门：验证预算、回归清单与发布门禁
• 相关阅读：一个人的运维：可用性、告警、事故与值班