一年来，做了很多次有 AB 实验的需求了。AB 实验对产品的决策方向是非常重要的，这也给我们测试时候指明了重点。本文记录一下业务需求侧 AB 实验的测试要点。

在单体架构时代，一个请求的所有逻辑都在同一个进程中执行，调试和排查问题相对简单：查看日志、打断点、分析堆栈，基本能定位到问题所在。

但在微服务架构下，一个用户请求可能会经过网关、认证服务、订单服务、支付服务、库存服务等多个服务。当请求失败或响应缓慢时，问题可能出现在链路中的任何一个环节：

一、问题

传统的 UI 自动化测试代码往往是这样写的：

def test_login_and_create_report():
    driver.get("/login")
    driver.find_element(By.ID, "username").send_keys("admin")
    driver.find_element(By.ID, "password").send_keys("admin123")
    driver.find_element(By.ID, "login-btn").click()

    driver.get("/reports")
    driver.find_element(By.ID, "new-report").click()
    driver.find_element(By.ID, "report-name").send_keys("测试报表")
    driver.find_element(By.ID, "save-btn").click()

    assert "创建成功" in driver.page_source

问题很明显：测试逻辑被一大堆底层操作淹没了，看不出主线流程。

一、背景

在 UI 自动化测试中，持续维护测试脚本的成本很高。页面稍微一改动，大量的测试用例就有可能失败，需要人工修改适配。

因此，有人提出了POM（Page Object Model）设计模式。核心思维是将页面结构和测试逻辑分离，使测试代码更易于维护和扩展。

Robot Framework 默认是单线程顺序执行用例的，但我发现大家写得挺好，用例之间并没有依赖关系，完全可以并行执行。我发现了一个叫 Pabot 的东西，是专门用于并行执行 Robot Framework 的库。