前几年带小团队的时候，我特别怕周五下午。
那时候我们没有专职测试，几个开发兄弟写完代码，本地随便点点就扔到测试环境。结果就是，每到周五上线前，大家才发现核心流程跑不通，或者修好一个Bug又引出三个新Bug。那种对着日志排查到凌晨两点的绝望感，我现在想起来还头皮发麻。
当时我痛定思痛，觉得必须得搞“自动化测试”。于是我犯了一个很多技术负责人都会犯的错：试图用大厂的标准来要求小团队。
我们花了两周时间搭Jenkins，写了几百个Selenium UI脚本，结果呢？项目界面改版，脚本全废。维护脚本的时间比写业务代码还长，团队怨声载道，最后这套“高大上”的系统彻底吃灰。
踩了这些坑，交了学费，我才慢慢摸索出一套适合5-20人研发团队的“穷人版”自动化方案。今天咱不聊高深的理论，就聊聊怎么在没钱、没人的情况下，把代码质量守住。
误区一：痴迷UI自动化，简直是由于“自杀”
很多团队想做自动化，第一反应是：“我要模拟用户操作，把登录、下单、支付全自动点一遍。”
我亲眼见过一个做电商SaaS的朋友，招了个实习生专门写UI自动化脚本。三个月过去，脚本写了200多个，覆盖率看着挺高。结果那年双十一前夕，前端为了优化体验改了DOM结构，CSS类名变了。
一夜之间，200个脚本全红。 那个实习生差点就在工位上哭了。
这就是小团队的痛点：业务变动太快，UI是最不稳定的层级。
我的建议是：倒金字塔策略。
别去追求那种金字塔尖的UI测试，把80%的精力花在API接口测试上。 接口的参数和返回结构，通常比页面布局稳定得多。
真实落地案例： 后来我们在一个内部CRM项目中，完全放弃了UI自动化。我们用最简单的 Postman + Newman（或者简单的 Pytest 脚本），只覆盖最核心的几条链路：
- 登录获取Token；
- 创建订单；
- 支付回调；
- 查询订单状态。
我们把这个脚本挂在GitLab CI上，每次代码合并只跑这4个接口。虽然只覆盖了5%的功能，但它拦截了80%因为后端改动导致的“低级瘫痪”事故。
你要做的，不是全覆盖，而是守住“生命线”。
误区二：工具贪大求全，DevOps变成了“运维灾难”
市面上关于DevOps的教程，动不动就是 K8s + Jenkins + SonarQube + Nexus 一整套全家桶。
如果你团队里没有专职运维，千万别碰这一套。
我之前有个项目，为了显得正规，强行上了Jenkins。结果那台Jenkins服务器隔三差五就磁盘爆满，或者插件冲突导致构建失败。开发人员不想修，推给我；我没时间修，构建就停了。最后大家又回到了FTP上传代码的原始时代。
对于小团队，工具越“无感”越好。性价比最高的方案，往往是代码托管平台自带的CI/CD。
我用了两年的方案： 如果你们用 GitHub，就用 GitHub Actions；用 GitLab，就用 GitLab CI。
别去搞复杂的Docker编排，一个简单的 Shell 脚本往往最有效。
看看这个最简单的 .gitlab-ci.yml 片段，它帮我们解决了大问题：
stages:
- test
- deploy
# 阶段1：代码提交后自动跑单元测试/接口测试
unit_test:
stage: test
script:
- npm install
- npm test # 这里只跑关键的逻辑测试，不要跑耗时的
# 阶段2：只有打tag时才自动部署到测试服
deploy_dev:
stage: deploy
only:
- tags
script:
- ssh user@your-server "cd /app && git pull && pm2 restart app"
你没看错，就这么几行。它没有花哨的仪表盘，但它保证了**“谁提交的代码导致测试挂了，谁就会收到邮件通知”**。这种即时的反馈环，比任何复杂的报告都有用。
小思考： 你们团队现在的部署流程，是一个人掌控的“黑盒”，还是透明的自动化流程？如果负责部署的那个人请假了，别人能顶上吗？
误区三：把自动化当成“测试人员的事”
这是最深层的思维误区。
很多开发会觉得：“我只管写代码，自动化测试脚本是QA写的。”
在小团队，这种思维是致命的。因为你们可能根本没有QA，或者只有一个忙不过来的兼职测试。如果开发只管“拉屎”不管“擦屁股”，代码质量永远上不去。
性价比最高的做法是：防守左移，让开发承担最低限度的测试责任。
怎么落地？不要靠行政命令，要靠工具约束。
我们在团队里引入了一个硬性规定：Git Hook（提交前检查）。
利用 husky (前端) or pre-commit (后端) 这样的工具，在开发人员执行 git commit 的瞬间，强制运行代码风格检查（Lint）和最基本的冒烟测试。
真实场景复盘： 刚推行这个的时候，阻力很大。有开发抱怨：“我提交个代码还得等两分钟，太慢了。”
但我坚持了下来。两周后，神奇的事情发生了。原本代码仓库里各种 var const 混用、缩进乱七八糟的问题消失了；因为简单的语法错误导致的构建失败率下降了90%。
大家习惯了**“提交即通过”，而不是“提交碰运气”**。
这不需要你花一分钱，只需要在项目初始化时配置好那几个文件。
总结：给技术负责人的3个落地锦囊
回过头看，小团队做自动化测试，核心不是比拼谁的工具牛，而是比拼ROI（投入产出比）。
如果你正在为团队的质量问题发愁，不妨试试这三步：
- 砍掉臃肿的计划：别想做100%覆盖率。哪怕只有一个脚本，只要它能自动跑通“用户登录→下单”这条主链路，它就是有价值的。先让它跑起来，比什么都强。
- 善用现成工具：别自建Jenkins了。把GitHub Actions/GitLab CI用起来，把云服务商提供的免费监控用起来。
- 开发自测文化：给项目加个
pre-commit钩子。哪怕只是检查一下代码格式，也是迈向自动化的第一步。
最后留个问题： 你现在的项目中，如果删掉所有测试文档和用例，只保留一个自动化脚本，你会选择保留哪一个功能点的测试？
想清楚这个问题，你就知道从哪里下手了。