1. 项目概述当AI成为你的专属测试工程师最近在搞APP测试的朋友应该都体会过那种重复、枯燥但又必须保证覆盖率的痛苦。点这里、点那里录脚本、跑用例、看日志、报Bug……一套流程下来人累得够呛效率还上不去。我干了这么多年移动端测试对这种“人肉测试机”的状态深恶痛绝。直到前段时间我结合手头几个热门的AI工具和自动化框架折腾出了一个东西——我把它叫做“APP自动化测试Skill”。这玩意儿不是什么全新的测试框架而是一个基于现有成熟工具比如Appium、Playwright和AI大模型如Claude Code、Cursor构建的“智能测试代理”。它的核心思路是把测试用例的自然语言描述、甚至是模糊的业务需求直接交给AI去理解和执行让AI来充当那个不知疲倦、且具备一定“思考”能力的测试执行工程师。简单说就是你想测什么用大白话告诉它它就能自己去写脚本、跑起来、然后给你一份带截图和问题分析的测试报告。听起来是不是有点“AI替你打工”那味儿了这背后其实是“AI Agent”智能体概念在测试领域的一次落地尝试。我结合了网络热词里提到的Claude Code Skill、AI编程、自动化测试框架等元素目标是让测试人员尤其是那些对编码不那么熟悉的朋友也能轻松驾驭复杂的自动化测试。无论是测四大银行虚拟仿真app这样的金融应用还是鸿蒙app开发小项目甚至是应对自动化测试面试题里提到的各种场景这个Skill都试图提供一种更智能的解决方案。2. 核心设计思路从“写脚本”到“说需求”的范式转变传统的自动化测试无论是用Appium、Selenium还是Playwright核心流程都是人工分析需求 - 人工编写测试脚本 - 配置环境执行 - 人工分析结果。这个过程中“编写测试脚本”是最大的门槛和耗时点它要求测试人员具备良好的编程能力和对测试框架的深入理解。我这个“APP自动化测试Skill”的设计就是要打破这个模式。它的核心思路是引入一个“AI翻译层”和“决策执行层”。2.1 架构拆解三层智能测试引擎整个Skill的架构可以粗略分为三层自然语言理解与规划层这是大脑。我主要集成了类似Claude或通义灵码这类具备强大代码理解和生成能力的AI。当你输入“测试一下用户登录功能用错误密码试试再检查登录成功后的首页元素”这样的指令时这一层负责将模糊的自然语言需求拆解成具体的、可执行的测试步骤序列。它会理解“用户登录”对应哪个页面、“错误密码”是哪个测试数据、“首页元素”具体指哪些控件。脚本生成与适配层这是双手。根据规划层输出的步骤序列以及你预先配置好的项目信息如APP包名、首页Activity、控件定位策略等这一层会自动生成可执行的测试代码。这里没有重新发明轮子而是基于成熟的Python Playwright for Android/iOS或Appium框架来生成脚本。它的智能体现在能根据上下文选择最合适的定位方式如ID、XPath、文本并生成健壮的等待和断言逻辑。执行调度与反馈层这是双腿。负责调用真实的设备或模拟器执行生成的脚本并监控执行过程。关键的是它不止是跑完拉倒还会在关键步骤自动截图收集日志Logcat、Console。当测试失败时它能将错误信息、上下文截图再次反馈给AI理解层让AI尝试分析失败原因是脚本问题、环境问题还是真正的Bug甚至尝试自我修复脚本或给出明确的排查建议。注意这里完全避开了任何涉及网络代理工具的内容。所有AI交互均基于合规的、可公开访问的API如OpenAI API、国内大模型API或本地化部署的大模型来完成确保整个流程在安全、合规的环境下进行。2.2 为什么选择Playwright AI这个组合在热词里看到了Appium、Selenium、Playwright甚至还有2026年跨平台自动化测试工具这样的未来概念。我选择以Playwright为主要执行底座是经过一番考量的。跨端能力Playwright不仅支持Web对移动端Android、iOS的原生应用和混合应用测试支持也越来越成熟和稳定。一套语法几乎能通吃这符合“多终端统一测试”的趋势。稳定性与智能等待Playwright内置的自动等待机制减少了大量编写time.sleep的麻烦让AI生成的脚本更稳定不容易因为网络或渲染延迟而失败。丰富的录制与调试工具Playwright Test提供了强大的录制、追踪Trace和调试功能。当AI生成的脚本出现问题时我可以利用这些工具快速定位并把问题场景Trace文件作为上下文反馈给AI让它学习修正。而AI部分我没有局限于某一个模型。实践中我采用了一种“分工协作”的思路用Claude或GPT-4这类长文本、强推理模型做需求分析和步骤规划用Cursor或通义灵码这类深度集成IDE、更懂项目上下文的工具来做具体的代码生成和补全。这比单纯依赖一个模型效果要好得多。3. 实操搭建手把手构建你的AI测试Skill光说不练假把式。下面我就以测试一个简单的安卓计算器APP为例拆解如何从零搭建这个Skill的核心部分。我们会用到Python、Playwright for Android、以及OpenAI的API作为AI大脑示例。3.1 环境准备与基础框架搭建首先你需要一个Python环境建议3.8以及一台可供调试的安卓设备或模拟器。# 1. 创建项目目录并初始化虚拟环境 mkdir ai-test-skill cd ai-test-skill python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 2. 安装核心依赖 pip install playwright openai pytest # 安装Playwright的浏览器和Android驱动 playwright install android接下来初始化一个基础的测试项目结构。我建议使用pytest作为测试运行器它比unittest更灵活报告也更美观。# 项目结构大致如下 ai-test-skill/ ├── requirements.txt ├── conftest.py # pytest全局配置设备初始化等 ├── ai_core.py # AI交互的核心模块 ├── skill_engine.py # 技能引擎协调AI规划与脚本执行 ├── tests/ │ ├── __init__.py │ └── test_calculator_ai.py # 由AI生成的测试用例示例 └── artifacts/ # 存放测试报告、截图、日志conftest.py里我们配置好Playwright连接的安卓设备# conftest.py import pytest from playwright.sync_api import Browser, Page, sync_playwright pytest.fixture(scopesession) def android_device(): 连接到安卓设备或模拟器 playwright sync_playwright().start() # 这里假设你已通过playwright install android安装了驱动且设备已通过adb连接 # 更稳妥的方式是使用设备序列号 device playwright.devices[Pixel 5] # 或使用具体的设备描述 browser playwright.chromium.launch() context browser.new_context(**device) page context.new_page() yield page context.close() browser.close() playwright.stop()3.2 AI核心模块让机器听懂人话ai_core.py是这个Skill的大脑。它负责与AI大模型对话将测试需求转化为结构化指令。# ai_core.py import openai import json import os from typing import List, Dict, Any class AITestPlanner: def __init__(self, api_key: str, model: str gpt-4): openai.api_key api_key # 注意实际使用请从环境变量读取避免硬编码 self.model model # 定义系统角色让AI扮演一个资深的测试自动化专家 self.system_prompt 你是一个资深的移动应用测试自动化专家。你的任务是将用户用自然语言描述的测试需求转化为详细、可执行、符合Playwright for Android语法的测试步骤序列。 输出必须是一个严格的JSON数组每个元素是一个步骤对象。步骤对象包含以下字段 - action: 操作类型如 launch_app, tap, input_text, assert_text, swipe, back, screenshot等。 - target: 操作目标描述用于后续生成定位器。如“登录按钮”、“用户名输入框”。 - value: 可选操作需要的值。如输入文本、预期的断言文本。 - comment: 该步骤的注释或说明。 请根据Android应用常见交互进行合理推断。如果需求模糊请基于常见应用逻辑进行补充。 def plan_test_steps(self, requirement: str, app_info: Dict[str, Any]) - List[Dict]: 将测试需求转化为步骤计划 user_prompt f 测试需求{requirement} 应用信息{app_info} 请生成测试步骤序列。 try: response openai.ChatCompletion.create( modelself.model, messages[ {role: system, content: self.system_prompt}, {role: user, content: user_prompt} ], temperature0.2, # 低温度保证输出稳定性 ) content response.choices[0].message.content # 清理可能出现的markdown代码块标记 if content.startswith(json): content content[7:] if content.endswith(): content content[:-3] steps json.loads(content.strip()) return steps except json.JSONDecodeError as e: print(fAI返回的JSON解析失败: {e}) print(f原始返回内容: {content}) # 可以在这里加入重试或降级逻辑 return [] except Exception as e: print(f调用AI API失败: {e}) return [] def generate_playwright_code(self, steps: List[Dict], page_var_name: str page) - str: 将步骤计划转化为Playwright Python代码 code_lines [# 由AI生成的测试脚本, import pytest, ] for i, step in enumerate(steps): action step.get(action) target step.get(target, ) value step.get(value, ) comment step.get(comment, ) code_lines.append(f # 步骤{i1}: {comment}) if action launch_app: # 这里需要你事先在conftest中配置好app启动或者使用page.context.new_page()方式 # 简化处理假设app已启动 code_lines.append(f # 应用已在fixture中启动) elif action tap: # 这是一个难点如何将target描述转化为定位器 # 初级方案假设我们有一个映射表或让AI生成更具体的定位提示如“包含文本‘登录’的按钮” # 这里我们生成一个通用模板后续需要“定位器解析器”来完善 code_lines.append(f {page_var_name}.locator(\text{target}\).first.click() # 可能需要调整定位策略) elif action input_text: code_lines.append(f {page_var_name}.locator(\text{target}\).first.fill(\{value}\)) elif action assert_text: code_lines.append(f assert {page_var_name}.locator(\text{value}\).first.is_visible()) elif action screenshot: code_lines.append(f {page_var_name}.screenshot(pathf\artifacts/step_{i1}.png\)) code_lines.append() # 空行分隔 # 将代码片段包装成一个pytest测试函数 function_code f\ndef test_ai_generated({page_var_name}):\n \n.join(f {line} if line.strip() and not line.startswith(#) else line for line in code_lines) return function_code这个AITestPlanner类做了两件事plan_test_steps把自然语言需求变成结构化的步骤列表generate_playwright_code则把这个列表转换成初步的Python代码。注意这里的代码生成是“粗糙”的因为它无法精确知道控件的唯一定位器。这是当前AI在测试领域落地的核心挑战之一。为了解决它我引入了下一个关键模块。3.3 技能引擎与定位器智能解析skill_engine.py是协调中心它还有一个重要职责结合运行时上下文优化AI生成的定位器。# skill_engine.py import subprocess import tempfile import os from ai_core import AITestPlanner from playwright.sync_api import Page class TestSkillEngine: def __init__(self, ai_planner: AITestPlanner, app_package: str, app_activity: str None): self.ai_planner ai_planner self.app_package app_package self.app_activity app_activity self.locator_strategy_priority [text, role, id, xpath] # 定位策略优先级 def execute_requirement(self, requirement: str, page: Page): 核心执行流程需求 - AI规划 - 代码生成与优化 - 执行 print(f处理需求: {requirement}) # 1. AI规划步骤 app_info {package: self.app_package, activity: self.app_activity} steps self.ai_planner.plan_test_steps(requirement, app_info) if not steps: print(AI规划失败退出。) return print(fAI生成{len(steps)}个步骤。) # 2. 动态优化步骤中的定位器关键 optimized_steps self._optimize_locators(steps, page) # 3. 生成最终可执行代码或直接解释执行 # 这里演示直接解释执行优化后的步骤更灵活 self._interpret_and_execute_steps(optimized_steps, page) def _optimize_locators(self, steps: List[Dict], page: Page) - List[Dict]: 尝试优化步骤中的定位器描述。 这是一个简化版。理想情况下可以 a) 利用Playwright的page.locator(selector).all()获取所有匹配元素结合AI描述选择最可能的一个。 b) 使用OCR识别屏幕文本辅助定位。 c) 维护一个页面元素映射库Page Object Model。 optimized [] for step in steps: opt_step step.copy() target_desc step.get(target, ) # 如果target是明确的文本我们可以直接使用 if target_desc and 按钮 in target_desc: # 尝试提取按钮文本例如从“登录按钮”提取“登录” possible_text target_desc.replace(按钮, ).strip() # 检查页面上是否存在这个文本 if page.locator(ftext{possible_text}).count() 0: opt_step[_resolved_locator] ftext{possible_text} else: # 如果找不到回退到原始描述执行时可能需要更复杂的逻辑 opt_step[_resolved_locator] target_desc else: opt_step[_resolved_locator] target_desc optimized.append(opt_step) return optimized def _interpret_and_execute_steps(self, steps: List[Dict], page: Page): 解释并执行优化后的步骤序列 for i, step in enumerate(steps): action step.get(action) locator step.get(_resolved_locator, step.get(target, )) value step.get(value, ) print(f执行步骤{i1}: {action} - {locator}) try: if action tap or action click: # 使用优化后的定位器 page.locator(locator).first.click() elif action input_text: page.locator(locator).first.fill(value) elif action assert_text: assert page.locator(ftext{value}).first.is_visible(), f未找到文本: {value} elif action screenshot: page.screenshot(pathfartifacts/step_{i1}_{action}.png) # ... 其他action处理 page.wait_for_timeout(500) # 步骤间短暂等待观察效果 except Exception as e: print(f步骤{i1}执行失败: {e}) page.screenshot(pathfartifacts/error_step_{i1}.png) # 这里可以加入失败处理逻辑比如尝试备用定位器或者记录错误后继续 # 对于关键步骤可以选择break break这个引擎的关键在于_optimize_locators方法。它试图在运行时将AI生成的模糊描述如“登录按钮”与当前页面上的实际元素进行匹配。这是一个持续优化的过程你可以通过集成OCR、维护控件资源ID白名单、甚至让AI学习分析UI层级结构通过page.locator(*).all_inner_texts()获取来不断增强它的解析能力。3.4 编写你的第一个AI驱动测试用例现在我们把所有部分组合起来。在tests/test_calculator_ai.py中# tests/test_calculator_ai.py import sys import os sys.path.append(os.path.dirname(os.path.dirname(__file__))) from skill_engine import TestSkillEngine from ai_core import AITestPlanner def test_ai_calculator(android_device): # 1. 启动被测应用这里以系统计算器为例包名可能不同 # 更优的方式是通过android_device.context.new_page()连接到一个已启动的app # 这里简化处理假设页面已经指向了计算器APP page android_device # 你可以通过ADB命令启动特定App # subprocess.run([adb, shell, am, start, -n, com.android.calculator2/.Calculator]) # 2. 初始化AI规划器和技能引擎 # 注意请将YOUR_OPENAI_API_KEY替换为你的实际API Key或从环境变量读取 api_key os.getenv(OPENAI_API_KEY, YOUR_OPENAI_API_KEY) planner AITestPlanner(api_keyapi_key, modelgpt-3.5-turbo) # 先用3.5测试成本低 engine TestSkillEngine(ai_plannerplanner, app_packagecom.android.calculator2) # 3. 定义你的测试需求用自然语言 test_requirement 测试安卓计算器应用的基本运算功能。 1. 先点击清除按钮如果有的话确保计算器归零。 2. 输入数字 12。 3. 点击加法按钮 。 4. 输入数字 34。 5. 点击等号按钮 。 6. 验证结果区域是否显示正确的结果 46。 7. 在点击等号后截图保存。 # 4. 让AI技能引擎去执行 engine.execute_requirement(test_requirement, page) # 5. 断言可以放在引擎内部也可以在这里补充。 # 因为我们在需求中已经包含了验证步骤引擎会执行assert。 # 这里可以添加一些最终的全局断言 # assert page.locator(text46).is_visible()运行这个测试pytest tests/test_calculator_ai.py -v如果一切顺利你会看到AI规划出的步骤被逐个执行控制台有日志输出并且在artifacts文件夹下会生成每一步的截图。这就是“AI替你打工”的雏形你只需要用中文描述想测什么剩下的脚本生成、定位适配、执行和验证都由这个Skill来尝试完成。4. 避坑指南与效能提升实战理想很丰满但第一次跑通后你肯定会遇到各种问题。下面是我在开发这个Skill过程中踩过的坑和总结的优化技巧。4.1 定位器解析从“玄学”到“科学”问题AI生成的“登录按钮”在代码里写成page.locator(text登录按钮)但实际APP里这个按钮的文本可能就是“登录”或者它根本没有文本只有一个图标。直接执行必然失败。解决方案建立多级回退的定位器解析策略。首选精确匹配尝试用AI描述中的核心词如“登录”进行文本定位。角色与属性回退如果文本定位失败尝试通过角色rolebutton结合其他属性如aria-label,content-desc来定位。这需要你获取APP的UI层级信息。可以通过page.locator(*).all()遍历并打印元素的属性来构建知识库。坐标点击最后手段对于某些极度动态或难以定位的元素在特定屏幕分辨率下可以记录相对坐标。但这种方法非常脆弱不推荐作为主要方案。让AI学习你的APP在系统提示词system_prompt里加入你APP特有的控件描述。例如“该应用的登录按钮的resource-id是com.example.app:id/btn_login或者其文本是‘Sign In’。” AI在生成步骤时会倾向于使用这些已知信息。我在skill_engine.py的_optimize_locators方法里实现了简单的文本提取和匹配但这只是起点。一个更高级的实现是在第一次成功执行某个流程后将(页面状态描述, 目标描述, 成功定位器)作为样本保存下来形成一个不断增长的定位器映射库供后续相似需求直接使用或供AI参考。4.2 处理动态内容与异步加载问题AI生成的脚本是线性的click()之后立刻assert但页面可能还在加载导致断言失败。解决方案在AI生成代码或引擎解释执行时强制注入等待逻辑。隐式等待Playwright本身有自动等待但对于网络请求或复杂动画可能需要更长时间。可以在引擎执行每个click、fill操作后添加一个针对下一个预期元素出现的显式等待。# 在执行click后不是直接执行下一步而是 page.locator(locator).first.click() # 等待下一个操作的目标元素出现或者等待一个网络请求完成 page.wait_for_selector(next_locator, statevisible, timeout10000)让AI感知“等待”在给AI的系统提示词中明确说明“在可能引起页面跳转或内容刷新的操作如点击提交按钮、跳转标签页后应添加等待页面稳定或特定元素出现的步骤。” AI在规划时就会主动插入sleep或wait_for_selector步骤。4.3 测试数据管理与场景扩展问题测试需求里说“用错误密码试试”AI知道要输入错误密码但“错误密码”具体是什么是固定的“wrong”还是需要从数据池里随机取一个解决方案将测试数据与测试逻辑分离并让AI学会调用数据池。建立测试数据文件创建一个test_data.json或data_pool.py定义如invalid_passwords [, 123, wrongpassword, admin123]。增强AI提示词告诉AI“当需要测试数据时请使用data_pool.get_invalid_password()这样的函数调用来表示而不是硬编码具体值。”引擎后处理在_interpret_and_execute_steps阶段检测到步骤的value字段包含特定的函数调用标记如{{get_invalid_password}}就将其替换为从数据池中取出的真实值。这样你的一句“用5个不同的无效用户名和密码组合测试登录”AI就能规划出循环结构并调用数据池生成覆盖更广的测试。4.4 报告生成与失败分析智能化问题测试失败了是脚本问题、环境问题还是真的Bug只看日志和截图判断起来费时费力。解决方案让Skill不仅会执行还要会初步分析。丰富执行上下文在每次测试执行时除了截图额外捕获当前页面源码page.content()或可访问的UI树结构。控制台日志page.on(console, ...)。网络请求列表如果权限允许。失败时调用AI诊断当assert失败或发生异常时将错误信息、最后一张截图、以及之前的页面状态描述打包发送给AI可以换用一个更擅长分析的模型如GPT-4。提示词示例“以下是一个自动化测试失败的场景。错误信息是AssertionError: Element not found。这是失败前的屏幕截图描述[截图描述]。这是测试试图执行的操作点击‘提交’按钮。请分析可能的原因并按可能性排序A. 定位器不准确B. 页面未加载完成C. 元素被遮挡D. 应用出现了Bug如按钮不可点击。请给出下一步排查建议。”自动生成诊断报告将AI的分析结果连同原始的执行日志和截图整合成一份HTML报告。这份报告不仅能告诉你“失败了”还能给出“可能是什么原因”和“接下来该看哪里”的建议极大提升排查效率。5. 进阶构想从Skill到自主测试Agent目前这个Skill还处于“你指挥它执行”的阶段。结合热词中的AI Agent概念我们可以展望它的进化形态目标驱动测试你不再需要描述步骤只需要给出一个业务目标如“确保用户从注册到支付下单的全流程畅通”。Agent自己会去探索APP识别出关键路径注册、登录、浏览商品、加入购物车、支付并自动生成覆盖这些路径的测试用例集甚至尝试探索边界情况如支付时断网。视觉理解强化集成pytesseract或EasyOCR等OCR库以及轻量级的图像识别模型让Agent能真正“看到”屏幕理解那些无法通过无障碍服务获取的UI元素如自定义图形按钮、验证码等。这能从根本上解决动态定位的难题。自学习与自适应Agent在测试过程中会记录哪些定位器是稳定的哪些是脆弱的。对于脆弱的定位器它会尝试寻找更稳定的替代方案如用相对坐标组合其他属性并将这个经验更新到自己的知识库中。下次遇到类似页面它会优先使用更优方案。与开发流程集成这个Skill可以作为一个GitHub Action或GitLab CI/CD的环节。每当开发提交新代码Agent自动拉取最新的APK/IPA运行核心场景的自动化测试并将智能分析后的报告直接评论在Merge Request上。这实现了真正的“AI测试左移”。实现这些进阶功能需要更多的工程工作和算法集成但核心思想不变将测试人员从重复、低价值的脚本编写和执行中解放出来让他们专注于更高级的测试设计、质量分析和风险评估。让AI去处理那些它擅长的模式识别、重复劳动和初步分析让人去做需要创造力和深度思考的工作。这才是“AI替你打工”的真正意义。这条路还很长我分享的这个Skill只是一个起点。它可能还不完美运行中会遇到各种奇怪的失败但每一次调试和优化都是让测试工作变得更智能、更高效的一步。如果你也在做类似的事情或者有更好的想法欢迎一起交流。毕竟让机器干机器该干的活我们才能去做更有意思的事。