答案。

问题的历史：

最初，自动化测试经常被"直接"编写，没有架构分层：验证逻辑和执行机制混合在一起。随着项目的增长，逐渐显而易见，这种框架和测试逻辑的混合会导致脆弱且难以维护的代码库。出现了关于责任分离的架构建议。

问题：

如果测试依赖于框架的内部实现或包含与环境交互的逻辑，任何更改都会迫使重新编写大量测试。测试用例复杂，代码重复，迁移到新框架或平台变得困难。

解决方案：

严格分离：

• 框架（基线基础设施）： 测试执行的通用机制、日志记录、错误处理、报告、辅助类的基础（如驱动程序、适配器和工具）。
• 测试逻辑（测试用例）： 表达测试语义目标的具体场景，仅使用框架的公共API。

关键特点：

• 由于平台变化的隔离，便于维护
• 可重用测试逻辑
• 减少冗余和代码重复

具有陷阱的问题。

测试步骤可以直接写在测试中吗，如果数量很少？

不推荐。即使是短测试也可能膨胀，缺乏分层会迅速导致混乱。

测试场景应该知道启动机制吗（例如，何时初始化驱动程序）？

不应该。所有基础设施的细节应隐藏在框架层中。

在用例中硬编码测试参数（例如，url、凭证）是正常的吗？

不正常。测试参数应通过框架和环境的设置进行配置。

常见错误和反模式

• 在框架方法内而不是测试中放置状态检查
• 在测试中使用框架的私有方法
• 在测试中复制辅助函数
• 硬编码参数

生活中的例子

负面案例

在项目中，测试直接调用Selenium驱动程序的方法，每个测试中重复连接到WebDriver。每个测试单独解析配置。

优点：

• 可以快速开始编写没有架构的自动测试

缺点：

• 驱动程序或启动参数的更改会导致大规模修改
• 所有测试中的重复代码
• 难以扩展和维护项目

正面案例

测试使用框架的基本抽象：通用的初始化和拆卸，通过配置器进行参数的贯穿传递，测试逻辑通过高级方法表达。

优点：

• 维护和修改简便
• 测试逻辑易于移植和扩展
• 参数的单一入口

缺点：

• 在基础设施上的初始投入