简介这是一套面向中初级测试工程师与自动化测试学习者的Python自动化测试框架实战资源聚焦Web UI与接口自动化两大核心场景解决手工测试效率低、回归成本高、跨平台验证难等典型问题。资源共62个文件含25个核心Python源码覆盖PO模式页面对象、unittest测试用例、Requests接口封装、日志/邮件/断言等通用模块、5个XML配置文件用于环境与数据管理、2个TXT说明文档及Markdown格式README整体压缩包仅78KB轻量易部署。已有4931人学习下载框架结构清晰pages目录实现UI层解耦APIs目录封装接口请求逻辑testcase组织可扩展测试集report自动生成HTML测试报告配合requirement.txt与config.ini开箱即用。读者可直接运行jd相关用例快速上手亦可基于base_page.py和base_api.py快速适配新项目是理解自动化分层设计与工程化落地的优质参考样本。1. 项目概述为什么我们需要一个“全栈”自动化框架干了十几年测试从手工点点点到脚本满天飞再到如今各种“智能”工具层出不穷我最大的感受是测试自动化的核心从来不是工具本身而是如何将它们高效、稳定地组织起来形成一个可持续运转的体系。很多团队一上来就纠结用Selenium还是Playwright用Requests还是RestAssured结果往往是脚本写了一堆维护成本却高得吓人最后成了一堆没人敢动的“祖传代码”。今天聊的这个“软件测试自动化框架”指的不是某个单一的库或工具而是一个整合了Web UI自动化、接口自动化并能应对未来扩展如移动端、数据库校验的工程化解决方案。它的核心目标就一个让自动化测试像生产线一样可靠、高效、低维护成本地持续产出价值。为什么强调“全栈”因为现代应用往往是前后端分离的一个业务场景的验证可能既需要模拟用户在前端界面的操作UI测试又需要校验后端接口的数据逻辑接口测试。如果这两套自动化是割裂的就会出现数据不同步、用例重复编写、问题定位困难等一系列麻烦。一个设计良好的自动化框架应该能让你用同一套数据驱动逻辑同时驱动UI和接口测试用同一套断言机制去验证页面元素和接口响应用同一套报告体系清晰地展示端到端的测试结果。这听起来很美好但实现起来坑可不少。接下来我就结合自己趟过的雷拆解一下如何从零搭建这样一个框架以及其中那些文档里不会写的“魔鬼细节”。2. 框架整体设计与核心思路拆解2.1 核心架构选型模块化与分层设计搭建框架首要问题是选择技术栈和设计架构。我的原则是不追求最新最炫但求稳定、社区活跃、易于团队上手。对于Web UI自动化目前主流是Selenium和Playwright。Selenium是老牌劲旅生态极其丰富但需要自己处理很多异步等待和浏览器驱动问题。Playwright是后起之秀由微软出品自带智能等待、自动录制、多浏览器支持Chromium, Firefox, WebKit对现代Web应用尤其是单页应用SPA的支持更好。如果你的团队技术较新应用复杂度高我强烈建议从Playwright开始它能省去大量处理元素等待、弹窗、iframe的麻烦脚本稳定性显著提升。对于接口自动化Python的requests库或Java的RestAssured是经典选择简单直接。但考虑到与UI测试的整合以及更强大的功能如Schema校验、数据生成我倾向于使用pytestrequestsPydanticPython栈或TestNGRestAssuredJacksonJava栈。pytest和TestNG不仅是测试运行器更是强大的夹具Fixture管理和参数化工具是框架的“骨架”。架构上必须采用清晰的分层设计这是降低耦合度的关键。我常用的分层如下基础层Core封装所有与具体工具如Playwright、requests的交互。提供统一的“浏览器操作类”、“HTTP请求客户端类”、“日志记录器”、“配置文件读取器”等。这一层的目标是如果未来要把Playwright换成Cypress只需要修改这一层的代码上层业务用例完全不受影响。页面对象层Page Objects专为UI测试设计。将每个页面或重要组件封装成一个类类内部包含元素定位器和该页面的核心操作方法如登录、搜索。切记不要把断言写在页面对象里它的职责只是“操作”不是“验证”。接口层API Clients专为接口测试设计。将每个业务模块的接口封装成类方法内部处理鉴权、默认请求头、通用参数等。返回结构化的响应对象。业务层Test Cases这里是编写具体测试用例的地方。用例通过调用页面对象或接口客户端来组合业务流并在此处进行断言验证。这一层应该读起来像自然语言清晰地描述测试场景。数据层Test Data管理测试数据。可以是JSON、YAML、Excel或数据库。关键是要将测试数据与测试逻辑分离支持参数化。任务层Task/Runner使用pytest或TestNG来组织用例运行、生成报告、集成CI/CD。注意分层不是越多越好。过度设计会让框架变得笨重。对于中小型项目将“基础层”和“工具封装层”合并也是完全可行的。关键是边界要清晰。2.2 数据驱动让用例活起来的秘诀数据驱动测试是自动化框架的灵魂。它的好处显而易见一份测试逻辑可以通过多组数据反复验证极大提高了用例的覆盖率和复用性。实现数据驱动pytest的pytest.mark.parametrize装饰器是神器。但数据从哪来我推荐使用YAML或JSON文件。它们结构清晰易于阅读和编写比Excel更容易做版本控制。例如我们有一个登录测试的数据文件login_data.yaml:- case_name: 登录成功-管理员 username: admin password: 123456 expected: login_success - case_name: 登录失败-密码错误 username: test_user password: wrong_pwd expected: error_invalid_password在测试用例中可以这样读取并参数化import pytest import yaml def load_login_data(): with open(data/login_data.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) class TestLogin: pytest.mark.parametrize(data, load_login_data()) def test_login(self, page, data): # page是Playwright的页面Fixture # 调用封装的登录页面对象 login_page LoginPage(page) login_page.navigate() login_page.fill_credentials(data[username], data[password]) login_page.submit() # 根据预期结果进行断言 if data[expected] login_success: assert DashboardPage(page).is_displayed() elif data[expected] error_invalid_password: assert login_page.get_error_message() 密码错误实操心得数据驱动时千万别把UI测试数据和接口测试数据混在一个文件里。因为两者的关注点不同UI测试数据可能包含元素定位信息虽然不推荐、截图路径等接口测试数据则更关注请求体、期望响应码、响应体结构。建议按业务模块或测试类型建立不同的数据目录。2.3 配置管理一套代码多环境运行测试框架必须能在开发、测试、预生产等多个环境中无缝切换。硬编码环境地址是绝对的大忌。我的做法是使用配置文件环境变量的模式。创建一个config目录里面放置config.yaml(或config.ini): 存放所有环境的公共配置和默认配置。dev.yaml: 开发环境特定配置如数据库地址、内网服务地址。test.yaml: 测试环境特定配置。prod.yaml: 生产环境配置通常只用于监控或只读场景。框架启动时通过一个环境变量如ENVtest来决定加载哪个环境的配置文件并与公共配置合并。Python可以使用pyyaml和box库轻松实现。# config_manager.py import os import yaml from box import Box class ConfigManager: _instance None def __new__(cls): if cls._instance is None: cls._instance super().__new__(cls) cls._instance._load_config() return cls._instance def _load_config(self): env os.getenv(ENV, test).lower() # 加载基础配置 with open(config/config.yaml, r) as f: base_config yaml.safe_load(f) # 加载环境特定配置 env_file fconfig/{env}.yaml env_config {} if os.path.exists(env_file): with open(env_file, r) as f: env_config yaml.safe_load(f) # 合并环境配置覆盖基础配置 merged {**base_config, **env_config} self.config Box(merged) # 使用Box支持点号访问如 config.base_url # 使用时 from config_manager import ConfigManager config ConfigManager().config base_url config.base_url # 直接获取3. Web UI自动化核心细节与Playwright实战3.1 元素定位策略稳如泰山的基石元素定位不稳定是UI自动化失败的首要原因。Playwright提供了多种强大的定位器但要用对地方。优先使用角色Role和文本Text定位这是Playwright最推荐的方式因为它最接近用户感知。# 好通过按钮文本定位 page.get_by_role(button, name登录).click() # 好通过链接文本定位 page.get_by_text(忘记密码).click()使用CSS和XPath作为补充但需谨慎对于没有明确文本或角色的复杂元素可以使用CSS或XPath。绝对禁止使用包含索引如div[1]或动态ID的定位器。应该寻找稳定的属性如># 较好使用自定义测试ID page.locator([data-testidsubmit-btn]).click() # 不得已时使用相对稳定的XPath page.locator(//form[idloginForm]//input[typeemail]).fill(testexample.com)利用locator链式调用和过滤器Playwright的locatorAPI非常灵活。# 找到表格中第一行状态为“成功”的“查看”按钮 row page.locator(table tr).filter(has_text成功).first row.locator(button, has_text查看).click()避坑指南很多前端框架如React, Vue会生成动态的类名或ID。对付这种情况除了让开发加># 1. 等待导航完成 page.goto(/admin, wait_untilnetworkidle) # 等待到网络空闲 # 2. 等待请求/响应 with page.expect_response(**/api/user) as response_info: page.get_by_text(加载用户).click() response response_info.value print(response.json()) # 3. 等待元素出现/消失 page.locator(.loading-spinner).wait_for(statehidden) # 等待加载动画消失 page.locator(.toast-success).wait_for() # 等待成功提示出现 # 4. 自定义超时和轮询间隔针对特别慢的元素 page.locator(#slow-element).wait_for(timeout30000, statevisible)核心技巧如果你的脚本经常因为元素未就绪而失败首先检查是否用对了定位器和等待。其次可以适当增加page.set_default_timeout(timeout)的全局超时时间但这不是根本解决办法。根本办法是优化定位策略并利用Playwright的智能等待。3.3 页面对象模型POM的进阶实践基础的POM大家都会这里分享几个进阶模式让POM更健壮。组件化封装对于头部导航栏、侧边菜单、模态框等跨页面复用的组件单独封装成Component类。页面对象可以包含这些组件。class HeaderComponent: def __init__(self, page): self.page page self.user_menu page.locator([data-testiduser-avatar]) def logout(self): self.user_menu.click() self.page.locator(text退出登录).click() class HomePage: def __init__(self, page): self.page page self.header HeaderComponent(page) # 组合组件使用基类减少重复代码创建一个BasePage类存放所有页面共用的方法如导航、通用等待、截图等。class BasePage: def __init__(self, page): self.page page def navigate(self, url_suffix): full_url f{config.base_url}{url_suffix} self.page.goto(full_url, wait_untilnetworkidle) def take_screenshot(self, name): path fscreenshots/{name}_{datetime.now().strftime(%Y%m%d_%H%M%S)}.png self.page.screenshot(pathpath) return path懒加载定位器有时页面元素很多初始化时全部定位一遍影响性能。可以使用property装饰器实现懒加载。class LoginPage(BasePage): property def username_input(self): return self.page.locator(#username) property def password_input(self): return self.page.locator(#password) def login(self, user, pwd): self.username_input.fill(user) # 第一次访问时才真正定位元素 self.password_input.fill(pwd)4. 接口自动化核心细节与高效实践4.1 请求封装与鉴权处理直接在每个用例里写requests.post(url, jsondata, headersheaders)会带来大量重复代码。我们需要一个强大的HTTP客户端封装。# api_client.py import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry class APIClient: def __init__(self, base_url): self.base_url base_url self.session requests.Session() # 设置重试策略增强稳定性 retry_strategy Retry( total3, backoff_factor1, status_forcelist[429, 500, 502, 503, 504] ) adapter HTTPAdapter(max_retriesretry_strategy) self.session.mount(http://, adapter) self.session.mount(https://, adapter) self.default_headers {Content-Type: application/json} def _request(self, method, endpoint, **kwargs): url f{self.base_url}{endpoint} headers {**self.default_headers, **kwargs.pop(headers, {})} # 可以在这里统一添加鉴权Token if hasattr(self, token): headers[Authorization] fBearer {self.token} response self.session.request(method, url, headersheaders, **kwargs) response.raise_for_status() # 非200响应抛出异常 return response # 定义便捷方法 def get(self, endpoint, paramsNone, **kwargs): return self._request(GET, endpoint, paramsparams, **kwargs) def post(self, endpoint, jsonNone, **kwargs): return self._request(POST, endpoint, jsonjson, **kwargs) # ... 同理实现 put, delete, patch # 登录并获取token def login(self, username, password): resp self.post(/auth/login, json{username: username, password: password}) self.token resp.json()[data][token] return resp这个客户端处理了会话保持、默认请求头、自动重试和基础的鉴权逻辑。针对不同的业务模块可以继承这个类创建更具体的客户端比如UserAPIClient、OrderAPIClient。4.2 响应断言与Schema校验断言接口返回的正确性不仅仅是检查status_code200。一个健壮的断言应该包括状态码、业务码如果接口设计有、关键字段值以及响应体的结构Schema。基础断言使用pytest的assert语句或专门的断言库如assertpy更优雅。def test_get_user(self, api_client): resp api_client.get(/users/1) assert resp.status_code 200 user_data resp.json() # 使用assertpy from assertpy import assert_that assert_that(user_data).contains_key(id, name, email) assert_that(user_data[name]).is_not_empty()Schema校验强烈推荐使用jsonschema或Pydantic来验证响应体的结构是否符合预期。这能有效捕获接口字段变更或类型错误。from pydantic import BaseModel, EmailStr class UserResponse(BaseModel): id: int name: str email: EmailStr is_active: bool True # 默认值 def test_get_user_schema(self, api_client): resp api_client.get(/users/1) # 如果响应不符合UserResponse模型会抛出ValidationError user UserResponse(**resp.json()) assert user.is_active is True将Schema定义放在单独的文件中用例和接口客户端都可以引用保证一致性。4.3 测试数据准备与清理Fixture的妙用接口测试经常需要预先创建数据测试完成后又需要清理避免污染后续测试。pytest的Fixture是处理这类需求的绝佳工具。import pytest pytest.fixture def create_test_user(api_client): 创建一个测试用户并返回用户信息。测试后自动清理。 user_data {name: 测试用户, email: ftest_{uuid.uuid4().hex[:8]}example.com} resp api_client.post(/admin/users, jsonuser_data) user_id resp.json()[id] yield resp.json() # 测试用例执行时从这里获取数据 # 测试用例执行完毕后执行清理 api_client.delete(f/admin/users/{user_id}) def test_update_user(api_client, create_test_user): test_user create_test_user new_name 更新后的名字 update_resp api_client.put(f/users/{test_user[id]}, json{name: new_name}) assert update_resp.status_code 200 # 验证更新是否成功 get_resp api_client.get(f/users/{test_user[id]}) assert get_resp.json()[name] new_name这个Fixture确保了每个用到它的测试用例都有一个独立的测试用户且用例结束后无论成功失败该用户都会被删除实现了测试的隔离性。5. 框架整合与CI/CD流水线5.1 测试报告与结果可视化pytest原生支持多种报告格式如JUnit XML可以方便地集成到Jenkins、GitLab CI等工具中展示。但对于本地调试和团队内部查看一个美观的HTML报告更直观。我推荐使用pytest-html或allure-pytest。pytest-html简单易用生成单文件HTML报告。pytest --htmlreport.html --self-contained-htmlallure-pytest功能强大支持步骤描述、附件截图、日志、分类、趋势图等生成的是需要allure命令行工具渲染的交互式报告。pytest --alluredir./allure-results allure serve ./allure-results # 本地查看 # 或生成静态报告 allure generate ./allure-results -o ./allure-report --clean关键一步在框架中集成自动截图和日志附加到报告的功能。以Playwright为例可以在pytest的钩子函数中实现失败时自动截图并添加到allure报告中。# conftest.py import pytest import allure from playwright.sync_api import Page pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: # 获取page fixture page item.funcargs.get(page) if page: # 截图并附加到allure报告 screenshot page.screenshot(full_pageTrue) allure.attach(screenshot, name失败截图, attachment_typeallure.attachment_type.PNG) # 也可以附加页面源代码 # allure.attach(page.content(), name页面源码, attachment_typeallure.attachment_type.TEXT)5.2 集成到CI/CD流水线自动化测试只有集成到CI/CD中才能发挥最大价值——持续守护质量。以GitLab CI为例一个简单的.gitlab-ci.yml配置可能如下stages: - test ui-and-api-tests: stage: test image: mcr.microsoft.com/playwright/python:v1.40.0-noble # 包含Playwright的官方镜像 variables: ENV: test # 设置测试环境 before_script: - pip install -r requirements.txt - playwright install --with-deps chromium # 安装浏览器 script: - pytest --alluredirallure-results --junitxmlreport.xml -v artifacts: when: always paths: - allure-results/ - report.xml - screenshots/ # 如果需要保存截图 reports: junit: report.xml after_script: - echo 测试阶段完成在GitLab的流水线页面可以直接查看JUnit报告。如果需要Allure报告可以添加一个额外的Job使用allure镜像来生成并发布静态报告。注意事项CI环境中运行UI测试尤其是无头浏览器对资源有一定要求。确保Runner有足够的内存和CPU。另外网络稳定性也很关键对于外部依赖或较慢的环境需要合理设置超时时间。6. 常见问题排查与效能提升技巧6.1 UI自动化稳定性问题排查清单当UI测试偶尔失败Flaky Tests时按以下顺序排查元素定位器是否稳定这是最常见的原因。检查定位器是否依赖于动态生成的ID、类名或页面结构。优先使用># 在pytest配置或fixture中 pytest.fixture(scopesession) def browser_context_args(browser_context_args): return { **browser_context_args, viewport: {width: 1920, height: 1080}, # 固定视口 record_video_dir: videos/ # 录制视频 }6.2 接口自动化常见陷阱接口依赖与测试顺序避免用例之间存在严格的执行顺序依赖。每个用例都应该是独立的。如果确实需要依赖如B接口需要A接口创建的资源使用Fixture来创建前置条件而不是依赖上一个用例的执行结果。时间戳与唯一性接口测试中经常需要生成唯一的数据如用户名、订单号。使用时间戳或UUID是好习惯但要小心时区问题。建议在框架中提供一个统一的工具函数。def generate_unique_email(prefixtest): import uuid return f{prefix}_{uuid.uuid4().hex[:8]}test.com异步接口处理对于触发异步任务如导出报表、处理视频的接口测试不能只断言接口调用成功。需要设计轮询机制去查询任务状态或最终结果。def wait_for_async_task_complete(api_client, task_id, timeout60, interval2): import time start_time time.time() while time.time() - start_time timeout: resp api_client.get(f/tasks/{task_id}) status resp.json()[status] if status SUCCESS: return resp.json()[result] elif status FAILED: raise Exception(fTask {task_id} failed) time.sleep(interval) raise TimeoutError(fTask {task_id} not completed in {timeout}s)敏感信息处理测试脚本中不要硬编码密码、密钥等敏感信息。使用环境变量或安全的密码管理工具如python-dotenv加载.env文件但.env文件本身不能提交到代码库。6.3 效能提升让测试跑得更快并行测试pytest可以通过pytest-xdist插件轻松实现并行。pytest -n auto # 自动检测CPU核心数并行 pytest -n 2 # 指定2个worker并行注意并行时必须保证测试用例完全独立不共享任何状态如浏览器上下文、API Token、数据库数据。Fixture的scope要合理设置多用function少用session。测试用例选择与分组使用标记Mark来分类用例pytest.mark.smoke冒烟测试、pytest.mark.slow慢速测试。可以只运行特定标记的用例pytest -m smoke或者排除某些标记pytest -m not slow减少不必要的UI操作很多业务流程的验证其实通过接口测试就能完成速度更快、更稳定。UI测试应聚焦在真正需要用户交互和视觉验证的场景。这就是“全栈”框架的优势——你可以轻松地在同一个测试中先用接口准备好数据再用UI验证展示逻辑。搭建和维护一个自动化测试框架是一个持续迭代的过程没有一劳永逸的银弹。我的经验是从一个小而美的核心开始先解决团队最痛的点比如不稳定的登录测试然后随着业务增长逐步完善数据驱动、报告、CI/CD集成等能力。最重要的是让框架易于使用和维护这样团队成员才愿意用、愿意贡献自动化才能真正落地生根成为质量保障的坚实防线。本文还有配套的精品资源点击获取