还记得那个让人心跳漏一拍的时刻吗？
周五下午 5 点，你满怀信心地点击了"Merge Request"，心想终于可以过个安稳周末了。半小时后，测试群里的消息疯狂弹出，红色的 @所有人 显得格外刺眼——核心流程走不通，甚至连登录接口都报 500 错误。
那种挫败感，我太熟悉了。
很长一段时间里，我都陷入了一个怪圈：以为"开发只管写代码，测试才负责找 Bug"。直到我所在的那个只有 8 个人的初创团队因为一次严重的线上事故，不仅丢了客户，还让整个技术团队在那个周末陷入了无尽的指责与自我怀疑。
那时我才意识到，自测不仅仅是代码质量的保证，更是开发人员职业尊严的护城河。
对于资源有限、甚至没有专职测试人员的中小团队来说，我们不需要像大厂那样搞复杂的自动化流水线。今天，我想分享三个低成本、易落地的自测方法，它们曾帮助我的团队将提测被打回率降低了 60% 以上。
拒绝"由于环境不同导致的惨案"
很多时候，开发人员不愿意自测，借口往往是：“我本地是好的啊，谁知道测试环境为什么不行？”
这其实不是借口，是事实，也是痛点。
我曾见过一位非常有经验的后端老哥老张，因为本地安装的 MySQL 版本是 8.0，而测试服务器上是 5.7，导致一个复杂的 SQL 查询在上线后直接报错。排查这个问题花了整整 4 个小时，最后发现只是一个关键字语法的差异。
在中小团队，没有专职运维来维护环境的一致性，这个坑必须由开发自己填。
我的建议是：将"环境治理"纳入开发流程，而不是运维流程。
与其写文档告诉新人"请安装 Node 14 和 Redis 5"，不如直接给一个 docker-compose.yml 文件。
“当我们强制要求所有开发人员本地使用 Docker 启动依赖服务后，那些莫名其妙的配置问题消失了 90%。” —— 这是一位做 SaaS 产品的 CTO 朋友跟我分享的经验。
你只需要花半天时间，把数据库、缓存、消息队列等依赖项容器化。开发人员在自测时，不再依赖那个总是被别人改坏的"公共测试环境"，而是在本地拥有一套纯净的、和线上配置完全一致的"微缩环境"。
# 一个简单的 docker-compose 示例，让环境一致性不再是玄学
version: '3'
services:
db:
image: mysql:5.7 # 锁定版本，避免"我本地是好的"
environment:
MYSQL_ROOT_PASSWORD: secret
redis:
image: redis:alpine
api:
build: .
depends_on:
- db
- redis
这样做的好处是显而易见的：你在本地跑通的代码，在服务器上大概率也能跑通。 这种确定性，是缓解上线焦虑的最佳良药。
别试图搞全量单元测试，那是"富人"的游戏
在技术圈有一种政治正确，叫"追求 100% 的单元测试覆盖率"。但在快节奏的中小团队，这往往是一剂毒药。
我见过一个 5 人的创业团队，CTO 要求必须写单元测试才能提交代码。结果呢？大家为了凑覆盖率，写了大量毫无意义的断言（比如 expect(1+1).toBe(2)），反而因为改需求时要同步改测试代码，导致开发效率暴跌，最后这个规定名存实亡。
对于我们来说，要追求 ROI（投入产出比）最高的测试，而不是最完美的测试。
我更推荐**“关键路径冒烟测试”**。
哪怕你没有时间写任何测试代码，至少要保证"主流程"是通的。这就好比买车，你可以不检查雨刮器是不是由顶级橡胶制成，但你必须得确认引擎能发动、刹车能踩住。
我个人的习惯是，在项目里维护一个名为 smoke_test.sh 的脚本（或者 Postman 的 Collection）。它只做三件事：
- 模拟用户注册/登录；
- 创建一个核心业务订单；
- 完成支付流程（Mock 模式）。
这个脚本我用了两年，每次提交代码前跑一下，耗时不到 30 秒。
有一次，我在修改一个边缘功能时无意中删掉了一个全局中间件，导致所有 POST 请求失效。正是这个不起眼的脚本在本地拦截了这次事故。如果等到提测才发现，不仅浪费了测试人员的时间，更会让我显得极其不专业。
中小团队的资源，应该集中火力在**“让核心业务不挂”**上，而不是纠结于某个工具类的边界条件测试。
建立"自测清单"，哪怕是手写的
这是最不"技术"、最原始，但可能最有效的方法。
在航空业，飞行员起飞前都要对照 Checklist 检查仪表。在手术室，医生动刀前也要核对清单。为什么代码上线这么高风险的操作，我们却往往只凭记忆？
很多时候 Bug 产生的原因并非技术多难，而是**“忘了”**。
- “哎呀，忘了配数据库白名单。”
- “糟了，那个配置项忘了从 false 改回 true。”
- “糟糕，忘了处理空指针的情况。”
我建议每个技术负责人带着团队整理一份**“死都不犯的低级错误清单”**。不需要很长，5-10 条即可，贴在每个人的显示器旁边，或者放在 Merge Request 的模板里。
一个真实的案例： 某电商小程序团队，因为频繁出现"改了 A 功能导致 B 功能挂了"的情况，士气低落。后来他们规定，提测申请单里必须包含一张截图：“自测清单勾选图”。
清单内容包括：
- 新增接口是否有对应的权限控制？
- 涉及金额计算是否用了 BigDecimal（防止精度丢失）？
- 慢 SQL 是否已在本地 Explain 过？
- 异常情况（断网、超时）下页面是否有兜底展示？
哪怕只是机械地勾选一遍，人的大脑也会被强制切换到"审视模式"。实施这个策略两个月后，他们发现因粗心导致的 Bug 减少了 70%。
你也常常在提交代码的那一瞬间，心里闪过一丝"应该没问题吧"的犹豫吗？ 如果有，那就是你需要这张清单的时候。
写在最后
其实，减少测试依赖，并不是要消灭测试岗位，也不是要把开发累死。
它的底层逻辑是"信任重建"。
当开发人员能够交付高质量的代码，测试人员就能从繁琐的"点点点"中解放出来，去做更有价值的性能测试、安全测试；运维人员也不用在半夜被电话叫醒处理低级配置错误。
如果你想从今天开始改变，不妨试试这三步：
- 统一环境：花 2 小时整理一份 docker-compose 文件，发给团队所有人。
- 抓住核心：不要试图测试所有功能，先保证那 20% 的核心业务流程有脚本覆盖。
- 物理防呆：和团队一起复盘过去三个月的 Bug，总结出 5 条最高频的易错点，制成 CheckList。
技术之路漫长且艰辛，愿每一次代码提交，都能带给你稳稳的幸福感，而不是无尽的焦虑。