企业官网建设流程全解析

做测试自动化这几年，我见过太多人一上来就抱着pytest写脚本，把测试用例活活写成了代码，到最后接口变了、页面变了，代码改了又改，维护成本高得吓人。后来接触了机器人框架，也就是Robot Framework，这种关键字驱动的框架，反而在团队协作和用例可读性上给了我很大的帮助。这篇博客不是教科书，是我在实际实施机器人框架测试自动化过程中的经验和踩坑记录。如果你是第一次接触Robot Framework，或者已经在用但总感觉不得要领，这篇文章能帮你把基础打扎实。它是什么？一个开源、通用的自动化测试框架；能做什么？Web、接口、移动端、数据库等领域的自动化测试都能做；适合谁？想降低自动化测试门槛、让业务同事也能参与脚本维护的团队。

为什么我会说机器人框架比纯pytest脚本更适合某些场景？因为它把“操作步骤”和“测试逻辑”彻底分开了。你写的用例是一张表格，每一行是一个动作、一个断言，哪怕是完全不熟悉代码的测试人员，也能一字一句地读出来“打开浏览器，输入框内填账号，点击登录按钮，验证提示文字”。这种可读性是天然带来的，不是靠注释和规范硬撑出来的。这篇文章我会从框架选型、环境搭建、项目结构、真实用例、问题排查这几个方面，把机器人框架测试自动化的第一课讲透。

1. 从Pytest、Selenium到Robot Framework：为什么我需要“机器人框架”

1.1 Robot Framework的本质：关键字驱动

很多人第一次听到“机器人框架”都会以为是什么硬件机器人，实际上它是一套纯软件层面的自动化测试框架，本名Robot Framework。它的核心思想是“关键字驱动”：测试用例不再是一个个函数调用，而是通过关键字来组织。关键字是什么？可以简单理解成一个动作单元，比如“打开浏览器”“输入用户名”“点击登录”都可以是一个关键字。这些关键字背后可能是一个Python函数，又或者是其他底层库封装出来的能力。

这种设计带来的最大好处，就是测试用例的抽象层次提高了。你在用例里写的不是driver.find_element(By.ID, "username").send_keys("admin")，而是Input Text id=username admin。一眼就能看出来这段用例在做什么。机器人框架自带大量内置关键字，比如Log、Should Be Equal、Run Keyword If，同时还可以通过导入外部库扩展关键字，比如SeleniumLibrary、RequestsLibrary、AppiumLibrary。所以它不是一个只能做Web自动化的玩具，而是一个能在多个测试领域复用的通用框架。

我经常拿它跟pytest做对比。pytest是代码优先的框架，断言、fixture、参数化都靠写Python代码实现，灵活性极高，但学习曲线也高，而且代码写多了之后，用例的可读性完全取决于写代码的人。Robot Framework则是表格驱动，用例本身就像一张需求说明，稍微培训一下业务人员也能看懂甚至参与维护。注意，我这里不是说Robot Framework比pytest更好，而是它有完全不同的使用场景。如果你跟我一样，团队里有不少不懂代码的同事，或者你要在多个项目间快速复制自动化能力，机器人框架会舒服很多。

1.2 与Pytest、Selenium、Appium的关系

这里必须把概念理清楚，因为我在面试里问过的人十个有九个会搞混。Robot Framework和pytest属于同一个层级，都是测试框架，负责组织和执行测试用例。而Selenium、Appium属于更底层的自动化工具，它们负责驱动浏览器、App去做实际操作。机器人框架本身不具备直接驱动浏览器的能力，它要靠导入SeleniumLibrary来封装Selenium WebDriver。也就是说Robot Framework + SeleniumLibrary才等于“Web自动化测试框架完整体”。

同样的，接口自动化方面，Robot Framework本身没有发HTTP请求的能力，需要导入RequestsLibrary，而RequestsLibrary底层用的就是Python界大名鼎鼎的Requests库。移动端自动化则需要导入AppiumLibrary，它的能力封装自Appium。所以热词里那些selenium自动化测试框架、appium自动化测试、接口自动化测试框架，并不是机器人框架的替代品，而是它下面的“零件”。理解了这个关系，你以后看任何自称“机器人框架自动化”的项目，一眼就能看穿它用了什么底层技术。

1.3 选型背后的实际考量

我选机器人框架的时候，想得很清楚，不是为了追新，而是因为三个实实在在的原因。

第一，可读性。我们团队有一个业务测试工程师，他对Python一窍不通，但看我写了两天机器人用例之后，居然能自己照葫芦画瓢改测试数据。换成pytest，他连def test_login(self)缩进问题都搞不定。第二，可扩展性。机器框架自带十几个标准库，覆盖文件、字符串、操作系统、日期时间等常见操作，不够用还能用Python写自定义关键字库，扩展边界跟pytest一样宽。第三，报告能力。机器人框架默认就会输出漂亮的HTML报告和日志，不需要再额外接Allure或者自己写报告脚本，对于需要定期交付报告的团队来说省了很大的事。

当然缺点也明显。如果你写的关键字比较多，出了问题调试起来没有pytest那么直接，毕竟中间隔了一层语法。而且Robot Framework在写复杂循环、复杂字符串处理时，那种表格语法会显得很笨拙。所以我现在的工作流是：简单场景直接机器人框架，复杂数据逻辑用Python自定义库，必要时混用pytest跑回调。后面我会细说怎么混。

2. 环境准备与第一个机器人测试用例

2.1 安装环境：从0到能用，其实只有三步

很多新手卡在环境安装上，其实真的不难。我以Windows为例，Mac和Linux基本一样。首先确保你已经安装了Python 3.9以上版本，并勾选了Add Python to PATH。然后在命令行执行：

pip install robotframework

装完后验证一下：

robot --version

能输出版本号就说明框架本体装好了。接着，你还需要根据自己要做的测试类型装扩展库。我通常一次性把常用库装齐：

pip install robotframework-seleniumlibrary pip install robotframework-requestslibrary pip install robotframework-appiumlibrary

这里有个坑：SeleniumLibrary的版本需要和底层的selenium版本匹配，所以我习惯直接装robotframework-seleniumlibrary，它会自动拉取对应的Selenium版本。装完之后，用pip show robotframework-seleniumlibrary看版本。如果后面运行用例时报类似“cannot import name xxx”的错，大概率是selenium和seleniumlibrary版本冲突，这时候可以重新升级或降级。

2.2 项目目录结构设计

项目一开始就乱，后面一定会痛苦。我推荐一个非常经典的结构：

RobotProject/ ├── tests/ │ ├── web_login.robot │ └── api_login.robot ├── resources/ │ ├── common_keywords.robot │ └── variables.robot ├── results/ └── config/ └── config.py

tests放测试套件，resources放公共关键字和变量，results放输出报告，config放环境配置。当你用例多了以后，还可以在tests下按模块分子目录。这个结构的核心是分层：用例层、资源层、配置层。用例层只写场景步骤，资源层放复用关键字，配置层管环境变量。这样改一个IP地址，不用去几十个用例里翻。

如果团队用的是Git管理，我建议把results目录加进.gitignore。跑步一次自动化就会生成一堆output.xml、log.html、report.html，这些文件体积不小，而且每次都会变，没必要提交到版本库。评测报告和日志另存到公共路径即可。

2.3 第一个用例：用内置关键字跑起来

我们拿一个不依赖任何外部库的简单用例，先把流程走通。在一个.robot文件里，分四个区：Settings、Variables、Test Cases、Keywords。下面是最小可运行的例子：

*** Settings *** Documentation 这是一个简单的测试示例 *** Variables *** ${GREETING} Hello Robot Framework *** Test Cases *** 第一个测试用例 Log ${GREETING} Should Be Equal ${GREETING} Hello Robot Framework

*** Settings ***里可以导入库、引入资源文件、设置套件级别的参数。*** Variables ***定义变量，${GREETING}就是变量。*** Test Cases ***下面写用例。每个用例由若干关键字组成。上面的用例做的事情是：记录日志，断言变量等于预期字符串。

运行方式很简单，在这个目录下执行：

robot tests/demo.robot

跑完在results目录下会生成log.html、report.html、output.xml。直接用浏览器打开log.html，能看到每一步关键字的执行时间、状态、参数。这是机器人框架最让我满意的地方：不用装任何插件，天生就有高可读性的测试报告。

运行的时候，你会在控制台看到类似“1 test, 1 passed”的输出。如果失败，还会显示实际值和期望值。从这里就能感受到，这种看似简单的关键字组合，已经把断言、日志、报告全包了。

3. 实操：Web自动化与接口自动化的完整落地

3.1 用SeleniumLibrary跑通浏览器登录场景

在resources里放一个公共资源文件，比如common_keywords.robot，里面写一些复用关键字：

*** Settings *** Library SeleniumLibrary *** Keywords *** 打开登录页面 [Arguments] ${url} Open Browser ${url} chrome Maximize Browser Window 输入登录信息 [Arguments] ${username} ${password} Input Text id=user ${username} Input Text id=pass ${password} Click Element id=login_btn

这里要注意，Open Browser的第二个参数是浏览器类型。chrome需要先下载对应版本的ChromeDriver，并且保证chromedriver在PATH里。我每次新弄环境都会忘记这一步，其实可以加一行：

set chromedriver所在的目录加到环境变量PATH中

或者直接在Open Browser时指定executable_path参数，但我更推荐用自动方式：pip install webdriver-manager，然后结合它写一个Python自定义库来启动浏览器。这个后面再说。

测试用例部分，我习惯把测试数据和操作步骤分开。在tests/web_login.robot中这样写：

*** Settings *** Library SeleniumLibrary Resource ../resources/common_keywords.robot *** Variables *** ${URL} http://example.com/login ${USERNAME} admin ${PASSWORD} 123456 *** Test Cases *** 登录成功校验提示 打开登录页面 ${URL} 输入登录信息 ${USERNAME} ${PASSWORD} Wait Until Page Contains 欢迎回来 [Teardown] Close Browser

这里几乎每一行都是大白话。特别是Wait Until Page Contains，它自带隐式轮询和超时机制，可以避免页面刚加载完元素还没出现的坑。我强烈建议登录类用例至少加一个等待关键字，不要登录完直接断言，页面渲染不及时的话断言很脆弱。

3.2 用RequestsLibrary验证接口自动化

接口自动化部分，我优先会导入RequestsLibrary。看一个简单例子：

*** Settings *** Library RequestsLibrary *** Variables *** ${API_URL} http://example.com/api/v1/login *** Test Cases *** 登录接口返回token Create Session login ${API_URL} ${headers}= Create Dictionary Content-Type=application/json ${payload}= Create Dictionary username=admin password=123456 POST Request login / json=${payload} headers=${headers}

这个用例只是发了一个POST请求，但没有断言。所以还需要从响应里拿数据。RequestsLibrary的POST关键字返回的是Response对象，可以用${response.status_code}、${response.json()}访问。不过${response.json()}在机器人语法里直接取会有坑，我喜欢先Evaluate转成Python对象：

*** Test Cases *** 登录接口返回token Create Session login ${API_URL} ${resp}= POST Request login / json=${payload} Should Be Equal As Strings ${resp.status_code} 200 ${body}= Evaluate ${resp.json()} requests.Response Should Not Be Empty ${body['token']} token不能为空

注意Evaluate的第二个参数，告诉机器人框架要计算的Python表达式，第三个参数可以传入模块。这里requests.Response其实并不需要传，更稳妥的做法是直接${resp.text}再用Evaluate转字典：

${json}= Evaluate json.loads('''${resp.text}''') json

这样写有几个好处，一个是避免了机器人框架在解析JSON字符串时的转义问题，另一个是可以在json模块下做各种断言。接口自动化最关键的还是要学会从灵活的数据解析中拿到自己想要的字段，尤其是嵌套结构。我经常把复杂数据的提取写到自定义关键字里，比如“从响应中提取某某字段”和“断言返回结果数量”，这样用例会更干净。

3.3 报告生成与并行执行

机器人框架默认跑完后会在你指定的--outputdir目录生成三个文件。log.html是详细日志，按时间轴展示每一步关键字的细节；report.html是汇总报告，展示通过率、耗时和失败概览；output.xml是机器可读的结果，可以给CI系统用。命令行里这样指定：

robot --outputdir results tests/

如果用例多，跑得慢，可以用pabot做并行执行，安装命令：

pip install robotframework-pabot

然后：

pabot --processes 4 --outputdir results tests/

它可以同时跑多个套件，会自动合并output.xml到report和log。这里有个经验：不要把同一个套件内部的用例并行跑，因为有些用例会操作同一个浏览器实例，并行反而出问题。pabot是按文件分配的，所以为了提高并行效率，尽量保证套件之间互不依赖。

3.4 Appium集成和环境准备

移动端自动化方面，机器人框架可以通过AppiumLibrary扩展。核心配置是Open Application关键字，传入desired capabilities：

*** Settings *** Library AppiumLibrary *** Test Cases *** 打开商城App首页 Open Application http://localhost:4723/wd/hub ... platformName=Android ... deviceName=emulator-5554 ... appPackage=com.shop.app ... appActivity=.MainActivity

注意Appium版本不同，连接URL可能也不同。我实测的坑有两个：一是deviceName必须跟adb devices里显示的一致，不能随便乱写；二是新版的Appium 2.x不再支持remote URL里的/wd/hub后缀，需要用http://localhost:4723/，差一个路径就会导致连接失败。如果你也遇到“Could not start appium”之类的报错，先检查这两点，往往比网上到处找其他方法有效。

4. 常见问题与排查技巧实录

4.1 “Keyword 'xxx' not found” 到底是谁的锅

这是机器人框架新手最常遇到的报错。报错信息会明确告诉你找不到哪个关键字。我总结下来背后原因有三类。第一，库没有导入。比如你用Open Browser但没有在*** Settings ***里Library SeleniumLibrary，那当然找不到了。第二，库名或关键字名拼写错了。机器人框架的大小写敏感度有点微妙，关键字名不区分大小写，但Library名称是区分大小写的。seleniumlibrary和SeleniumLibrary就不一样。第三，自定义关键字定义在别的资源文件里，但你没有Resource引入。如果真是最后一种，我建议在Settings里加上Resource ../resources/xxx.robot，相对路径以当前文件所在目录为准，很容易搞混，更多时候我会用${EXECDIR}变量拼绝对路径。

我自己检查的顺序是：先看Settings里有没有正确导入，再看库有没有装到当前Python解释器环境，最后再用robot --help跑一下看是否有语法错误。曾经有一次我在项目里同时开着多个Python环境，pip装在了A环境，Robot跑在B环境，于是怎么都找不到库，后来才醒悟过来：检查pip列表时，务必确保和运行robot命令的是同一个Python环境。

4.2 元素定位失败和等待策略

Web自动化最气人的就是“明明登录按钮就在那里，可脚本就是点不到”。定位失败的原因五花八门，最常见的是iframe内嵌。SeleniumLibrary处理iframe时要先Select Frame再操作，操作完Unselect Frame，不然就找不到里面的元素。另一个是元素被遮挡，最常见的是弹窗和动态浮层。这时候用Click Element可能点击无效，我有时会改用Click Element At Coordinates，但治标不治本。更好的办法是加显式等待：Wait Until Element Is Visible或者Wait Until Element Is Enabled，等到元素真正可交互了再操作。

还有一个容易被忽略的问题：元素定位器写得太死。比如id=user这个id，前端如果一换版本改成了id=username，你的用例就废了。我现在的习惯是在资源文件里把所有定位器抽成变量：

*** Variables *** ${LOGIN_USER_INPUT} id=user ${LOGIN_PASS_INPUT} id=pass ${LOGIN_BTN} xpath=//button[@type='submit']

修改的时候只要改这一处，测试套件几乎不用动。页面结构经常变的项目，这种集中管理定位器的方式能省下大量时间。

4.3 测试数据清理与状态隔离

自动化用例最怕相互污染。假如一个用例注册了用户“test01”，另一个用例预期这个用户不存在，结果先跑了注册用例，后面就失败了。所以我给团队的规矩非常简单：每个用例必须有Test Setup和Test Teardown，在Setup里创建独立数据，在Teardown里清理这些数据。

机器人框架的Teardown可以是关键字，也可以直接调用Python脚本。举个例子：

*** Test Cases *** 注册新用户 [Setup] 准备测试数据 ... [Teardown] 清理测试数据 *** Keywords *** 准备测试数据 Create Session api ${API_URL} # 在数据库里插入一条记录 清理测试数据 # 删除这条记录

这里注意，Teardown即使用例失败也会执行，所以清理逻辑一定要写，不能偷懒。我曾经见过很多人图省事不写Teardown，最后被脏数据折磨得腰酸背痛。

另外，并行执行时尤其要注意数据库唯一索引。如果两个并行任务同时插入同一用户名，就会有一个失败。我用过一个小技巧：在数据末尾加随机后缀，变量格式为user_${TEST_RUN_ID}，然后在Setup里生成随机数。机器人框架自带Generate Random String关键字，可以生成随机串，拼到数据后面，这样并行也就互不干扰了。

4.4 调试技巧：别只盯着log.html

机器人框架提供了比较高效的调试方法。小问题可以直接在用例里加Log Many一口气打印多个变量，大问题我会在运行命令时加上--loglevel DEBUG，这样在执行日志里能看到关键字底层调用的更多细节。如果开启DEBUG还不够，还有一个杀手锏：安装robotframework-debuglibrary，然后在用例里加一个Debug关键字，跑到那里就会开启交互式调试终端，你可以直接输入Python表达式或者关键字名，看看当前环境里到底是什么状态。这个库帮我解决过好几次棘手问题，强烈推荐。

不过我自己最常用的调试工具反而是把results/output.xml用文本编辑器打开。它对格式友好，每个关键字调用都记录了起止时间和参数。如果某个用例在一台机器上过、一台机器上挂，直接对比两个output.xml，往往是环境差异而不是用例逻辑问题。

4.5 常见问题速查表

这张表是我在带新人时最常用的一张内部速查表。每次遇到问题，先对照现象找到排查方向，不要上来就改用例。

结尾部分，说说我实践下来的体会。刚开始我把机器人框架当成一个写脚本的工具，用着用着发现它真正的价值是“用例即文档”。团队里除了自动化工程师，业务分析师、项目经理也都愿意打开log.html看执行结果。后来我又做了一套公共关键字库，把登录、下单、数据准备这些高频操作封装成类似“登录系统”“创建订单”这样的业务关键字，业务同事甚至可以自己拖拽组成新用例。这才是机器人框架测试自动化最值得投入的地方：不是去替换所有人手写脚本，而是把测试知识沉淀成语义清晰的关键字积木。第一篇先写到这，后面我再接着聊如何自定义Python库和持续集成。

（未完待续）