我做了一个APP自动化测试Skill,从此AI替你打工

张开发
2026/4/14 16:31:36 15 分钟阅读

分享文章

我做了一个APP自动化测试Skill,从此AI替你打工
面试求职「面试试题小程序」内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试命中率杠杠的。大家刷起来…职场经验干货软件测试工程师简历上如何编写个人信息一周8个面试软件测试工程师简历上如何编写专业技能一周8个面试软件测试工程师简历上如何编写项目经验一周8个面试软件测试工程师简历上如何编写个人荣誉一周8个面试软件测试行情分享这些都不了解就别贸然冲了.软件测试面试重点搞清楚这些轻松拿到年薪30W软件测试面试刷题小程序免费使用永久使用在进入正题之前先从软件交付模式变更的视角说说为什么我们要给AI写Skill如果只关心Skill怎么做的可以直接滑到下面的内容软件交付模式的演进AI时代来临软件的交付模式正在面临巨大转变过去我们交付软件依赖CI流水线基建开发用git提交代码 → 触发CI流水线 → 编译打包 → 代码门禁单测、SA等 → 测试门禁提测准入任务一般是跑自动化校验准入Case是否签章等 → 部署测试环境 → QA测试 → 上线发布。开发用git提交代码到代码仓库后代码托管平台监听到有代码pushCI流水线就会自动触发一系列自动化任务所有自动化任务都依赖CI流水线一旦流水线某个job执行失败如单测case执行失败环境部署失败等依赖人工处理不需要人介入的部分也是依赖人为设计的自动化脚本此阶段AI的含量为0主导者是人后来各种AI Agent或AI测试平台横空出世我们到了人机协作模式你有没有发现CI流水线这样的基建正在被弱化使用甚至被Agent代替环境部署 → 部署Agent提测/提Bug → 交付助手Agent写测试用例 → 测试用例生成Agent构造测试数据 → 数据构造Agent上线 → 智能运维Agent……完成工作任务通过与Agent采用自然语言对话LUI的形式进行不再强依赖CI流水线Agent 运行原理如下人定义意图 → 人编排 Workflow/ReAct 链路 → Agent 按规则执行意图识别靠 NLU 或 LLM 做分类但分类体系、路由规则还是人设计的Workflow 模式人预先画好 DAG有向无环图Agent 按图执行本质是高级脚本ReAct 模式Agent 能自主推理下一步调什么工具但工具集、边界、停止条件都是人定义的此阶段虽有AI参与主导者还是人人来设计框架 定义边界Agent来负责执行决策AI的角色是受约束的自主体——能自主规划但在人划定的围栏内而现在大模型的能力已经足够强大如Claude Opus 4.6、GPT 5.4等等Claude Code、Codex、Gemini CLI等AI工具已可以代替产品写PRDUI做设计开发写代码QA做测试运维做部署等等此阶段人提供经验封装SkillAI负责自主编排AI是主导执行者——人的经验以 Skill 形式喂给 AIAI 决定何时、如何组合所以我们写的Skill本质就是喂给AI的经验让AI获得某项技能。想想最近很火的同事SkillAI加载了这个Skill就能化身成为同事的数字分身测试领域哪些Skill最有价值我认为是自动化测试相关的Skill既然是AI来主导AI来代替人工测试是必须要解决的事情这在以前AI完全取代人工测试几乎是一件不可能的事情但在AI时代这一切正在发生另外对于自动化测试在AI时代我认为UI自动化测试所带来的价值会高于接口自动化测试为什么得出这个结论除了一些互联网大厂还在区分服务端测试和客户端测试现在越来越多的公司一个QA要负责整个端到端的测试并且客户端发现的Bug数量一般要远多于服务端的Bug证明早在AI时代来临前E2E测试重要性还是比服务端接口测试更高的最近接口自动化测试Skill 和 UI自动化测试Skill我都分别写了一套两者在效果层面的对比如下接口自动化测试Skill 很难发现业务逻辑Bug通过读取接口文档或者读取代码库Claude Rules规则软件测试用例设计规范能快速生成接口自动化测试用例用Pytest框架管理用例用Allure生成测试报告运行AI生成的接口测试用例我一看用例通过率100%真的一点Bug都没有但我点点点发现app明明有很多bug呀分析了下为什么生成的接口测试用例无法发现业务问题主要原因是AI不了解业务逻辑AI生成接口自动化用例时不能直接跟需求文档PRD关联AI不知道PRD里的业务逻辑仅仅通过接口文档只能发现参数和返回值不符合预期无法发现业务逻辑Bug想想以前人工补充接口自动化测试用例QA同学具备业务经验都是了解接口参数如何进行关联接口上下游都是什么这样才能写出覆盖率更高的接口自动化用例如果实在想通过AI生成的接口自动化测试能发现业务逻辑我的想法是需要额外建设代码层面的知识图谱加入白盒分析能力获取接口调用链信息。图谱接口文档作为上下文给到大模型这样才能让LLM生成覆盖业务路径的测试用例但构建知识图谱的成本本身就比较高UI 自动化测试Skill发现业务逻辑Bug的好帮手UI 自动化可以从端到端的场景模拟用户的点击所以天然就能发现和PRD实现不一致的业务逻辑以往 UI 自动化往往因为业务快速迭代导致元素定位不准确、稳定性较低同时需要频繁人工维护用例整体 ROI 偏低AI 时代下情况有所变化定位元素方面对于 Web 开发或者Mac Electron的应用可通过 CDP (Chrome DevTools Protocol)直接访问应用的 DOM 结构提升元素定位能力。对于安卓应用也可以通过uiautomator2拿到真实的DOM树结构更关键的是大模型具备一定的自修复能力可以在执行失败时辅助分析原因并调整步骤从而提高 UI 自动化可用性自动化测试Skill我是怎么做的接口自动化Skill不再本文讨论范围内后续会单独出其他文章谈对于UI 自动化测试有两种一种是Web 自动化另一种是APP自动化调研后发现Web UI自动化测试选择方案很多另外还有playwright-skill以及browser_use这样的新框架等我实操后再来分享效果而APP UI 自动化测试由于APP内有各种各样业务逻辑往往稳定性不高但公司的产品一般都是有APPAPP 自动化测试也是需要解决的重点目前还没有看到成熟APP 自动化测试AI Agent Skill方案于是前段时间我自己实现了APP自动化测试 SkillSkill 整体设计对于Skill的整体设计我拆分了两个Skill第一个Skill是全量获取真实DOM树第二个Skill是根据PRD生成APP自动化测试用例这样设计的原因是我仍然采用传统的元素定位方式DOM树XPATH先获取到每个页面的真实DOM树这样生成出来的自动化测试用例才是真实可用的另外不需要在每次生成自动化的时候都去执行全量DOM获取如果不提供真实DOM树大模型会自行推断但自行推断生成出来的Case往往不可用还得反复修改为什么定位元素不用视觉定位框架我的核心使用诉求是AI来代替人工测试不只是回归测试冒烟和模块测试都交给AI所以执行速度不能太慢而字节Midscene.js靠纯视觉定位框架痛点问题就是执行速度慢因为每次执行Case都要过大模型另外纯自然语言描述Case看似灵活实则难管理如果自动化只是用来做例行回归接受跑一晚上第2天来看结果这种使用场景倒是比较适合用Midscene.js有使用过Midscene.js的同学可以评论区留言说下使用感受UI 自动化测试 Skill 实操步骤先执行dump-ui Skill再执行prd-to-test Skill生成APP自动化测试用例dump-ui skill 获取真实DOM树使用前置条件安卓真机连接PC打开USB调试提前安装好被测APP加载skill方法把skill原文件放在~/.claude/commands/目录下Claude Code会自动加载skill里面的dump-ui.md文件内容。使用方法打开Claude CodeVSCode插件引用文件作为上下文或者Claude Code命令行输入/dump-ui 自己的需求第一次使用需要输入应用包名属于前置信息比如获取应用包名等知道包名后AI才能调用ADB打开应用包名属于配置信息AI自己会固化在生成的配置文件中dump-ui Skill有两个功能说明全量页面自动探索适用于第一次使用或者后续有新页面迭代的场景仅扫描已有页面只对已知的页面DOM做版本更新这样速度会更快也可以两者同时使用在执行前CC会让你选择执行的模式我这里安装第一种扫描已有页面并且跳过未登录页面等待全量Dump任务完成AI会自动帮你写一个全量dump脚本自动执行脚本保存DOM树全量Dump完毕后会在data/ui-dumps文件夹里面存放该app的所有页面的dom信息如果执行该Skill时某个页面DOM已经存在会创建带版本号V2V3..的xml文件后续在使用生成用例Skill时会选择使用最新版本的页面DOM执行完毕后会有一个UI Dump 更新报告提示哪些页面DOM进行了版本变更部分页面可能存在获取DOM失败的情况可以让Cluade 编写补救脚本或者给到页面的正确导航路径重新获取也可以选择先跳过prd-to-test Skill 生成APP 自动化测试用例先加载prd-to-test Skill加载方式同上skill原文件进测试开发学习圈获取在Claude Code命令行窗口执行/prd-to-test 需求文档本地路径就可以开始生成APP自动化测试用例如果PRD文档过大Skill会让Claude Code按APP功能模块维度返回让用户选择本次要生成case的模块先跑通一个模块后再去生成其他模块的case执行到用例设计环节Skill里面描述了软件测试用例设计规范按照6层纬度去生成测试用例L1:页面元素存在性 页面元素是否存在L2:交互行为当前页面有哪些用户交互行为L3:异常流程异常的操作流程L4:验收标准产品验收需要通过的CaseL5:数据边界值如输入框等有数据输入的情况等价类边界值等L6:主流程场景Case场景化case保证流程是通过UI自动化测试用例生成完成后会在tests目录按模块维度生成UI自动化测试脚本我这里已经生成了4个模块所以有4个自动化脚本文件每个脚本文件包含50-100个case刚刚生成的是test_m4_messaging.py生成完毕后Claude Code自动验证刚刚生成的Case给出生成报告连接真机执行自动化测试脚本会产出Allure测试报告测试报告自动填充前置步骤测试步骤测试截图等信息部分不好执行的场景比如打开相册麦克风授权删除好友等脚本自动标记skip跳过这时由人工测试来覆盖PS初次执行生成Case可能会有些错误AI会启动自修复环节后重新执行测试如图我第一次运行某模块Case成功率只有约5%经过AI自修复后成功率提升到97%Allure测试报告-Case通过率结束语最后在实践AI代替人工测试的过程有几点跟大家分享对AI的信任AI生成出来的Case是否是有效的目前现阶段通过我的实践来看粗估是80%首次AI生成出来Case可用经过AI自修复后部分功能的Case可以达到100%可用我用的是Claude Opus 4.6模型业界公认最好的模型之一那这100% 可用的Case里面是否有无效操作或者执行不到位的情况的确存在现阶段即使AI 认为通过的Case我还是会人工核实检查一遍便于后续继续优化Skill对于有明显错误的Case让AI再次进行调整部分元素无法定位AI在修复UI自动化测试用例过程中部分元素可能无法定位比如点击按钮弹TabTab上选项无法定位最后只能用坐标或者ADB命令来定位一些异常场景AI踩坑的经验可以写进skill方便下次AI快速解决对于交互逻辑比较复杂跨页跨端的场景传统DOM树遍历的方式可能会存在无法定位到太深的元素或者遍历深度不足比如一个下单流程有选品-》加购物车-》支付等这样比较长的链路最后的支付流程可能很难被遍历到这样的场景还是需要人工来测试或者结合一些其他的UI自动化测试框架比如Airtest等视觉定位框架工作流转化我现在的工作模式已经转为AI辅助QA的工作模式通过一系列的Skill让AI主导测试用AI后效率到底提升了多少试想原来我一个需求写用例要0.5天人工测试要3天而现在AI 30分钟比用例生成完30分钟完成自动化测试脚本执行算上调整case时间1个小时不到1天就能完成一轮测试仅举例具体提效时间由不同需求流程有所区别AI辅助QA的模式仍然不是终点skill命令执行目前还需要人来触发能否完全交给AI执行完AI给我测试报告我只来验收结果这正是我目前还在探索的事情利用OpenClaw等Agent把工作流完全交给AI自主完成当然在实现这一切以前先需要把skill这样的单点能力完善好后续交给AI才能更加顺利最后下方这份完整的软件测试视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​

更多文章