1. 项目概述为什么我们需要Flybirds这样的跨端测试方案做UI自动化测试的朋友这几年应该都感受到了一个明显的痛点前端技术栈越来越碎片化。一个产品可能同时有Web官网、iOS App、Android App甚至还有小程序和用Flutter、React Native开发的混合应用。以前我们写自动化脚本往往是针对一个平台写一套比如用Selenium搞Web用Appium搞移动端。结果就是测试团队要维护好几套脚本学习成本高维护成本更高一旦业务逻辑变动所有平台的脚本都得改一遍效率极其低下。Flybirds的出现就是为了解决这个“多端测试”的难题。它不是一个简单的测试工具而是一套基于BDD行为驱动开发模式的、跨端跨框架的UI自动化测试方案。简单来说它的核心思想是用一套接近自然语言的测试用例驱动多端Web、Android、iOS、Flutter、RN的自动化执行。我第一次接触Flybirds是在一个需要同时验证H5页面和原生App登录流程一致性的项目中。传统方式下我得写两套完全不同的脚本一套用Playwright的API操作浏览器一套用Appium的API操作手机。而用Flybirds我只需要用类似“当 我打开登录页”、“那么 我应该看到用户名输入框”这样的句子写好测试场景它就能自动适配到不同的端去执行。这种“写一次跑多处”的体验对于追求研发效能和测试覆盖率的团队来说吸引力是巨大的。它特别适合哪些人呢首先是测试开发工程师和自动化测试工程师尤其是面临多端产品矩阵的团队。其次是前端开发同学如果你想为自己的组件库或业务页面快速搭建一套可读性高的冒烟测试Flybirds的BDD风格会让你和产品、QA的沟通变得非常顺畅。最后对于技术负责人或项目经理引入这样一套方案能显著降低自动化测试的长期维护成本让测试脚本真正成为资产而不是负担。2. 核心设计思路BDD与插件化架构是如何工作的要理解Flybirds为什么能“跨端”必须深入它的两个核心设计BDD范式与插件化架构。这两者结合构成了它区别于传统UI自动化框架的基石。2.1 BDD让测试用例成为沟通语言BDD不是Flybirds的发明但它将BDD的理念在UI自动化领域用到了极致。BDD的核心是用业务领域的通用语言来描述软件行为从而弥合开发、测试、产品等不同角色之间的沟通鸿沟。在Flybirds中这体现为使用Gherkin语法来编写测试用例。Gherkin是一种近乎纯文本的领域特定语言关键字如Given假设、When当、Then那么构成了测试场景的基本结构。# 这是一个Flybirds支持的测试用例文件.feature 功能: 用户登录 场景: 使用正确密码登录成功 假设 我打开应用首页 当 我在“用户名”输入框中输入“testuser” 且 我在“密码”输入框中输入“123456” 且 我点击“登录”按钮 那么 我应该看到文本“欢迎回来testuser”这种写法的好处显而易见可读性极高产品经理、业务方都能看懂测试在验证什么方便评审和确认需求。与代码解耦测试用例.feature文件是独立的底层用什么技术执行点击App还是操作浏览器被隐藏了。便于复用相同的业务逻辑如登录可以在Web端和App端的测试中复用同一个.feature文件描述。Flybirds利用Behave这个Python BDD框架来解析这些.feature文件并将每个Given/When/Then步骤映射到具体的Python代码称为step implementation中去执行。2.2 插件化架构实现“跨端”的魔法BDD解决了“写什么”的问题而插件化架构解决了“在哪里执行”的问题。这是Flybirds最精妙的设计。Flybirds本身是一个内核轻量、能力外挂的框架。它的核心Core只负责测试生命周期管理、配置加载、DSL解析和插件调度。而所有对具体端的操作能力比如点击一个Android按钮、获取一个iOS页面的文本、在Chrome浏览器里输入内容都被封装成一个个独立的插件Plugin。目前官方主要维护三大插件web插件基于Playwright提供对Web页面的自动化操作能力。Playwright支持Chromium、Firefox、WebKit三大内核所以天然也支持了多浏览器测试。android和ios插件基于Airtest提供对原生App、Flutter App、React Native App的自动化操作能力。Airtest本身集成了图像识别和Poco控件识别让App测试更稳定。ocr插件基于PaddleOCR和OpenCV提供图像识别和文字识别能力。这在验证验证码、识别非标准控件或进行视觉回归测试时非常有用。它们是如何协同工作的当你执行一条指令如“我点击‘登录’按钮”时Flybirds内核的工作流程是这样的根据当前配置确定测试目标端比如是测试Android App。加载并启用android插件。将“我点击‘登录’按钮”这个DSL语句交给android插件去解析。android插件内部会调用 Airtest 的API去查找屏幕上文本为“登录”的控件并点击。如果测试目标是Web端则内核会加载web插件并由它调用 Playwright 的API去完成点击。这种架构带来了巨大的灵活性扩展容易如果未来出现了新的终端比如鸿蒙应用社区只需要为其开发一个新的插件即可融入Flybirds生态。按需选用如果你的项目只测Web那就只安装web插件环境更干净。复用逻辑业务测试用例.feature可以最大程度地复用只有底层的步骤实现plugin需要针对不同端做适配。实操心得插件化设计意味着当你遇到某个端特有的操作比如处理iOS的系统弹窗你需要去阅读对应插件的文档或者学习其底层技术Airtest/Playwright。这有一定学习成本但换来的是极大的灵活性和控制力。3. 环境搭建与核心配置详解理论讲完了我们动手搭一个环境。Flybirds是Python项目所以Python环境是前提。我推荐使用Python 3.8及以上版本并且强烈建议使用虚拟环境venv或conda来管理依赖避免包冲突。3.1 基础环境安装首先通过pip安装Flybirds核心框架。它会自动安装Behave等核心依赖。# 创建并进入项目目录 mkdir flybirds-demo cd flybirds-demo # 创建虚拟环境可选但推荐 python -m venv venv # Windows激活: venv\Scripts\activate # Mac/Linux激活: source venv/bin/activate # 安装Flybirds pip install flybirds安装完成后你可以使用Flybirds提供的CLI脚手架快速创建一个项目结构。# 使用脚手架初始化项目 flybirds create执行命令后CLI会交互式地询问你项目名称、选择模板等。完成后你会得到一个标准的Flybirds项目目录大致如下my_flybirds_project/ ├── features/ # 存放 .feature 测试用例文件 │ ├── login.feature │ └── step_definitions/ # 存放步骤实现Python代码 │ └── web_steps.py ├── reports/ # 测试报告输出目录自动生成 ├── .gitignore ├── behave.ini # Behave框架的配置文件 ├── config.json # Flybirds核心配置文件 └── requirements.txt # 项目依赖这个结构非常清晰features放业务用例step_definitions放具体的自动化代码config.json管理全局配置。3.2 关键配置解析config.jsonconfig.json是Flybirds的大脑它决定了测试如何运行。我们重点看几个最关键的配置项。{ base: { run_env: web, // 指定运行环境web, android, ios language: zh-CN, // DSL语言zh-CN中文en英文 report_format: html, // 报告格式 rerun: false // 失败重跑 }, web: { browser: chromium, // 浏览器类型chromium, firefox, webkit headless: false, // 是否无头模式不显示浏览器界面 viewport: {width: 1920, height: 1080}, base_url: https://www.your-test-site.com }, android: { device: emulator-5554, // 设备序列号可通过 adb devices 获取 app_path: /path/to/your/app.apk, // App安装包路径 app_package: com.example.app, // App包名 app_activity: .MainActivity // 启动Activity }, ios: { device: iPhone 13, // 模拟器名称或真机UDID bundle_id: com.example.app, app_path: /path/to/your/app.app } }run_env这是最重要的开关。你想在哪个端跑测试就把它设为web、android或ios。Flybirds会根据这个值去加载对应的插件。language决定了你.feature文件里步骤的关键词是中文如“假设”、“当”还是英文“Given”、“When”。保持用例语言和配置一致。web配置块只有当run_env为web时才生效。headless: true适合在CI/CD流水线中运行调试时设为false可以看到浏览器操作过程。base_url可以设置基础地址这样在步骤里可以用相对路径。android/ios配置块同样只在对应环境生效。对于Android你需要提前通过ADB连接好设备或模拟器。app_path可以指向本地APK文件Flybirds会帮你安装。对于iOS配置更复杂一些通常需要Xcode和开发者证书更常用于模拟器测试。注意事项初次配置移动端时环境搭建是最容易踩坑的地方。对于Android请确保adb devices能正确列出你的设备。对于iOS请确保WebDriverAgentAirtest底层依赖已正确编译并安装到模拟器或真机上。建议先从Web端开始熟悉框架再挑战移动端。3.3 安装端驱动Plugin安装Flybirds核心框架并不会自动安装Playwright或Airtest的驱动。你需要根据要测试的端手动安装对应的驱动。对于Web测试# 安装Playwright的浏览器驱动 playwright install chromium # 也可以安装 firefox, webkit对于Android/iOS测试Airtest的依赖更多。Flybirds推荐使用其封装的安装命令# 安装移动端测试所需的核心依赖Airtest等 pip install flybirds[device]安装后还需要初始化Airtest环境。对于Android通常只要ADB连通即可。对于iOS可能需要更多设置请参考Airtest官方文档。4. 编写你的第一个跨端BDD测试用例环境配好了我们来写一个实实在在的测试。假设我们要测试一个跨平台应用的搜索功能在Web端和App端搜索框的行为应该一致。4.1 创建功能文件.feature在features目录下创建一个search.feature文件。我们用中文DSL来写。# features/search.feature 功能: 全局搜索功能 场景大纲: 用户可以使用搜索框找到内容 假设 我打开平台的首页 当 我在搜索框输入关键词 且 我点击搜索按钮 那么 我应该在结果页看到包含预期结果的条目 例子: | 平台 | 关键词 | 预期结果 | | Web | Flybirds | UI自动化 | | Android| Flybirds | UI自动化 | | iOS | Flybirds | UI自动化 |这里我们使用了场景大纲Scenario Outline和例子Examples这是BDD中实现数据驱动测试的强大工具。同一个测试流程可以通过表格注入不同的数据分别运行在Web、Android、iOS三个“平台”上。注意这里的“平台”是我们自定义的一个参数用于在步骤中做逻辑判断。4.2 实现步骤定义Step Definitions光有用例描述不行需要编写具体的代码来执行每个步骤。在features/step_definitions目录下创建common_steps.py。# features/step_definitions/common_steps.py from behave import given, when, then from flybirds.core.global_context import GlobalContext as g import re given(我打开{platform}的首页) def step_open_homepage(context, platform): 根据平台参数打开对应的首页。 这里需要根据你的实际项目替换成真实的URL或App启动逻辑。 config g.get_config() if platform.lower() web: # 使用web插件的能力打开浏览器并导航至base_url context.driver.goto(/) # 相对于config.json中的base_url print(f已打开Web首页) elif platform.lower() android: # 使用android插件的能力启动App # 通常config.json中配置了app_package和app_activity这里默认已启动 print(f已启动Android App) elif platform.lower() ios: # 使用ios插件的能力启动App print(f已启动iOS App) else: raise ValueError(f不支持的平台: {platform}) when(我在搜索框输入{keyword}) def step_input_search_keyword(context, keyword): 在搜索框输入文本。这里需要替换为页面上的真实元素选择器。 # 通过全局上下文g可以获取当前运行的插件实例 # web端和移动端查找元素的方式不同但Flybirds的DSL层做了统一 # 这里以通过placeholder属性查找为例 selector input[placeholder请输入搜索关键词] # 使用flybirds提供的统一元素操作API g.element.input_text(selector, keyword) when(我点击搜索按钮) def step_click_search_button(context): 点击搜索按钮。 # 可以通过文本内容查找按钮这是跨端能力很强的定位方式 g.element.click(搜索, bytext) then(我应该在结果页看到包含{expected_text}的条目) def step_verify_search_result(context, expected_text): 验证结果页面包含预期的文本。 # 等待页面加载并检查文本出现 g.element.wait_text(expected_text) # 更严格的验证可以获取所有结果条目进行断言 # result_items g.element.find_elements(.result-item) # assert any(expected_text in item.text for item in result_items), f未找到包含{expected_text}的结果 print(f验证成功页面包含文本{expected_text})代码解读与技巧given、when、then这些是Behave的装饰器将Python函数与.feature文件中的步骤描述绑定起来。步骤描述中的platform、keyword等变量会自动作为参数传入函数。GlobalContext (g)这是Flybirds提供的全局上下文对象是你的“瑞士军刀”。通过它你可以访问当前配置g.get_config()、操作元素g.element、管理页面g.page等。它屏蔽了底层是Playwright还是Airtest的差异。统一的操作APIg.element.click()、g.element.input_text()、g.element.wait_text()这些API是Flybirds抽象出来的。无论在Web还是App上你都用同一套方法。这是实现“一套脚本多端运行”的关键。元素定位示例中用了属性选择器input[placeholder...]和文本定位bytext。文本定位在跨端测试中非常有用因为UI文本通常是一致的。但对于复杂或动态元素你可能需要更稳定的定位方式如ID、XPath或CSS选择器Web、或POCO控件路径App。实操心得步骤实现函数里的context参数是Behave框架传入的场景上下文可以用于在步骤之间传递数据比如把登录后的token存进去。而Flybirds的g对象则提供了与具体端交互的能力。区分好两者的用途很重要。4.3 运行测试并查看报告编写完成后就可以运行测试了。在项目根目录下执行# 运行所有feature文件 behave # 运行指定的feature文件 behave features/search.feature # 运行指定标签的测试可以在feature中用tag标记场景 behave --tagssmoke运行完成后会在reports目录下生成一份详细的HTML报告。这份报告基于multiple-cucumber-html-reporter非常直观会展示每个场景、每个步骤的执行结果成功/失败、用时以及失败时的错误信息和截图如果配置了截图。如何配置失败截图在config.json的base部分或具体端的配置中可以添加screenshot: { on_failure: true, dir: ./screenshots/ }这样当任何步骤失败时Flybirds会自动截取当前屏幕并保存在HTML报告中可以直接点击查看极大方便了失败分析。5. 进阶技巧与最佳实践掌握了基础用法后下面这些技巧能让你写出更健壮、更易维护的Flybirds测试脚本。5.1 数据驱动与参数化上面的例子已经展示了使用**场景大纲Scenario Outline**进行数据驱动。这是BDD的核心优势之一。你还可以将测试数据外置到JSON或YAML文件中在步骤中读取。# 更复杂的数据驱动例子 场景大纲: 不同用户角色的登录测试 当 我以角色身份登录 那么 我应该看到欢迎语 例子: | 角色 | 欢迎语 | | 普通用户 | 欢迎回来 | | 管理员 | 欢迎进入管理后台 | | VIP用户 | 尊贵的VIP欢迎您 |5.2 页面对象模式Page Object Model, POM的融合虽然BDD的步骤定义已经将操作封装了一层但对于复杂页面建议引入POM模式将页面元素定位和基础操作进一步抽象让步骤定义文件更清爽只关注业务流。# features/pages/home_page.py class HomePage: 首页页面对象 def __init__(self, context): self.context context self.search_input input[placeholder请输入搜索关键词] self.search_button button:has-text(搜索) def open(self): g.driver.goto(/) def search(self, keyword): g.element.input_text(self.search_input, keyword) g.element.click(self.search_button) # 在步骤定义中使用 from features.pages.home_page import HomePage given(我打开首页) def step_impl(context): context.home_page HomePage(context) context.home_page.open() when(我搜索{keyword}) def step_impl(context, keyword): context.home_page.search(keyword)5.3 等待与稳定性提升UI自动化最大的敌人是“不稳定”元素加载慢、网络延迟都会导致失败。Flybirds提供了一些内置的等待策略但你需要善用它们。隐式等待在config.json的web或android配置中可以设置timeout默认30秒。这是全局等待元素出现的超时时间。显式等待在步骤中使用g.element.wait_text()或g.element.wait_ele()等待特定条件满足再进行下一步操作。重试机制对于某些不稳定的操作可以自己封装一个带重试的逻辑。from flybirds.utils import retry retry(max_attempts3, delay1) def click_stable_button(selector): 带重试的点击操作 g.element.click(selector)5.4 自定义步骤与插件扩展如果Flybirds内置的DSL步骤如“我点击xxx”不能满足你的需求你可以轻松地自定义步骤甚至开发自己的插件。自定义步骤直接在step_definitions目录下的Python文件中用given、when、then定义新的函数即可。只要函数名和步骤描述字符串匹配就会被调用。开发插件如果你需要为某个特殊设备或框架如微信小程序添加支持可以参照官方插件结构开发自己的插件。这需要你对Flybirds的插件生命周期和底层驱动如Airtest有较深理解但这是将Flybirds能力扩展到任何新平台的终极方式。6. 常见问题排查与实战避坑指南在实际项目中用Flybirds你肯定会遇到各种问题。这里我总结了一些高频问题和解决思路。6.1 元素定位失败这是UI自动化最常见的问题在跨端环境下更复杂。问题脚本报错提示找不到元素ElementNotFound。排查确认当前环境首先检查config.json中的run_env是否正确你写的Web定位器当然在App上找不到。验证定位器在Web端用浏览器开发者工具检查你的CSS选择器或XPath是否正确。在App端使用Airtest IDE附带的Poco Inspector工具查看控件的真实路径和属性。检查页面状态元素是否真的加载出来了在操作前加一个等待g.element.wait_ele(selector)。注意动态内容如果元素ID或类是动态生成的避免使用它们。改用相对稳定的属性如>