2,963 条后端自动化测试是怎么跑起来的

为什么餐饮系统特别怕"改一处碰坏一片"

别的管理系统，一个功能坏了，最多是这个功能不能用。

餐饮系统不一样，它的模块是咬在一起的：

• 改了菜品价格 —— 影响订单金额、影响成本核算、影响报表、影响会员积分
• 改了营业时间 —— 影响排班、影响打卡判定、影响日结的归属日
• 改了桌台状态 —— 影响排队、影响点单、影响交接班时长的统计

一处改动顺着数据流走一圈，可能碰到好几个模块。靠人记住"改这个要顺带测哪些"，在十几个模块的时候还行，到几十个模块就一定漏。

所以只能让机器记。

测试要分层，不然跑不动

2,963 条测试如果全塞在一层里跑，一次跑完要很久，坏了也不知道是哪一层坏。我们按三层分开跑：

第一层：单测

最快的一层，不连数据库、不发网络请求。主要覆盖纯计算逻辑：金额怎么算、折扣怎么叠加、时间区间怎么切。

这层的价值是秒级反馈——写完代码跑一下，几秒钟就知道这段逻辑对不对。

第二层：接口测试

连数据库，但不走页面。直接调后端接口，验证"传这些参数进去，应该返回什么、数据库应该变成什么样"。

餐饮系统里最容易出错的东西在这一层：订单状态流转、库存扣减、跨天的日结归属。这些问题在页面上点很难复现，直接打接口反而稳定。

第三层：端到端回归

走完整的页面流程，模拟一个人从登录到下单到结账。这层最慢，但只有它能发现"每个接口单独都对，连起来就错"的问题。

2,963 条是怎么攒出来的

不是一次写完的，是三条规矩慢慢攒的：

规矩一：修一个 bug，必须补一条测试。

这条最管用。线上出过的问题，如果不补测试，下次还会出。补了之后，这个 bug 就永久被盯住了。

规矩二：新接口上线，必须带测试。

不是"有空再补"——有空再补等于永远不补。接口和测试一起提，一起审。

规矩三：合并前必须全绿。

这就是回归门禁：想合进主干，2,963 条全得过。有一条红的就进不去。

回归门禁真正的价值不是"不犯错"

很多人以为跑测试是为了保证代码没有 bug。其实不是——测试保证不了没 bug，它保证的是"已知的坑不会再掉进去"。

真正的价值在别处：

• 敢改。 有 2,963 条在后面盯着，重构老代码这件事才敢动手。没有的话，谁都不敢碰三个月前那段没人看得懂的代码。
• 说得清。 出了问题，能定位到是哪一条从绿变红、是哪次改动引起的，不用大家凭印象猜。
• 省时间。 人工回归一遍要一天，机器跑一遍几十分钟。一天和几十分钟的差别，累积一年是很可观的。

写在最后

需要说清楚的是：上面讲的是通用做法和我们的实践，不代表对你承诺了任何具体的测试覆盖率或发布节奏。

具体到某一套系统里测试有多少条、分几层、门禁怎么设，要看它的模块数量、团队规模和迭代频率——照搬别人的数字没有意义。

我们这边能说的是：后端自动化测试目前有 2,963 条，分三层跑，合并前全绿才能进主干。这个数还在涨，因为规矩是"修一个 bug 补一条"。

智领赋能旗下系统包括巴掌柜 / MMFIM / 智能财税。技术栈上涉及 Spring Boot、Vue3 与 MySQL 兼容层等，均为工程实现层面的通用选型，不构成对任何第三方产品的评价。