1. 项目概述

如果你是一名测试工程师，或者正在向这个方向转型，那么“Python自动化测试脚本”这个标题对你来说，可能既熟悉又充满困惑。熟悉的是，这几乎是现代软件测试岗位的必备技能；困惑的是，面对网络上浩如烟海的教程和框架，从何下手、如何构建一个真正能用、好用的脚本，往往让人无从下手。我干了十多年测试，从手工点点点一路做到自动化测试架构，深知一个脚本从“能跑”到“好用”再到“可维护”，中间隔着无数个需要填平的坑。今天，我就以一个从业者的视角，抛开那些华而不实的理论，直接聊聊怎么用Python写出一个扎实、可靠、能直接用在项目里的自动化测试脚本。

简单来说，一个Python自动化测试脚本的核心任务，就是模拟用户或系统行为，自动执行预设的测试步骤，并验证结果是否符合预期。它解决的远不止是“解放人力”的问题，更深层的价值在于实现快速回归、保证核心功能稳定、以及在持续集成/持续交付（CI/CD）流程中充当质量守门员。无论你是测试新人想入门，还是有一定基础的开发者想提升脚本的工程化水平，这篇文章都会从最接地气的思路拆解到可落地的代码细节，带你走一遍完整的构建流程。我们会重点围绕接口自动化这个最常见、也最实用的场景展开，因为这是大多数项目自动化建设的起点和基石。

2. 自动化测试脚本的整体设计思路

写自动化脚本，最忌讳的就是一上来就敲代码。在没有想清楚“测什么”、“怎么测”、“如何组织”之前，写出来的代码往往结构混乱、难以维护，最后变成没人敢动的“祖传代码”。一个清晰的顶层设计，是脚本能否长期存活的关键。

2.1 核心需求解析：我们到底要自动化什么？

首先得明确目标。自动化测试不是银弹，不能也不应该试图自动化所有测试。根据我的经验，优先级最高的是那些 重复执行频率高、业务价值大、执行过程稳定 的测试场景。典型例子包括：

1. 核心业务流程的冒烟测试 ：每次发布前，必须保证主流程畅通。比如电商的下单-支付流程。
2. 公共接口的回归测试 ：底层服务或模块修改后，需要快速验证其对外提供的接口是否依然正常工作。
3. 数据一致性校验 ：比如订单生成后，数据库、缓存、消息队列里的数据是否同步正确。

对于新手，我强烈建议从 单个接口的自动化 开始。理由很简单：接口是系统间交互的契约，相对稳定；输入输出明确，易于断言；技术实现难度适中，容易获得正反馈。就像我们引用的那篇博客里用天气查询接口做例子一样，从一个明确的、简单的接口入手，能把自动化测试的完整流程跑通。

2.2 技术栈选型：为什么是Python + pytest + Requests？

看到“Python自动化测试”，很多人会立刻想到Selenium或Appium做UI自动化。但对于构建自动化测试体系而言， 接口自动化应该优先于UI自动化 。因为接口测试更快、更稳定、维护成本更低，更能触及业务逻辑的核心。

因此，我们的基础技术栈很明确：

• Python ：语法简洁，生态丰富，是测试自动化领域的事实标准语言。
• pytest ：目前最主流的Python测试框架。它比unittest更简洁灵活，夹具（fixture）机制强大，插件生态丰富（如生成报告、控制执行顺序），社区活跃。用它来组织和管理我们的测试用例再合适不过。
• Requests ：用于发送HTTP请求的库，其API设计非常人性化，是处理接口测试的利器。

这个组合的优势在于，它们各自专注又完美互补：Python提供语言基础，pytest提供测试骨架和运行引擎，Requests则负责具体的网络交互操作。整个技术栈轻量、高效，学习曲线平缓。

2.3 脚本架构设计：从“脚本”到“项目”

一个可持续维护的自动化测试，不应该只是一个单独的 .py 文件。我们需要一个初步的项目结构来组织代码。在项目初期，我建议至少包含以下目录和文件：

your_auto_test_project/
├── test_cases/           # 存放测试用例脚本
│   └── test_weather_api.py
├── common/               # 存放公共模块
│   ├── __init__.py
│   ├── request_client.py # 封装requests的客户端
│   └── logger.py         # 日志记录模块
├── config/               # 配置文件
│   └── config.yaml       # 或 config.ini, settings.py
├── data/                 # 测试数据文件
│   └── test_data.json
├── reports/              # 测试报告目录（pytest-html等插件生成）
├── conftest.py           # pytest的全局配置文件，定义fixture
└── requirements.txt      # 项目依赖列表

为什么这么设计？

• 分离关注点 ：用例脚本只关心测试逻辑（输入、执行、断言），而网络请求、日志、配置读取等公共操作被抽离到 common 模块。这样，当请求库需要升级或日志格式需要调整时，你只需要修改一个地方。
• 数据驱动 ：将测试数据（如不同的城市参数）从代码中分离出来，放到 data 目录下的文件里。这样增加测试场景时，无需修改代码，只需添加数据，让脚本更容易扩展。
• 配置化管理 ：将环境URL、超时时间、重试次数等配置项放在 config 中。切换测试环境（从测试环境到预发布环境）时，只需改一个配置，而不是翻遍所有脚本。

注意 ：不要一开始就追求大而全的框架。这个结构是一个“最小可行架构”，它足够支撑初期项目，又为未来的扩展预留了空间。很多团队失败的原因就是一开始架构设计得太复杂，导致迟迟无法产出有价值的测试用例。

3. 核心模块拆解与实现细节

有了顶层设计，我们来深入看看几个核心模块具体该怎么实现。这里面的细节，直接决定了脚本的健壮性和可维护性。

3.1 请求客户端的封装：告别散装的Requests调用

直接在测试用例里写 requests.get(url, params) 是最快的，但也是最糟糕的做法。一旦需要添加统一的请求头、超时设置、异常处理或日志记录，你就需要修改每一个用例。正确的做法是封装一个自己的请求客户端。

# common/request_client.py
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
import logging

logger = logging.getLogger(__name__)

class RequestClient:
    def __init__(self, base_url='', timeout=10):
        self.base_url = base_url
        self.timeout = timeout
        self.session = requests.Session()
        
        # 配置重试策略：对于网络波动导致的503、502等错误进行重试
        retry_strategy = Retry(
            total=3,  # 总重试次数
            backoff_factor=1,  # 重试等待时间因子
            status_forcelist=[500, 502, 503, 504]  # 遇到这些状态码才重试
        )
        adapter = HTTPAdapter(max_retries=retry_strategy)
        self.session.mount('http://', adapter)
        self.session.mount('https://', adapter)
        
        # 设置默认请求头（可根据项目需要调整）
        self.session.headers.update({
            'User-Agent': 'MyAutoTestClient/1.0',
            'Content-Type': 'application/json'
        })
    
    def request(self, method, endpoint, **kwargs):
        """统一的请求方法"""
        url = f"{self.base_url}{endpoint}" if self.base_url else endpoint
        
        # 确保超时设置
        if 'timeout' not in kwargs:
            kwargs['timeout'] = self.timeout
            
        logger.info(f"发送请求: {method} {url}, 参数: {kwargs.get('params', {})}, 数据: {kwargs.get('data', {})}")
        
        try:
            response = self.session.request(method, url, **kwargs)
            logger.info(f"收到响应: 状态码={response.status_code}, 耗时={response.elapsed.total_seconds():.2f}s")
            # 可以在这里添加对响应内容的初步日志，注意敏感信息过滤
            # logger.debug(f"响应体: {response.text[:500]}") # 只记录前500字符
            return response
        except requests.exceptions.Timeout:
            logger.error(f"请求超时: {url}")
            raise
        except requests.exceptions.ConnectionError:
            logger.error(f"网络连接错误: {url}")
            raise
        except Exception as e:
            logger.error(f"请求发生未知错误: {e}")
            raise
    
    # 提供便捷方法
    def get(self, endpoint, params=None, **kwargs):
        return self.request('GET', endpoint, params=params, **kwargs)
    
    def post(self, endpoint, data=None, json=None, **kwargs):
        return self.request('POST', endpoint, data=data, json=json, **kwargs)
    
    # 可以继续封装 put, delete, patch 等方法

封装的价值 ：

1. 统一行为 ：所有请求都经过同一个客户端，确保了超时、重试、日志等行为的一致性。
2. 易于维护 ：未来如果需要更换请求库（虽然概率很小），或者增加统一的认证逻辑、代理设置，只需修改这个类。
3. 提升健壮性 ：内置的重试机制可以应对临时的网络抖动或服务不稳定，让测试脚本更可靠。

3.2 测试用例的规范化编写

用例脚本应该清晰、简洁，只关注测试逻辑本身。我们利用上面封装的客户端来重写天气查询的例子。

# test_cases/test_weather_api.py
import pytest
from common.request_client import RequestClient

class TestWeatherAPI:
    """天气查询接口测试套件"""
    
    # 使用pytest fixture来初始化客户端，实现依赖注入
    @pytest.fixture(scope="class")
    def client(self):
        # 这里可以从配置文件读取base_url，实现环境隔离
        # base_url = config.get('TEST_ENV', 'base_url')
        # 本例中接口是固定的，所以不设置base_url
        client = RequestClient(timeout=15) # 针对这个稍慢的接口，延长超时时间
        yield client
        # 测试类结束后可以做一些清理工作，比如关闭session（但RequestClient内部会处理）
    
    @pytest.mark.parametrize("city, expected_keyword", [
        ("浙江杭州天气", "window.tplData"),  # 正向用例：城市存在
        ("不存在的城市天气", "暂未开通此城市查询"), # 异常用例：城市不存在
        ("北京天气", "window.tplData"),       # 增加更多正向用例
    ])
    def test_query_weather(self, client, city, expected_keyword):
        """测试天气查询接口：验证不同城市输入返回正确信息"""
        url = "https://weathernew.pae.baidu.com/weathernew/pc"
        params = {
            "query": city,
            "srcid": 4982
        }
        
        # 发起请求
        response = client.get(url, params=params)
        
        # 断言
        assert response.status_code == 200, f"接口请求失败，状态码: {response.status_code}"
        
        if expected_keyword == "window.tplData":
            # 对于存在的城市，响应中应包含天气数据
            assert expected_keyword in response.text, f"响应中未找到关键字'{expected_keyword}'，城市：{city}"
        else:
            # 对于不存在的城市，响应中应包含错误提示，且不包含天气数据
            assert expected_keyword in response.text, f"响应中未找到错误提示'{expected_keyword}'，城市：{city}"
            assert "window.tplData" not in response.text, f"不存在的城市'{city}'却返回了天气数据"

这段代码的改进点 ：

1. 使用Fixture管理资源 ： client fixture确保了测试类中所有用例共享同一个请求会话（Session），提高了效率，并且能自动管理资源的创建和清理。
2. 参数化测试 ：使用 @pytest.mark.parametrize 装饰器，将测试数据和逻辑分离。只需在一个列表里添加新的 (城市, 预期关键词) 组合，就能轻松扩展测试场景，避免了写多个重复的测试方法。
3. 清晰的断言信息 ：断言失败时，会输出自定义的错误信息，能快速定位是哪个城市、哪个检查点出了问题，而不是一个简单的 AssertionError 。
4. 逻辑分离 ：将正向和异常的断言逻辑区分开，使代码意图更明确。

3.3 测试数据的管理策略

当测试用例越来越多时，硬编码在装饰器里的数据也会变得难以管理。这时，我们可以将测试数据外置。

方法一：使用JSON或YAML文件

# data/weather_test_data.yaml
test_cases:
  - name: "查询存在的城市-杭州"
    city: "浙江杭州天气"
    expected_keyword: "window.tplData"
    should_contain_tplData: true
  - name: "查询存在的城市-北京"
    city: "北京天气"
    expected_keyword: "window.tplData"
    should_contain_tplData: true
  - name: "查询不存在的城市"
    city: "微信公众号：测试上分之路"
    expected_keyword: "暂未开通此城市查询"
    should_contain_tplData: false

然后在测试用例中读取这个文件：

import yaml
import pytest

def load_test_data():
    with open('data/weather_test_data.yaml', 'r', encoding='utf-8') as f:
        data = yaml.safe_load(f)
    return data['test_cases']

class TestWeatherAPIWithDataFile:
    @pytest.fixture(params=load_test_data())
    def weather_test_case(self, request):
        """通过fixture参数化加载外部数据"""
        return request.param
    
    def test_query_weather_with_data(self, client, weather_test_case):
        case = weather_test_case
        url = "https://weathernew.pae.baidu.com/weathernew/pc"
        params = {"query": case['city'], "srcid": 4982}
        
        response = client.get(url, params=params)
        assert response.status_code == 200
        
        assert case['expected_keyword'] in response.text
        
        if case['should_contain_tplData']:
            assert "window.tplData" in response.text
        else:
            assert "window.tplData" not in response.text

方法二：使用Python文件或字典 对于更复杂的数据逻辑（比如需要动态生成数据），可以直接在Python模块中定义数据生成函数。

实操心得 ：对于简单的、静态的测试数据，YAML/JSON文件非常直观，非技术人员也能看懂和修改。对于需要复杂逻辑生成的动态数据（比如依赖前一个接口返回的ID），则更适合在 conftest.py 或专用的数据准备fixture中用Python代码生成。不要拘泥于一种形式，根据实际情况混合使用。

4. 进阶：让脚本更健壮、更智能

基础脚本跑起来后，我们就要考虑如何让它更可靠、更能融入开发流程。这部分是区分“玩具脚本”和“生产级脚本”的关键。

4.1 异常处理与断言增强

基础的 assert 语句在失败时提供的信息有限。pytest虽然能捕获断言失败，但对于业务逻辑的复杂校验，我们需要更强大的断言库和更精细的异常处理。

使用 assert 语句的细节 ：

# 不推荐的写法
assert response.json()['code'] == 0

# 推荐的写法：提供清晰的失败信息
actual_code = response.json().get('code')
expected_code = 0
assert actual_code == expected_code, f"响应code校验失败。预期: {expected_code}, 实际: {actual_code}。完整响应: {response.text}"

使用更强大的断言库 ： 虽然Python自带的 assert 够用，但像 pytest-assume 这样的插件允许你执行多个断言，即使前面的失败，后面的也会继续执行，从而在一次测试中收集所有失败点，而不是遇到第一个错误就停止。

# 安装
pip install pytest-assume

import pytest
from pytest_assume.plugin import assume

def test_complex_assertions(client):
    response = client.get("/api/user/1")
    
    # 即使第一个断言失败，第二个也会执行
    with assume: assert response.status_code == 200, "状态码错误"
    with assume: assert "user" in response.json(), "响应体缺少user字段"
    with assume: assert response.json()["user"]["active"] is True, "用户状态非活跃"
    # 所有断言执行完后，再统一报告哪些失败了

4.2 测试夹具（Fixture）的深度使用

Fixture是pytest的灵魂，它不仅能提供数据，还能完成 setup（准备）和 teardown（清理）工作。

场景示例：测试一个需要登录态的接口

# conftest.py
import pytest

@pytest.fixture(scope="session")
def global_client():
    """全局唯一的请求客户端"""
    from common.request_client import RequestClient
    client = RequestClient(base_url="https://api.your-test-env.com")
    yield client
    # session范围结束时，可以做一些全局清理，比如登出所有用户（如果需要）

@pytest.fixture(scope="function")  # 默认就是function范围，每个测试函数都重新登录
def authenticated_client(global_client):
    """为需要认证的测试提供一个已登录的客户端"""
    login_url = "/auth/login"
    login_data = {"username": "test_user", "password": "test_pass123"}
    
    resp = global_client.post(login_url, json=login_data)
    assert resp.status_code == 200
    token = resp.json()["token"]
    
    # 将token添加到后续请求的头部
    global_client.session.headers.update({"Authorization": f"Bearer {token}"})
    
    yield global_client
    
    # 测试函数结束后，清理认证头，避免影响其他测试
    global_client.session.headers.pop("Authorization", None)

# test_cases/test_user_profile.py
class TestUserProfile:
    def test_get_profile(self, authenticated_client):
        """测试获取用户资料，需要登录态"""
        response = authenticated_client.get("/api/user/profile")
        assert response.status_code == 200
        assert response.json()["username"] == "test_user"
    
    def test_update_profile(self, authenticated_client):
        """测试更新用户资料"""
        update_data = {"nickname": "新昵称"}
        response = authenticated_client.put("/api/user/profile", json=update_data)
        assert response.status_code == 200

Fixture的作用域（scope）选择 ：

• function （默认）：每个测试函数运行一次。适合需要独立、干净环境的测试。
• class ：每个测试类运行一次。该类中的所有测试方法共享同一个fixture实例。
• module ：每个 .py 文件运行一次。
• session ：整个pytest运行过程只运行一次。适合初始化数据库连接、读取全局配置等耗时操作。

注意事项 ：谨慎使用 session 和 module 级别的fixture，特别是当它们会修改共享状态（如全局变量、数据库数据）时。不恰当的共享可能导致测试用例之间相互污染，造成难以排查的偶发失败。一个基本原则是：除非初始化成本极高且状态只读，否则优先使用 function 级别。

4.3 测试报告与日志集成

脚本不能光自己跑得欢，结果还得让人看得懂。清晰的结果报告和日志是自动化测试价值体现的重要一环。

生成HTML测试报告 ： 使用 pytest-html 插件可以轻松生成美观的测试报告。

pip install pytest-html

运行测试时指定生成报告：

pytest test_cases/ --html=reports/report.html --self-contained-html

--self-contained-html 参数会将CSS等资源内嵌到HTML中，生成单个文件，方便分享。

结构化日志记录 ： 我们在 RequestClient 中已经加入了基础的日志。我们还可以在项目根目录的 conftest.py 中配置更详细的pytest运行日志。

# conftest.py
import logging
import sys

def pytest_configure(config):
    """pytest配置钩子，用于初始化日志"""
    # 创建一个根logger
    root_logger = logging.getLogger()
    root_logger.setLevel(logging.INFO)
    
    # 控制台处理器
    console_handler = logging.StreamHandler(sys.stdout)
    console_handler.setLevel(logging.INFO)
    formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
    console_handler.setFormatter(formatter)
    root_logger.addHandler(console_handler)
    
    # 文件处理器（可选）
    file_handler = logging.FileHandler('logs/test_run.log', mode='a', encoding='utf-8')
    file_handler.setLevel(logging.DEBUG)  # 文件里记录更详细的DEBUG信息
    file_handler.setFormatter(formatter)
    root_logger.addHandler(file_handler)

这样配置后，测试运行时的关键步骤（如请求发送、响应接收、断言失败）都会输出到控制台和日志文件，便于事后排查问题。

5. 集成到CI/CD流程

自动化测试脚本的最终归宿，是集成到持续集成/持续部署（CI/CD）流水线中，每次代码提交或定时触发，自动运行测试，守护代码质量。

5.1 使用GitHub Actions进行持续集成

这里以GitHub Actions为例，展示如何配置一个最简单的CI流水线。

# .github/workflows/python-test.yml
name: Python Automated Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
  schedule:
    # 每天凌晨2点运行一次（UTC时间）
    - cron: '0 2 * * *'

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.8, 3.9, 3.10] # 支持多版本Python测试

    steps:
    - uses: actions/checkout@v3 # 检出代码
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
        # 安装测试所需的额外包
        pip install pytest pytest-html requests
    - name: Lint with flake8 (可选)
      run: |
        pip install flake8
        # 停止构建如果存在Python语法错误或未定义的名称
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # 退出-zero将所有错误视为警告。GitHub编辑器是127字符行
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    - name: Test with pytest
      run: |
        # 运行测试并生成HTML报告
        pytest test_cases/ -v --html=reports/report.html --self-contained-html
    - name: Upload test report
      uses: actions/upload-artifact@v3
      if: always() # 即使测试失败也上传报告
      with:
        name: pytest-report-${{ matrix.python-version }}
        path: reports/report.html

这个工作流实现了：

1. 触发条件 ：代码推送到主分支/开发分支、创建Pull Request时，以及每天定时运行。
2. 多版本测试 ：在Python 3.8, 3.9, 3.10三个版本上运行测试，确保兼容性。
3. 依赖安装 ：自动安装 requirements.txt 中的依赖。
4. 代码检查 ：（可选）使用 flake8 进行简单的代码风格和语法检查。
5. 执行测试 ：运行pytest，并生成HTML报告。
6. 归档结果 ：将测试报告作为构件（Artifact）上传，无论测试成功与否，你都可以从GitHub Actions的页面下载并查看详细的报告。

5.2 测试失败的通知机制

测试失败了得有人知道。可以在CI流水线中添加失败通知。

# 在上述workflow文件的末尾，与jobs同级添加
# .github/workflows/python-test.yml (续)
    - name: Notify on failure (via Slack example)
      if: failure()
      uses: 8398a7/action-slack@v3
      with:
        status: ${{ job.status }} # 必填
        author_name: Python Test Bot # 可选
        fields: repo,message,commit,author,action,eventName,ref,workflow,job,took # 可选
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} # 需要在仓库Settings/Secrets中配置

你需要先在Slack中创建一个Incoming Webhook，然后将生成的URL添加到GitHub仓库的Secrets中，命名为 SLACK_WEBHOOK_URL 。这样，每当测试失败时，相关频道就会收到通知。

6. 常见问题与实战避坑指南

在实际编写和运行自动化脚本的过程中，你会遇到各种各样的问题。这里我总结了一些高频问题和解决思路。

6.1 环境与依赖问题

问题1： ModuleNotFoundError: No module named 'requests'

• 原因 ：没有安装所需的Python包，或者是在虚拟环境外运行了脚本。
• 解决 ：
  1. 始终在虚拟环境中工作。使用 python -m venv venv 创建， source venv/bin/activate （Linux/Mac）或 venv\Scripts\activate （Windows）激活。
  2. 使用 requirements.txt 文件管理依赖。通过 pip freeze > requirements.txt 生成，通过 pip install -r requirements.txt 安装。
  3. 在CI脚本和团队文档中明确依赖安装步骤。

问题2：接口响应慢导致测试超时

• 原因 ：测试环境不稳定、网络延迟或接口本身性能差。
• 解决 ：
  1. 在 RequestClient 中合理设置 timeout 参数（如30秒），并启用重试机制（如前文代码所示）。
  2. 区分“功能失败”和“环境超时”。在断言中，对于超时异常可以特殊处理，标记为“阻塞”或“跳过”，而不是“失败”。
  3. 考虑在非业务高峰期运行自动化测试套件。

6.2 测试数据问题

问题3：测试数据被污染或依赖特定状态

• 现象 ：测试用例第一次跑通过，第二次跑失败，因为数据状态变了（如用户已注册、订单已存在）。
• 解决 ：
  1. 测试数据隔离 ：为每次测试运行生成唯一标识的数据，如使用时间戳、UUID作为用户名、订单号的一部分。
  2. 测试数据清理 ：使用fixture的 teardown 功能，或者通过调用专门的清理接口，在测试结束后删除创建的数据。
  3. 使用测试数据库 ：确保自动化测试连接的是独立的测试数据库，可以与开发/生产环境隔离，并方便重置。

问题4：依赖外部不可控数据（如天气接口）

• 现象 ：测试一个查询第三方天气的接口，断言“北京”的天气描述包含“晴”，但实际返回“多云”，导致测试失败。
• 解决 ：
  1. 解耦 ：对于第三方依赖，理想情况是使用Mock（模拟）服务。在单元测试或集成测试中，用 unittest.mock 模块替换掉真实的网络请求，返回预设的、稳定的数据。
  2. 断言可接受范围 ：如果必须测真实接口，断言应该针对接口契约而非具体内容。例如，断言返回的JSON结构正确、包含必填字段、状态码为200，而不是断言具体的天气描述。
  3. 标记不稳定测试 ：使用 @pytest.mark.flaky 或 @pytest.mark.xfail 标记那些已知可能因外部原因失败的测试，避免它们影响整个测试套件的通过率判断。

6.3 脚本维护性问题

问题5：用例越来越多，执行时间越来越长

• 原因 ：所有测试串行执行。
• 解决 ：
  1. 用例分组与标记 ：使用 @pytest.mark.slow 标记耗时长的用例。平时只运行快用例（ pytest -m "not slow" ），全量测试在CI上定时运行。
  2. 并行执行 ：使用 pytest-xdist 插件实现多进程并行运行测试。安装后，只需 pytest -n auto （auto表示自动检测CPU核心数）即可大幅缩短执行时间。
  3. 测试分层 ：建立测试金字塔。大量的、快速的单元测试（使用mock）作为底座，中层的接口集成测试，顶层的少量端到端（E2E）UI测试。将自动化重心放在中下层。

问题6：页面元素或接口字段变更导致大量用例失败

• 原因 ：定位器或断言字段硬编码在测试脚本中。
• 解决 ：
  1. 使用Page Object模式（UI测试） ：将页面元素定位器集中管理，页面变更只需修改一个地方。
  2. 对于接口测试 ：将接口的URL、请求方法、甚至预期的响应字段结构，定义在配置类或数据文件中。核心断言逻辑基于配置，而不是硬编码的字符串。
  3. 定期巡检与重构 ：将自动化测试脚本视为产品代码的一部分，定期进行代码审查和重构，消除重复，提高抽象层次。

6.4 一个实战排查案例：偶发性的SSL证书错误

现象 ：在CI服务器上，测试脚本偶尔会报 SSLError ，而在本地开发机却一直正常。 排查思路 ：

1. 看日志 ：错误信息通常是 [SSL: CERTIFICATE_VERIFY_FAILED] 。说明在SSL握手阶段，客户端（你的脚本）不信任服务器返回的证书。
2. 分析差异 ：本地机器可能安装了公司内网的根证书，或者Python的证书库是完整的。CI服务器是一个干净的Docker镜像，可能缺少必要的证书。
3. 临时方案（不推荐） ：在 requests 请求中设置 verify=False 。 这是非常危险的做法 ，因为它完全禁用了SSL证书验证，会使你面临中间人攻击的风险。
4. 根治方案 ：
   • 确保CI服务器使用的Python环境证书库是完整的。对于基于Debian/Ubuntu的镜像，可以运行 apt-get update && apt-get install -y ca-certificates 来安装CA证书包。
   • 如果测试的是内部服务，使用的是私有CA签发的证书，则需要将私有CA的根证书添加到信任链中。可以通过环境变量 REQUESTS_CA_BUNDLE 或 CURL_CA_BUNDLE 指定自定义的证书包路径，或者在创建 RequestClient 的Session时，指定 verify 参数为你的证书文件路径。

# 正确的做法：指定自定义CA证书
client.session.verify = '/path/to/your/corporate-ca-bundle.pem'

踩过这个坑之后，我养成了一个习惯：在封装请求客户端时，将SSL验证作为一个可配置项，默认开启，但允许在配置文件中指定自定义证书路径，以适配不同的部署环境。