第 1 篇：没有专职测试的小团队，为什么需要 ai-phone？

没有专职测试的小团队，怎么把移动端回归先跑起来？我们在公司落地了 ai-phone

很多中小团队的移动端测试，真实情况都差不多。

开发改完一个需求，自己点一遍。测试同学如果有，就再按主流程点一遍。没有专职测试的团队，可能就是产品、开发、运营谁有空谁点一下。

功能少的时候，这种方式还能撑住。

但 App 一旦复杂起来，问题就会越来越明显。

登录要点，首页要点，搜索要点，订单要点，会员要点，设置页要点。Android 要点，iOS 要点，现在很多团队还多了 HarmonyOS。

每次发版前大家都会说一句："主流程回归一下。"

但到底有没有走全，很多时候其实说不清。

不是大家不重视质量，而是很多团队真的没有那么多测试资源。

有些公司没有专职测试岗位。有些公司有测试，但测试同学更多是在做手工验证、提 bug、写基础用例，没有精力维护一套完整自动化体系。

传统移动端自动化当然可以做。

Appium、UIAutomator、XCTest、Sonic、STF，这些工具都能解决一部分问题。

但对小团队来说，传统自动化最容易卡在两个地方：

第一，写起来有门槛。第二，维护起来很痛苦。

按钮文案改了，控件层级变了，id 没了，弹窗多了，脚本就挂了。

最后自动化变成了另一个需要人长期维护的系统。

对没有测试岗位的团队来说，这件事很容易半路放弃。

所以我们在公司落地 ai-phone 的初衷很简单：

能不能先把最核心、最重复、最容易漏的移动端回归流程，用 AI 真机自动化兜起来一部分？

注意，这里不是说替代测试。

也不是说 AI 可以解决所有质量问题。

更现实一点讲，就是每次提测和发版前，至少让机器把主流程先跑一遍，给开发和测试留下一份真实手机执行出来的报告。

ai-phone 是什么

ai-phone 是一个三端真机 AI 自动化中台。

它支持 Android、iOS、HarmonyOS 三端真机接入。

你可以把它理解成一个"AI 真机执行层"：

text 复制代码

外部平台提交自然语言 case
↓
ai-phone 调度设备池
↓
真实手机执行
↓
生成步骤日志和 HTML 报告
↓
通过 Kafka / Webhook 回传结果

它不是一个单纯的 Appium 封装，也不是一个"AI 点手机"的 demo。

它更像一个内部质量基础设施。

它有设备池，有调度队列，有 Web 工作台，有实时画面，有执行日志，有单 case 报告，有批次报告，也有运维大盘。

这些东西单独看都不复杂，但组合起来之后，才真正接近公司里能用的形态。

因为公司真正需要的不是"手机能被点一下"，而是：

text 复制代码

谁发起的任务？
跑在哪台设备上？
跑到哪一步了？
失败截图是什么？
报告在哪里？
结果怎么回到内部平台？

这才是落地时绕不开的问题。

它已经在公司落地，不只是 demo

ai-phone 现在已经在我们公司内部落地使用。

我们内部不是让大家单独打开 ai-phone 去跑任务，而是把它接到了已有的内部平台里。

这里我们用到的是龙虾。

你可以把龙虾理解成公司内部的测试 / 用例 / 执行流程平台。

我们现在的分工大概是：

text 复制代码

龙虾：负责用例管理、回归集合、触发入口、执行记录、报告沉淀

ai-phone：负责三端真机调度、自然语言执行、截图日志、HTML 报告、结果回调

也就是说，龙虾负责"这次要测什么"，ai-phone 负责"把它在真实手机上跑出来"。

这两个系统的边界很重要。

如果 ai-phone 什么都做，用例管理也做，权限也做，项目模块也做，测试计划也做，很快就会变成另一个测试平台。

但公司里其实已经有龙虾了。

那 ai-phone 最合适的位置就不是重新造平台，而是作为龙虾下面的一个真机 AI 执行层。

为什么要结合龙虾

单独使用 ai-phone，也可以跑自然语言任务。

比如你在工作台里输入：

text 复制代码

打开 App，进入个人中心，确认用户昵称展示正常。

它可以调度真机去执行。

但这只是工具层面的使用。

公司真正要的是流程闭环。

比如一次提测，龙虾里已经有回归集合：

text 复制代码

登录冒烟
首页冒烟
搜索冒烟
订单冒烟
个人中心冒烟

开发或测试只需要在龙虾里点击"运行 AI 冒烟"。

然后龙虾把这些 case 组装成一个批次，调用 ai-phone 的接口。

ai-phone 收到之后，按 Android、iOS、HarmonyOS 拆分任务，分发到设备池执行。

每条 case 执行结束后，ai-phone 把结果、失败原因、报告地址回传给龙虾。

最后，用户还是在龙虾里看结果：

text 复制代码

这个 case 跑没跑？
在哪个端跑的？
成功还是失败？
失败截图是什么？
完整报告在哪里？

这样开发和测试不用关心底层是 adb、WDA、hdc 还是 hypium。

他们关心的是业务结果。

这也是 ai-phone 在公司里能真正落地的原因。

它解决的不是"测试平台"问题，而是"真机执行"问题

这点我觉得很关键。

ai-phone 不应该做项目管理。不应该做成员权限。不应该做完整用例树。不应该做复杂审批流。也不应该替代龙虾。

它只需要把一件事做好：

把自然语言 case 稳定地执行在真实手机上，然后返回结果。

龙虾负责流程，ai-phone 负责执行。

这个边界清楚之后，系统就不会越做越乱。

内部落地时，我们也是按这个思路拆的：

text 复制代码

龙虾 = 测试流程大脑
ai-phone = 三端真机执行手脚

龙虾知道业务、知道项目、知道这次发版要跑哪些集合。

ai-phone 不需要知道这些。

ai-phone 只需要知道：

text 复制代码

我要跑哪个 case
在哪个端跑
runContent 是什么
结果要回调到哪里

这就是一个比较舒服的系统边界。

它适合什么团队

我觉得 ai-phone 最适合两类团队。

第一类，是没有专职测试岗位的小团队。

这种团队最缺的不是测试理论，而是一个能长期跑主流程的工具。

先不追求全量覆盖，也不追求复杂断言。

第一阶段只需要把最核心的 5 条流程跑起来：

text 复制代码

启动 App
登录
进入首页
进入核心详情页
进入个人中心

这 5 条看起来简单，但价值不低。

因为它们一旦挂了，基本都是阻塞级问题。

如果每次提测前，龙虾都能触发 ai-phone 自动跑一遍，并且留下截图、日志和报告，就已经比完全靠人强很多。

第二类，是只有基础测试的团队。

这种团队可能有测试同学，但自动化建设比较薄弱。

测试同学主要做手工回归、提 bug、写测试点，没有精力写脚本和维护脚本。

ai-phone 可以让测试同学把核心手工用例改成自然语言。

比如：

text 复制代码

打开 App，进入登录页，输入测试账号，点击登录，确认进入首页并展示用户昵称。

或者：

text 复制代码

进入商品详情页，点击立即购买，选择默认规格，进入订单确认页，检查商品名称和价格展示正常。

测试同学不需要一开始学 Appium，也不需要维护控件定位。

他们可以先把最核心的业务路径沉淀下来，然后通过龙虾投递给 ai-phone 执行。

这样测试同学的精力就可以从"重复点手机"，慢慢转到"设计用例、分析失败、判断问题"上。

为什么三端真机很重要

很多移动端自动化工具，Android 支持不错，iOS 麻烦一点，HarmonyOS 经常需要自己补。

但国内团队现在越来越容易遇到三端并行：

text 复制代码

Android
iOS
HarmonyOS

尤其是一些业务 App，只测 Android 已经不够了。

ai-phone 的价值之一，就是把三端放到了同一个执行平台里。

底层可以不同。

Android 走 Android 的链路。 iOS 走 iOS 的链路。 HarmonyOS 走 HarmonyOS 的链路。

但平台层对外表现一致。

龙虾只需要提交：

json 复制代码

{
  "caseId": "login_001",
  "caseName": "手机号登录",
  "runContent": "打开 App，进入手机号登录页，输入测试手机号，完成登录，确认进入首页。",
  "platforms": ["android", "ios", "harmony"]
}

ai-phone 负责把它拆成三个端的执行任务。

对业务方来说，不需要关心具体底层实现。

这就是中台的价值。

它不适合什么场景

这里也要说实话。

ai-phone 不是万能的。

如果一个流程强依赖短信验证码、图形验证码、人脸识别、支付密码、系统安全认证，它不适合一开始就做完全无人值守。

如果 App 起始状态很乱，比如账号状态不固定、弹窗每天变、测试数据不干净，它也会不稳定。

如果团队要求每一步都像传统脚本一样完全确定，不能接受模型判断带来的不确定性，也要谨慎。

AI 视觉自动化更适合做这些事情：

text 复制代码

主流程巡检
冒烟测试
多端一致性验证
简单回归
线上问题复现

不适合一上来承担所有质量保障。

所以我的建议是：

先把它放在"回归兜底"的位置。

不要一开始就想替代全部手工测试，也不要一开始就想覆盖所有复杂业务。

先把最容易漏、最重复、最核心的流程跑起来。

结合龙虾之后，真正的价值是什么

ai-phone 单独看，是一个真机 AI 自动化平台。

但接入龙虾之后，它的价值会更明显。

单独使用 ai-phone，解决的是：

text 复制代码

我能不能让手机自己跑一条自然语言任务？

接入龙虾之后，解决的是：

text 复制代码

每次提测时，哪些 case 应该跑？
谁触发的？
跑在哪些端？
结果怎么回到测试流程？
报告怎么挂到用例下面？
失败怎么沉淀？

这才是公司落地需要的东西。

我们内部的链路大概是：

text 复制代码

开发或测试在龙虾选择回归集合
↓
龙虾根据 case、端、环境组装执行批次
↓
调用 ai-phone /api/submissions
↓
ai-phone 按 Android / iOS / HarmonyOS 分发到设备池
↓
真机执行并生成报告
↓
Kafka / Webhook 返回 case 终态和批次终态
↓
龙虾更新进度、挂载报告、沉淀失败记录

这条链路跑通之后，ai-phone 就不只是一个工具了，而是研发流程的一部分。

开发提测时，可以让龙虾触发一轮 AI 冒烟。

测试回归时，可以让龙虾触发一轮主路径检查。

发版前，可以让三端设备一起跑核心流程。

失败后，大家看的是同一份报告。

这比"某个人在本地跑了一个自动化脚本"要有价值得多。

最后

我对 ai-phone 的定位一直比较克制。

它不是 AI 测试银弹。

它也不是拿来替代测试团队的东西。

但它确实解决了一个很具体的问题：

当团队没有足够测试资源时，能不能先让机器把最重要的移动端主流程跑起来？

在我们公司的落地里，它没有取代龙虾，也没有取代测试同学。

它做的是执行层。龙虾做的是流程层。人做的是判断和治理。

这套组合目前看下来，是比较符合中小团队现实情况的。

如果你的团队也面临类似问题，我的建议不是一上来就追求大而全。

先接一台 Android。先跑 5 条主流程。先把报告回填到内部平台。先让每次提测前都有一份真实手机跑出来的结果。

这一步跑顺了，ai-phone 就已经开始产生价值了。

下一篇我会拆一下 ai-phone 的执行链路：一条自然语言 case，是怎么从龙虾投递出来，经过 ai-phone 调度，最后变成真实手机上的点击、输入和滑动的。

github: github.com/dongxinsupe...