自动化测试与CI/CD：让代码上线不再“提心吊胆”

你有没有经历过这样的场景？改完一个功能，本地跑得好好的，一上线就出问题。客户投诉、领导追问，自己还一头雾水：‘我这儿明明没问题啊！’

这其实是软件开发里最常见的坑——手动测试靠不住，发布流程不规范。这时候，自动化测试和 CI/CD 就派上用场了。

什么是自动化测试？

简单说，就是写一段代码去自动检查另一段代码。比如你写了个加法函数，可以写个测试脚本让它自动输入 2 和 3，看输出是不是 5。不用每次手动点来点去。

举个例子，你在做电商项目，有个计算总价的功能。如果每次都手动选商品、点结算、核对金额，费时又容易漏。而自动化测试可以在你提交代码后，自动跑一遍所有可能的组合，几分钟内告诉你有没有问题。

def test_calculate_total():
    items = [{'price': 10, 'quantity': 2}, {'price': 5, 'quantity': 4}]
    assert calculate_total(items) == 40

CI/CD 又是什么？

CI 是持续集成（Continuous Integration），CD 是持续交付或部署（Continuous Delivery/Deployment）。听起来高大上，其实本质很简单：每次你提交代码，系统就自动帮你跑测试、打包、甚至发布到服务器。

想象一下，你和几个同事都在改同一个项目。有人改了用户登录，有人改了订单逻辑。如果大家改完直接往主分支扔代码，很容易冲突，也容易把坏代码带进去。而有了 CI，每个人提交代码后，系统会自动合并、跑测试。如果测试不过，就别想往上合，问题当场暴露。

CD 则是更进一步。测试通过后，系统可以自动把代码发到测试环境，甚至生产环境。比如你公司规定晚上 12 点上线，不需要你熬夜手动操作，系统到点自动完成。

它们是怎么搭伙干活的？

自动化测试是 CI/CD 的“守门员”。没有测试，CI 就没法判断代码能不能过。而 CI/CD 给自动化测试提供了“执行舞台”，让测试能自动触发、快速反馈。

常见的工作流是：你写完代码，推送到 Git 仓库 → CI 工具（比如 GitHub Actions、GitLab CI）检测到变动 → 自动拉代码、安装依赖、运行测试 → 测试全过，标记为“可发布” → CD 流程接手，把应用部署到服务器。

name: Run Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: python -m pytest

这套流程跑顺了，你会发现：bug 出现得早，修得快；发布不再紧张兮兮；团队协作也更顺畅。哪怕新人加入，也能靠测试知道什么能动、什么不能动。

现在很多工具都支持开箱即用。GitHub + Actions、GitLab CI、Jenkins，配个配置文件就能跑起来。测试框架也很多，Python 有 pytest，JavaScript 有 Jest，Java 有 JUnit。

别想着一步到位。可以从最核心的功能写起，比如用户注册、支付流程，先覆盖住关键路径。慢慢再补全边界情况。重要的是先动起来，而不是等“完美方案”。