Python接口自动化测试实战：从登录接口入手构建健壮测试框架

1. 项目概述：为什么我们需要一个登录接口自动化测试脚本？

如果你是一名后端开发或者测试工程师，每天上班第一件事可能就是打开浏览器，手动输入用户名和密码，点击登录，然后检查返回的JSON里有没有token，或者看看页面是不是跳转到了首页。日复一日，一个项目可能有几十个接口需要回归测试，手动操作不仅枯燥，效率低下，而且容易因为疲劳而出错。尤其是在敏捷开发或持续集成的环境下，每次代码提交后都需要快速验证核心功能，手动测试根本跟不上节奏。

这就是自动化测试脚本的价值所在。一个用Python编写的用户登录接口自动化测试脚本，其核心目标就是将这个重复、机械的验证过程交给代码去执行。它不仅能模拟用户发起登录请求，还能自动断言响应结果是否符合预期，并生成清晰的测试报告。这不仅仅是“偷懒”，更是提升软件质量、保证交付速度的工程化手段。我见过太多团队因为手动测试遗漏了某个边界条件，导致线上出现登录故障，影响用户体验甚至造成直接损失。因此，无论是个人学习Python实战，还是团队构建测试左移的能力，从登录接口这个最高频、最核心的入口点切入自动化测试，都是一个绝佳的选择。

这个脚本适合所有对Python有基础了解，并且希望将自动化测试能力应用到实际工作中的开发者、测试人员，甚至是DevOps工程师。你不需要是测试专家，但需要对HTTP协议、JSON数据格式以及Python的基本语法有所了解。接下来，我会带你从零开始，构建一个健壮、可维护、可直接集成到CI/CD流水线中的登录接口测试脚本。

2. 核心需求与方案设计拆解

在动手写代码之前，我们必须想清楚这个脚本要解决哪些具体问题，以及如何设计才能让它既好用又可靠。一个拍脑袋就写的脚本，后期维护会成为噩梦。

2.1 核心需求解析

基于“用户登录”这个业务场景，我们可以拆解出以下几个核心测试需求：

1. 正向用例测试：使用正确的用户名和密码，验证是否能成功登录并获取预期的响应（如token、用户信息等）。
2. 反向用例测试（异常测试）：这是保证系统健壮性的关键。我们需要测试各种错误情况：
   • 密码错误：返回的HTTP状态码和错误信息是否正确。
   • 用户名不存在：系统是否做了合理的提示，而非暴露过多内部信息。
   • 参数缺失：不传用户名或密码，接口是否做了参数校验。
   • 参数格式错误：比如密码传入一个超长字符串、特殊字符，或用户名传入SQL注入片段（虽然防注入是开发的事，但测试需要验证其有效性）。
   • 账号锁定：连续多次错误登录后，账号是否被临时锁定，并给出相应提示。
3. 性能与安全边界测试（进阶）：
   • 响应时间：登录接口的响应时间是否在可接受范围内（如200ms以内）。
   • 并发登录：少量用户并发登录时，接口表现是否正常。
   • 密码传输：是否使用HTTPS？请求日志中是否明文暴露了密码？（这更多是安全审计，但测试脚本可以辅助检查）。

2.2 技术方案选型与工具链

要实现上述需求，我们需要选择合适的Python库来构建我们的测试框架。这里我推荐一个经典且强大的组合：requests+pytest+Allure。

• requests：Python中事实标准的HTTP库，语法简洁，功能强大，用于发送登录的HTTP请求。
• pytest：一个非常成熟和流行的Python测试框架。它比Python自带的unittest更灵活，夹具（fixture）功能强大，插件生态丰富，非常适合组织我们的测试用例。
• pytest-html/Allure：用于生成测试报告。pytest-html简单易用，能生成一个基础的HTML报告。Allure则能生成非常美观、信息丰富的交互式报告，支持步骤展示、附件（如请求/响应日志）等，是展示测试成果的利器。
• PyYAML或json：用于管理测试数据。将用户名、密码、预期结果等配置信息从代码中分离出来，存放在YAML或JSON文件中，提高脚本的可维护性和数据驱动能力。

为什么选择这个组合？首先，requests几乎是人手必备，学习成本低。其次，pytest的社区活跃度远超unittest，其“约定优于配置”的理念和丰富的装饰器（如@pytest.mark.parametrize）能让数据驱动测试变得异常简单。最后，一个漂亮的测试报告是向团队证明自动化测试价值的最直观方式，Allure在这方面无出其右。这个组合在业界经过大量实践检验，生态完整，遇到问题很容易找到解决方案。

注意：有些教程可能会用unittest，这当然可以。但从可扩展性和工程化角度，pytest是更优的选择。特别是当你的测试用例越来越多，需要共享前置条件（如登录获取token）时，pytest的fixture机制会优雅得多。

3. 环境准备与项目结构搭建

工欲善其事，必先利其器。我们先来搭建一个清晰的项目环境。

3.1 创建虚拟环境与安装依赖

永远不要在系统的全局Python环境里安装项目依赖。使用虚拟环境可以避免包版本冲突。

# 1. 创建项目目录并进入 mkdir login_api_test && cd login_api_test # 2. 创建虚拟环境（这里使用Python3内置的venv模块） python3 -m venv venv # 3. 激活虚拟环境 # 在Windows上： venv\Scripts\activate # 在macOS/Linux上： source venv/bin/activate # 激活后，命令行提示符前通常会显示 (venv) # 4. 安装核心依赖 pip install requests pytest pytest-html allure-pytest PyYAML

3.2 设计项目目录结构

一个清晰的结构是项目可维护性的基石。我建议采用如下结构：

login_api_test/ ├── venv/ # 虚拟环境目录（.gitignore忽略） ├── config/ # 配置文件目录 │ └── config.yaml # 存放基础URL、超时时间等全局配置 ├── test_data/ # 测试数据目录 │ └── login_data.yaml # 存放登录相关的测试用例数据 ├── test_cases/ # 测试用例目录 │ └── test_login.py # 登录接口测试用例 ├── utils/ # 工具函数目录 │ ├── __init__.py │ ├── logger.py # 日志记录模块 │ └── request_client.py # 对requests进行封装的HTTP客户端 ├── reports/ # 测试报告输出目录（.gitignore忽略） ├── conftest.py # pytest的共享夹具配置文件 ├── requirements.txt # 项目依赖清单 └── README.md # 项目说明文档

这样设计的好处：

• 分离关注点：配置、数据、用例、工具各司其职，修改其中一项不会影响其他部分。
• 易于维护：当接口地址变更时，只需修改config.yaml；当测试数据增加时，只需编辑YAML文件，无需改动Python代码。
• 便于集成：清晰的目录结构让CI/CD工具（如Jenkins、GitLab CI）更容易识别和执行测试任务。

现在，我们先创建最重要的几个文件。

创建requirements.txt:

requests>=2.28.0 pytest>=7.0.0 pytest-html>=3.2.0 allure-pytest>=2.12.0 PyYAML>=6.0

可以通过pip freeze > requirements.txt生成，但建议手动维护一个干净、版本明确的清单。

创建config/config.yaml:

base: base_url: "https://api.your-app.com/v1" # 替换为你的接口基础地址 timeout: 10 # 请求超时时间，单位秒 login: path: "/auth/login" # 登录接口路径 success_code: 200 # 登录成功的HTTP状态码

这个文件存放了所有测试用例共享的配置信息。

创建test_data/login_data.yaml:

# 正向用例 positive_cases: - case_id: "LOGIN_001" title: "使用正确的管理员账号登录" username: "admin" password: "admin123" expected: http_code: 200 code: 0 # 业务状态码，假设0表示成功 message: "登录成功" data_has_keys: ["token", "user_id", "username"] # 期望返回的data字段中包含这些键 # 反向用例 negative_cases: - case_id: "LOGIN_002" title: "密码错误" username: "admin" password: "wrong_password" expected: http_code: 401 # 或 200，具体看后端设计 code: 1001 # 业务错误码 message: "用户名或密码错误" data_is_null: true # 期望data字段为null或空 - case_id: "LOGIN_003" title: "用户名不存在" username: "not_exist_user" password: "any_password" expected: http_code: 401 code: 1001 message: "用户名或密码错误" # 通常和密码错误提示一致，避免用户枚举 - case_id: "LOGIN_004" title: "用户名为空" username: "" password: "admin123" expected: http_code: 400 # 请求参数错误 code: 1002 message: "用户名不能为空" - case_id: "LOGIN_005" title: "密码为空" username: "admin" password: "" expected: http_code: 400 code: 1003 message: "密码不能为空"

YAML的层次结构非常清晰，很适合管理多组测试数据。这里我们定义了正向和反向两大类用例，每个用例都有唯一的case_id、描述性的title、测试输入和详细的预期结果。

4. 核心工具模块封装

在编写具体的测试用例之前，我们先封装两个工具模块，这会让后续的测试代码更简洁、更健壮。

4.1 封装HTTP请求客户端 (utils/request_client.py)

直接在每个测试用例里写requests.post(...)不是好习惯。我们应该封装一个客户端，统一处理请求头、超时、日志记录和基础异常处理。

import requests import yaml import os from utils.logger import setup_logger logger = setup_logger(__name__) class RequestClient: """封装HTTP请求的客户端""" def __init__(self, base_url=None, timeout=10): """ 初始化客户端 :param base_url: 基础URL，从config.yaml读取 :param timeout: 请求超时时间 """ self.base_url = base_url self.timeout = timeout self.session = requests.Session() # 使用Session可以保持Cookie等 # 可以在这里设置一些默认请求头，如User-Agent self.session.headers.update({ 'User-Agent': 'LoginAPITest/1.0', 'Content-Type': 'application/json' }) def _read_config(self): """读取配置文件，如果初始化时未指定base_url则使用配置文件的""" config_path = os.path.join(os.path.dirname(__file__), '..', 'config', 'config.yaml') with open(config_path, 'r', encoding='utf-8') as f: config = yaml.safe_load(f) return config def post(self, path, json_data=None, **kwargs): """ 发送POST请求 :param path: 接口路径，如 /auth/login :param json_data: 要发送的JSON数据 :param kwargs: 其他传递给requests的参数 :return: requests.Response对象 """ if not self.base_url: config = self._read_config() self.base_url = config['base']['base_url'] self.timeout = config['base'].get('timeout', self.timeout) url = f"{self.base_url.rstrip('/')}/{path.lstrip('/')}" logger.info(f"发送POST请求: {url}") logger.debug(f"请求数据: {json_data}") try: # 关键点：这里统一指定了超时时间，避免请求卡死 response = self.session.post( url, json=json_data, timeout=self.timeout, **kwargs ) logger.info(f"收到响应，状态码: {response.status_code}") logger.debug(f"响应体: {response.text[:500]}...") # 日志只记录前500字符，避免过长 return response except requests.exceptions.Timeout: logger.error(f"请求超时: {url}, 超时时间: {self.timeout}s") raise except requests.exceptions.ConnectionError: logger.error(f"网络连接错误: {url}") raise except Exception as e: logger.error(f"请求发生未知异常: {e}") raise # 类似地，可以封装get, put, delete等方法 # def get(self, path, params=None, **kwargs): # ...

封装要点解析：

1. 使用Session：requests.Session()可以自动管理Cookie，如果你后续的测试需要依赖登录后的会话，这会非常方便。
2. 统一请求头：在初始化时设置默认的Content-Type为application/json，并添加一个自定义的User-Agent，便于服务端识别请求来源。
3. 集中异常处理：将网络超时、连接错误等常见异常捕获并记录到日志中，而不是让它们在测试用例中突然抛出，使得测试报告更清晰。
4. 日志记录：在关键步骤（发请求、收响应）记录日志，这是调试和排查问题的第一手资料。注意，记录响应体时我截取了前500个字符，这是因为有些接口返回的数据可能很大（比如包含用户列表），全量打印会刷屏，不利于查看。

4.2 配置日志模块 (utils/logger.py)

一个好的日志系统是自动化测试的“眼睛”。我们配置一个既能输出到控制台，又能写入文件的logger。

import logging import os from datetime import datetime def setup_logger(name, log_level=logging.INFO): """ 设置并返回一个logger实例 :param name: logger的名称，通常使用 __name__ :param log_level: 日志级别 :return: 配置好的logger对象 """ # 创建logger logger = logging.getLogger(name) logger.setLevel(log_level) # 避免重复添加handler（在import多次时可能发生） if logger.handlers: return logger # 定义日志格式 formatter = logging.Formatter( '%(asctime)s - %(name)s - %(levelname)s - %(message)s', datefmt='%Y-%m-%d %H:%M:%S' ) # 控制台handler console_handler = logging.StreamHandler() console_handler.setLevel(log_level) console_handler.setFormatter(formatter) logger.addHandler(console_handler) # 文件handler - 按日期生成日志文件 log_dir = "logs" os.makedirs(log_dir, exist_ok=True) log_file = os.path.join(log_dir, f"test_{datetime.now().strftime('%Y%m%d')}.log") file_handler = logging.FileHandler(log_file, encoding='utf-8') file_handler.setLevel(log_level) file_handler.setFormatter(formatter) logger.addHandler(file_handler) return logger

日志配置心得：

• 按日期分割：日志文件按天生成（test_20231027.log），避免单个文件过大，也方便按时间查找问题。
• 避免重复handler：在函数中检查logger.handlers，这是一个小技巧。因为Python的logging模块是单例的，如果同一个logger被setup_logger多次调用，会导致重复添加handler，使得一条日志被打印多次。
• 统一的格式：时间、模块名、日志级别、信息，这是一个非常实用的标准格式。

5. 编写pytest测试用例与夹具

现在，我们进入最核心的部分：编写实际的测试用例。我们将利用pytest的强大功能来组织它们。

5.1 创建共享夹具 (conftest.py)

conftest.py是pytest特有的配置文件，其中定义的fixture可以被同一目录及子目录下的所有测试文件共享。我们将在这里初始化HTTP客户端和加载测试数据。

import pytest import yaml import os from utils.request_client import RequestClient def load_yaml_data(file_path): """加载YAML测试数据文件""" with open(file_path, 'r', encoding='utf-8') as f: data = yaml.safe_load(f) return data @pytest.fixture(scope="session") def api_client(): """ 会话级别的fixture，返回一个HTTP请求客户端。 scope="session"表示整个测试会话只初始化一次，所有测试用例共享。 这避免了为每个用例都创建新的客户端和Session，提升测试速度。 """ client = RequestClient() yield client # 如果需要，可以在这里添加会话结束后的清理工作，如关闭session # client.session.close() @pytest.fixture(scope="module") def login_data(): """ 模块级别的fixture，加载登录测试数据。 scope="module"表示每个测试模块（文件）只加载一次。 """ data_file_path = os.path.join(os.path.dirname(__file__), 'test_data', 'login_data.yaml') return load_yaml_data(data_file_path)

夹具（Fixture）使用技巧：

• scope参数：这是pytest夹具的精髓。scope="session"的夹具在整个pytest执行过程中只初始化一次，非常适合重量级资源（如数据库连接、HTTP客户端）。scope="module"在每个测试文件执行时初始化一次。scope="function"（默认）则为每个测试函数初始化一次。合理利用scope能极大提升测试效率。
• yield：fixture使用yield代替return，yield之前的代码是设置部分，之后的代码是清理部分。即使测试用例中发生异常，清理部分的代码也会执行，确保资源被正确释放。

5.2 编写登录接口测试用例 (test_cases/test_login.py)

终于到了编写具体测试逻辑的时候。我们将使用pytest.mark.parametrize来实现数据驱动测试。

import pytest import json from utils.logger import setup_logger logger = setup_logger(__name__) class TestLoginAPI: """用户登录接口测试类""" @pytest.mark.parametrize("case_data", [ pytest.param(case, id=case['case_id']) for case in pytest.login_data['positive_cases'] # 这里login_data是fixture，需要通过参数传入 ]) def test_login_success(self, api_client, login_data, case_data): """ 测试登录成功场景（数据驱动） 使用@pytest.mark.parametrize装饰器，pytest会自动用login_data['positive_cases']列表中的 每一个字典作为case_data参数，运行一次这个测试函数。 id参数用于在测试报告中标识每条用例，这里我们用case_id。 """ logger.info(f"开始执行正向用例: {case_data['title']} ({case_data['case_id']})") # 1. 准备请求数据 request_body = { "username": case_data['username'], "password": case_data['password'] } # 2. 发送请求 # 注意：这里从config中读取路径，或者你也可以将路径写在测试数据里 response = api_client.post("/auth/login", json_data=request_body) # 3. 断言HTTP状态码 assert response.status_code == case_data['expected']['http_code'], \ f"HTTP状态码断言失败。预期: {case_data['expected']['http_code']}, 实际: {response.status_code}" # 4. 解析响应JSON try: response_json = response.json() except json.JSONDecodeError as e: logger.error(f"响应不是有效的JSON: {response.text}") pytest.fail(f"响应不是有效的JSON: {e}") # 5. 断言业务状态码和消息 assert response_json.get('code') == case_data['expected']['code'], \ f"业务状态码断言失败。预期: {case_data['expected']['code']}, 实际: {response_json.get('code')}" assert response_json.get('message') == case_data['expected']['message'], \ f"消息断言失败。预期: {case_data['expected']['message']}, 实际: {response_json.get('message')}" # 6. 断言返回数据中包含必要的字段 expected_keys = case_data['expected'].get('data_has_keys', []) if expected_keys: data = response_json.get('data', {}) for key in expected_keys: assert key in data, f"返回数据中缺少预期的字段: {key}。完整数据: {data}" # 7. 可选：对返回的token进行简单格式校验（例如，长度或前缀） if 'token' in response_json.get('data', {}): token = response_json['data']['token'] assert isinstance(token, str) and len(token) > 10, f"Token格式异常: {token}" logger.info(f"正向用例 {case_data['case_id']} 执行通过") @pytest.mark.parametrize("case_data", [ pytest.param(case, id=case['case_id']) for case in pytest.login_data['negative_cases'] ]) def test_login_failure(self, api_client, login_data, case_data): """ 测试登录失败场景（数据驱动） 整体逻辑与成功用例类似，但断言点在于错误提示是否正确。 """ logger.info(f"开始执行反向用例: {case_data['title']} ({case_data['case_id']})") request_body = {} # 只有非空的字段才加入请求体，模拟参数缺失的场景 if case_data['username'] is not None: # 注意：空字符串''和None是不同的 request_body['username'] = case_data['username'] if case_data['password'] is not None: request_body['password'] = case_data['password'] response = api_client.post("/auth/login", json_data=request_body) # 断言HTTP状态码 assert response.status_code == case_data['expected']['http_code'], \ f"HTTP状态码断言失败。预期: {case_data['expected']['http_code']}, 实际: {response.status_code}" # 处理可能的非JSON响应（例如，某些错误直接返回HTML） try: response_json = response.json() except json.JSONDecodeError: # 如果预期就是非JSON（如400 Bad Request返回纯文本），这里可以灵活处理 # 本例假设错误情况也返回JSON logger.error(f"响应不是有效的JSON: {response.text}") pytest.fail(f"响应不是有效的JSON，状态码: {response.status_code}") # 断言业务错误码和消息 assert response_json.get('code') == case_data['expected']['code'], \ f"业务错误码断言失败。预期: {case_data['expected']['code']}, 实际: {response_json.get('code')}" assert case_data['expected']['message'] in response_json.get('message', ''), \ f"错误消息不匹配。预期包含: '{case_data['expected']['message']}', 实际: '{response_json.get('message')}'" # 断言data字段为空（如果预期如此） if case_data['expected'].get('data_is_null'): # 注意：有些接口成功时data是{}，失败时data是null。这里检查是否为None或空dict data = response_json.get('data') assert data is None or data == {}, f"预期data字段为空，实际为: {data}" logger.info(f"反向用例 {case_data['case_id']} 执行通过")

测试用例编写核心要点：

1. 清晰的测试类和方法名：TestLoginAPI，test_login_success，test_login_failure。pytest默认会查找以Test开头的类或以test_开头的函数。
2. 数据驱动：@pytest.mark.parametrize是神器。它把测试数据和测试逻辑完全分离。我们只需要维护YAML文件，就能轻松增减测试用例。装饰器中的id参数非常重要，它让测试报告中的用例标识清晰可读。
3. 详尽的断言：断言是测试的灵魂。我们不仅断言HTTP状态码，还断言业务状态码、消息文本以及返回数据的结构。断言失败时，使用f-string输出详细的预期值和实际值，极大方便了问题定位。
4. 健壮的错误处理：使用try...except捕获JSONDecodeError。因为接口可能因为内部错误返回非JSON格式的HTML错误页面，我们的脚本不应该因此崩溃，而应该明确地让测试失败并记录原因。
5. 灵活的请求体构建：在反向用例中，我们根据测试数据决定是否添加username和password字段，这巧妙地覆盖了“参数缺失”的测试场景。

6. 运行测试与生成报告

脚本写好了，让我们运行它并看看成果。

6.1 使用pytest运行测试

在项目根目录下，打开终端（确保虚拟环境已激活），执行以下命令：

# 最基本的方式，运行所有测试 pytest # 更常用的方式：指定测试目录，显示详细输出，并忽略警告 pytest test_cases/ -v -s --tb=short # 运行特定的测试文件 pytest test_cases/test_login.py -v # 运行特定测试类 pytest test_cases/test_login.py::TestLoginAPI -v # 运行特定测试方法 pytest test_cases/test_login.py::TestLoginAPI::test_login_success -v

命令行参数解释：

• -v：增加输出详细程度，会显示每个测试用例的名称和结果。
• -s：允许终端输出打印语句（即我们的logger.info），否则pytest会捕获所有标准输出。
• --tb=short：当测试失败时，只显示简短的Traceback信息，更清晰。你也可以用--tb=no关闭。
• -k：通过关键字表达式选择测试用例，例如pytest -k "success"只运行名称中包含“success”的测试。

6.2 生成HTML测试报告

使用pytest-html插件可以快速生成一个美观的HTML报告。

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

--self-contained-html参数会将CSS样式内嵌到HTML文件中，生成一个独立的报告文件，方便分享。

6.3 生成Allure测试报告（推荐）

Allure报告提供了更强大的功能，如历史趋势图、测试步骤展示、附件等。

首先，你需要安装Allure命令行工具。请参考 Allure官方文档 进行安装。

然后运行测试并生成Allure结果数据：

pytest test_cases/ -v -s --alluredir=reports/allure-results

最后，使用Allure命令生成可交互的HTML报告：

# 在项目根目录下执行 allure serve reports/allure-results

这条命令会启动一个本地Web服务，并在浏览器中打开生成的Allure报告。报告里可以看到每个用例的详细步骤、请求/响应数据（如果我们在代码中附加了的话）、通过率图表等，非常专业。

7. 常见问题排查与实战技巧

在实际编写和运行自动化测试脚本时，你肯定会遇到各种各样的问题。这里我分享一些最常见的坑和解决技巧。

7.1 请求失败与超时问题

• 问题：脚本报错requests.exceptions.ConnectionError或Timeout。
• 排查：
  1. 检查网络：首先用ping或curl命令手动测试接口地址是否可达。
  2. 检查配置：确认config.yaml中的base_url和接口path拼接正确，没有多余的斜杠。
  3. 检查代理：如果你在公司网络，可能需要配置代理。可以在RequestClient的session中设置proxies参数，或者设置环境变量HTTP_PROXY/HTTPS_PROXY。
  4. 调整超时时间：对于慢接口，适当增加config.yaml中的timeout值。
• 技巧：在RequestClient的post方法中，我们已经捕获了这些异常并记录了详细的日志，查看日志文件通常能快速定位问题。

7.2 响应断言失败问题

• 问题：测试用例失败，断言提示业务状态码或消息不匹配。
• 排查：
  1. 查看日志：检查脚本打印的请求和响应日志，确认发送的数据和收到的数据是否符合预期。
  2. 手动验证：使用Postman或curl工具，用完全相同的参数手动请求一次接口，对比结果。
  3. 检查测试数据：确认login_data.yaml中的预期结果（code,message）与接口文档或实际行为一致。后端接口的返回格式可能发生了变更。
  4. 检查编码：如果响应消息包含中文，确保你的脚本和日志文件使用了正确的编码（如UTF-8）。
• 技巧：在断言失败时，我们使用了f-string输出预期和实际值，这比简单的assert a == b提供了多得多的信息。

7.3 测试数据管理问题

• 问题：测试用例很多，YAML文件变得冗长难维护；或者需要测试不同环境（测试/预发/生产）。
• 解决方案：
  1. 数据分层：将基础配置（如成功用户）和用例数据分离。可以创建一个base_data.yaml存放公共数据，在login_data.yaml中引用。
  2. 使用变量：YAML支持锚点（&）和别名（*）来复用数据块。
  3. 环境隔离：创建多个配置文件，如config_test.yaml,config_staging.yaml。通过环境变量（如ENV=test）让脚本动态加载对应的配置。可以在conftest.py的api_client夹具中读取环境变量来决定加载哪个配置。

7.4 如何集成到CI/CD流程

自动化测试只有集成到持续集成/持续部署流水线中，才能发挥最大价值。

1. 准备requirements.txt：我们已经有了。
2. 编写CI脚本：以GitLab CI为例，可以在项目根目录创建.gitlab-ci.yml。

   stages: - test api-test: stage: test image: python:3.9-slim # 使用带有Python的Docker镜像 before_script: - pip install -r requirements.txt - apt-get update && apt-get install -y default-jre-headless # 安装Java（Allure需要） - wget https://github.com/allure-framework/allure2/releases/download/2.24.0/allure-2.24.0.tgz - tar -zxvf allure-2.24.0.tgz -C /opt/ - ln -s /opt/allure-2.24.0/bin/allure /usr/bin/allure script: - pytest test_cases/ -v --alluredir=allure-results after_script: - allure generate allure-results -o allure-report --clean artifacts: paths: - allure-report/ expire_in: 30 days only: - main # 只在main分支合并时触发 - merge_requests # 或者在合并请求时触发

3. 查看报告：CI任务完成后，可以在流水线页面下载或在线查看生成的Allure报告。

7.5 进阶：让脚本更健壮与可扩展

• 重试机制：对于网络不稳定的环境，可以为请求添加重试逻辑。可以使用tenacity库或自己封装一个带重试的请求函数。
• 数据库校验：有些登录测试可能需要验证数据库中的状态（如登录失败次数是否累加）。可以在测试用例中连接测试数据库，执行查询进行断言。切记使用测试数据库，并做好数据清理！
• Token管理：登录成功后获取的token，可以存放到api_client会话的headers中，供后续需要认证的接口测试使用。
• API文档同步：可以使用swagger-py-codegen或openapi-core等库，根据OpenAPI/Swagger文档自动生成部分测试代码或进行接口响应模式验证。

编写自动化测试脚本是一个不断迭代和优化的过程。从最初的一个简单脚本，到如今这个结构清晰、数据驱动、报告完善的项目，我最大的体会是：前期在结构和设计上多花一点时间，后期在维护和扩展上就能节省大量时间。这个脚本不仅仅能测试登录接口，其框架（配置管理、数据驱动、工具封装、报告生成）完全可以作为你其他接口自动化测试的模板。希望这份详细的指南能帮助你顺利起步，并将其应用到你的实际项目中。