1. 初识Setup和Teardown测试世界的开场白与谢幕词第一次接触RobotFramework时我对着测试报告里那些重复的打开浏览器、登录系统操作发愁。直到发现了Setup和Teardown这对黄金搭档才明白原来测试也可以有优雅的仪式感。简单来说Setup就像演出前的灯光调试Teardown则是散场后的座椅归位。比如测试电商下单功能我们总需要先登录、清空购物车测试后再恢复初始状态——这些固定动作正是它们的用武之地。在RobotFramework中这两个机制遵循着谁的地盘谁做主原则。测试用例、套件文件、套件目录这三个层级就像俄罗斯套娃外层设置会影响内层但内层可以覆盖外层的规则。想象成公司管理制度集团有通用规范目录级分公司可以细化规则文件级具体项目组还能定制特殊流程用例级。这种层级设计让测试代码既保持统一性又不失灵活性。*** Test Cases *** 购物车添加商品测试 [Setup] 登录系统 清空购物车 [Teardown] 退出登录 添加商品到购物车 验证购物车商品数量2. 测试用例级的精准控制2.1 基础配置就像定制西装每个测试用例都可以拥有专属的Setup和Teardown就像高级定制西装般合身。我在测试支付系统时深有体会有的用例需要模拟信用卡支付环境有的则需要配置支付宝沙箱。直接在用例头部声明既清晰又便于维护*** Test Cases *** 信用卡支付测试 [Setup] 配置信用卡测试环境 [Teardown] 重置支付网关 执行信用卡支付流程 验证交易结果 支付宝支付测试 [Setup] 初始化支付宝沙箱 执行扫码支付操作 验证支付状态 [Teardown] 清除沙箱交易记录注意两个细节陷阱一是关键字只能写一个但可以用自定义关键字打包多个操作二是Teardown即使用例失败也会执行。有次我忘记在Teardown中释放测试数据库锁导致后续用例全部卡死——这个教训让我养成了在Teardown中必须做资源清理的习惯。2.2 动态参数的妙用更高级的玩法是结合变量传递参数。我们项目中有个智能家居测试场景不同用例需要初始化不同温度值*** Variables *** ${DEFAULT_TEMP} 26 *** Test Cases *** 空调制热模式测试 [Setup] 设置空调模式 制热 ${DEFAULT_TEMP} 验证温度上升曲线 [Teardown] 恢复默认设置 空调节能模式测试 [Setup] 设置空调模式 节能 ${DEFAULT_TEMP-2} 验证功耗降低效果 [Teardown] 恢复默认设置3. 测试套件文件级的效率革命3.1 告别重复代码的苦役当发现团队里有20个用例都在重复写相同的浏览器初始化代码时我意识到该升级到套件文件级配置了。在*** Settings ***区域声明Suite Setup/Teardown就像给整个测试文件装上自动门*** Settings *** Suite Setup 打开浏览器 ${URL} chrome Suite Teardown 关闭所有浏览器 Test Setup 清空Cookies Test Teardown 截图保存 *** Test Cases *** 搜索功能测试 输入搜索关键词 RobotFramework 验证搜索结果 购物车功能测试 添加测试商品 验证购物车数量这里有套件级Suite和测试级Test两种设置它们的执行顺序就像洋葱层层包裹Suite Setup最先执行然后每个Test Case执行前跑Test Setup除非用例自己有Setup最后以Suite Teardown收尾。实际运行日志会显示清晰的层级关系Suite Setup - 打开浏览器 Test Case1 Test Setup - 清空Cookies ...用例步骤... Test Teardown - 截图保存 Test Case2 Test Setup - 清空Cookies ...用例步骤... Test Teardown - 截图保存 Suite Teardown - 关闭浏览器3.2 多层级混合使用的实战技巧在物联网设备测试中我开发了一套组合拳策略Suite Setup负责启动模拟设备服务Test Setup重置设备状态关键用例再单独配置特殊环境。这种分层管理就像军事行动中的战略、战术和单兵配合*** Settings *** Suite Setup 启动设备模拟服务 ${IP} Suite Teardown 停止模拟服务 Test Setup 重置设备到出厂设置 *** Test Cases *** 固件升级测试 [Setup] 加载测试固件 V1.2.3 执行OTA升级 验证版本号 [Teardown] 清理升级缓存 普通功能测试 测试WiFi连接 验证传感器数据特别注意Suite Teardown的异常处理——即使中间用例失败也要确保资源释放。有次测试中断导致模拟服务进程残留后来我在Teardown中增加了进程强制终止的逻辑。4. 测试套件目录级的大规模作战4.1 初始化文件的魔法当项目膨胀到几十个测试文件时__init__.robot文件就是我们的秘密武器。这个放在测试目录下的特殊文件能统一管理所有子文件的初始化和清理。就像大型演唱会的总控台一键控制所有灯光音响测试项目/ ├── __init__.robot ├── 登录模块/ │ ├── test_login.robot │ └── test_logout.robot └── 支付模块/ ├── test_alipay.robot └── test_wechatpay.robot__init__.robot内容示例*** Settings *** Suite Setup 初始化测试数据库 ${DB_CONFIG} Suite Teardown 备份测试数据 ${BACKUP_PATH} Test Setup 生成测试报告头 Test Teardown 记录测试耗时4.2 企业级测试架构实践在金融系统测试中我们设计了三级初始化体系目录级初始化创建测试账户文件级设置交易环境用例级准备具体测试数据。这种架构让上千个测试用例保持高度一致性金融测试/ ├── __init__.robot # 创建测试账户 ├── 转账业务/ │ ├── __init__.robot # 设置转账限额 │ ├── test_同行转账.robot # 准备同行账户 │ └── test_跨行转账.robot # 配置跨行通道 └── 理财业务/ ├── __init__.robot # 初始化理财产品 └── test_申购赎回.robot # 设置申购参数执行时通过robot 金融测试/命令即可触发完整测试流程系统会自动按顺序执行各层级的Setup和Teardown。测试报告会清晰显示层级关系方便定位问题金融测试 Suite Setup - 创建测试账户 转账业务 Suite Setup - 设置转账限额 同行转账测试 Test Setup - 准备同行账户 ...测试步骤... 跨行转账测试 Test Setup - 配置跨行通道 ...测试步骤... Suite Teardown - 重置转账限额 理财业务 Suite Setup - 初始化理财产品 申购赎回测试 Test Setup - 设置申购参数 ...测试步骤... Suite Teardown - 清理理财数据 Suite Teardown - 归档测试账户5. 避坑指南与性能优化5.1 那些年我踩过的坑循环依赖陷阱有次在目录级Setup调用了一个文件级关键字结果执行时文件还没加载导致失败。现在我的原则是层级越高的Setup应该使用越基础的关键字。超时雪崩多个层级的Setup顺序执行时如果每个都接近超时阈值整体时间会指数级增长。后来我们为不同层级设置了差异化的超时时间*** Settings *** Suite Setup 大数据量初始化 timeout10min Test Setup 快速重置环境 timeout30s静默失败风险Teardown中的失败不会标记用例为失败但会影响后续测试。我们现在会在Teardown中加入严格检查[Teardown] Run Keyword And Continue On Failure 验证资源释放5.2 高性能配置技巧对于大型测试集这些优化手段能显著提升效率懒加载模式在目录级Setup只做必要初始化文件级Setup按需加载并行执行兼容确保各层级的Setup/Teardown不依赖全局状态条件化执行通过变量控制是否执行某些清理操作*** Settings *** Suite Setup 初始化测试环境 ${ENV_MODE} Test Teardown Run Keyword If ${CLEAN_FLAG} 清理测试数据6. 真实项目案例拆解最近完成的智能家居测试平台充分运用了多层级Setup/Teardown目录级init.robotSetup启动家庭网关模拟器Teardown生成设备健康报告文件级test_lighting.robotSetup添加虚拟照明设备Teardown重置照明场景用例级调光测试 [Setup] 设置亮度参数 50% 验证平滑调光效果 [Teardown] 恢复默认亮度这种架构使200设备测试用例的维护工作量减少了70%。特别是当需要更换网关模拟器时只需修改一处目录级Setup即可。7. 可视化调试技巧使用内置的Log和Debug关键字输出执行轨迹*** Settings *** Suite Setup Log Suite Setup开始 consoleTrue Suite Teardown Log Suite Teardown结束 consoleTrue *** Test Cases *** 示例用例 [Setup] Log 用例Setup开始 consoleTrue Log 主体步骤执行中... [Teardown] Log 用例Teardown结束 consoleTrue配合--listener选项记录更详细的执行时序这对调试复杂的层级关系特别有用。我习惯用时间戳标记关键节点[Teardown] Run Keywords ... 记录时间戳 Teardown开始 ... AND ... 执行清理操作 ... AND ... 记录时间戳 Teardown结束8. 设计模式进阶对于复杂场景可以建立初始化/清理的金字塔模型基础设施层目录级数据库连接模拟服务启动全局配置加载业务模块层文件级API客户端初始化测试数据准备权限配置用例场景层用例级特定参数设置前置条件检查临时文件生成这种分层的设计模式使得在扩展新测试模块时就像搭积木一样简单自然。当我们需要新增一个支付渠道测试时只需要在目录级Setup已建立的支付网关连接基础上文件级Setup配置该渠道特有参数用例级Setup设置具体测试金额*** Test Cases *** 新支付渠道限额测试 [Setup] 设置单笔限额 ${NEW_CHANNEL} 5000 执行大额支付 4999 验证支付成功 [Teardown] 重置渠道限额9. 与持续集成的完美配合在CI/CD流水线中合理的Setup/Teardown层级设计能实现并行测试不同测试模块可以独立初始化失败隔离一个模块的Teardown不会影响其他模块资源回收确保即使测试失败也会释放CI资源典型的Jenkins配置示例pipeline { stages { stage(测试) { steps { script { // 执行目录级初始化 sh robot --include setup 初始化测试/ // 并行执行各模块测试 parallel { stage(模块A) { sh robot 模块A测试/ } stage(模块B) { sh robot 模块B测试/ } } // 执行目录级清理 sh robot --include teardown 清理测试/ } } } } }10. 自定义关键字的艺术将重复使用的Setup/Teardown逻辑封装成自定义关键字就像编写自己的测试工具库*** Keywords *** 初始化浏览器环境 [Arguments] ${browser}chrome 打开浏览器 ${BASE_URL} ${browser} 设置窗口大小 1920 1080 禁用浏览器缓存 清理测试数据 删除临时文件 ${TEST_DATA_PATH} 重置数据库快照 ${DB_SNAPSHOT}然后在各层级Setup/Teardown中调用这些标准化关键字既能保证一致性又便于统一修改。当需要将浏览器从Chrome切换到Firefox时只需修改关键字定义一处即可。对于特别复杂的初始化流程可以采用建造者模式分步构建*** Test Cases *** 高级配置测试 [Setup] Run Keywords ... 初始化基础环境 AND ... 加载性能插件 AND ... 配置监控参数 ... 执行压力测试 [Teardown] Run Keywords ... 收集性能数据 AND ... 生成分析报告 AND ... 关闭监控服务11. 版本兼容性处理随着系统升级Setup/Teardown也需要考虑多版本兼容。我们的做法是通过变量控制不同版本的初始化逻辑*** Settings *** Suite Setup 初始化系统 ${SYSTEM_VERSION} *** Keywords *** 初始化系统 [Arguments] ${version} Run Keyword If $version 2.0 初始化V2系统 ... ELSE IF $version 1.5 初始化V1.5系统 ... ELSE 初始化默认系统在Teardown中同样需要区分版本进行清理特别是当不同版本的数据结构有差异时[Teardown] Run Keyword If ${IS_LEGACY_VERSION} 传统数据清理 ... ELSE 标准数据清理12. 安全测试专项应用在安全测试中Setup/Teardown的层级设计更为关键目录级创建隔离的测试沙箱文件级配置具体的测试策略如渗透测试、模糊测试用例级设置特定攻击向量*** Settings *** Suite Setup 创建安全沙箱 ${SANDBOX_CONFIG} Suite Teardown 销毁沙箱环境 *** Test Cases *** SQL注入测试 [Setup] 配置SQL过滤器 ${FILTER_RULES} 执行注入攻击 验证防御效果 [Teardown] 清理测试痕迹这种结构确保即使攻击性测试也不会影响真实环境所有测试都在受控的隔离环境中进行。13. 移动端测试的特殊考量移动测试如Appium中Setup/Teardown需要额外处理设备连接问题*** Settings *** Test Setup Run Keywords ... 解锁设备 AND ... 启动被测应用 Test Teardown Run Keywords ... 关闭应用 AND ... 恢复设备默认设置对于需要多设备并行测试的场景可以在目录级Setup中初始化设备池文件级Setup分配具体设备*** Keywords *** 分配测试设备 ${device} Acquire From Device Pool Set Global Variable ${CURRENT_DEVICE} ${device} 连接设备 ${device}14. 数据驱动测试的整合当使用[Template]进行数据驱动测试时Setup/Teardown的执行规则稍有不同*** Test Cases *** 多登录方式测试 [Template] 测试登录功能 [Setup] 重置登录限制 username password 预期结果 admin Admin123 ${TRUE} guest wrong_pass ${FALSE} [Teardown] 记录登录尝试 *** Keywords *** 测试登录功能 [Arguments] ${user} ${pwd} ${expected} 输入用户名 ${user} 输入密码 ${pwd} 点击登录按钮 验证登录结果 ${expected}注意此时Setup/Teardown在整个模板用例开始前/结束后执行而不是为每行数据都执行。如果需要对每组数据都初始化应该将逻辑放在模板关键字内部。15. 异常处理的最佳实践完善的异常处理是Setup/Teardown可靠性的关键。我们团队现在遵循这些规则Setup严格检查初始化失败立即终止避免后续测试无意义Teardown柔性处理即使部分清理失败也要继续执行剩余操作状态回滚机制在关键操作前保存状态便于Teardown时恢复*** Keywords *** 安全初始化 ${original} 获取系统配置 Set Test Variable ${ORIGINAL_CONFIG} ${original} 尝试更新配置 ${NEW_CONFIG} 验证配置生效 安全清理 Run Keyword And Ignore Error ... 恢复系统配置 ${ORIGINAL_CONFIG} 记录清理状态 ${TEST_STATUS}16. 性能测试的专属优化性能测试中的Setup/Teardown需要特别关注预热处理在Suite Setup中执行预热操作避免冷启动影响数据隔离确保不同性能测试用例使用独立数据集结果收集在Teardown中统一采集性能指标*** Settings *** Suite Setup 预热服务器 ${WARMUP_PARAMS} Test Teardown 收集性能指标 ${TEST_NAME} *** Test Cases *** 并发查询测试 [Setup] 生成测试数据 ${DATA_SIZE} 执行并发查询 ${THREAD_COUNT} [Teardown] 清理测试数据17. 多环境支持策略为支持测试/预发/生产多环境我们采用这样的架构env/ ├── dev/ │ └── __init__.robot # 开发环境初始化 ├── staging/ │ └── __init__.robot # 预发环境初始化 └── prod/ └── __init__.robot # 生产环境初始化通过命令行参数动态选择环境robot --variable ENV:dev 测试套件/对应的初始化文件内容*** Settings *** Suite Setup 初始化${ENV}环境 Suite Teardown 清理${ENV}环境 *** Keywords *** 初始化dev环境 连接开发数据库 使用模拟支付网关 初始化staging环境 连接预发数据库 使用沙箱支付网关18. 插件体系扩展通过自定义监听器(Listener)可以更灵活地控制Setup/Teardownclass MyListener: def start_suite(self, suite): print(f自定义前置处理: {suite.name}) def end_suite(self, suite): print(f自定义清理处理: {suite.name})在RobotFramework中注册*** Settings *** Listener MyListener这种方式适合需要与外部系统深度集成的场景比如在Setup中自动创建JIRA工单在Teardown中更新测试状态。19. 与BDD风格的结合当使用RobotFramework的BDD风格时Setup/Teardown可以这样组织*** Settings *** Suite Setup 初始化用户系统 Suite Teardown 清理用户数据 *** Test Cases *** 用户注册场景 [Setup] 重置注册限制 Given 访问注册页面 When 输入有效注册信息 Then 应显示注册成功 [Teardown] 记录注册日志 用户登录场景 Given 访问登录页面 When 输入正确凭证 Then 应跳转到个人中心这种写法既保持了BDD的自然语言可读性又通过Setup/Teardown维护了测试的稳定性。20. 大型测试套件架构设计对于超大型测试项目1000用例我们采用初始化分级策略核心层必须目录级基础设施准备文件级模块数据准备可选层按需用例组级通过标签选择初始化用例级特殊场景定制通过标签控制部分Setup/Teardown的执行*** Settings *** Suite Setup Run Keyword If api in {TEST_TAGS} 初始化API测试环境 *** Test Cases *** API连通性测试 [Tags] api smoke 测试接口连通 /health执行时可以通过--include/--exclude参数灵活控制robot --include api 测试套件/ # 只执行API相关测试并触发对应初始化21. 调试技巧与日志分析当Setup/Teardown出现问题时这些调试技巧很实用详细日志使用--loglevel DEBUG参数步骤隔离临时添加Fail关键字定位问题点变量追踪在Teardown中dump关键变量[Teardown] Run Keywords ... 记录变量状态 AND ... 验证清理结果 AND ... Run Keyword If ${DEBUG}True Pause Execution22. 与版本控制的协同在团队协作中Setup/Teardown的管理建议基础配置将通用的Setup/Teardown放在版本控制的资源文件中环境差异通过配置文件管理不同环境的初始化参数变更追踪对__init__.robot文件设置严格的代码审查典型的资源文件引用方式*** Settings *** Resource common_setup.robot Suite Setup 通用套件初始化 Suite Teardown 通用套件清理23. 跨平台测试方案对于需要跨Windows/Linux/macOS的测试Setup/Teardown可以这样设计*** Keywords *** 平台相关初始化 ${os} Evaluate platform.system() platform Run Keyword If $os Windows Windows初始化 ... ELSE IF $os Linux Linux初始化 ... ELSE Mac初始化 平台相关清理 ${os} Evaluate platform.system() platform Run Keyword If $os Windows Windows清理 ... ELSE IF $os Linux Linux清理 ... ELSE Mac清理24. 测试报告增强技巧通过在Setup/Teardown中添加元信息可以生成更丰富的测试报告*** Settings *** Suite Setup Set Suite Metadata 环境类型 ${ENV_TYPE} Suite Teardown Add Suite Tag 执行耗时:${SUITE_DURATION} *** Test Cases *** 示例用例 [Setup] Set Test Message 用例开始时间:${CURTIME} ... 执行测试步骤... [Teardown] Set Test Message 用例状态:${TEST_STATUS}25. 资源监控与报警在关键测试的Setup/Teardown中加入资源监控*** Keywords *** 安全初始化 记录CPU使用率 ${SUITE_NAME}_start 记录内存占用 ${SUITE_NAME}_start ...正常初始化逻辑... 安全清理 记录CPU使用率 ${SUITE_NAME}_end 记录内存占用 ${SUITE_NAME}_end Run Keyword If ${MEMORY_LEAK} 触发内存泄漏报警 ...正常清理逻辑...26. 多语言测试支持对于国际化测试Setup可以动态设置语言环境*** Test Cases *** 法语界面测试 [Setup] 设置浏览器语言 fr 验证界面翻译 [Teardown] 重置浏览器语言 日语界面测试 [Setup] 设置浏览器语言 ja 验证界面翻译 [Teardown] 重置浏览器语言27. 自动化部署集成将Setup/Teardown与部署流程结合*** Settings *** Suite Setup 部署测试版本 ${BUILD_NUMBER} Suite Teardown 回滚到稳定版本 *** Test Cases *** 新功能冒烟测试 [Setup] 切换到新功能开关 验证新功能 [Teardown] 重置功能开关28. 可视化配置管理对于复杂的初始化参数可以使用YAML文件管理*** Settings *** Suite Setup 加载测试配置 ${CONFIG_FILE} *** Keywords *** 加载测试配置 [Arguments] ${file} ${config} Evaluate yaml.safe_load(open(${file})) yaml Set Suite Variable ${DB_CONFIG} ${config[database]} Set Suite Variable ${API_CONFIG} ${config[api]}对应的YAML配置示例database: host: test-db.example.com port: 3306 user: tester api: base_url: https://api.test.com/v2 timeout: 1029. 智能回滚机制在金融类测试中我们实现了事务型Teardown*** Keywords *** 事务性初始化 [Arguments] ${operations} {snapshots} Create List FOR ${op} IN {operations} ${snapshot} 执行带快照的初始化 ${op} Append To List ${snapshots} ${snapshot} END [Return] ${snapshots} 事务性清理 [Arguments] ${snapshots} FOR ${snapshot} IN {snapshots} 根据快照回滚 ${snapshot} END用例中的使用示例*** Test Cases *** 跨行转账测试 ${snapshots} 事务性初始化 ${TRANSFER_OPS} 执行转账测试流程 [Teardown] 事务性清理 ${snapshots}30. 测试数据生命周期管理完善的测试数据管理应该贯穿Setup/TeardownSetup阶段创建主测试数据生成衍生数据建立数据关联Teardown阶段标记测试数据归档关键数据清理临时数据*** Keywords *** 创建测试订单 ${order_id} 生成测试订单 ${TEST_USER} ${payment_id} 模拟支付 ${order_id} [Return] ${order_id} ${payment_id} 清理订单数据 [Arguments] ${order_id} ${payment_id} 标记测试订单 ${order_id} 取消支付记录 ${payment_id} 删除临时数据 ${order_id}31. 多租户测试策略对于SaaS系统的多租户测试Setup/Teardown需要特别设计*** Settings *** Suite Setup 创建测试租户 ${TENANT_CONFIG} Suite Teardown 清理租户数据 ${TENANT_ID} *** Test Cases *** 租户隔离测试 [Setup] 切换租户上下文 ${TENANT_A} 验证数据隔离 ${TENANT_B} [Teardown] 重置租户上下文32. 测试夹具(Fixture)模式借鉴pytest的fixture概念可以创建可重用的测试环境*** Keywords *** 数据库夹具 [Arguments] ${schema} ${conn} 建立数据库连接 ${schema} Set Test Variable ${DB_CONN} ${conn} [Teardown] 关闭数据库连接 ${conn} API客户端夹具 [Arguments] ${version} ${client} 初始化API客户端 ${version} Set Test Variable ${API_CLIENT} ${client} [Teardown] 清理API缓存 ${client}在测试用例中使用*** Test Cases *** 数据导入测试 [Setup] 数据库夹具 test_schema [Setup] API客户端夹具 v2 执行数据导入 验证数据一致性33. A/B测试场景支持对于需要A/B测试的场景Setup可以动态配置*** Keywords *** 配置AB测试 [Arguments] ${test_name} ${group} ${variant} 获取AB测试配置 ${test_name} ${group} 激活测试变体 ${variant} [Return] ${variant} *** Test Cases *** 新界面AB测试 [Setup] ${variant} 配置AB测试 new_ui B 验证B版本功能 [Teardown] 重置AB测试 new_ui34. 测试环境验证在Setup中加入环境健康检查*** Keywords *** 环境检查 验证数据库连接 验证API可达性 验证文件系统权限 Run Keyword If ${任何检查失败} Fail 环境不满足测试要求 *** Settings *** Suite Setup 环境检查35. 智能跳过机制基于环境状态的智能Setup*** Keywords *** 条件初始化 ${需要初始化} 检查初始化状态 Run Keyword If ${需要初始化} 执行完整初始化 ... ELSE 执行轻量初始化 *** Settings *** Suite Setup 条件初始化36. 测试数据工厂模式将测试数据生成封装成工厂方法*** Keywords *** 用户数据工厂 [Arguments] ${type}normal ${user} Create Dictionary Run Keyword If $type normal 填充普通用户数据 ${user} ... ELSE IF $type vip 填充VIP用户数据 ${user} ... ELSE IF $type admin 填充管理员数据 ${user} [Return] ${user} *** Test Cases *** VIP功能测试 [Setup] ${test_user} 用户数据工厂 vip 登录并验证VIP权限 ${test_user} [Teardown] 删除测试用户 ${test_user}37. 分布式测试支持在分布式测试环境中Setup/Teardown需要特别考虑*** Settings *** Suite Setup 注册测试节点 ${NODE_ID} Suite Teardown 上报测试结果 ${NODE_ID} *** Keywords *** 节点初始化 [Arguments] ${role} Run Keyword If $role master 启动控制中心 ... ELSE IF $role worker 连接控制中心38. 测试用例依赖管理虽然RobotFramework官方不建议用例依赖但可以通过Setup/Teardown实现*** Test Cases *** 用户注册测试 [Setup] 确保注册功能可用 执行注册流程 [Teardown] 记录注册测试状态 用户登录测试 [Setup] 确保存在测试用户 执行登录流程 [Teardown] 清理登录状态39. 测试结果增强在Teardown中丰富测试结果信息*** Keywords *** 增强结果记录 ${screenshot} 捕获屏幕截图 ${logs} 获取系统日志 附加测试证据 ${screenshot} ${logs} *** Test Cases *** 界面渲染测试 [Teardown] Run Keywords ... 验证渲染结果 AND ... 增强结果记录40. 终极实战电商系统测试案例综合运用各层级Setup/Teardown的真实电商测试案例电商测试/ ├── __init__.robot # 初始化支付网关创建测试店铺 ├── 商品模块/ │ ├── __init__.robot # 加载商品类目设置货币汇率 │ ├── test_上架.robot # 测试商品CRUD │ └── test_搜索.robot # 测试搜索功能 └── 订单模块/ ├── __init__.robot # 配置物流渠道设置税费规则 ├── test_创建订单.robot # 测试下单流程 └── test_支付.robot # 测试支付流程典型测试文件结构*** Settings *** Suite Setup 初始化订单系统 Suite Teardown 清理订单数据 Test Setup 生成测试用户 Test Teardown 归档测试订单 *** Test Cases *** 信用卡支付测试 [Setup] 绑定测试信用卡 执行支付流程 credit_card [Teardown] 解绑支付方式 优惠券支付测试 [Setup] 发放测试优惠券 执行支付流程 coupon [Teardown] 回收未用优惠券执行这样的测试架构不仅保证了测试的独立性和可重复性还能清晰看到各层级的初始化和清理过程。当某个模块测试失败时可以快速定位是初始化问题、测试本身问题还是清理环节的问题。