Appium与Robot Framework集成CI：打造移动应用自动化测试流水线-开发者社区

1. 项目概述：为什么需要将Appium与Robot Framework集成到CI中？

在移动应用开发迭代越来越快的今天，我见过太多团队被重复、繁琐的手工回归测试拖慢了节奏。每次发版前，测试同学抱着好几台手机，一遍遍地点着相同的功能，不仅效率低下，还容易因为人为疲劳导致漏测。自动化测试是解决这个问题的必然选择，而Appium作为跨平台的移动端自动化测试框架，加上Robot Framework这款以关键字驱动、易读易维护的测试框架，构成了一个强大的组合拳。

但这个组合拳如果只停留在本地运行，价值就大打折扣了。想象一下，开发同学深夜提交了一版代码，你第二天早上来了才发现自动化脚本跑挂了，还得花时间去定位是环境问题、脚本问题还是真的引入了Bug。这个过程存在严重的反馈延迟。持续集成（CI）的核心思想，正是要将这种反馈周期压缩到最短。我们的目标，就是打造一个“无人值守”的自动化质量守护者：每当有新的代码提交，CI系统（比如Jenkins）就自动拉取代码、构建应用、部署到测试环境（或真机/模拟器），然后触发我们写好的Appium+Robot Framework测试套件，最后将清晰的测试报告推送给团队。这样，问题在引入后几分钟内就能暴露出来，修复成本最低。

所以，这个项目标题“Appium与Robot Framework结合的移动应用自动化测试持续集成脚本”，本质上是在构建一套端到端的自动化测试流水线。它不仅仅是写几个脚本，而是涉及环境搭建、框架集成、脚本设计、CI配置和报告反馈等多个环节的系统工程。接下来，我会结合我多次搭建这类系统的经验，拆解其中的核心环节、分享实操细节和那些容易踩坑的地方。

2. 技术栈选型与整体架构设计

在动手写脚本之前，我们先得把“用什么”和“怎么搭”想清楚。这里的选择直接决定了后续脚本的复杂度、维护成本和稳定性。

2.1 核心组件深度解析

Appium：它不是一个单独的“工具”，而是一个遵循WebDriver协议的C/S架构服务器。它的强大在于“一次编写，多端运行”（iOS & Android）。Appium Server负责接收来自客户端（我们的测试脚本）的HTTP请求，并将其翻译成对应平台（XCUITest for iOS, UiAutomator2/Espresso for Android）的原生指令来操作设备。选择Appium，就意味着我们不用分别去学习iOS和Android两套完全不同的自动化工具链。

Robot Framework：这是一个基于Python的、高度可扩展的通用自动化框架。它的灵魂在于“关键字驱动”和“表格化语法”。你可以把“点击登录按钮”、“输入用户名”这样的操作封装成一个关键字，然后在测试用例里像写自然语言一样去调用它们。它的测试用例文件（.robot）结构清晰，非技术人员（如产品经理、业务分析师）也能看懂大概逻辑，这极大地提升了测试资产的可维护性和团队协作效率。它内置了丰富的库（如SeleniumLibrary用于Web，AppiumLibrary就是我们要用的），也支持你用Python或Java轻松创建自定义库。

持续集成服务器（以Jenkins为例）：Jenkins是这个流水线的大脑和调度中心。它负责监听代码仓库（如Git）的变更，触发一系列预定义的任务（Job）。在我们的场景里，这个任务就是执行自动化测试。Jenkins的强大在于其庞大的插件生态，比如我们可以用Robot Framework plugin来漂亮地展示测试报告，用Email Extension Plugin来发送带详细结果的邮件。

2.2 系统架构设计图（逻辑层面）

整个系统的运行流程可以概括为以下步骤，这构成了我们脚本设计的蓝图：

触发阶段：开发人员向Git仓库的特定分支（如develop）推送代码。
构建与准备阶段：Jenkins被触发，拉取最新代码，执行构建命令（例如，对于Android是./gradlew assembleDebug，生成APK文件）。
环境部署阶段：Jenkins将构建好的APK/IPA文件安装到已连接的测试设备或模拟器/仿真器上。同时，确保Appium Server已经启动并监听着。
测试执行阶段：Jenkins调用命令行，执行Robot Framework测试套件。RF脚本通过AppiumLibrary与Appium Server通信，进而驱动手机应用完成测试。
结果收集与反馈阶段：测试执行完毕，生成XML格式的输出文件（output.xml）和日志报告（log.html, report.html）。Jenkins收集这些文件，通过插件将其可视化，并通过邮件、钉钉、Slack等渠道将结果通知给相关人员。

注意：这里有一个关键决策点——测试设备的管理。对于团队，我强烈建议使用云真机平台或自建的设备农场（Selenium Grid for Mobile）。让Jenkins任务从设备池中动态申请一台空闲设备来执行测试，这能解决“谁占用了测试机”的冲突问题，也是实现真正并行测试和持续集成的基石。如果资源有限，至少也要为CI任务专用一两台稳定的设备或模拟器。

3. 环境搭建与核心配置实操

这一部分是基石，环境没搭好，一切脚本都是空中楼阁。我会按照从底层到上层的顺序来讲解。

3.1 基础环境准备（以macOS/Linux为例）

首先，我们需要安装所有必要的运行时和依赖。

1. 安装Node.js与AppiumAppium Server是基于Node.js的，所以首先需要安装Node.js（建议使用LTS版本）。我习惯用nvm来管理Node版本，这样可以灵活切换。

# 安装nvm（如果尚未安装） curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 重新加载shell配置，或打开新终端 source ~/.bashrc # 或 ~/.zshrc # 安装Node.js LTS版本 nvm install --lts nvm use --lts # 通过npm安装Appium（全局安装） npm install -g appium # 安装Appium Doctor，用于检查环境是否完整 npm install -g appium-doctor # 检查环境（重点关注Android或iOS部分） appium-doctor --android # 或 appium-doctor --ios

2. 安装Python与Robot FrameworkRobot Framework是Python写的，相关库也都是Python包。

# 确保已安装Python3（建议3.7+） python3 --version # 使用pip安装Robot Framework核心及必要库 pip install robotframework # 安装AppiumLibrary，这是RF与Appium通信的桥梁 pip install robotframework-appiumlibrary # 安装其他有用的扩展库，如用于处理HTTP请求的RequestsLibrary pip install robotframework-requests pip install robotframework-databaselibrary # 如果需要操作数据库

3. 移动端SDK配置（以Android为例）这是最繁琐但也最重要的一步。你需要配置ANDROID_HOME环境变量，并且确保platform-tools和emulator等工具在系统PATH中。

下载Android Studio：从中安装Android SDK。

配置环境变量：在你的shell配置文件（如~/.bashrc或~/.zshrc）中添加：

export ANDROID_HOME=$HOME/Library/Android/sdk # macOS路径示例，Linux/Windows请对应修改 export PATH=$PATH:$ANDROID_HOME/emulator export PATH=$PATH:$ANDROID_HOME/platform-tools export PATH=$PATH:$ANDROID_HOME/tools/bin

创建并启动模拟器：可以通过Android Studio的AVD Manager创建，也可以用命令行：
```
# 列出所有可用的系统镜像 avdmanager list avd # 启动名为`Pixel_4_API_30`的模拟器 emulator -avd Pixel_4_API_30 -no-snapshot-load &
```
实操心得：为了CI的稳定性，建议使用无界面（headless）模式启动模拟器，并禁用动画，可以加速启动和执行。命令如：emulator -avd Pixel_4_API_30 -no-window -no-boot-anim -no-audio &。同时，务必在CI任务开始时检查模拟器是否已完全启动（adb shell getprop sys.boot_completed返回1），再执行测试。

3.2 编写你的第一个Robot Framework测试脚本

环境准备好后，我们来创建一个最简单的测试用例，验证整个链路是否通畅。

项目目录结构建议：

my-automation-project/ ├── resources/ │ ├── common_keywords.robot # 公共自定义关键字 │ └── app_variables.py # 应用相关变量，如包名、活动名 ├── testcases/ │ └── smoke_test/ │ └── login_test.robot # 具体的测试用例文件 ├── results/ # 存放测试输出（应在.gitignore中） └── run_tests.sh # 本地执行脚本

一个最基础的测试脚本示例 (testcases/smoke_test/login_test.robot):

*** Settings *** Documentation 简单的登录功能冒烟测试 Library AppiumLibrary Suite Setup Open Test Application Suite Teardown Close Application *** Variables *** # 这里可以引用外部变量文件，便于CI时动态替换 ${APPIUM_SERVER_URL} http://localhost:4723/wd/hub ${PLATFORM_NAME} Android ${PLATFORM_VERSION} 11.0 ${DEVICE_NAME} emulator-5554 ${APP_PACKAGE} com.example.myapp ${APP_ACTIVITY} com.example.myapp.MainActivity *** Keywords *** Open Test Application Open Application ${APPIUM_SERVER_URL} ... platformName=${PLATFORM_NAME} ... platformVersion=${PLATFORM_VERSION} ... deviceName=${DEVICE_NAME} ... automationName=UiAutomator2 ... appPackage=${APP_PACKAGE} ... appActivity=${APP_ACTIVITY} ... noReset=true # 不清空应用数据，根据测试需求调整 *** Test Cases *** User Should Be Able To Login With Valid Credentials [Documentation] 使用有效凭证登录成功 # 假设应用已打开，在登录页面 Input Text id=com.example.myapp:id/username_field testuser Input Text id=com.example.myapp:id/password_field Pass1234 Click Element id=com.example.myapp:id/login_button # 验证登录后页面元素出现 Wait Until Page Contains Element id=com.example.myapp:id/welcome_message timeout=10s Element Text Should Be id=com.example.myapp:id/welcome_message Welcome, testuser! Login Should Fail With Invalid Password [Documentation] 使用错误密码登录应失败 Input Text id=com.example.myapp:id/username_field testuser Input Text id=com.example.myapp:id/password_field wrongpass Click Element id=com.example.myapp:id/login_button # 验证错误提示信息 Wait Until Page Contains Element id=com.example.myapp:id/error_toast timeout=5s Page Should Contain Text Invalid credentials

本地执行测试：确保Appium Server已启动（在终端运行appium），并且模拟器/真机已连接（adb devices可看到设备）。

cd my-automation-project # 使用robot命令执行测试套件，并指定输出目录 robot --outputdir results/ testcases/smoke_test/

执行后，在results/目录下会生成report.html和log.html，用浏览器打开即可查看详尽的测试报告和日志。

4. 构建健壮且可维护的测试脚本工程

直接在上面写用例会很快遇到维护问题。我们需要良好的工程结构、数据驱动和自定义关键字来提升脚本质量。

4.1 使用Resource文件与变量分离

将设备和应用的配置从测试用例中分离出来，是适应CI环境的关键。因为CI服务器上的设备信息、应用路径很可能与本地不同。

1. 创建资源文件 (resources/common.robot):

*** Settings *** Library AppiumLibrary Library Collections *** Variables *** # 这些变量可以被外部覆盖，例如通过命令行参数 ${APPIUM_SERVER} http://localhost:4723/wd/hub ${APP_PATH} ${CURDIR}${/}..${/}..${/}app${/}myapp-debug.apk # 设备配置通过命令行传入，此处给默认值 ${DEVICE_CONFIG} platformName=Android,platformVersion=11,deviceName=emulator-5554,automationName=UiAutomator2

2. 创建Python变量文件 (resources/config.py):更灵活的方式是使用Python文件，可以利用Python的逻辑处理能力。

import os # 基础配置 APPIUM_SERVER = os.getenv('APPIUM_SERVER_URL', 'http://localhost:4723/wd/hub') # 设备配置 - 可以从环境变量读取，CI/CD时动态注入 DEVICE_CONFIG = { 'platformName': os.getenv('PLATFORM_NAME', 'Android'), 'platformVersion': os.getenv('PLATFORM_VERSION', '11.0'), 'deviceName': os.getenv('DEVICE_NAME', 'emulator-5554'), 'automationName': 'UiAutomator2', 'app': os.getenv('APP_PATH', '/path/to/your/app.apk'), # 或者用appPackage/appActivity 'noReset': True, 'newCommandTimeout': 300, }

3. 在测试用例中引用 (testcases/login.robot):

*** Settings *** Resource ../resources/common.robot Variables ../resources/config.py Suite Setup Open Application With Config Suite Teardown Close Application *** Keywords *** Open Application With Config # 将Python字典转换为RF可用的参数 &{config}= Create Dictionary &{DEVICE_CONFIG} Open Application ${APPIUM_SERVER} &{config}

4.2 实现数据驱动测试

数据驱动测试（DDT）能将测试逻辑与测试数据分离，用同一套脚本验证多组数据，极大减少脚本数量。

Robot Framework原生支持通过[Template]标签实现数据驱动。但我更推荐使用DataDriver这个外部库，它更强大直观。

pip install robotframework-datadriver

创建数据文件 (data/login_data.csv):

test_case,username,password,expected_result Valid Login,testuser,Pass1234,SUCCESS Invalid Password,testuser,wrongpass,ERROR: Invalid credentials Empty Username,,somepass,ERROR: Username required

编写数据驱动测试用例 (testcases/ddt_login.robot):

*** Settings *** Library AppiumLibrary Library DataDriver file=data/login_data.csv encoding=utf-8 Test Setup Open App To Login Page Test Teardown Close Application Test Template Validate Login Scenario *** Keywords *** Open App To Login Page # ... 打开应用并跳转到登录页的代码 ... Open Application ... # 配置信息 # 假设有操作能确保进入登录页 Validate Login Scenario [Arguments] ${username} ${password} ${expected_result} Input Text id=username_field ${username} Input Text id=password_field ${password} Click Element id=login_button Run Keyword If '${expected_result}' == 'SUCCESS' ... Run Keywords ... Wait Until Page Contains Element id=welcome timeout=10s ... AND ... Log Login Success ... ELSE ... Wait Until Page Contains Element id=error_msg timeout=5s ... Element Should Contain Text id=error_msg ${expected_result} *** Test Cases *** Login Test with CSV Data ${username} ${password} ${expected_result} # 这个测试用例会基于CSV文件的每一行数据，自动执行多次

4.3 封装强大的自定义关键字

当内置关键字和库的关键字不够用时，或者你想把复杂的操作序列封装成一个有业务含义的步骤时，就需要自定义关键字。这是提升脚本可读性和维护性的核心。

在Python中创建自定义库 (libraries/AppCustomKeywords.py):

from robot.api.deco import keyword from AppiumLibrary import AppiumLibrary # 假设你已经有了一个AppiumLibrary的实例，可以通过混合类的方式扩展 # 更常见的做法是创建一个独立的关键字类 class AppCustomKeywords: ROBOT_LIBRARY_SCOPE = 'GLOBAL' # 库的作用域，GLOBAL表示全局单例 def __init__(self): self.appium_lib = AppiumLibrary() # 内部使用AppiumLibrary @keyword def login_with_credentials(self, username, password): """封装登录流程""" self.appium_lib.input_text('id=username_field', username) self.appium_lib.input_text('id=password_field', password) self.appium_lib.click_element('id=login_button') # 可以在这里添加一些等待和验证，使关键字更健壮 self.appium_lib.wait_until_page_contains_element('id=welcome_screen', timeout=10) @keyword def take_screenshot_and_embed_to_log(self, name_prefix='screenshot'): """截屏并嵌入到Robot Framework的日志中。这在CI中排查问题时非常有用。""" import datetime filename = f"{name_prefix}_{datetime.datetime.now().strftime('%H%M%S')}.png" # 获取当前工作目录下的screenshots文件夹路径 path = os.path.join(os.getcwd(), 'screenshots', filename) self.appium_lib.capture_page_screenshot(path) # 使用robot的BuiltIn库将图片嵌入日志 from robot.libraries.BuiltIn import BuiltIn BuiltIn().log(f'<img src="{path}" width="800px">', html=True)

在Robot脚本中使用自定义关键字：

*** Settings *** Library ../libraries/AppCustomKeywords.py *** Test Cases *** Example Using Custom Keyword Login With Credentials john.doe mySecretPassword Take Screenshot And Embed To Log login_success

5. 集成到Jenkins：打造自动化流水线

本地脚本跑通了，现在要把它们放到Jenkins上，实现自动化触发。

5.1 Jenkins任务配置详解

新建一个自由风格的软件项目。
源码管理：配置你的Git仓库地址和凭证，指定要监听的分支（如*/develop）。
构建触发器：选择Poll SCM（轮询SCM），日程表填H/5 * * * *表示每5分钟检查一次是否有变更。更佳实践是使用GitHub Webhook或GitLab Webhook，实现代码一推送就立即触发。
构建环境：可以勾选“Provide Node & npm bin/ folder to PATH”如果你需要在Jenkins上运行Appium。但更常见的做法是，将Appium Server作为一个独立的服务运行在某个机器上（或使用云服务），Jenkins任务只负责执行测试脚本。

构建步骤：这是核心。我们需要添加一系列shell命令。

步骤一：准备环境。确保Python依赖已安装。

pip install -r requirements.txt # 将robotframework, appiumlibrary等写入此文件

步骤二：启动Appium Server（如果需要）。如果Appium Server没作为服务运行，可以在这里后台启动。注意管理进程。

# 后台启动Appium，并记录PID appium --log-level error --session-override > appium.log 2>&1 & APPIUM_PID=$! echo $APPIUM_PID > appium.pid sleep 10 # 等待Appium Server启动完成

步骤三：执行测试。关键是通过命令行参数动态传入配置。

# 使用环境变量或构建参数来覆盖脚本中的变量 robot \ --variable APPIUM_SERVER_URL:${APPIUM_SERVER_URL} \ --variable PLATFORM_NAME:${PLATFORM_NAME} \ --variable DEVICE_NAME:${DEVICE_NAME} \ --variable APP_PATH:${WORKSPACE}/app/build/outputs/apk/debug/app-debug.apk \ --outputdir ${WORKSPACE}/results \ --log report.html \ --report NONE \ testcases/

$WORKSPACE是Jenkins的工作目录。--variable选项用于覆盖Robot脚本中定义的变量。

步骤四：清理。测试结束后，关闭Appium Server。

# 读取并杀死Appium进程 if [ -f appium.pid ]; then kill $(cat appium.pid) 2>/dev/null || true rm -f appium.pid fi

后置构建操作：
- 归档产物：可以归档生成的APK、测试报告等。
- 发布Robot Framework报告：安装“Robot Framework plugin”插件后，在“后置构建操作”中添加“Publish Robot Framework test results”，指定output.xml的路径（如results/output.xml）。这样Jenkins job页面上就会出现一个漂亮的Robot Framework报告标签页。
- 邮件通知：安装“Email Extension Plugin”，配置在构建失败或不稳定时发送邮件，邮件内容可以链接到测试报告。

5.2 使用Jenkins Pipeline (Jenkinsfile)

对于更复杂、可维护性更高的流水线，我强烈推荐使用Jenkinsfile（声明式或脚本式Pipeline）。它将整个CI/CD流程作为代码进行管理。

一个简单的声明式Pipeline示例 (Jenkinsfile):

pipeline { agent any // 指定在任意可用agent上运行 environment { // 定义环境变量，可以从Jenkins凭据或参数中读取 APPIUM_SERVER = credentials('appium-server-url') // 假设你在Jenkins中存储了凭据 DEVICE_NAME = 'emulator-5554' } stages { stage('Checkout') { steps { checkout scm // 拉取代码 } } stage('Install Dependencies') { steps { sh 'pip install -r requirements.txt' } } stage('Start Appium Server') { steps { sh ''' # 这里假设我们使用一个全局运行的Appium服务，所以不需要启动 # 如果需要启动，同上 echo "Assuming Appium Server is running at ${APPIUM_SERVER}" ''' } } stage('Run Robot Tests') { steps { sh """ robot \ --variable APPIUM_SERVER_URL:'${APPIUM_SERVER}' \ --variable DEVICE_NAME:'${DEVICE_NAME}' \ --outputdir ./results \ --log report.html \ --report NONE \ testcases/ """ } post { always { // 无论成功失败，都归档报告 archiveArtifacts artifacts: 'results/**/*', allowEmptyArchive: true // 发布Robot Framework报告 robot outputPath: 'results' } } } } post { always { // 清理工作，如关闭模拟器（如果由本任务启动） sh './scripts/cleanup.sh' } failure { // 构建失败时，可以发送更紧急的通知 emailext ( subject: "FAILED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'", body: "Check console output at ${env.BUILD_URL}", to: 'team@example.com' ) } } }

将Jenkinsfile放在项目根目录，然后在Jenkins中创建一个“Pipeline”类型的任务，并指定从SCM读取Jenkinsfile。这样，流水线的任何修改都将随代码一起被版本控制。

6. 实战中的疑难杂症与优化策略

搭建过程很少一帆风顺，这里分享一些我踩过的坑和解决方案。

6.1 环境与稳定性问题

问题1：Appium Session创建失败，提示“无法创建新会话”或“无法找到设备”。

排查思路：
1. 检查设备连接：在CI服务器上运行adb devices，确认设备列表中有目标设备且状态是device，而不是offline或unauthorized。对于模拟器，确保已完全启动。
2. 检查Appium Server：确认Appium Server正在运行且端口（默认4723）未被占用。查看Appium Server日志，通常会有详细的错误信息。
3. 检查Desired Capabilities：仔细核对platformVersion、deviceName、appPackage/appActivity或app路径是否正确。deviceName对于Android模拟器通常是emulator-5554这类格式，可以通过adb devices获取。
4. 应用安装问题：如果使用app参数，确保路径正确且APK文件有效。有时需要先卸载旧版本：在Desired Capabilities中设置fullReset=true或noReset=false。

问题2：元素定位失败，脚本在CI上不稳定，但在本地稳定。

原因与策略：
1. 并发与状态残留：CI上可能并行执行多个任务，或者之前的测试未完全清理状态。使用noReset=true可以避免每次清理数据，但可能导致状态干扰。根据测试类型选择。对于关键流程，我倾向于使用fullReset=true保证环境干净，但会牺牲执行时间。
2. 等待策略不足：网络、应用响应在CI环境可能更慢。永远不要使用固定的sleep。改用Robot Framework的Wait Until ...系列关键字，并设置合理的超时时间。
3. 元素定位器过于脆弱：优先使用id或accessibility id。如果只能使用XPath，尽量使用相对路径和稳定的属性，避免使用索引（如//android.widget.Button[3]）。可以借助Appium Desktop或浏览器开发者工具来辅助定位。
4. 截图与日志：在关键步骤前后，以及失败时，一定要截图。如前文所示，封装一个自动截图并嵌入日志的关键字，在CI报告中能直接看到失败时的界面，极大提升排查效率。

6.2 性能与效率优化

1. 测试用例设计与选择：

分层测试：不是所有测试都适合加入CI。CI流水线中应该运行冒烟测试（Smoke）和核心功能回归测试。这些用例应该快速（建议整套在10-20分钟内）、稳定、覆盖主干流程。更全面的测试套件可以安排在夜间定时任务中执行。
使用标签（Tag）：在Robot Framework中，可以用[Tags]给测试用例打标签。
```
*** Test Cases *** Critical Login Test [Tags] smoke critical ... # 测试步骤
```
然后在CI脚本中，只运行特定标签的用例：
```
robot --include smoke --outputdir results testcases/
```

2. 并行测试：如果有多台设备或模拟器，可以并行执行测试以缩短反馈时间。Robot Framework本身支持通过pabot进行并行。

pip install robotframework-pabot # 假设有两台设备，device1和device2 pabot \ --processes 2 \ --variablefile device1_config.py \ --variablefile device2_config.py \ --outputdir results \ testcases/

你需要为每个进程准备一个独立的变量文件，指定不同的deviceName和udid。在Jenkins上，你需要确保有足够的Agent或节点来支持并行。

3. 测试数据与状态管理：

为CI准备独立的测试账号和数据，避免与手工测试或其他CI运行冲突。
测试结束后，做好数据清理工作，比如调用后端接口删除测试产生的数据，或者使用数据库回滚技术。

6.3 报告与反馈优化

原始的Robot Framework报告已经很详细，但在团队协作中还可以做得更好。

集成到团队沟通工具：除了邮件，可以将测试结果通过Webhook发送到钉钉、企业微信、Slack等频道。可以写一个简单的Python脚本，解析output.xml或report.html，提取关键信息（通过率、失败用例列表）并格式化发送。
趋势分析：利用Jenkins的插件（如Plot plugin）或外部工具（如Allure），将每次构建的通过率、用例数量、执行时长等指标绘制成趋势图，直观反映自动化测试的健康度和项目质量趋势。

失败重试机制：对于某些因环境偶发问题导致的失败，可以配置重试。Robot Framework可以通过--rerunfailed选项重新运行失败的用例。可以在CI脚本中这样实现：

robot --outputdir first_run --log none --report none testcases/ # 如果第一次运行有失败，重试一次 if [ -f first_run/output.xml ]; then robot --outputdir second_run --rerunfailed first_run/output.xml testcases/ # 合并两次运行的结果 rebot --outputdir final_results --output output.xml --merge first_run/output.xml second_run/output.xml fi

将Appium、Robot Framework和Jenkins（或其他CI工具）串联起来，是一个从“自动化”走向“智能化”质量保障的关键步骤。它意味着质量反馈环的加速和左移。这个过程肯定会遇到各种环境、脚本和流程上的挑战，但每解决一个，团队的交付能力和信心就会增强一分。我的经验是，从小处着手，先让一两个核心用例在CI上稳定跑起来，再逐步扩展范围和完善流程。记住，可持续维护的、稳定的自动化脚本，其价值远大于一堆脆弱的一次性脚本。