测试语法基础：掌握测试用例的编写规范

Robot Framework 的核心价值在于其关键字驱动（Keyword-Driven）的测试设计理念，而这一切的载体就是结构严谨、语法清晰的测试用例。测试用例不仅是自动化脚本的执行单元，更是团队协作中的“活文档”。本章将深入剖析测试用例的四大核心组成要素——名称、文档、标签、设置与步骤，帮助您从“能写脚本”进阶到“写出规范、可维护、可追溯的高质量测试用例”。我们将从语法规则、执行逻辑到工程实践，构建一套完整的用例编写方法论。

测试用例名称：可读性与唯一性的平衡

测试用例名称是用例的唯一标识符，在 Robot Framework 中，它直接定义在 *** Test Cases *** 表格下，作为第一列内容。名称的规范直接影响测试报告的可读性、失败时的排查效率以及 CI/CD 流水线中的日志追踪。一个优秀的用例名称应当做到“见名知意”，即从名称中就能推断出测试的业务场景、操作对象和预期结果。

在命名实践中，推荐采用“业务模块_操作动作_预期结果”或“条件_动作_结果”的格式。例如，登录模块_输入正确密码_登录成功 比 test_login_001 更具信息量。Robot Framework 对名称的大小写不敏感，但保留空格和特殊字符，因此可以使用空格和下划线提升可读性。需要注意的是，名称不应包含换行符，且在同一套件内必须唯一，否则执行时后定义的同名用例会覆盖前者，导致测试遗漏。

文档与标签：用例的“说明书”与“分类器”

[Documentation] 设置项用于为用例添加详细的描述性文本，支持 HTML 格式和变量替换。它不仅是给测试人员看的注释，更会渲染到测试报告和日志中，成为团队沟通的桥梁。优秀的文档应包含：用例的业务价值、前置条件（如测试数据准备）、关键步骤的意图、预期结果的详细描述以及可能的风险提示。例如：

*** Test Cases ***
验证购物车价格计算
    [Documentation]    验证当商品参与满减活动时，购物车总价计算正确。
    ...    前置条件：用户已登录，购物车中存在2件商品A（单价100元）。
    ...    预期结果：满200减30后，总价显示为170元。
    [Tags]    smoke    cart    pricing
    Given 用户已登录
    When 用户将商品A加入购物车
    And 用户将第二件商品A加入购物车
    Then 购物车总价应为 170 元

[Tags] 是 Robot Framework 最强大的分类工具。标签可以用于：选择执行子集（如只运行 smoke 标签的用例）、统计测试结果、按模块或优先级过滤、以及通过 --exclude 参数跳过特定用例。标签的命名建议采用小写字母和连字符，如 regression、windows-only。在 CI 流水线中，标签是动态组合测试集的核心手段，例如每晚回归执行 regression 标签，而每次提交只执行 smoke 标签。

设置项：Setup、Teardown 与超时控制

测试用例的设置项定义了用例的执行边界和生命周期管理。[Setup] 在用例步骤执行前运行，通常用于初始化测试环境、创建测试数据、启动浏览器或建立数据库连接。[Teardown] 无论用例成功或失败都会执行，用于清理资源、关闭浏览器、删除临时文件或恢复环境状态。这种“前置准备-测试执行-后置清理”的模型是保证测试独立性和可重复性的基石。

除了 Setup 和 Teardown，[Timeout] 设置项用于定义用例的最大执行时间，防止死循环或外部服务挂起导致 CI 任务无限阻塞。超时时间支持单位后缀（如 1 minute 30 seconds），超时后用例将被强制终止并标记为失败。此外，[Template] 设置项可以将用例转换为数据驱动模式，将步骤中的关键字固定，仅通过参数变化生成多个测试变体，极大减少重复代码。

步骤编写：关键字驱动的核心实践

测试步骤是用例的主体，由一系列关键字调用组成。每个步骤占据一行，格式为“关键字名称 + 参数”。步骤的编写质量直接决定了用例的可读性和可维护性。优秀的步骤应当遵循“行为驱动”风格，使用自然语言描述业务动作，而非底层实现细节。例如，输入文本 id=username admin 比 Input Text //input[@id='username'] admin 更贴近业务，但后者在 XPath 定位上更精确。关键在于合理抽象：将底层 Selenium 关键字封装为业务关键字（如 用户登录），然后在用例中调用。

步骤中的断言是测试的灵魂。Robot Framework 提供 Should Be Equal、Should Contain、Should Be True 等内置断言关键字。断言应尽量具体，避免模糊判断。例如，验证登录成功时，应同时断言 URL 变化、页面包含用户昵称、Cookie 存在等多个维度，而非仅检查“登录成功”文本是否存在。此外，步骤之间应保持逻辑连贯，使用 Given/When/Then 或 And/But 前缀增强可读性，这并非强制语法，但能显著提升用例的叙事性。

案例拆解：从需求到用例的完整闭环

下面通过一个电商平台的“优惠券叠加使用”场景，完整演示测试用例的编写规范与决策过程。

背景与约束：系统规定“满减券”和“折扣券”不可叠加使用，但“免邮券”可与任意券叠加。前端在用户选择第二张券时应禁用并提示。测试环境为 Chrome 浏览器，测试数据需通过 API 预置。

初始现象与目标：开发提交代码后，测试人员需验证该规则在前端交互和价格计算两个层面的正确性。目标用例需覆盖：选择满减券后再选折扣券被阻止、选择免邮券后仍可选满减券、最终价格计算正确。

关键输入数据：商品单价 200 元，满减券减 30 元，折扣券 8 折，免邮券免运费（运费 10 元）。

分析判断过程：该场景涉及 UI 交互和价格计算，需拆分为两个用例：一个验证交互限制（UI 层面），一个验证价格计算（逻辑层面）。交互用例应使用前端定位断言按钮状态；价格用例应通过 API 获取最终订单金额进行断言，避免依赖 UI 渲染。

实际操作步骤：

*** Test Cases ***
验证满减券与折扣券不可叠加
    [Documentation]    用户选择满减券后，折扣券应被禁用并显示提示
    [Tags]    regression    coupon    ui
    [Setup]    预置商品和用户优惠券    product_id=101    user=test01
    Given 用户打开商品详情页
    When 用户点击“选择优惠券”
    And 用户选择“满30减10”券
    Then 折扣券选项应为禁用状态
    And 页面应显示提示“不可与折扣券叠加”
    [Teardown]    清理测试订单

验证免邮券与满减券叠加价格计算
    [Documentation]    免邮券可与满减券叠加，总价=商品价-满减+运费(免)
    [Tags]    regression    coupon    pricing
    [Setup]    预置商品和用户优惠券    product_id=101    user=test01
    Given 用户将商品加入购物车
    When 用户选择“满30减10”券
    And 用户选择“免邮券”
    Then 购物车总价应显示为 190 元
    And 结算页运费应显示为 0 元
    [Teardown]    清理测试订单

结果对比与复盘：执行后，交互用例因前端提示文案与需求文档不一致而失败，开发修复文案后通过。价格用例一次通过。复盘发现，若在用例中直接断言“190 元”硬编码，后续促销规则变更时维护成本高，应改为从配置接口动态获取满减金额。此外，Setup 中通过 API 预置数据比 UI 操作更稳定，执行时间缩短了 40%。

常见误区与总结复盘

在编写测试用例时，初学者常陷入以下误区：误区一：用例名称过于笼统，如 test1，导致报告无法追溯；误区二：忽略 Teardown，导致测试数据残留，影响后续用例执行；误区三：在步骤中直接使用复杂 XPath 或 CSS 选择器，使得用例与页面结构强耦合，页面微调即导致脚本崩溃；误区四：断言不足或过度断言，前者导致漏测，后者导致用例脆弱。

正确的做法是：将用例视为可执行的规格说明，遵循“一个用例只验证一个核心业务规则”的原则。通过合理的标签体系管理用例规模，通过 Setup/Teardown 保证测试隔离，通过业务关键字封装底层技术细节。最终，测试用例不仅是回归的保障，更是团队对业务规则共识的载体。