AutoPilot--零代码全栈自动化测试工具

qq_39340176

88人浏览 · 2026-08-30 13:00:26

qq_39340176 · 2026-08-30 13:00:26 发布

AutoPilot 是面向测试团队的可视化关键字驱动全栈自动化测试工具，由桌面 IDE 与协同管理平台组成。IDE 统一承载 Web、HTTP、Android、iOS 等测试资产的设计、控件检视、本地调试与多设备并行执行；Platform 提供项目权限、工程制品、应用版本、Runner 设备池、远程批跑、报告归档与 Android/iOS 真机 Web 远控，形成从用例设计、本机验证到规模化执行与结果追溯的完整测试交付闭环。

前言

如果你维护过 Selenium、Appium 或接口自动化项目，大概率遇到过这些问题：

脚本散落在不同仓库，Web、接口和移动端各用一套工程；
定位元素、准备驱动、管理端口，占掉了大量调试时间；
本机能跑不等于团队能用，换一台机器就要重新搭环境；
手机多起来以后，谁在用、跑哪个版本、报告在哪里，都开始依赖人工协调；
传统 iOS 真机自动化往往与 macOS、Xcode 和 Appium 工具链深度绑定，现有 Windows/Linux 测试资源难以参与 iOS 日常回归。

核心亮点

AutoPilot 想解决的，不只是“再封装一层自动化 API”，而是让测试人员在一个可视化 IDE 中完成编排、检视、调试和执行，再通过配套 Platform 把本机能力扩展成团队级的设备池与远程批跑。

亮点	AutoPilot 当前实现
常规用例“0 代码”编排	从关键字库拖拽封装好步骤，通过参数表单配置数据、对象和断言，不需要为常规场景编写底层 Selenium/Appium 框架代码
一个工程覆盖多端	同一工程组织 Web、HTTP、Android、iOS、数据与中间件测试资产
控件检视与实时镜像	在 IDE 内采集 Web/Android/iOS 控件树，维护定位信息，并提供移动端本机镜像
iOS 跨平台自动化	WDA 完成首次签名与部署后，Windows/Linux 可通过 WDA-direct 连接真机，执行 iOS 用例、控件检视与设备操作
Android/iOS 真机 Web 远控	通过 Platform 在浏览器中查看并操作 Runner 节点上的 Android/iOS 真机，同时查看设备日志与会话状态
多机群跑	同平台多设备并行执行；每台设备拥有独立执行上下文和端口，适合兼容性回归
本机调试到远程批跑	IDE 验证后上传工程制品，Platform 创建 Job，Runner 领取任务并回传日志、报告和执行证据
AI 自动化用例生成	传统关键字自动化可以独立运行，输入自然语言基于AI生成自动化测试用例与辅助编写能力按需启用

IDE主界面

一、AutoPilot IDE：把自动化编写这件事变简单

AutoPilot 采用双仓协同架构，由 AutoPilot IDE 与 Autopilot-Platform 两个可独立部署、通过公开契约协作的工程组成。

AutoPilot IDE 是测试资产的创作与本地执行端：负责工程管理、可视化用例编排、对象与 Binding 维护、控件检视、设备镜像、本机调试、多设备并行执行，以及工程制品的打包和投递。它不是简单的“制品编译器”，而是测试人员日常工作的主要入口。
Autopilot-Platform 是协作治理与远程执行管理端：负责用户与项目权限、工程制品和应用版本、Job 调度、Runner 与设备池、远程设备会话、报告归档及审计。
Runner 是真正靠近执行资源的节点：部署在连接浏览器或真机的主机上，向 Platform 注册和发送心跳，领取 Job 后调用执行核，并回传日志、报告、结构化结果与执行证据。

这样的职责划分使 IDE 可以专注交互效率和本机调试体验，Platform 则负责多人协作、资源治理和规模化执行，两者之间不会形成第二套相互竞争的用例编辑语义。

1. 双仓项目结构

两个仓库的核心目录如下。这里只展示理解产品架构所需的主要模块：

AutoPilot/
├─ autopilot/
│  ├─ app/          # IDE 启动与应用装配
│  ├─ ui/           # PyQt6 主窗口、编辑器和交互组件
│  ├─ metadata/     # 关键字 XML 元数据及目录加载
│  ├─ keywords/     # Web、HTTP、Mobile、Public 等关键字实现
│  ├─ model/        # 用例、套件、对象库及 YAML 序列化
│  ├─ engine/       # 步骤派发、套件执行和多设备并行
│  ├─ inspector/    # Web/Android/iOS 控件树与快照
│  ├─ mobile/       # adb、Appium、WDA、go-ios 等设备能力
│  ├─ intent/       # Intent、Binding、解析与自愈
│  ├─ authoring/    # AI 辅助编写链路
│  ├─ mgmt/         # Platform HTTP 客户端
│  ├─ runner/       # IDE Runner 入口
│  └─ report/       # HTML 报告与结构化结果
├─ contracts/       # 双仓公开 Schema 与运行时契约
├─ docs/            # 配置、架构和平台说明
├─ tools/           # 预检、批量执行及契约校验
└─ run.py           # 桌面 IDE 启动入口

Autopilot-Platform/
├─ autopilot_platform/
│  ├─ platform/     # FastAPI 应用、领域服务、API、调度与权限
│  ├─ frontend/     # Vue 3 + TypeScript Web 工作台
│  ├─ runner/       # 独立 Runner 与远程设备能力
│  ├─ ap/           # 面向 Runner 部署的执行核切片
│  ├─ core/         # 双通道共享常量、Schema 与平台枚举
│  └─ appparse/     # APK/IPA 等应用包解析
├─ contracts/       # JSON Schema、OpenAPI 与 RUNTIME_PIN
├─ alembic/         # 数据库迁移
├─ deploy/          # 部署示例与生产配置模板
├─ tools/           # 初始化、治理与检查工具
└─ start_dev.py     # 本地开发联调入口

双仓边界并不依赖目录名称约定，而是由 HTTP API、工程制品、JSON Schema、运行时版本及 result.json 等公开契约共同约束。

2. 不是传统的手写代码脚本，而是可视化关键字编排

AutoPilot 采用“元数据驱动的可视化关键字模型”：

metadata/keyword_defs/ 以 XML 描述关键字名称、分类、平台、参数和风险等级；
IDE 将元数据加载为可搜索的关键字目录；
用户通过拖拽、双击或右键把关键字插入步骤编辑器；
参数表单根据元数据生成配置项，并关联对象库、数据池和输出变量；
条件、循环及 before/case/after/fault 执行段共同组成结构化用例；
model/serializer.py 将工程资产保存为 YAML；
执行时，engine/executor.py 按 keyword_id 从注册表查找实现并完成派发。

这条创作路径与“录一遍鼠标操作，再生成一份难维护脚本”不同。用例的核心资产是结构化步骤、对象定位和参数，而不是一段只能由原作者理解的过程代码。

关键代码模块

autopilot/metadata/keyword_defs/*.xml：定义关键字的展示名称、参数、适用平台和功能说明。
autopilot/ui/widgets/keyword_panel.py：加载、搜索和拖拽关键字。
autopilot/ui/widgets/case_editor.py：接收关键字或内嵌用例，维护结构化步骤。
autopilot/model/serializer.py：完成模型对象与 YAML 工程文件之间的转换。
autopilot/keywords/registry.py：将 keyword_id 注册到具体的 Python 实现。
autopilot/engine/executor.py：解析步骤、派发关键字、回写输出并记录执行结果。

关键字注册表是元数据模型与 Python 执行实现之间的桥梁。以下为 AutoPilot/autopilot/keywords/registry.py 的关键逻辑节选：

REGISTRY: dict[str, KeywordDef] = {}

def keyword(keyword_id: str, *, name: str = "", category: str = "",
            out_params: Optional[list[str]] = None,
            legacy_impl: str = "", risk_level: str = ""):
    def deco(func: Callable) -> Callable:
        if keyword_id in REGISTRY:
            raise ValueError(f"关键字 id 重复注册: {keyword_id}")
        REGISTRY[keyword_id] = KeywordDef(
            keyword_id=keyword_id,
            func=func,
            name=name,
            category=category,
            out_params=list(out_params or []),
            legacy_impl=legacy_impl,
            risk_level=(risk_level or "").strip().lower(),
        )
        return func
    return deco

步骤执行时不依赖界面文案，而是使用稳定的 keyword_id 查找实现。以下节选自 AutoPilot/autopilot/engine/executor.py，省略了与派发机制无关的结果附加字段：

def _run_step(self, step: Step, result: RunResult) -> None:
    if not step.is_run:
        self._add(result, StepResult(
            step.keyword_id, step.comment, "SKIP", "isrun=false"
        ))
        return

    kwdef = REGISTRY.get(step.keyword_id)
    if kwdef is None:
        self._add(result, StepResult(
            step.keyword_id, step.comment,
            "NOIMPL", "关键字未实现/已砍除"
        ))
        return

    self._execute_step_body(step, kwdef)

这套设计将“用户看到的关键字目录”“工程中保存的结构化步骤”和“运行时调用的 Python 实现”解耦：新增或扩展关键字时，可以沿用相同的注册、编辑和执行链路，而不需要为每项能力重新开发一套编辑器。

IDE 当前提供六类顶层关键字：

WebUI：浏览器、页面、元素、窗口、截图和断言；
HTTP：请求、会话、鉴权、JSON/XML、提取与断言；
Mobile：Android/iOS 会话、控件、手势、应用与设备操作；
Public：流程控制、数据与通用能力；
Intent：意图步骤与 Binding；
自定义关键字：为复杂或项目专属逻辑保留扩展口。

3. 用一个工程组织 Web、接口与移动端

AutoPilot 工程就是一个普通目录，不强制额外的工程清单。测试资产可以按业务自由分层：

资源	文件后缀	用途
测试用例	`.tc.yaml`	before/case/after/fault 步骤与数据驱动
测试套件	`.ts.yaml`	聚合用例及套件级前后置步骤
测试计划	`.tp.yaml`	组合用例或套件
对象库	`.map.yaml`	统一维护元素定位信息
数据配置	`.properties`	工程级参数
自定义关键字	`.ks.yaml`	组合步骤与项目扩展

这种模型的关键不只是“文件后缀统一”，而是 Web、接口和移动端测试可以围绕同一业务工程组织，不必把登录接口、Web 下单和 App 验证拆成互不相识的资产。

4. Inspector：定位元素不必在多个工具间来回切

UI 自动化最消耗时间的工作之一，是在被测界面、元素查看器和脚本编辑器之间反复切换。

AutoPilot 将控件检视放进 IDE：

Web：读取 DOM 与截图；
Android：采集 UiAutomator2/Appium 控件树；
iOS：采集 WDA 控件树；
将选中的定位信息回填到对象库或步骤参数；
支持截图区域选择，用于图片定位资源。

检视器采用只读快照思路，不把“录制用户所有操作”当作唯一创作方式。测试人员仍然能够明确看到步骤、对象和参数之间的关系，后期维护更容易定位到具体资产。

5. 本机镜像：边看、边点、边调试

IDE 内的本机镜像覆盖 Android 和 iOS：

Android 使用 scrcpy 视频链路；
iOS 在 macOS 可尝试 AVFoundation 采集；
WDA MJPEG 可用时走视频流；
视频流不可用时保留截图轮询回退。

镜像的价值不只是“把手机画面搬到电脑上”，而是让设备选择、控件检视、单步执行和失败排查处于同一个工作台中。

6. iOS 跨平台执行：让 Windows/Linux 也能承担真机回归

传统 iOS 自动化经常将日常执行环境与 macOS、Xcode 和 Appium 绑定在一起。AutoPilot 将“首次签名准备”与“日常自动化执行”拆分为两个阶段：

首次使用 macOS 与 Xcode 完成 WDA 编译、签名和真机部署；
设备准备完成后，Windows/Linux 可通过 go-ios 与 pymobiledevice3 建立隧道和端口转发；
执行引擎通过 WDA-direct 创建 HTTP 会话，完成应用操作、控件定位、点击、输入、手势和断言；
同一套 .tc.yaml 用例可以在 Windows、Linux 或 macOS 执行节点上继续复用。

这意味着团队可以将 Mac 保留给 WDA 的首次工程准备，再把大量日常 iOS 回归任务分配到现有 Windows/Linux 测试节点，降低对单一操作系统的持续依赖。

7. 多设备并行：把单机回归变成多机群跑

AutoPilot 已实现同平台多设备并行。其语义非常明确：

选择 N 条用例和 M 台同平台设备后，每台设备完整执行这 N 条用例，共产生 N×M 次执行。

每个并行 worker 拥有独立的：

设备 UDID；
Appium/WDA 与相关端口；
执行上下文；
日志与结果；
故障隔离。

IDE 中连接至少两台同平台设备后，可以在运行流程中选择并行执行；也可以使用命令行：

python tools/run_suite.py --project <工程目录> --parallel --platform android --workers 3

这套“多机群跑”能力可将同一批用例并行投放到多台 Android 或 iOS 设备，显著提升多机型兼容性回归的执行效率。

二、从一条用例看 AutoPilot 的实际使用体验

假设需要验证一个移动应用的登录流程，并在多台设备上回归：

第一步：创建工程

在 IDE 中新建工程。系统会准备基础配置目录，随后可按业务模块建立用例、对象库和数据配置。

第二步：通过 Inspector 获取对象

连接 Android 或 iOS 真机，打开控件检视器，采集当前页面的控件树和截图，将账号框、密码框、登录按钮等定位信息保存到对象库。

第三步：拖拽关键字编排步骤

从 Mobile 关键字库中插入点击、输入、等待和断言步骤，在参数表单中绑定对象与测试数据。常规流程不需要直接编写 Appium/WDA 调用代码。

第四步：本机单步调试

先选一台设备运行，观察控制台、镜像画面和步骤结果。定位或数据有问题时，直接回到对象库或参数表单修改。

第五步：开启多设备并行

连接多台同平台设备，选择并行执行。每台设备使用独立端口和上下文完成整批用例，避免会话串台。

第六步：查看结果

本机生成 HTML 报告，并保留结构化结果和执行证据。需要团队共享时，再把工程制品交给 Platform。

这条链路体现了 IDE 的核心定位：先让一个测试人员在本机高效完成“编写—定位—调试—群跑—排错”闭环。

三、Autopilot-Platform：把桌面 IDE 扩展为团队级设备与执行平台

当自动化只服务一个人时，本机 IDE 已经可以完成大量工作；当团队开始共享工程、安装包、设备和报告时，才需要 Platform。
Platform主界面
Platform 是 AutoPilot IDE 的“团队能力放大器”：它不仅负责工程、任务与报告治理，还能将分散在 Runner 节点上的 Android/iOS 真机统一纳入设备池，并提供浏览器远程控制入口。

1. 把本机验证过的工程交给远程 Runner

完整链路如下：

Runner 不是一个只能被手工触发的脚本。它会向 Platform 注册、发送心跳、上报设备与后端能力、领取 Job，并在执行结束后回传报告和结构化结果。

2. Android/iOS 真机 Web 远控：在浏览器中统一管理和操作设备

Runner 会向 Platform 上报本机连接的 Android/iOS 设备及其健康、占用、维护和会话状态。团队成员无需在浏览器所在电脑直接连接 USB 设备，即可从 Platform 发起真机远控会话。

Android 远控：Runner 通过 scrcpy 获取设备画面，并借助 WebRTC 向浏览器传输，支持远程触控、输入和设备日志查看。
iOS 远控：通过 WDA 执行设备交互，使用 MJPEG 提供实时画面，支持远程触控、文本输入、应用操作、文件操作与设备日志。
设备池治理：Platform 统一维护设备可用状态、远控会话与资源占用关系，远控调试与自动化 Job 可围绕同一设备池协同。

这使 Platform 不只是一个任务列表和报告仓库，而是真正能够连接、观察和操作远程真机的团队级测试工作台。

3. 工程、安装包和报告各自版本化

Platform 有意将三个对象分开：

对象	管理内容
工程制品	用例、配置、对象与 Binding 等工程 zip
应用资源	APK、XAPK、IPA 安装包版本
Job	将工程、可选应用版本、设备与执行参数组合起来

这样可以回答一次回归中最关键的追溯问题：哪份工程、哪版应用、在哪些设备上运行，最终生成了什么结果。

4. 团队治理能力

Platform 当前实现还包括：

组织、项目空间与成员；
用户 JWT 与 Runner Token 分通道鉴权；
ACL、邀请、角色能力和审计；
计划任务、Job 取消与重试；
日志流、报告归档与双报告对比；
需求、逻辑/意图用例、知识库和人工评审；
可选的设计 AI 与 IDE 辅助编写网关。

这些能力是第二主线：它们不会取代 IDE 的创作体验，而是让已经形成的测试资产可以被团队持续使用。

四、双仓运行架构与数据流

目录结构定义了代码职责，运行时的数据流则由 IDE、Platform 和 Runner 三类部署单元共同完成。两个仓库并不是简单的“前端与后端”关系。

部署单元	主责
AutoPilot IDE	用例编排、对象与 Binding、Inspector、本机镜像、本机执行、制品投递
Platform 服务与 Web 工作台	身份权限、设计评审、制品/应用、Job、计划、报告、设备池与审计
独立 Runner / IDE Runner	注册、心跳、领取任务、调用执行核、回传结果
`autopilot_platform/ap/`	供 Runner 部署的执行核切片

双仓通过 HTTP API、工程制品、公开 JSON Schema、运行时版本和 result.json 契约协作，不直接互相硬引用。

五、它和常见自动化方案的差异在哪里

这里不做没有数据支撑的性能比较，只看产品形态：

维度	纯脚本框架常见形态	AutoPilot 当前形态
用例创作	编写 Python/Java 等脚本	关键字库拖拽 + 参数表单 + 结构化步骤
多端组织	Web、接口、移动端常分开维护	一个工程模型统一组织
元素定位	外部 Inspector 与代码间切换	IDE 内检视并回填对象/参数
设备调试	单独镜像或命令行工具	IDE 内镜像、检视、单步与控制台
多机回归	自行处理进程、端口和结果	同平台多设备并行，设备上下文隔离
团队交付	依赖 Git、CI 和自建报告系统拼装	配套 Platform 管制品、应用、Job、设备和报告
扩展能力	代码灵活，但门槛较高	常规场景可视化；复杂逻辑保留自定义关键字

AutoPilot 的差异化价值，在于将可视化创作、专业调试、多机执行和团队治理整合进同一产品体系，同时为复杂场景保留自定义关键字的扩展空间。

六、哪些团队更适合使用

1. 业务测试人员较多，希望降低自动化门槛

常规场景可以通过关键字和表单完成，同时仍有对象库、数据驱动和自定义关键字应对后续复杂度。

2. 同时维护 Web、接口和移动端自动化

团队不希望为每类测试维护一套完全独立的工程结构与交付流程。

3. 有多台 Android/iOS 真机需要周期性回归

IDE 可进行本机多设备并行，Platform 与 Runner 可进一步组织远程设备资源和批跑任务。

4. 需要审计和复现一次测试执行

工程制品、应用版本、设备、日志、报告、结构化结果和证据能够形成关联。

AutoPilot 更适合已经超越单点脚本验证阶段，需要统一管理多端用例、真机资源、执行任务与报告证据的测试团队。

七、技术栈：桌面创作与 Web 治理各取所长

AutoPilot IDE

Python 3.10+；
PyQt6 桌面界面；
Selenium 4，可选 Playwright；
Appium、adb、WDA、pymobiledevice3、go-ios；
httpx、JSON/XML 处理、PyYAML、openpyxl；
OpenCV、NumPy，以及可选镜像依赖。

Autopilot-Platform

FastAPI、Uvicorn、Pydantic；
SQLAlchemy 2、Alembic，开发默认 SQLite，可选 PostgreSQL；
Vue 3、TypeScript、Pinia、Vue Router、Vite；
独立 Runner 与可部署执行核；
可选 Android/iOS Web 远控依赖；
可选测试设计 AI/RAG 依赖。

八、快速体验：先启动 Platform，再启动 IDE

下面的命令用于本机开发联调，不是生产部署方案。

1. 启动 Platform

在 Autopilot-Platform 仓库执行：

py -3.12 -m venv .venv
./.venv/Scripts/python.exe -m pip install -U pip
./.venv/Scripts/python.exe -m pip install -e ".[dev,runner]"

Push-Location autopilot_platform/frontend
npm install
Pop-Location

./.venv/Scripts/python.exe tools/init_platform.py init
./.venv/Scripts/python.exe start_dev.py

开发入口：

Web 工作台：http://127.0.0.1:5173
OpenAPI：http://127.0.0.1:8000/docs
健康检查：http://127.0.0.1:8000/health

2. 启动独立 Runner

start_dev.py 不会自动启动执行节点。另开终端：

$env:MC_RUNNER_TOKEN = "<YOUR_RUNNER_TOKEN>"
python -m autopilot_platform.runner --server http://127.0.0.1:8000 --token-env MC_RUNNER_TOKEN

只检查本机设备和后端能力：

python -m autopilot_platform.runner --dry-probe

3. 启动 AutoPilot IDE

在 AutoPilot 仓库执行：

py -3.12 -m venv .venv
./.venv/Scripts/python.exe -m pip install -U pip
./.venv/Scripts/python.exe -m pip install -e ".[data,mirror,icons]"
./.venv/Scripts/python.exe tools/preflight.py
./.venv/Scripts/python.exe run.py

最小体验路径：

新建工程；
创建对象库和测试用例；
从关键字库拖入步骤；
连接浏览器或真机进行检视和试跑；
多台同平台设备并行执行；
上传工程制品，在 Platform 创建远程 Job；
查看日志、报告和执行证据。

九、落地建议：从本机验证到团队规模化

为了更高效地发挥双仓体系的价值，建议按照“本机创作与验证——平台统一管理——执行节点规模运行”的路径逐步接入：

先用 IDE 完成核心流程验证。 常规场景优先使用可视化关键字编排；遇到复杂业务逻辑时，可通过自定义关键字延伸项目能力。
按回归目标组织多设备执行。 IDE 支持同平台多设备并行执行，适合将同一套用例投放到多台 Android 或 iOS 设备上完成兼容性回归。
按职责部署 IDE、Platform 与 Runner。 IDE 承担用例、对象库和 Binding 的创作与调试；Platform 负责协作治理与任务编排；Runner 连接浏览器和真机，提供远程执行算力。
提前准备移动端工具链。 Android 执行环境需要配置 JDK、Appium、USB 授权等基础能力；iOS 设备的首次 WDA 签名与部署建议在 macOS 和 Xcode 环境中完成。
根据需求启用 AI 辅助能力。 关键字编排、本机执行和远程批跑均可独立运行；AI 生成与辅助编写可按团队的模型服务与成本策略选择性接入。
区分开发联调与正式环境。 start_dev.py 与 SQLite 便于快速体验；正式落地时，应结合团队的网络、账号安全、数据库和 Runner 资源规划完成部署。
通过公开契约管理双仓升级。 IDE 与 Platform 以 HTTP API、JSON Schema、运行时版本和结果文件作为协作边界，联合升级时按契约完成版本配对即可。

十、总结：IDE 做深，Platform 做宽

AutoPilot 的产品主次可以用一句话概括：

IDE 把测试编写、元素定位、本机调试和多机执行做深；Platform 再把这些能力扩展到团队协作、远程设备、任务调度和报告治理。

它最值得关注的不是某一个底层驱动，而是四件事情被真正串在了一起：

常规场景通过关键字实现低代码/“0 代码”编排；
Web、接口、Android 和 iOS 进入同一工程模型；
Inspector、镜像、单步调试和多设备并行集中在一个桌面工作台；
本机验证过的资产可以继续流向 Platform 与 Runner，而不是止步于开发者电脑。

对于希望降低自动化门槛、管理多台真机，并把个人脚本升级为团队测试资产的团队，这比单纯再搭一套脚本框架更值得研究。

项目仓库

AutoPilot IDE：https://github.com/zhoujun94511/AutoPilot
Autopilot-Platform：https://github.com/zhoujun94511/Autopilot-Platform

EazyDevelop社区

一站式 AI 云服务平台

更多推荐

腾讯发布AI神器Marvis，用过的人都说回不去了

装上它，用户无需复杂的配置和技能安装，即可预装六名7x24小时在线的AI“牛马”Agent（PM、Windows 系统运维、APP 操作专员、网页交互专员、数字资产管家、搜索专家），用自然语言就能实现对手机和电脑的全流程操控。你可以通过描述来找文件，比如"找出上周写的关于AI的文档"，或者"找我在长城拍的照片"，它会自动识别图片内容和文字，这相当于为你打造了一个专属的"个人知识库"。同时支持端侧隐

EazyDevelop社区

springboot甘肃自驾游系统84716-计算机课程设计、毕业设计

EazyDevelop社区

2026年适合零售门店的微商城门店小程序运营效率提升方向

适合零售门店的微商城门店小程序是集成线上商城、线下收银、会员管理、营销工具于一体的轻量化SaaS产品，专为实体零售门店打造，区别于独立的电商平台或纯收银软件。其核心特点是线上线下数据原生互通，无需在多套系统间切换操作，门店的商品、库存、会员、订单数据在同一后台统一管理，避免人工同步带来的误差与效率损耗。这类产品通常采用零代码可视化搭建模式，门店运营人员无需技术基础，通过拖拽组件即可完成商城页面、活

EazyDevelop社区

所有评论(0)

查看更多评论

qq_39340176

@qq_39340176

已为社区贡献1条内容

AutoPilot--零代码全栈自动化测试工具

qq_39340176

前言

核心亮点

一、AutoPilot IDE：把自动化编写这件事变简单

1. 双仓项目结构

2. 不是传统的手写代码脚本，而是可视化关键字编排

关键代码模块

3. 用一个工程组织 Web、接口与移动端

4. Inspector：定位元素不必在多个工具间来回切

5. 本机镜像：边看、边点、边调试

6. iOS 跨平台执行：让 Windows/Linux 也能承担真机回归

7. 多设备并行：把单机回归变成多机群跑

二、从一条用例看 AutoPilot 的实际使用体验

第一步：创建工程

第二步：通过 Inspector 获取对象

第三步：拖拽关键字编排步骤

第四步：本机单步调试

第五步：开启多设备并行

第六步：查看结果

三、Autopilot-Platform：把桌面 IDE 扩展为团队级设备与执行平台

1. 把本机验证过的工程交给远程 Runner

2. Android/iOS 真机 Web 远控：在浏览器中统一管理和操作设备

3. 工程、安装包和报告各自版本化

4. 团队治理能力

四、双仓运行架构与数据流

五、它和常见自动化方案的差异在哪里

六、哪些团队更适合使用

1. 业务测试人员较多，希望降低自动化门槛

2. 同时维护 Web、接口和移动端自动化

3. 有多台 Android/iOS 真机需要周期性回归

4. 需要审计和复现一次测试执行

七、技术栈：桌面创作与 Web 治理各取所长

AutoPilot IDE

Autopilot-Platform

八、快速体验：先启动 Platform，再启动 IDE

1. 启动 Platform

2. 启动独立 Runner

3. 启动 AutoPilot IDE

九、落地建议：从本机验证到团队规模化

十、总结：IDE 做深，Platform 做宽

项目仓库

所有评论(0)

温馨提示：您尚未绑定手机号

qq_39340176