经济下行，单元测试总第一个被砍掉，到底冤不冤？

市场环境收紧，项目工期被压缩，预算不断收紧，很多嵌入式、车载软件项目里，单元测试总是最先被牺牲掉的那一环。

业务要往前推进，集成测试不能动，实车、硬件测试更是底线，到最后，单元测试就成了可以暂缓的工作。不少管理者的想法很直接：只要功能能够跑通就可以。单元测试耗人力、耗时间，看不到立竿见影的产出，先放一放，等版本交付完成之后再来补做。

但一个值得思考的问题摆在面前：项目吃紧就砍掉单元测试，这件事，到底冤不冤？

软件行业有一个广为认同的规律：缺陷修复成本曲线。 一个 Bug，如果在编码、单元测试阶段就被识别出来，修复成本极低，修改几行代码，十几分钟就能解决问题。

可如果这个缺陷被放过，流转到集成测试阶段，就要花费大量时间复现问题、定位根因、跨模块联调，修复成本会成倍上涨。一旦流入实车测试环节，牵扯硬件、中断、多模块时序交互，排查难度会进一步放大。

最严重的情况，缺陷直接流向终端客户，带来的就是设备故障、客户投诉，甚至车载产品的召回风险，产生的损失，是编码阶段修复成本的几十上百倍。

道理人人都懂，但现实落地却十分残酷。 单元测试消灭的，大多是本不会发生的 Bug，它的收益是隐性的。你很难拿出直观的数据向管理层证明：正是做了单元测试，规避了多少未来可能爆发的故障。

但写用例、维护测试套件投入的工时，是当下实实在在看得见的成本。在降本、赶交付的双重压力之下，单元测试天然就成为优先被取舍的对象。

当然，我们也不能神化单元测试，嵌入式场景本身就存在客观现实难题。 大量嵌入式代码直接操作寄存器、中断、外设硬件，开展单元测试就需要编写大量桩函数，隔离硬件依赖。桩开发、用例维护，确实会占用不小的研发精力。尤其车载 ISO 26262 功能安全项目，还要满足 MC‑DC 覆盖率、需求双向追溯等合规要求，整套落地绝非简单敲几行代码就能完成。

行业里往往走向两个极端。 一部分团队直接全盘放弃单元测试，把全部质量压力，全部转嫁到集成测试与实车测试身上；还有一部分团队纯粹为了应付认证审核，为了覆盖率而刷覆盖率，堆砌大量无效测试用例。报告数据十分好看，却起不到拦截缺陷的实际作用。

砍掉单元测试看似省下眼前的人力投入，本质只是把风险向后转移。当下节省下来的成本，是把隐患留给后续集成阶段、系统测试，甚至留给已经上线的量产产品。

经济环境不好，难道就只能二选一：要么不计成本全量做单元测试，要么直接彻底砍掉？其实大可不必。

我们不需要要求所有函数、全部模块，执行同等强度的单元测试。可以推行风险分级测试策略：安全相关、高风险、迭代频繁的核心业务模块，坚持落地单元测试，守住风险底线；普通辅助类、低风险模块，可以适度简化测试力度，把有限的研发资源用在刀刃上。

单元测试的核心目标，从来不是完成纸面指标，而是前置拦截代码逻辑缺陷，规避后期代价更高的返工。真正的降本，不是砍掉前置质量活动，不应该把所有风险全部后置。

回到最初的问题，单元测试总是第一个被砍掉，到底冤不冤？ 短期项目视角看，赶进度似乎很划算；放到完整产品生命周期来看，实则埋下很高的潜在风险。

很多团队不是不清楚单元测试的价值，真正卡住落地的，往往不是工具，而是项目排期、代码架构，以及团队的考核取舍机制。

你们公司项目工期紧张的时候，单元测试会被直接砍掉吗？欢迎留言交流。