自动化测试套件需分层设计：ui层用selenium/pytest验证交互流程，接口层用requests/pytest验证数据逻辑，二者互补；统一配置管理、原子化用例、状态传递与清理、allure集成报告实现可维护、可追溯的持续回归。
构建自动化测试套件，核心是分层覆盖、职责清晰、可维护性强。UI 层验证用户可见行为，接口层保障数据逻辑与服务稳定性，两者不是替代关系，而是互补验证——UI 测试容易因前端变动失效，接口测试则更早介入、更稳定、更适合持续回归。
明确分层目标与工具选型
UI 自动化聚焦页面交互流程（如登录→搜索→下单），推荐 Selenium + Pytest（Python）或 TestNG + Maven（Java），搭配 Page Object 模式解耦页面结构与测试逻辑；接口自动化专注请求-响应验证（如调用登录接口校验 token 生成、状态码、字段结构），主流组合是 Requests + Pytest + Allure，配合 YAML/JSON 管理测试数据和用例配置。
- 不建议用同一套脚本混写 UI 和接口操作，会降低可读性与复用性
- 接口测试优先于 UI 测试启动：只要接口文档（Swagger/OpenAPI）或契约定稿，即可编写用例
- UI 测试环境需稳定可控（如固定测试账号、Mock 弹窗/广告），否则脚本频繁失败会失去可信度
统一数据与配置管理
避免硬编码 URL、账号、密钥、断言值。把环境配置（dev/test/prod）、测试数据（用户名、商品 ID）、接口定义（路径、method、headers）分别抽离为独立文件。
- 用 conf/env.yaml 存不同环境的 base_url、超时时间、数据库连接等
- 用 data/login_cases.yaml 定义多组登录场景：正常账号、密码错误、空用户名等
- 接口请求参数尽量通过函数动态生成（如时间戳、随机手机号），而非静态写死
设计可串联、可隔离的测试流
单个测试用例应原子化（只验证一个业务点），但多个用例之间可按需串联执行——比如“注册→登录→创建订单→查询订单”形成端到端链路。关键在于状态传递与清理机制。
- 用 pytest 的 fixture 实现前置登录并返回 token，供后续接口用例自动注入 Authorization 头
- 每个用例执行后主动清理数据（如调用删除订单接口或清空测试库记录），避免污染下一条用例
- UI 测试中，用 setup_method / teardown_method 控制浏览器启停粒度，不每次用例都重开浏览器
集成报告与失败归因
自动化不是跑完就结束，重点是快速定位问题。Allure 报告能展示请求详情、响应体、截图（UI）、SQL 日志（如有）；失败时自动抓取关键信息。
- 接口用例失败时，记录完整 request + response（含 headers/status code/body）
- UI 用例失败时，自动保存当前页面截图和 DOM 快照（Selenium 提供 get_screenshot_as_file + page_source）
- 所有日志统一输出到 allure-results 目录，用 allure serve 一键启服务查看可视化报告
