Python自动化测试与CI/CD落地：从环境搭建到稳定性治理

说实话，很多人一提到Python自动化测试，第一反应就是装个Selenium，写个脚本把网页从头点一遍，然后就没有然后了。结果呢？本地跑得好好的，换台机器就报错；用例写了两百条，一到回归就红成一片；CI/CD听起来很高大上，可真把测试接进流水线，反倒成了最不稳定的那一环。这还真不是技术不够，而是缺少一条从环境、用例设计、框架选型到流水线集成的完整链路。

这篇文章就按这条链路来写，内容覆盖Python自动化测试与CI/CD落地，既有接口自动化，也有UI自动化，还会专门讲几类高频踩坑点，比如非预期弹窗导致的失败、CI环境不稳定、报告没人看之类的问题。你如果已经能写出“能跑”的Python脚本，但不知道自动化测试该怎么工程化，或者刚被安排去搭建测试体系，看这篇应该能少走不少弯路。

1. 自动化测试起步，先把Python工程环境搭成“能长期用”的样子

很多人一上来就pip install selenium然后开写，写到第三个项目就崩了：包版本打架、Python版本对不上、别人拉你代码跑不起来。我见过太多这种场景，所以第一件事不是讲框架，而是把工程环境理清楚。

1.1 Python版本和虚拟环境怎么选

Python版本，我用得最多的是3.9到3.11这个区间。别一上来就追最新版，企业项目里很多依赖库还没跟上，你装个3.13，Selenium或某些内部封装库可能就报兼容性问题。同样，也不要还停留在2.7时代，处理中文编码和依赖管理会让你怀疑人生。

虚拟环境是必选项。每个项目一个独立的解释器环境，依赖版本互相隔离，这个习惯越早养成越好。打个比方：你不可能把装修用的工具箱和做饭用的调料盒放在同一个抽屉里，项目也是一样，A项目要Django 3.2，B项目要Django 4.2，放一起必出事。

创建虚拟环境的路径很简单：

# 进入项目目录 cd my_automation_project # 创建虚拟环境，venv是Python自带的，不需要额外安装 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS / Linux: source venv/bin/activate # 看到命令行前面出现(venv)就说明激活成功了

激活后，安装的所有包都会进到这个虚拟环境里。依赖导出我建议分场景：如果有完整的依赖清单，直接用requirements.txt；如果项目一开始没规划好，想自动找出实际用到的包，可以试试pipreqs。最简单的方式是这样的：

pip freeze > requirements.txt

不过你如果环境里已经装了很多不相关的包，freeze会把它们全部打进去。我更建议定期整理，只保留项目实际使用的依赖，这样你或者别的同事用pip install -r requirements.txt的时候，不会装一堆用不上的东西。

1.2 目录结构，提前定好能省很多事

自动化测试项目最怕的就是所有脚本堆在一个目录里。今天一个login_test.py，明天一个test_order.py，全在根目录，过两个月看到就头疼。

我常用的自动化测试项目结构是这样：

my_automation_project/ ├── config/ # 配置文件和公共常量 │ ├── __init__.py │ └── settings.py ├── data/ # 测试数据文件，Excel、YAML、JSON都放这 ├── tests/ # 测试用例 │ ├── __init__.py │ ├── test_api/ # 接口用例 │ └── test_ui/ # UI用例 ├── common/ # 公共封装，如请求封装、日志封装、弹窗处理 │ ├── __init__.py │ └── request_util.py ├── reports/ # 测试报告和日志输出 ├── requirements.txt └── pytest.ini # pytest配置

pytest.ini里我会至少配置这样几个字段：

[pytest] testpaths = tests log_cli = true log_cli_level = INFO addopts = -v --tb=short

配置了testpaths之后，pytest会自动去tests目录下收集用例，不用每次手动指定路径。log_cli开启后，跑用例的时候能直接看到日志输出，排查问题会舒服很多。

1.3 VSCode配置Python环境的两个细节

用VSCode写Python是现在的主流，但很多人会遇到同一个问题：明明在终端里能import的包，编辑器却报红，或者调试的时候提示ModuleNotFoundError。原因基本都是解释器没选对。

在VSCode里按Ctrl+Shift+P，输入“Python: Select Interpreter”，选择你虚拟环境里的那个python.exe，而不是系统全局的Python。选完重启一下终端，再跑代码就正常了。

另一个细节是调试配置。用pytest跑用例，不需要自己去写一堆main函数，直接在VSCode的调试面板里创建launch.json，配置成pytest即可：

{ "version": "0.2.0", "configurations": [ { "name": "Python: pytest", "type": "python", "request": "launch", "module": "pytest", "args": ["-v"] } ] }

这样你可以在用例里打断点，点调试就进pytest流程，观察变量和调用链比print大法效率高得多。

2. 接口自动化测试：从“能调通”到“能回归”的完整思路

UI自动化不稳定是个长期痛点，所以在项目初期优先做接口自动化，是性价比最高的方案。接口测试跑得快、定位准，接口过了，前端大概率不用背锅；接口挂了，问题范围直接缩小到后端，开发排查也快。

2.1 为什么接口自动化要放在UI前面

测试金字塔很多人都听说过：底层大量单元测试，中间层服务/接口测试，顶层少量端到端UI测试。落到实际业务里，我的经验是接口自动化至少要占自动化用例的60%以上。

接口测试的好处是稳定。UI上每个版本样式变一变，元素定位可能就全崩了，但接口的字段和协议相对稳定。而且接口用例执行速度极快，一个后端接口用例几十毫秒到几百毫秒就出结果，UI用例动辄几十秒甚至一分钟起步。跑完100个接口用例可能只要2分钟，100个UI用例可能要跑一小时，这个时间成本在CI/CD里差异会被无限放大。

2.2 requests核心用法：别把写请求当调工具

Python做接口自动化，requests库是绝对的主角。但很多人只是会用requests.get()、requests.post()，真正遇到问题就懵了。

先看一个实际场景：接口需要先登录拿token，然后带着token去请求业务数据。

import requests # 登录接口 login_url = "https://api.example.com/login" login_data = { "username": "tester", "password": "123456" } resp = requests.post(login_url, json=login_data, timeout=10) assert resp.status_code == 200 token = resp.json()["data"]["token"] # 带token请求业务接口 headers = {"Authorization": f"Bearer {token}"} order_url = "https://api.example.com/orders" order_resp = requests.get(order_url, headers=headers, timeout=10) assert order_resp.status_code == 200 order_data = order_resp.json()

这里有几个细节值得注意：

• 用json=传参，requests会自动把字典序列化成JSON，并且设置Content-Type为application/json。如果你用data=传参，发送的是表单格式，很多后端接口根本解析不了。
• timeout一定要设置。不设timeout的话，接口如果一直没有响应，你的测试用例会一直挂在那里，在CI上直接拖垮整个流水线。10秒是我常用的默认值，取决于业务接口的响应时间，可以调大/调小。
• 每一个请求都要做响应断言，不能只print出来人眼观察，否则自动化失去了意义。

更复杂的场景，比如需要保持登录状态，requests.Session可以帮你自动维持Cookie和连接池：

session = requests.Session() session.post(login_url, json=login_data) # 后续请求直接用session.get/post，自动带登录状态 resp = session.get(order_url, timeout=10)

2.3 pytest组织用例：fixture和参数化是核心

requests负责发请求，pytest负责把用例组织起来。如果你还在用unittest，我强烈建议切到pytest，语法更简洁，fixture和参数化也更灵活。

fixture适合处理“每个用例都需要的前置条件”：

import pytest import requests @pytest.fixture(scope="session") def base_url(): # 这里可以做环境切换，qa/prod return "https://api.example.com" @pytest.fixture(scope="session") def login_session(base_url): s = requests.Session() resp = s.post( f"{base_url}/login", json={"username": "tester", "password": "123456"}, timeout=10 ) return s def test_get_orders(login_session, base_url): resp = login_session.get(f"{base_url}/orders", timeout=10) assert resp.status_code == 200 assert resp.json()["code"] == 0

fixture的scope参数很有讲究：

• scope="function"：每个用例都执行一次，适用于创建临时数据。
• scope="session"：整个测试会话只执行一次，比如登录获取token，复用在多个用例里。

参数化是做数据驱动的核心。接口测试经常要覆盖多组输入，比如不同账号、不同参数组合：

import pytest @pytest.mark.parametrize("username,password,expected_code", [ ("tester1", "123456", 0), ("tester2", "wrong_pwd", 10001), ("", "123456", 10002), ]) def test_login_cases(username, password, expected_code): resp = requests.post( "https://api.example.com/login", json={"username": username, "password": password}, timeout=10 ) assert resp.json()["code"] == expected_code

这种写法有三个作用：一是用例简洁，一组参数就是一条测试场景；二是可读性好，后面的人一看就知道覆盖了哪些分支；三是新增场景成本极低，往参数列表里加一行就行。

更复杂的场景，可以把数据放到YAML或Excel里，然后写一个读取数据的工具类，配合pytest生成用例。不过刚开始做，不建议一上来就搞太重的数据驱动框架，先用参数化把核心场景跑通，后面再逐步扩展。

2.4 环境切换和动态参数，最容易踩的两个坑

接口自动化项目做大了，一定会遇到环境问题。本地联调用测试环境，流水线里也要跑不同环境，代码里如果写死了域名，换个环境就得改代码。

我的做法是在pytest.ini里配置环境变量，或者在config/settings.py里统一管理：

import os ENV = os.getenv("TEST_ENV", "qa").lower() BASE_URL_MAP = { "qa": "https://qa-api.example.com", "staging": "https://staging-api.example.com", "prod": "https://api.example.com", } BASE_URL = BASE_URL_MAP.get(ENV, BASE_URL_MAP["qa"])

然后在命令行里启动测试时指定环境：

TEST_ENV=staging pytest -q

这样环境切换不碰代码，流水线里也只需要改环境变量。

动态参数是另一个高频问题。比如创建订单会返回一个订单ID，然后需要拿这个订单ID去查订单详情。处理方式是把上一个接口的响应保存下来，传给下一个接口。pytest里有一个非常方便的做法，利用request fixture在用例之间传递数据，但前提是同一个测试类里，用例顺序是可控的：

import pytest @pytest.fixture(scope="class") def created_order(login_session, base_url): create_resp = login_session.post( f"{base_url}/orders", json={"product": "iphone", "qty": 1}, timeout=10 ) return create_resp.json()["data"]["order_id"] @pytest.mark.usefixtures("login_session") class TestOrderFlow: def test_get_order_detail(self, created_order, login_session, base_url): resp = login_session.get(f"{base_url}/orders/{created_order}", timeout=10) assert resp.status_code == 200

这样设计的好处是：创建订单这个“前置动作”只在每个测试类里执行一次，然后多个用例可以复用；而且用例之间的依赖关系在代码里一目了然。

3. UI自动化测试的“脆皮”困境与合理取舍

接口自动化解决的是业务逻辑的回归，但有些交互流程，比如注册、下单、页面操作，光靠接口覆盖不了，这时候必须上UI自动化。UI自动化要说最难的点，不是写脚本，而是处理稳定性和维护成本的问题。

3.1 Selenium还是Playwright，我的选型建议

Selenium是老牌框架，文档多、资料全、兼容性强，团队的熟悉度高；Playwright是后起之秀，自带自动等待、录制脚本、多浏览器支持，能处理登录页的复杂交互。我自己个人在做新项目的时候，已经优先推荐Playwright了。

但这不意味着Selenium要被淘汰。如果你维护的是一个大规模Selenium项目，完全没必要推倒重来，稳定性和团队熟练度更重要。选型标准很简单：新项目，优先Playwright；老项目，继续用Selenium，把稳定性做扎实。

这里我以Selenium为例写一个UI登陆用例，因为Selenium的资料最多，很多团队还在用：

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login(): driver = webdriver.Chrome() driver.get("https://example.com/login") WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, "username")) ).send_keys("tester") driver.find_element(By.ID, "password").send_keys("123456") driver.find_element(By.ID, "login-btn").click() WebDriverWait(driver, 10).until( EC.url_contains("/dashboard") ) assert "/dashboard" in driver.current_url driver.quit()

3.2 定位与等待：少用sleep，多用显式等待

UI自动化里，90%的不稳定因素来自元素定位和等待。代码写快了，元素还没渲染出来就去找；网络慢了，页面还在加载就去点击；接口响应不确定，sleep(5)可能不够也可能过多。

元素定位优先级我建议这样排：

• 优先用data-testid、id、name这类稳定的属性，前端开发可以配合预留测试钩子。
• 其次用CSS选择器，结构清晰，性能好。
• XPath虽然强大，但尽量少用绝对路径，特别是含层级索引的，前端稍微改个DOM结构定位就崩。

等待机制，一句话总结：能用显式等待，绝不用隐式等待；能用等待，绝不用sleep。

显式等待的标准写法：

WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, "order-list")) )

系统会每隔几百毫秒检查一次元素是否出现，最多等10秒。如果10秒还没出现，就报超时异常，这样效率比sleep高得多。把等待封装成公共函数，避免每个用例里都写一堆样板代码：

def wait_element(driver, by, value, timeout=10): return WebDriverWait(driver, timeout).until( EC.element_to_be_clickable((by, value)) )

3.3 非预期弹窗导致失败：一个值得单独解决的经典问题

非预期弹窗（被截获的弹出框）是UI自动化最常遇到的失败原因之一。页面加载到一半，突然弹出一个抽奖活动、一个服务通知、一个广告浮窗甚至一个系统级别的对话框，直接把后续元素定位全挡住了，用例当场失败。

真实场景里弹窗类型基本有这几种：

• 浏览器原生弹窗（alert/confirm/prompt），Selenium可以自动处理或用driver.switch_to.alert接受/关闭。
• 页面内模态框（Modal），通常是一个div浮层，用close按钮或遮罩层点击关闭。
• 系统级弹窗，比如下载、上传文件时的操作系统窗口，处理起来更麻烦。

处理思路不是每个用例都去写弹窗处理，而是做一个统一防御。比如在公共的操作方法里，每次点击前先尝试关闭可能出现的弹窗：

def safe_click(driver, by, value, timeout=5): try: # 先尝试关闭常见的公告弹窗 close_btn = driver.find_element(By.CLASS_NAME, "close-popup") close_btn.click() except Exception: pass # 没有弹窗就算了，不阻塞主流程 element = wait_element(driver, by, value) element.click()

更稳妥的办法，是把弹窗处理和失败重试结合起来：当用例因为点击失败而报错时，先尝试恢复页面状态（关闭弹窗、回到首页），然后重试一次操作。如果重试还是不行，再上报失败。

def retry_click(driver, by, value, retry=2): for i in range(retry): try: safe_click(driver, by, value) return except Exception as e: driver.save_screenshot(f"retry_{i}.png") driver.refresh() # 刷新页面，消除弹窗影响 raise AssertionError(f"点击元素失败: {by}={value}")

这种“防御+重试”的机制，虽然看起来不够优雅，但在实际项目中非常有效。它能硬扛掉很大一部分偶发的弹窗干扰，让UI自动化真正在CI里稳定跑起来。

3.4 无头模式与CI适配

UI自动化接入CI，服务器上通常没有图形界面，所以必须开启无头模式。Selenium的配置如下：

from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--headless") options.add_argument("--no-sandbox") options.add_argument("--disable-dev-shm-usage") options.add_argument("--window-size=1920,1080")

• --no-sandbox：在部分Linux CI容器里必须加，否则Chrome启动直接报错。
• --disable-dev-shm-usage：容器环境/dev/shm空间太小，不加可能导致Chrome崩溃。
• --window-size一定设大一点，小窗口下很多前端组件会折叠或遮挡，元素定位也会出问题。

在CI里跑UI用例，还有两个细节：

• 失败时一定要截图保存，最好同时保存页面源码，便于排查。
• 跑完的后处理里，用driver.quit()关闭浏览器，不要等进程自己结束，否则CI上会残留一堆僵尸Chrome进程，最后把服务器内存耗光。

4. 把测试代码放进CI/CD流水线：从手动跑用例到自动发布前校验

自动化测试项目跑通了，下一步就是把它接进CI/CD。以前是人手动跑用例，现在要变成代码提交后或每天固定时间自动跑，并且结果自动通知给团队。

4.1 为什么本地能跑，流水线里就各种挂

很多团队第一次把测试接进流水线，都会遇到“本地是绿的，CI上是红的”这种情况。原因无非这几类：

• 依赖版本不一致：本地环境装了A包1.1.0，CI里根据requirements.txt装的是A包1.0.9，行为差异导致用例失败。
• 环境变量缺失：本地测试用的token、密钥写在代码里或环境变量里，CI的机器上没有这些配置。
• 网络或域名限制：CI服务器可能访问不了某些内网域名，或者访问外部环境超时。
• 数据状态不一致：本地数据库里有测试数据，CI环境里的库是干净的或有脏数据，导致接口返回值不同。

解决思路就一条：让CI环境尽可能贴近本地。通过Docker容器、固定依赖版本、在流水线里配置环境变量，把环境和数据都前置准备好，而不是等用例跑了才发现问题。

4.2 一个可以直接抄的GitHub Actions配置

如果你的代码托管在GitHub上，GitHub Actions是最简单的方式。下面这个workflow演示了提交代码后，自动拉代码、装依赖、跑pytest、上传报告，全部自动完成：

name: Python Automation Tests on: push: branches: [ main, develop ] pull_request: branches: [ main ] schedule: - cron: '0 2 * * *' # 每天凌晨2点跑一次回归 jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: | python -m pip install --upgrade pip pip install pytest pytest-html pytest-xdist pytest-rerunfailures pip install -r requirements.txt - name: Run tests env: TEST_ENV: staging API_TOKEN: ${{ secrets.API_TOKEN }} run: | pytest -n 4 --reruns 2 --html=reports/report.html --self-contained-html - name: Upload report uses: actions/upload-artifact@v4 if: always() with: name: pytest-report path: reports/

这个配置文件里能改变命运的就是那三条GitHub Actions配置：

• pytest -n 4：用pytest-xdist并行跑4个进程，用例多的时候速度能快好几倍。
• --reruns 2：用pytest-rerunfailures对失败用例重试2次。注意，重试的目的是容忍偶发网络抖动，而不是掩盖真正的逻辑bug，所以重试后依然失败的话，流水线依然是红的。
• if: always()：即使测试失败了，也要上传报告文件，方便排查。

secrets.API_TOKEN这种敏感信息，在GitHub仓库的Settings -> Secrets里配置，不会出现在代码里。

4.3 Jenkins流水线怎么配置

GitHub Actions好用，但很多公司内网用的还是Jenkins。Jenkins里我习惯用Pipeline（Jenkinsfile）的方式，把流水线配置写在代码仓库里，方便版本化管理。一个简单示例如下：

pipeline { agent any environment { TEST_ENV = 'staging' PYTHON_BIN = '/usr/bin/python3' } stages { stage('Checkout') { steps { checkout scm } } stage('Setup') { steps { sh '${PYTHON_BIN} -m venv venv' sh 'venv/bin/pip install -r requirements.txt' } } stage('Test') { steps { sh 'venv/bin/pytest tests/ -n 4 --reruns 2 --alluredir=allure-results' } } stage('Report') { steps { allure includeProperties: true, jdk: '', reportBuildPolicy: 'ALWAYS' junit 'reports/*.xml' } } } post { always { archiveArtifacts artifacts: 'allure-results/**', allowEmptyArchive: true } failure { // 发送通知，钉钉/企业微信/邮件都行 emailext subject: "自动化测试失败: ${env.JOB_NAME}", body: '请查看流水线日志', to: 'qa@example.com' } } }

Jenkins配置里最有用的两个参数：

• allure includeProperties：直接生成可视化测试报告，浏览器点开就能看，比命令行的文本输出直观一百倍。
• archiveArtifacts：把结果存档，既有报告也有日志，事后追溯方便。

4.4 让CI执行更快、更稳定的两个技巧

流水线跑多了就会发现，除了用例本身的稳定性，执行速度和稳定性同样影响团队情绪。如果每次跑一小时才出结果，开发等不起；如果流水线天天报错，最后就没人看流水线状态了。

执行速度优化手段：

• 在CI上做依赖缓存，requirements.txt没有变化就不重复pip install。
• 用pytest-xdist并行执行，但注意用例之间不能有数据依赖，否则并行会互相污染。
• 把冒烟用例和全量回归用例分开。代码提交时只跑冒烟集合，每天定时跑全量回归，反馈速度快，覆盖也到位。

稳定性的核心手段：

• 失败重试。但只对UI用例和偶发性接口超时做重试，不要掩盖真实失败。
• 失败后的自动清理。用例执行中创建的测试数据，无论成功失败都要清理，避免脏数据影响后续运行。

5. 跑得稳比跑得多重要：稳定性治理与长期维护

自动化测试跑起来了，真正的挑战才刚开始。你会发现一个残酷的事实：用例越多，维护成本越高。如果自动化测试天天报红，比不自动化还可怕，因为团队会失去对它的信任。

5.1 用例设计的独立性原则

接口用例和UI用例，每一类都应该尽量独立。意思是：不管其他用例执行顺序如何、其他用例是否失败，单个用例都应该能独立跑通。

具体来说有三点：

• 用例的测试数据自己创建，不要依赖之前的代码“刚好”创建了A数据。
• 用例的前置准备用fixture或setup完成，而不是在另一个用例里偷偷执行。
• 不要在两个用例之间共享可变状态。比如A用例改了配置，B用例假设配置还是原来的，顺序一变就挂了。

我刚开始写自动化的时候习惯把一些公共操作放在用例类里，一个用例跑完，数据没清理，另一个用例直接拿这个数据继续跑。看起来省事了，但后来发现这种用例完全没法并行、没法单独调试，改起来也煎熬。后来全部改成独立用例，虽然执行时重复创建了一些数据，但稳定性和可维护性提升了好几个档次。

5.2 减少“脆皮”用例的自我修养

UI自动化里，最怕的就是一类用例：每次跑结果都不一样，这次过了，下次就挂了，再跑一次又过了。这类“脆皮”用例特别消耗团队精力，因为你不确定它是真bug还是假失败。

脆皮用例的常见原因：

• 隐式等待不够，或者用了固定sleep。解决办法是全部改显式等待。
• 定位器写得太脆弱，比如依赖了层级索引span[1]这种，前端微调就挂。
• 测试环境数据不稳定，比如优惠券被领完了、订单状态被后续用例改了。
• 浏览器执行动画未结束，点击被浮动层拦截。解决办法是点击前判断元素是否可点击，而不是简单判断存在。

处理脆皮用例的关键是记录：失败时一定要截图和保存页面源码，看看到底卡在哪一步。如果连续多次同样的原因，不要急着修，先看是不是环境问题；如果大概率是产品结构变了的偶发弹窗，再决定是加防御还是改定位。

5.3 自动化测试与手工测试，边界在哪里

有团队会问：自动化测试都上了，是不是手工测试就不需要了？我的观点正好相反：自动化替代的是那些重复、琐碎、执行频繁的回归步骤；而探索性测试、需求理解、用户体验判断这些事，自动化还替代不了。

我的建议是用“风险优先”来做取舍：

• 核心主流程（注册、登录、下单、支付）优先自动化，这些功能改动频繁、影响面大、回归成本最高。
• 边缘条件和异常场景，主要靠手工或者留一部分接口用例覆盖。
• 新增功能的最初版本，不建议急着自动化，先把功能本身测稳定，再补自动化，否则你会整天改脚本而不是发现bug。

自动化覆盖率不是越高越好，重点是让测试体系能稳定运转。一个能一直跑、反馈准确的50条用例，比一个三天两头红、没人会修的200条用例有价值得多。

5.4 把自动化测试当成产品来维护

这是我做了这么多年最深的体会。自动化测试项目和你写的任何产品代码一样，有需求、有设计、有迭代、有维护。不是写完脚本就结束了，而是把它当作一个长期存在的内部工具来运营：

• 每次业务功能变化时，同步更新对应用例，而不是等用例挂了才想起来改。
• 定期清理无效用例，不要留着那些永远在跑、永远不稳定的“僵尸用例”。
• 对失败用例做分类统计：是脚本问题、数据问题还是产品bug，记录原因并持续优化。

说一个具体的习惯：我每两周会花一点时间，拉出最近所有失败用例，按原因归类。如果是元素定位变了，当场就改；如果是偶发环境问题，加防御或重试；如果是新需求改动了交互，评估是否需要重写用例。把“维护用例”当成和“写代码”同样重要的事情来做，自动化测试的长期价值才会体现出来。

最后分享一个我自己的经验：做自动化测试，别急着一次铺开所有功能。选一条核心主流程，把环境、用例、CI/CD、报告、通知全部打通，让它能稳定跑一个月，再考虑扩大范围。我见过不少团队一上来就规划几十个模块的自动化，结果框架搭了三个月，用例没跑几条，项目组就被拖垮了。小而稳定，先有个能给大家看的结果，比什么都重要。