1. 项目概述与核心价值最近在搞移动端应用的质量保障一个绕不开的痛点就是回归测试和性能监控。手动点点点不仅效率低下还容易遗漏尤其是在需要获取启动时间、页面渲染耗时这些性能指标时纯手工几乎不可能做到精准和重复。于是一套基于 Python整合了 ADB 和 Appium 的自动化方案就成了我的首选。这个方案的核心目标很明确实现 UI 自动化操作并在此过程中精准抓取应用的关键性能耗时数据。简单来说它就像给测试工程师配了一个不知疲倦的“数字员工”。这个员工能严格按照预设的脚本在手机或模拟器上打开应用、点击按钮、输入文字、滑动页面完成一系列复杂的业务流程。更重要的是在它执行这些操作的同时还能像一名专业的性能分析师一样默默地记录下每一个关键动作所花费的时间比如应用从点击图标到首页完全加载出来用了多久从列表页进入详情页的跳转是否流畅。这些数据对于评估应用版本迭代后的性能表现、定位卡顿和耗电问题至关重要。这套方案特别适合移动端测试工程师、质量保障QA人员以及对应用性能有要求的开发者。即使你 Python 刚入门只要跟着步骤走也能搭建起来。它的优势在于Appium 提供了跨平台iOS/Android的统一 API写一套脚本能跑两个平台而 ADB 则是我们深入 Android 系统内部获取底层性能数据的“瑞士军刀”。两者结合既解决了“做什么”自动化操作也解决了“看得多细”性能监控的问题。2. 环境搭建与工具链选型工欲善其事必先利其器。在开始写自动化脚本之前一个稳定、兼容的环境是基石。这里我会详细拆解每一步的安装和配置并解释为什么选这些工具以及如何避开常见的坑。2.1 Python 环境与核心库安装Python 是这个项目的“大脑”我们选择 Python 3.7 及以上版本主要是为了更好的库兼容性和语言特性支持。安装过程很简单从官网下载安装包记得勾选“Add Python to PATH”这样就能在命令行里直接使用python和pip命令了。安装好 Python 后我们需要通过 pip 安装几个核心的库pip install Appium-Python-Client pip install pytest pip install openpyxl # 可选用于将结果写入ExcelAppium-Python-Client: 这是 Appium 官方提供的 Python 语言客户端库它封装了与 Appium 服务器通信的所有细节让我们能用 Python 代码轻松发送各种自动化指令如点击、滑动、查找元素。pytest: 一个非常强大的测试框架。我们不仅可以用它来组织和管理我们的测试用例更重要的是它的 Fixture 机制能优雅地处理测试前置如启动 Appium 会话和后置如关闭会话、生成报告工作让脚本结构更清晰。openpyxl: 这是一个可选库。当我们的性能测试跑完后会产生一堆时间数据直接打印在控制台不便于分析和存档。用 openpyxl 可以把数据规整地写入 Excel 表格方便后续做图表和趋势分析。注意国内网络使用 pip 安装可能会很慢或失败建议配置清华源或阿里云等国内镜像源。命令如pip install Appium-Python-Client -i https://pypi.tuna.tsinghua.edu.cn/simple2.2 ADB 工具配置与验证ADBAndroid Debug Bridge是 Android 开发/测试的“桥梁”。我们用它来连接设备、安装应用、拉取日志以及最关键的一步——获取性能数据。下载与安装从 Android 开发者官网下载 “Platform-Tools” 包解压到一个你喜欢的路径例如D:\android\platform-tools。配置环境变量这是最容易出错的一步。将刚才解压的platform-tools目录的完整路径添加到系统的PATH环境变量中。添加完成后务必重新打开你的命令行终端CMD 或 PowerShell让新的环境变量生效。验证连接用 USB 线连接你的 Android 手机并在手机上开启“开发者选项”中的“USB 调试”功能。然后在命令行输入adb devices如果看到设备列表中出现你的设备序列号后面跟着device字样而不是unauthorized恭喜你ADB 连接成功。如果显示unauthorized需要在手机屏幕上点击确认允许调试。为什么必须用 ADB因为 Appium 本身虽然能驱动应用但对于一些细粒度的、系统层面的性能数据抓取如 CPU 占用率、内存详细数据、FPS直接通过其 API 获取并不方便或不够精确。而 ADB 命令如adb shell dumpsys gfxinfo package_name可以获取渲染性能数据adb shell top可以查看实时进程资源占用这些是性能分析的金矿。2.3 Appium Server 的安装与启动Appium 是一个开源工具它扮演着“翻译官”的角色。我们的 Python 脚本发送指令给 Appium ServerAppium Server 再将其翻译成手机系统UIAutomator2 for Android, XCUITest for iOS能理解的指令从而控制应用。安装最推荐的方式是通过 Node.js 的包管理器 npm 来安装。首先确保安装了 Node.js然后命令行运行npm install -g appium这会在全局安装 Appium。你也可以使用 Appium 官方提供的桌面版Appium Desktop图形界面对于初学者查看元素结构非常友好。驱动安装Appium 2.0 之后驱动需要单独安装。对于 Android我们需要安装uiautomator2驱动appium driver install uiautomator2启动服务器在命令行输入appium即可启动默认设置在本地 4723 端口的 Appium 服务器。你会看到一串日志输出最后有listening on 0.0.0.0:4723就表示启动成功。让这个命令行窗口保持运行不要关闭。实操心得在正式跑自动化脚本前我强烈建议先用 Appium Desktop 的 Inspector 功能连接你的应用。用它来查看页面元素的属性如 resource-id, class, text这些属性是我们后续写脚本定位元素的关键依据。光靠猜元素定位方式会浪费大量时间在调试脚本上。3. 自动化脚本核心架构设计环境准备好后我们来设计脚本的骨架。一个好的架构能让脚本易于维护、扩展和复用。这里我采用 “Page Object Model (POM)” 设计模式并结合 pytest 来组织。3.1 能力配置与驱动初始化所有与 Appium 的交互都始于一个Desired Capabilities配置字典。它告诉 Appium Server你要测试哪个应用在什么设备上测试用什么引擎from appium import webdriver from appium.options.android import UiAutomator2Options def get_driver(): options UiAutomator2Options() options.platform_name Android # 平台 options.device_name your_device_serial # 通过adb devices获取 options.app_package com.example.myapp # 被测应用包名 options.app_activity .MainActivity # 应用启动Activity options.automation_name uiautomator2 # 自动化引擎 options.no_reset True # 是否在会话间重置应用状态如登录信息 # 连接Appium服务器并传入配置 driver webdriver.Remote(http://127.0.0.1:4723, optionsoptions) return driver关键参数解析device_name: 这里最好填写adb devices列出的设备序列号在多设备时能精确指定。app_package和app_activity: 如何获取有两个方法1) 问开发2) 在已安装应用的手机上执行adb shell dumpsys window | findstr mCurrentFocusWindows或grepMac/Linux当前最上层活动的信息里就包含包名和 Activity。no_reset: 设为True意味着 Appium 不会在每次测试开始前清除应用数据。这对于需要登录状态的测试流程非常有用可以避免每次都要走登录流程。3.2 页面对象模型封装POM 模式的核心思想是将每个应用页面封装成一个类页面上的元素和操作就是这个类的方法。这样当页面 UI 改动时我们只需要修改对应的页面类而不需要到处修改测试脚本。# base_page.py class BasePage: def __init__(self, driver): self.driver driver def find_element(self, locator): # 添加显式等待提高脚本稳定性 from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element WebDriverWait(self.driver, 10).until( EC.presence_of_element_located(locator) ) return element # login_page.py from appium.webdriver.common.appiumby import AppiumBy from base_page import BasePage class LoginPage(BasePage): # 定位器 username_input (AppiumBy.ID, com.example.myapp:id/et_username) password_input (AppiumBy.ID, com.example.myapp:id/et_password) login_button (AppiumBy.ID, com.example.myapp:id/btn_login) def input_username(self, username): self.find_element(self.username_input).send_keys(username) def input_password(self, password): self.find_element(self.password_input).send_keys(password) def click_login(self): self.find_element(self.login_button).click()为什么用 POM假设登录按钮的 ID 变了。在非 POM 的脚本里你可能在 10 个不同的测试用例里都写了定位这个按钮的代码你需要改10次。而在 POM 中你只需要在LoginPage类里修改一次login_button这个定位器所有用例自动生效。这极大地提升了维护性。3.3 测试用例与性能采集点融合我们用 pytest 来写测试用例并把性能采集的逻辑嵌入到关键的测试步骤中。# test_performance.py import pytest from login_page import LoginPage from home_page import HomePage import time class TestAppPerformance: pytest.fixture(scopeclass) def driver(self): 启动驱动整个测试类只执行一次 drv get_driver() yield drv drv.quit() def test_cold_start_time(self, driver): 测试冷启动时间 # 1. 确保应用已关闭 driver.terminate_app(com.example.myapp) # 2. 开始计时 start_time time.time() # 3. 启动应用 driver.activate_app(com.example.myapp) # 4. 等待并确认首页特定元素出现标志着启动完成 home_page HomePage(driver) home_page.wait_for_welcome_text() # 假设这个方法会等待欢迎语出现 # 5. 结束计时 end_time time.time() launch_time end_time - start_time print(f应用冷启动耗时{launch_time:.2f}秒) # 这里可以将 launch_time 写入文件或数据库 assert launch_time 3.0, f启动时间{launch_time}秒超过3秒阈值 def test_login_flow_performance(self, driver): 测试登录流程性能 login_page LoginPage(driver) # 记录进入登录页的时间点可通过页面特定元素出现来判断 login_page_start time.time() login_page.input_username(testuser) login_page.input_password(testpass) # 记录点击登录按钮前的时间点 before_click time.time() login_page.click_login() # 等待登录成功后的页面跳转如首页出现 home_page HomePage(driver) home_page.wait_for_avatar() login_complete time.time() input_time before_click - login_page_start navigate_time login_complete - before_click total_login_time login_complete - login_page_start print(f登录流程 - 输入耗时{input_time:.2f}秒 跳转耗时{navigate_time:.2f}秒 总耗时{total_login_time:.2f}秒)在这个例子中我们不仅测试了功能能否登录还精准地测量了“冷启动”和“登录流程”两个关键场景的耗时。time.time()提供了高精度的计时。更复杂的性能数据则需要借助 ADB。4. 关键性能指标获取与ADB深度集成UI 操作的时间只是性能的一面。要全面评估应用我们还需要获取系统层面的资源消耗数据。这时就需要在 Python 脚本中调用 ADB 命令。4.1 封装 ADB 命令执行器我们可以在 Python 中通过subprocess模块来执行 ADB 命令并获取结果。import subprocess import re class ADBHelper: staticmethod def run_adb_command(cmd): 执行ADB命令并返回输出 full_cmd fadb {cmd} try: result subprocess.run(full_cmd, shellTrue, capture_outputTrue, textTrue, timeout10) if result.returncode 0: return result.stdout.strip() else: print(fADB命令执行失败: {result.stderr}) return None except subprocess.TimeoutExpired: print(fADB命令执行超时: {full_cmd}) return None staticmethod def get_cpu_memory(package_name): 获取指定包名应用的CPU和内存占用 # 获取CPU占用有些系统需要多次采样取平均 cpu_info ADBHelper.run_adb_command(fshell top -n 1 | findstr {package_name}) # 获取内存占用PSS mem_info ADBHelper.run_adb_command(fshell dumpsys meminfo {package_name} | findstr TOTAL) # 这里需要解析返回的文本提取数字 cpu ADBHelper._parse_cpu(cpu_info) mem ADBHelper._parse_memory(mem_info) return cpu, mem staticmethod def _parse_cpu(cpu_str): # 简易解析实际字符串可能为 com.example.myapp 10% 1% ... if cpu_str: parts cpu_str.split() if len(parts) 2: return parts[2].rstrip(%) # 假设CPU百分比在第三列 return N/A staticmethod def get_fps(package_name): 获取应用帧率信息适用于Android 4.1需开启GPU渲染模式 # 先清空旧的帧信息 ADBHelper.run_adb_command(fshell dumpsys gfxinfo {package_name} reset) # 进行一段UI操作这需要你的自动化脚本触发 # ... # 然后获取帧数据 fps_info ADBHelper.run_adb_command(fshell dumpsys gfxinfo {package_name}) # 解析输出计算掉帧Jank次数或平均FPS # 输出格式包含“Profile data in ms”部分列出了每帧渲染的耗时 frames ADBHelper._parse_gfxinfo(fps_info) # 简单计算假设16.67ms为一帧的基准60FPS超过16.67ms的帧视为掉帧 jank_count sum(1 for frame in frames if frame 16.67) return len(frames), jank_count4.2 在自动化流程中集成性能监控现在我们将 ADB 性能采集点插入到之前的测试流程中形成完整的性能测试用例。def test_comprehensive_performance(self, driver, adb_helper): 综合性能测试操作流 资源监控 performance_data [] # 场景1冷启动 driver.terminate_app(com.example.myapp) start_cpu_mem adb_helper.get_cpu_memory(com.example.myapp) # 启动前基线 start_time time.time() driver.activate_app(com.example.myapp) HomePage(driver).wait_for_welcome_text() cold_launch_time time.time() - start_time after_launch_cpu_mem adb_helper.get_cpu_memory(com.example.myapp) # 启动后 performance_data.append({ 场景: 冷启动, 耗时(秒): cold_launch_time, 启动前CPU(%): start_cpu_mem[0], 启动后CPU(%): after_launch_cpu_mem[0], 启动后内存(MB): after_launch_cpu_mem[1] }) # 场景2复杂列表滑动 home_page HomePage(driver) home_page.go_to_news_list() list_page NewsListPage(driver) # 滑动前获取一次FPS基线 total_frames_before, jank_before adb_helper.get_fps(com.example.myapp) # 执行多次快速滑动 for i in range(5): list_page.swipe_up_quick() time.sleep(0.5) # 滑动间隔 # 滑动后获取FPS数据 total_frames_after, jank_after adb_helper.get_fps(com.example.myapp) jank_during_swipe jank_after - jank_before performance_data.append({ 场景: 列表快速滑动, 滑动帧数: total_frames_after - total_frames_before, 掉帧次数: jank_during_swipe, 滑动后CPU(%): adb_helper.get_cpu_memory(com.example.myapp)[0] }) # 将performance_data写入Excel或日志文件 self._write_to_report(performance_data)通过这种方式我们在一个自动化测试流程中同步采集了时间性能启动耗时和系统资源性能CPU、内存、FPS/掉帧。这些数据结合在一起才能对应用性能做出全面评估。5. 实战技巧、常见问题与优化策略在实际项目中摸爬滚打我积累了一些脚本稳定性和效率提升的经验也踩过不少坑。5.1 提升脚本稳定性的关键使用显式等待告别time.sleep这是最重要的原则。不要用固定的time.sleep(10)而要用WebDriverWait配合expected_conditions。因为网络、设备性能会导致元素加载时间不定。固定等待要么浪费时间等太久要么导致失败等不够。# 坏味道 time.sleep(5) driver.find_element(...).click() # 好习惯 from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((AppiumBy.ID, some_id)) ) element.click()元素定位策略优先级优先使用resource-id(Android) 或accessibility-id(iOS)因为它们是唯一且稳定的。其次是xpath但尽量使用相对路径和非索引依赖的表达式因为 UI 结构容易变化。class和text容易重复需谨慎使用。异常处理与截图在关键操作步骤周围添加try...except并在失败时自动截图能极大提升调试效率。from datetime import datetime try: login_page.click_login() except Exception as e: timestamp datetime.now().strftime(%Y%m%d_%H%M%S) driver.get_screenshot_as_file(fscreenshot_failure_{timestamp}.png) print(f登录点击失败: {e}) raise # 重新抛出异常让测试失败5.2 常见问题排查清单问题现象可能原因排查步骤SessionNotCreatedExceptionDesired Capabilities 配置错误Appium 与设备/应用不兼容。1. 检查appPackage和appActivity是否正确。2. 确认设备已通过adb devices连接。3. 查看 Appium Server 日志通常有详细错误信息。NoSuchElementException元素定位器错误页面未加载完成元素在 WebView 内。1. 用 Appium Inspector 确认定位器。2. 添加显式等待等待元素出现。3. 如果是 WebView需要driver.switch_to.context(WEBVIEW_xxx)切换上下文。脚本执行速度慢使用了大量固定sleep网络或设备响应慢。1. 将sleep替换为显式等待。2. 检查设备性能关闭不必要的后台应用。3. 考虑在 WiFi 而非 USB 下执行需相应配置。ADB 命令无返回或超时设备断开连接ADB 服务异常命令本身执行慢。1. 重新执行adb devices确认连接。2. 重启 ADB 服务adb kill-server adb start-server。3. 对于dumpsys等可能较慢的命令增加subprocess的timeout参数。性能数据波动大系统后台干扰测试环境不干净单次采样不具代表性。1. 测试前重启设备清理后台。2. 同一场景多次测试取平均值或中位数。3. 在固定的、性能稳定的设备上运行性能测试。5.3 高级优化与扩展方向当基础框架跑通后可以考虑以下方向来提升整个方案的效能和深度并发测试使用pytest-xdist插件可以实现测试用例的分布式执行同时控制多台设备运行不同的测试套件大幅缩短测试总时间。与 CI/CD 集成将你的自动化性能测试脚本集成到 Jenkins、GitLab CI 等持续集成平台。每次开发提交代码后自动触发一轮核心场景的自动化测试和性能采集实现质量卡点。性能基线管理不要只关注单次数据。建立一个性能基线数据库将每次测试的结果如启动时间、内存值存储起来。在测试报告中不仅展示当前值还要与历史基线如前一个版本进行对比自动判断是否出现性能回归如耗时增长超过10%。更丰富的性能指标除了启动时间、CPU、内存、FPS还可以探索电量消耗使用adb shell dumpsys batterystats进行粗略评估或借助专业硬件工具。网络流量使用adb shell cat /proc/net/xt_qtaguid/stats或tcpdump抓包分析。流畅度分析除了dumpsys gfxinfo高版本 Android 可以使用FrameMetricsAPI 获取更精确的帧耗时分布。这套基于 Python ADB Appium 的自动化及性能获取方案本质上是一个高度可定制的工具箱。从简单的点击计时到复杂的系统资源监控其深度和广度取决于你的需求。开始时可以从一个核心场景如启动做起逐步丰富你的“性能探针”最终构建起覆盖核心用户体验路径的自动化性能监控体系让性能回归无所遁形。
1. 项目概述与核心价值最近在搞移动端应用的质量保障一个绕不开的痛点就是回归测试和性能监控。手动点点点不仅效率低下还容易遗漏尤其是在需要获取启动时间、页面渲染耗时这些性能指标时纯手工几乎不可能做到精准和重复。于是一套基于 Python整合了 ADB 和 Appium 的自动化方案就成了我的首选。这个方案的核心目标很明确实现 UI 自动化操作并在此过程中精准抓取应用的关键性能耗时数据。简单来说它就像给测试工程师配了一个不知疲倦的“数字员工”。这个员工能严格按照预设的脚本在手机或模拟器上打开应用、点击按钮、输入文字、滑动页面完成一系列复杂的业务流程。更重要的是在它执行这些操作的同时还能像一名专业的性能分析师一样默默地记录下每一个关键动作所花费的时间比如应用从点击图标到首页完全加载出来用了多久从列表页进入详情页的跳转是否流畅。这些数据对于评估应用版本迭代后的性能表现、定位卡顿和耗电问题至关重要。这套方案特别适合移动端测试工程师、质量保障QA人员以及对应用性能有要求的开发者。即使你 Python 刚入门只要跟着步骤走也能搭建起来。它的优势在于Appium 提供了跨平台iOS/Android的统一 API写一套脚本能跑两个平台而 ADB 则是我们深入 Android 系统内部获取底层性能数据的“瑞士军刀”。两者结合既解决了“做什么”自动化操作也解决了“看得多细”性能监控的问题。2. 环境搭建与工具链选型工欲善其事必先利其器。在开始写自动化脚本之前一个稳定、兼容的环境是基石。这里我会详细拆解每一步的安装和配置并解释为什么选这些工具以及如何避开常见的坑。2.1 Python 环境与核心库安装Python 是这个项目的“大脑”我们选择 Python 3.7 及以上版本主要是为了更好的库兼容性和语言特性支持。安装过程很简单从官网下载安装包记得勾选“Add Python to PATH”这样就能在命令行里直接使用python和pip命令了。安装好 Python 后我们需要通过 pip 安装几个核心的库pip install Appium-Python-Client pip install pytest pip install openpyxl # 可选用于将结果写入ExcelAppium-Python-Client: 这是 Appium 官方提供的 Python 语言客户端库它封装了与 Appium 服务器通信的所有细节让我们能用 Python 代码轻松发送各种自动化指令如点击、滑动、查找元素。pytest: 一个非常强大的测试框架。我们不仅可以用它来组织和管理我们的测试用例更重要的是它的 Fixture 机制能优雅地处理测试前置如启动 Appium 会话和后置如关闭会话、生成报告工作让脚本结构更清晰。openpyxl: 这是一个可选库。当我们的性能测试跑完后会产生一堆时间数据直接打印在控制台不便于分析和存档。用 openpyxl 可以把数据规整地写入 Excel 表格方便后续做图表和趋势分析。注意国内网络使用 pip 安装可能会很慢或失败建议配置清华源或阿里云等国内镜像源。命令如pip install Appium-Python-Client -i https://pypi.tuna.tsinghua.edu.cn/simple2.2 ADB 工具配置与验证ADBAndroid Debug Bridge是 Android 开发/测试的“桥梁”。我们用它来连接设备、安装应用、拉取日志以及最关键的一步——获取性能数据。下载与安装从 Android 开发者官网下载 “Platform-Tools” 包解压到一个你喜欢的路径例如D:\android\platform-tools。配置环境变量这是最容易出错的一步。将刚才解压的platform-tools目录的完整路径添加到系统的PATH环境变量中。添加完成后务必重新打开你的命令行终端CMD 或 PowerShell让新的环境变量生效。验证连接用 USB 线连接你的 Android 手机并在手机上开启“开发者选项”中的“USB 调试”功能。然后在命令行输入adb devices如果看到设备列表中出现你的设备序列号后面跟着device字样而不是unauthorized恭喜你ADB 连接成功。如果显示unauthorized需要在手机屏幕上点击确认允许调试。为什么必须用 ADB因为 Appium 本身虽然能驱动应用但对于一些细粒度的、系统层面的性能数据抓取如 CPU 占用率、内存详细数据、FPS直接通过其 API 获取并不方便或不够精确。而 ADB 命令如adb shell dumpsys gfxinfo package_name可以获取渲染性能数据adb shell top可以查看实时进程资源占用这些是性能分析的金矿。2.3 Appium Server 的安装与启动Appium 是一个开源工具它扮演着“翻译官”的角色。我们的 Python 脚本发送指令给 Appium ServerAppium Server 再将其翻译成手机系统UIAutomator2 for Android, XCUITest for iOS能理解的指令从而控制应用。安装最推荐的方式是通过 Node.js 的包管理器 npm 来安装。首先确保安装了 Node.js然后命令行运行npm install -g appium这会在全局安装 Appium。你也可以使用 Appium 官方提供的桌面版Appium Desktop图形界面对于初学者查看元素结构非常友好。驱动安装Appium 2.0 之后驱动需要单独安装。对于 Android我们需要安装uiautomator2驱动appium driver install uiautomator2启动服务器在命令行输入appium即可启动默认设置在本地 4723 端口的 Appium 服务器。你会看到一串日志输出最后有listening on 0.0.0.0:4723就表示启动成功。让这个命令行窗口保持运行不要关闭。实操心得在正式跑自动化脚本前我强烈建议先用 Appium Desktop 的 Inspector 功能连接你的应用。用它来查看页面元素的属性如 resource-id, class, text这些属性是我们后续写脚本定位元素的关键依据。光靠猜元素定位方式会浪费大量时间在调试脚本上。3. 自动化脚本核心架构设计环境准备好后我们来设计脚本的骨架。一个好的架构能让脚本易于维护、扩展和复用。这里我采用 “Page Object Model (POM)” 设计模式并结合 pytest 来组织。3.1 能力配置与驱动初始化所有与 Appium 的交互都始于一个Desired Capabilities配置字典。它告诉 Appium Server你要测试哪个应用在什么设备上测试用什么引擎from appium import webdriver from appium.options.android import UiAutomator2Options def get_driver(): options UiAutomator2Options() options.platform_name Android # 平台 options.device_name your_device_serial # 通过adb devices获取 options.app_package com.example.myapp # 被测应用包名 options.app_activity .MainActivity # 应用启动Activity options.automation_name uiautomator2 # 自动化引擎 options.no_reset True # 是否在会话间重置应用状态如登录信息 # 连接Appium服务器并传入配置 driver webdriver.Remote(http://127.0.0.1:4723, optionsoptions) return driver关键参数解析device_name: 这里最好填写adb devices列出的设备序列号在多设备时能精确指定。app_package和app_activity: 如何获取有两个方法1) 问开发2) 在已安装应用的手机上执行adb shell dumpsys window | findstr mCurrentFocusWindows或grepMac/Linux当前最上层活动的信息里就包含包名和 Activity。no_reset: 设为True意味着 Appium 不会在每次测试开始前清除应用数据。这对于需要登录状态的测试流程非常有用可以避免每次都要走登录流程。3.2 页面对象模型封装POM 模式的核心思想是将每个应用页面封装成一个类页面上的元素和操作就是这个类的方法。这样当页面 UI 改动时我们只需要修改对应的页面类而不需要到处修改测试脚本。# base_page.py class BasePage: def __init__(self, driver): self.driver driver def find_element(self, locator): # 添加显式等待提高脚本稳定性 from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element WebDriverWait(self.driver, 10).until( EC.presence_of_element_located(locator) ) return element # login_page.py from appium.webdriver.common.appiumby import AppiumBy from base_page import BasePage class LoginPage(BasePage): # 定位器 username_input (AppiumBy.ID, com.example.myapp:id/et_username) password_input (AppiumBy.ID, com.example.myapp:id/et_password) login_button (AppiumBy.ID, com.example.myapp:id/btn_login) def input_username(self, username): self.find_element(self.username_input).send_keys(username) def input_password(self, password): self.find_element(self.password_input).send_keys(password) def click_login(self): self.find_element(self.login_button).click()为什么用 POM假设登录按钮的 ID 变了。在非 POM 的脚本里你可能在 10 个不同的测试用例里都写了定位这个按钮的代码你需要改10次。而在 POM 中你只需要在LoginPage类里修改一次login_button这个定位器所有用例自动生效。这极大地提升了维护性。3.3 测试用例与性能采集点融合我们用 pytest 来写测试用例并把性能采集的逻辑嵌入到关键的测试步骤中。# test_performance.py import pytest from login_page import LoginPage from home_page import HomePage import time class TestAppPerformance: pytest.fixture(scopeclass) def driver(self): 启动驱动整个测试类只执行一次 drv get_driver() yield drv drv.quit() def test_cold_start_time(self, driver): 测试冷启动时间 # 1. 确保应用已关闭 driver.terminate_app(com.example.myapp) # 2. 开始计时 start_time time.time() # 3. 启动应用 driver.activate_app(com.example.myapp) # 4. 等待并确认首页特定元素出现标志着启动完成 home_page HomePage(driver) home_page.wait_for_welcome_text() # 假设这个方法会等待欢迎语出现 # 5. 结束计时 end_time time.time() launch_time end_time - start_time print(f应用冷启动耗时{launch_time:.2f}秒) # 这里可以将 launch_time 写入文件或数据库 assert launch_time 3.0, f启动时间{launch_time}秒超过3秒阈值 def test_login_flow_performance(self, driver): 测试登录流程性能 login_page LoginPage(driver) # 记录进入登录页的时间点可通过页面特定元素出现来判断 login_page_start time.time() login_page.input_username(testuser) login_page.input_password(testpass) # 记录点击登录按钮前的时间点 before_click time.time() login_page.click_login() # 等待登录成功后的页面跳转如首页出现 home_page HomePage(driver) home_page.wait_for_avatar() login_complete time.time() input_time before_click - login_page_start navigate_time login_complete - before_click total_login_time login_complete - login_page_start print(f登录流程 - 输入耗时{input_time:.2f}秒 跳转耗时{navigate_time:.2f}秒 总耗时{total_login_time:.2f}秒)在这个例子中我们不仅测试了功能能否登录还精准地测量了“冷启动”和“登录流程”两个关键场景的耗时。time.time()提供了高精度的计时。更复杂的性能数据则需要借助 ADB。4. 关键性能指标获取与ADB深度集成UI 操作的时间只是性能的一面。要全面评估应用我们还需要获取系统层面的资源消耗数据。这时就需要在 Python 脚本中调用 ADB 命令。4.1 封装 ADB 命令执行器我们可以在 Python 中通过subprocess模块来执行 ADB 命令并获取结果。import subprocess import re class ADBHelper: staticmethod def run_adb_command(cmd): 执行ADB命令并返回输出 full_cmd fadb {cmd} try: result subprocess.run(full_cmd, shellTrue, capture_outputTrue, textTrue, timeout10) if result.returncode 0: return result.stdout.strip() else: print(fADB命令执行失败: {result.stderr}) return None except subprocess.TimeoutExpired: print(fADB命令执行超时: {full_cmd}) return None staticmethod def get_cpu_memory(package_name): 获取指定包名应用的CPU和内存占用 # 获取CPU占用有些系统需要多次采样取平均 cpu_info ADBHelper.run_adb_command(fshell top -n 1 | findstr {package_name}) # 获取内存占用PSS mem_info ADBHelper.run_adb_command(fshell dumpsys meminfo {package_name} | findstr TOTAL) # 这里需要解析返回的文本提取数字 cpu ADBHelper._parse_cpu(cpu_info) mem ADBHelper._parse_memory(mem_info) return cpu, mem staticmethod def _parse_cpu(cpu_str): # 简易解析实际字符串可能为 com.example.myapp 10% 1% ... if cpu_str: parts cpu_str.split() if len(parts) 2: return parts[2].rstrip(%) # 假设CPU百分比在第三列 return N/A staticmethod def get_fps(package_name): 获取应用帧率信息适用于Android 4.1需开启GPU渲染模式 # 先清空旧的帧信息 ADBHelper.run_adb_command(fshell dumpsys gfxinfo {package_name} reset) # 进行一段UI操作这需要你的自动化脚本触发 # ... # 然后获取帧数据 fps_info ADBHelper.run_adb_command(fshell dumpsys gfxinfo {package_name}) # 解析输出计算掉帧Jank次数或平均FPS # 输出格式包含“Profile data in ms”部分列出了每帧渲染的耗时 frames ADBHelper._parse_gfxinfo(fps_info) # 简单计算假设16.67ms为一帧的基准60FPS超过16.67ms的帧视为掉帧 jank_count sum(1 for frame in frames if frame 16.67) return len(frames), jank_count4.2 在自动化流程中集成性能监控现在我们将 ADB 性能采集点插入到之前的测试流程中形成完整的性能测试用例。def test_comprehensive_performance(self, driver, adb_helper): 综合性能测试操作流 资源监控 performance_data [] # 场景1冷启动 driver.terminate_app(com.example.myapp) start_cpu_mem adb_helper.get_cpu_memory(com.example.myapp) # 启动前基线 start_time time.time() driver.activate_app(com.example.myapp) HomePage(driver).wait_for_welcome_text() cold_launch_time time.time() - start_time after_launch_cpu_mem adb_helper.get_cpu_memory(com.example.myapp) # 启动后 performance_data.append({ 场景: 冷启动, 耗时(秒): cold_launch_time, 启动前CPU(%): start_cpu_mem[0], 启动后CPU(%): after_launch_cpu_mem[0], 启动后内存(MB): after_launch_cpu_mem[1] }) # 场景2复杂列表滑动 home_page HomePage(driver) home_page.go_to_news_list() list_page NewsListPage(driver) # 滑动前获取一次FPS基线 total_frames_before, jank_before adb_helper.get_fps(com.example.myapp) # 执行多次快速滑动 for i in range(5): list_page.swipe_up_quick() time.sleep(0.5) # 滑动间隔 # 滑动后获取FPS数据 total_frames_after, jank_after adb_helper.get_fps(com.example.myapp) jank_during_swipe jank_after - jank_before performance_data.append({ 场景: 列表快速滑动, 滑动帧数: total_frames_after - total_frames_before, 掉帧次数: jank_during_swipe, 滑动后CPU(%): adb_helper.get_cpu_memory(com.example.myapp)[0] }) # 将performance_data写入Excel或日志文件 self._write_to_report(performance_data)通过这种方式我们在一个自动化测试流程中同步采集了时间性能启动耗时和系统资源性能CPU、内存、FPS/掉帧。这些数据结合在一起才能对应用性能做出全面评估。5. 实战技巧、常见问题与优化策略在实际项目中摸爬滚打我积累了一些脚本稳定性和效率提升的经验也踩过不少坑。5.1 提升脚本稳定性的关键使用显式等待告别time.sleep这是最重要的原则。不要用固定的time.sleep(10)而要用WebDriverWait配合expected_conditions。因为网络、设备性能会导致元素加载时间不定。固定等待要么浪费时间等太久要么导致失败等不够。# 坏味道 time.sleep(5) driver.find_element(...).click() # 好习惯 from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((AppiumBy.ID, some_id)) ) element.click()元素定位策略优先级优先使用resource-id(Android) 或accessibility-id(iOS)因为它们是唯一且稳定的。其次是xpath但尽量使用相对路径和非索引依赖的表达式因为 UI 结构容易变化。class和text容易重复需谨慎使用。异常处理与截图在关键操作步骤周围添加try...except并在失败时自动截图能极大提升调试效率。from datetime import datetime try: login_page.click_login() except Exception as e: timestamp datetime.now().strftime(%Y%m%d_%H%M%S) driver.get_screenshot_as_file(fscreenshot_failure_{timestamp}.png) print(f登录点击失败: {e}) raise # 重新抛出异常让测试失败5.2 常见问题排查清单问题现象可能原因排查步骤SessionNotCreatedExceptionDesired Capabilities 配置错误Appium 与设备/应用不兼容。1. 检查appPackage和appActivity是否正确。2. 确认设备已通过adb devices连接。3. 查看 Appium Server 日志通常有详细错误信息。NoSuchElementException元素定位器错误页面未加载完成元素在 WebView 内。1. 用 Appium Inspector 确认定位器。2. 添加显式等待等待元素出现。3. 如果是 WebView需要driver.switch_to.context(WEBVIEW_xxx)切换上下文。脚本执行速度慢使用了大量固定sleep网络或设备响应慢。1. 将sleep替换为显式等待。2. 检查设备性能关闭不必要的后台应用。3. 考虑在 WiFi 而非 USB 下执行需相应配置。ADB 命令无返回或超时设备断开连接ADB 服务异常命令本身执行慢。1. 重新执行adb devices确认连接。2. 重启 ADB 服务adb kill-server adb start-server。3. 对于dumpsys等可能较慢的命令增加subprocess的timeout参数。性能数据波动大系统后台干扰测试环境不干净单次采样不具代表性。1. 测试前重启设备清理后台。2. 同一场景多次测试取平均值或中位数。3. 在固定的、性能稳定的设备上运行性能测试。5.3 高级优化与扩展方向当基础框架跑通后可以考虑以下方向来提升整个方案的效能和深度并发测试使用pytest-xdist插件可以实现测试用例的分布式执行同时控制多台设备运行不同的测试套件大幅缩短测试总时间。与 CI/CD 集成将你的自动化性能测试脚本集成到 Jenkins、GitLab CI 等持续集成平台。每次开发提交代码后自动触发一轮核心场景的自动化测试和性能采集实现质量卡点。性能基线管理不要只关注单次数据。建立一个性能基线数据库将每次测试的结果如启动时间、内存值存储起来。在测试报告中不仅展示当前值还要与历史基线如前一个版本进行对比自动判断是否出现性能回归如耗时增长超过10%。更丰富的性能指标除了启动时间、CPU、内存、FPS还可以探索电量消耗使用adb shell dumpsys batterystats进行粗略评估或借助专业硬件工具。网络流量使用adb shell cat /proc/net/xt_qtaguid/stats或tcpdump抓包分析。流畅度分析除了dumpsys gfxinfo高版本 Android 可以使用FrameMetricsAPI 获取更精确的帧耗时分布。这套基于 Python ADB Appium 的自动化及性能获取方案本质上是一个高度可定制的工具箱。从简单的点击计时到复杂的系统资源监控其深度和广度取决于你的需求。开始时可以从一个核心场景如启动做起逐步丰富你的“性能探针”最终构建起覆盖核心用户体验路径的自动化性能监控体系让性能回归无所遁形。
