客户在评审技术方案时问了句内行话：听说正规团队都写单元测试，我们这个项目要不要写？写，工期和报价上浮三成左右；不写，出bug的概率实实在在高一截。后端系统开发的测试投入，不是有情怀就上的事，得按回报分层算账。
先看测试到底防什么
单元测试的价值有两个：防当前出错，改代码时立刻知道有没有改坏东西；防将来出错，半年后别人接手改逻辑，跑一遍测试就知道兼容不兼容。第二个价值对存续期长的系统尤其大——很多老系统不敢动，就是因为没有测试兜底，谁改谁心虚。但写测试本身要耗工时，全覆盖的项目，测试代码量和业务代码量几乎一比一，这就是那三成成本的来源。
务实的分法是按风险分层
- 钱相关的逻辑必须测：佣金计算、税费规则、对账逻辑、满减叠加，这些地方错一分钱都是事故，写单元测试的回报最高，一个算错规则的bug损失可能超过全部测试投入；
- 复杂规则要测：排班算法、库存分配、价格阶梯这类逻辑绕弯的模块，人脑推演容易漏分支；
- 普通增删改查不强制：列表查询、表单录入这些，人工测试加上线反馈就够了，强行覆盖纯属烧钱。
除单元测试外，还有一层性价比很高的投入：核心路径的自动化回归。把登录、下单、支付这些主流程写成十来个自动化用例，每次发版前跑一遍，五分钟挡住八成的低级回归。它不追求覆盖率，只守住最不能出事的路径，投入一两个星期，长期受益。
有个现实问题要提醒：测试代码也是代码，写歪了反而添乱。见过测试和实现耦合得死死的，改个字段名要同步改五十个测试，团队干脆把测试删了。规范的做法是测试盯行为不盯实现，这需要团队有经验，签约时不妨看看对方过往项目的测试代码长什么样。
验收时看什么
别被覆盖率数字唬住，百分之八十的覆盖率可能全是无用的增删改查测试。要看的是：钱相关的模块有没有对应测试，测试断言的是业务规则还是代码结构，让开发方现场改一个佣金系数跑测试给你看，红绿变化说明测试是真在守规则的。
两条建议：合同里把测试范围写清楚，钱相关模块必须带单元测试交付，其余按人工测试报告验收；系统要长期演进的话，把核心路径回归测试列入二期投入。比格网络对涉及资金计算的项目一律强制单元测试，这类钱花得最值，一次事故的账就够了。测试分层投入也由此成了后端系统开发报价里值得单独确认的一栏。
