答案。

历史上，在自动化测试涉及多个组件（UI、API、数据库、第三方服务）的复杂流程时，测试人员面临着困难：逻辑重复、测试缺乏连贯性、无法重现产品的端到端使用场景。

问题在于，这些测试通常超出了一个子系统的范围，需要复杂的数据准备、环境配置、不同系统部分之间正确的交互顺序。这一切都大大复杂化了自动测试的启动、可重复性和维护。

解决方案是采用端到端自动化，将状态准备分离到不同的层次，使用测试助手和混合方法（例如，通过直接访问数据库或API准备数据，而检查本身则通过UI进行）。这可以保持复杂度在可控范围内，不会“污染”测试逻辑。这个方法可以很好地根据模式进行结构化。

示例：

# 通过API准备数据
def create_order():
    ...
# 通过UI验证结果
def test_order_flow():
    id = create_order()
    go_to_order_page(id)
    assert get_status_from_ui() == 'COMPLETED'

关键特性：

多级数据准备和验证。
每个测试的责任明确划分（API、UI、数据库）。
使用模拟或存根来处理外部依赖。

陷阱问题。

是否可以仅依靠UI测试来检查端到端流程？

仅依靠UI测试是不够可靠的，它们速度太慢，且通常无法充分验证复杂场景中的大量数据和不同状态。

在执行E2E测试时，如何处理不稳定的外部服务？

使用模拟和存根文件，尽量减少外部服务的故障和不可用性对E2E测试稳定性的影响。

是否需要在复杂流程的每个级别覆盖负面案例？

是的，否则可能会错过层之间的集成错误。

常见错误和反模式

“笨重”的测试，单次运行做过多事情。
测试内部的数据准备混乱（违反责任分离原则）。
测试之间缺乏数据隔离。

生活中的示例

负面案例

在新项目中，测试人员开始创建端到端测试，完全模拟用户通过UI的操作，但没有考虑数据准备和环境的稳定性——如果外部服务不可用或已更改，测试有时会失败。

优点：

最大限度接近用户场景。
易于向业务展示。

缺点：

维护复杂。
稳定性下降（依赖外部服务）。
调试困难。

正面案例

在类似情况下，测试分为数据准备（通过API）、通过UI验证业务逻辑，并通过模拟隔离外部依赖。这显著提高了测试的速度、稳定性和透明度。