Files
InterfaceAutoTest/docs/重构总结.md
CNWei 6393414ab2 feat,fix(core,docs): 完善核心模块代码注释并添加架构改进文档
- 为 core 目录下主要模块 (models, context, creator, base_api, exchange, executor) 添加了详细的类和方法 Docstring。
   - 新增 docs/架构改进.md 文件。
2026-03-18 11:26:55 +08:00

3.6 KiB
Raw Blame History

本次重构核心总结:升级为“模型驱动+混合模式”的自动化测试框架我们本次重构的目标是将现有框架从基于字典dict的松散操作升级为一个结构严谨、易于扩展的现代化测试框架。其核心包含以下四大支柱1. 核心驱动力Pydantic 模型层•目标:用强类型、带校验的模型对象取代脆弱的字典操作。•实现:创建 commons/models/case_model.py 文件,并定义 CaseInfo 类。•关键收益:•健壮性:在执行测试前,通过模型实例化,对 YAML 文件中的字段、类型、结构进行严格校验,提前发现拼写错误或格式问题。•可维护性:代码中不再出现 case.get("request") 这类“魔法字符串”,而是通过 case.request 这样的属性访问IDE 可以提供智能提示和补全,代码更清晰、更安全。•灵活性:支持使用 alias让 YAML 中的字段名(如 validate与模型属性名如 validate_data解耦使模型设计更符合 Python 规范。2. 执行模式支持混合模式Hybrid Mode•目标让框架同时适应简单的数据驱动测试和复杂的业务流测试。•实现•YAML 驱动模式:保留并优化 TestAPI 类。它负责扫描 tests/features/ 目录下的 test_.yaml 文件,并动态生成 pytest 用例。此模式非常适合单接口、多场景的数据验证。•手动脚本模式:允许在 tests/flows/ 目录下直接编写 test_.py 脚本。开发者可以像写普通 pytest 用例一样通过导入业务方法来编排复杂的、跨多个接口的业务流程。3. 架构设计:清晰的三层分离•目标:遵循最佳实践,分离关注点,让框架结构清晰,避免混乱。•实现:•数据层 (YAML + Pydantic Model) :定义测试的输入数据和预期结果(是什么)。•业务层/服务层 (api/.py):将原始的 HTTP 请求封装成具有业务含义的方法,如 api.auth.login()。它定义了如何执行具体业务操作(怎么做)。•测试层 (TestAPI 或 test_.py) 作为“导演”负责编排测试流程。它从数据层获取数据调用业务层的方法执行动作并进行最终断言测什么。4. 上下文与状态:统一的会话与变量池•目标:打通 YAML 驱动和手动脚本之间的数据壁垒,实现真正的端到端流程测试。•实现:•所有测试(无论来源)共享同一个 core.session.Session 实例,确保 Cookie、Header 等会话状态的连续性。•所有测试共享同一个 commons.exchange.Exchange 实例(变量交换器)。•关键收益:手动脚本(.py中通过登录获取的 token可以被无缝地注入到后续的 YAML 用例中反之YAML 用例提取的 ID 也能被后续的 .py 脚本使用。重构后的标准执行流程(以 YAML 为例1.加载TestAPI 扫描并加载 test_*.yaml 文件。2.数据驱动DataDriver 将 YAML 文件内容解析为多个独立的、参数化的测试用例。3.执行:在 pytest 的 test_func 内部: a. 变量替换exchanger.replace() 将用例中的 ${variable} 替换为实际值。 b. 模型校验CaseInfo(replaced_case_data) 将替换后的字典实例化为 CaseInfo 模型对象,完成数据校验。(这是与旧流程最核心的区别) c. 请求发送:使用模型对象的数据发送请求 session.request( case.request.model_dump())。 d. 变量提取exchanger.extract() 从响应中提取数据,并存入全局变量池。 e. 断言validator.assert_all(case.validate_data) 使用模型中的断言数据进行校验。