【Appium 系列】第20节-测试项目结构设计 — 从脚本到工程

对应代码配套代码/test/完整目录结构说明本节讲解如何组织一个中大型 Appium 测试项目从目录结构到文件职责从脚本到工程的演进。这节讲什么测试项目从小到大会经历三个阶段阶段 1脚本阶段test_login.py # 一个文件搞定 test_register.py # 又一个文件问题代码重复多维护困难。阶段 2框架阶段base/ # 基类 base_driver.py base_page.py pages/ # 页面对象 login_page.py tests/ # 测试用例 test_login.py问题文件多了但结构不清晰。阶段 3工程阶段本节要讲的test/ base/ # 驱动管理 pages/ # 页面对象 tests/ # 测试用例 api/ # API 测试封装 core/ # 核心模块路由、执行器、验证器 utils/ # 工具类日志、截图、报告 testcases/ # 测试数据YAML、设计稿 scripts/ # 辅助脚本环境检查、并行执行 conftest.py # pytest 配置 config.yaml # 全局配置问题结构复杂需要理解每个目录的职责。目录结构详解base/ — 驱动管理文件职责base_driver.pyAppium 驱动初始化Android/iOSbase_page.py页面对象基类元素定位、等待、操作设计原则基类只封装通用逻辑不包含业务代码具体页面继承基类实现页面特有逻辑pages/ — 页面对象文件职责login_page.py登录页面元素和操作shell_home_page.py首页元素和操作register_page.py注册页面元素和操作设计原则每个页面对应一个文件页面类继承BasePage只封装元素定位和操作不包含断言断言在测试用例中tests/ — 测试用例文件职责test_login_api.py登录接口测试test_appium_demo.pyAppium UI 测试示例test_login_data_driven_example.py数据驱动登录测试设计原则测试文件以test_开头pytest 约定测试类以Test开头测试方法以test_开头一个文件测试一个功能模块api/ — API 测试封装文件职责base_api.pyAPI 请求封装GET/POST/PUT/DELETE设计原则统一处理请求头、超时、重试支持 Bearer Token 认证返回结构化结果状态码、响应体、耗时core/ — 核心模块文件职责test_router.py测试路由API vs UI 自动选择hybrid_test_executor.py混合测试执行器validator.py测试结果验证器data_driver.py数据驱动引擎test_recorder.py测试录制器设计原则核心模块是框架的大脑不依赖具体业务只封装测试逻辑可独立测试、独立升级utils/ — 工具类文件职责logger.py日志工具screenshot.py截图工具visual_comparison.py视觉对比xmind_parser.pyXMind 解析bug_reporter.pyBug 报告生成allure_helper.pyAllure 报告辅助设计原则工具类是工具箱按需取用每个工具独立不互相依赖工具类应该可复用到其他项目testcases/ — 测试数据目录内容yaml/YAML 格式的测试用例data/测试数据用户、配置等ui_designs/UI 设计稿用于视觉对比设计原则测试数据与测试代码分离数据文件用 YAML/JSON 格式易读易维护设计稿用 PNG 格式用于视觉回归scripts/ — 辅助脚本文件职责check_android_env.py检查 Android 环境run_parallel_test.py并行执行测试xmind_to_yaml.pyXMind 转 YAMLopen_allure_report.sh打开 Allure 报告设计原则辅助脚本是一次性工具不纳入 pytest 执行脚本应该独立运行不依赖测试框架脚本应该有清晰的命令行参数文件职责边界什么该放 base/什么该放 pages/base/通用逻辑所有页面都用的元素定位、等待、点击、滑动截图、日志、异常处理pages/页面特有逻辑只在这个页面用的登录页面的用户名输入框定位首页的导航栏元素什么该放 core/什么该放 utils/core/测试框架的核心逻辑路由、执行器、验证器这些模块决定测试怎么跑utils/辅助工具日志、截图、报告这些模块决定测试怎么记录什么该放 tests/什么该放 testcases/tests/Python 测试代码pytest 测试文件包含断言、fixture、hooktestcases/测试数据YAML 格式的测试用例设计稿、配置文件不包含代码只包含数据注意事项1. 不要把所有代码放一个文件随着项目增长测试代码会越来越多。如果不分文件一个文件可能有几千行难以维护。建议每个文件不超过 500 行超过 500 行考虑拆分拆分原则按职责拆分不是按行数拆分2. 不要循环导入A 导入 BB 导入 CC 又导入 A → 循环导入启动报错。建议基类不导入子类工具类不导入业务类测试用例导入所有模块但不被其他模块导入3. 配置文件统一管理配置分散在各个文件中如 Appium 地址、超时时间修改时容易遗漏。建议所有配置集中在config.yaml代码通过config_reader.py读取配置环境变量优先级高于配置文件4. 测试数据与代码分离测试数据用户名、密码、URL硬编码在测试代码中修改时需要改代码。建议测试数据放在testcases/data/目录使用 YAML 格式易读、支持注释测试代码通过data_driver.py加载数据总结测试项目结构的核心原则职责清晰每个目录、每个文件都有明确职责低耦合模块之间依赖少修改一个不影响其他高内聚相关代码放在一起容易找到可扩展新增功能时知道该往哪加代码配套代码中的实现配套代码/test/完整目录结构数十个 Python 文件涵盖驱动管理、页面对象、API 封装、核心模块、工具类、测试数据等完整分层可直接作为模板使用。后续第 1-16 节内容完成。配套代码已覆盖 Appium 测试的完整生命周期环境搭建→驱动初始化→页面对象→API 测试→数据驱动→智能路由→混合执行→视觉测试→用例转换→重试容错→报告管理→项目结构。