1. 项目概述当自动化测试遇上语音通话最近在做一个移动端IM项目的测试里面集成了语音通话功能。每次版本迭代测试同学都要抱着十几台手机手动拨号、接听、挂断再检查通话质量一套流程下来半天就没了。更头疼的是网络抖动、弱网环境这些场景手动模拟起来既不准又麻烦。这让我开始琢磨能不能把这套流程自动化起来毕竟重复、枯燥、易出错的活儿正是自动化测试的用武之地。在移动端自动化测试领域Appium是绕不开的名字。它支持Android和iOS双平台用一套脚本就能搞定这对于我们这种需要覆盖多端、多机型的团队来说吸引力巨大。但Appium的常规操作比如点击按钮、输入文本、滑动列表大家都很熟了。真正让我觉得有挑战的是“语音通话”这个场景。它不仅仅是UI交互还涉及到音频流的建立、传输和中断以及背后的系统级调用。这要求我们的自动化脚本不仅要能“看得见”操作UI还得能“听得见”控制音频和“说得了”模拟终端指令。所以今天我想分享的就是如何利用Appium并结合一些终端ADB控制技巧来实现一个相对完整的语音通话自动化测试方案。这个方案不仅能模拟拨号、接听、挂断等基础流程还能深入到通话质量验证的层面比如通过系统接口获取通话状态、模拟网络切换等。如果你也在为语音通话这类涉及底层硬件的功能测试而头疼希望这篇实战总结能给你一些直接的参考。2. 环境搭建与核心工具链解析工欲善其事必先利其器。要实现语音通话的自动化光有Appium还不够我们需要一套能打通从UI到系统底层的工具链。2.1 Appium服务端与客户端配置首先Appium本身是一个C/S架构。我们需要启动一个Appium服务器然后通过客户端用Python、Java等语言编写发送指令。对于Python环境我推荐使用appium-python-client库。安装很简单pip install Appium-Python-Client但这里有个关键点Appium服务器版本与客户端库版本的兼容性。我踩过坑新版的服务器搭配旧版的客户端库经常会出现一些莫名其妙的协议错误。我的经验是尽量保持两者版本同步更新。你可以通过以下命令分别查看和安装指定版本# 安装Appium服务器全局安装 npm install -g appiumlatest # 或者使用npx避免全局污染 npx appiumlatest # 安装指定版本的Python客户端 pip install Appium-Python-Client2.11.1启动Appium服务器时我习惯加上一些参数来获取更详细的日志便于调试appium --log-level debug --allow-insecure chromedriver_autodownload--log-level debug会在控制台输出非常详细的通信日志当脚本执行出错时这是定位问题根源的第一手资料。--allow-insecure参数则是为了解决一些新版本的安全限制比如自动下载ChromeDriver。2.2 Android测试环境深度配置我们的主战场是Android因此ADBAndroid Debug Bridge是另一个核心工具。它是我们与设备系统层对话的桥梁。1. 设备连接与授权确保设备通过USB连接后执行adb devices能看到设备并显示为device状态而不是unauthorized。如果是无线调试需要先用USB连接执行adb tcpip 5555然后adb connect 设备IP:5555。2. 关键ADB命令准备语音通话测试会频繁用到以下几个ADB命令建议提前熟悉adb shell dumpsys telecom获取当前系统的通话状态详情这是验证通话是否成功建立的核心命令。adb shell input keyevent KEYCODE_CALL模拟按下“拨号”硬件键。adb shell input keyevent KEYCODE_ENDCALL模拟按下“挂断”硬件键。adb shell screenrecord录制屏幕用于后期回溯测试过程特别是验证UI状态。adb shell monkey可以用于压力测试期间随机触发其他事件测试通话的稳定性。3. 权限授予被测应用通常是系统拨号盘或你自己的IM应用需要获取电话、麦克风、联系人等敏感权限。在自动化开始前可以通过ADB一键授予adb shell pm grant package_name android.permission.CALL_PHONE adb shell pm grant package_name android.permission.RECORD_AUDIO # ... 其他所需权限这样可以避免脚本执行时被系统的权限弹窗阻塞。2.3 构建Desired Capabilities连接设备的“身份证”Desired Capabilities是一组发送给Appium服务器的键值对用于告诉服务器你想如何启动会话。对于语音通话测试配置需要格外细致。from appium import webdriver from appium.options.android import UiAutomator2Options # 使用新的Options模式推荐 options UiAutomator2Options() options.platform_name Android options.device_name 你的设备名称 # 在adb devices中看到的名字 options.automation_name UiAutomator2 # Android的自动化引擎 options.app_package com.android.dialer # 系统拨号盘包名 options.app_activity .main.impl.MainActivity # 启动Activity # 关键配置不重置应用状态避免每次都要授权 options.no_reset True # 关键配置确保在测试后停止应用释放资源 options.full_reset False # 超时设置 options.new_command_timeout 300 # 5分钟无新命令则超时 # 如果需要测试预装应用如拨号盘可以不指定app而是指定appPackage和appActivity # options.app /path/to/your/app.apk driver webdriver.Remote(http://localhost:4723, optionsoptions)注意deviceName在Android上其实不是必须的Appium主要靠udid来识别设备。但为了清晰建议填写。更准确的做法是使用options.udid ‘设备序列号’。3. 核心测试策略从UI模拟到系统验证语音通话自动化测试可以拆解为几个核心阶段启动应用、拨号、验证通话建立、执行通话中操作、挂断、验证通话结束。每个阶段都需要UI操作和系统状态验证相结合。3.1 启动应用与拨号操作启动应用后首先需要定位到拨号盘。这里就涉及到元素定位策略。对于系统拨号盘不同手机厂商的UI差异很大ID可能不同。# 启动驱动后 try: # 1. 尝试通过ID定位拨号盘按钮最常见 dialpad_btn driver.find_element(AppiumBy.ID, ‘com.android.dialer:id/dialpad_fab’) dialpad_btn.click() time.sleep(1) # 等待动画 # 2. 如果ID定位失败尝试其他策略 # 通过Accessibility IDcontent-desc # dialpad_btn driver.find_element(AppiumBy.ACCESSIBILITY_ID, “拨号键盘”) # 通过XPath灵活性高但易碎 # dialpad_btn driver.find_element(AppiumBy.XPATH, “//android.widget.ImageButton[content-desc‘拨号键盘’]”) # 3. 输入号码 number_mapping { ‘1’: ‘com.android.dialer:id/one’, ‘2’: ‘com.android.dialer:id/two’, # ... 映射0-9, *, # } phone_number ‘13800138000’ for digit in phone_number: if digit in number_mapping: driver.find_element(AppiumBy.ID, number_mapping[digit]).click() time.sleep(0.2) # 模拟人手输入间隔避免过快 # 4. 点击拨打按钮 call_btn driver.find_element(AppiumBy.ID, ‘com.android.dialer:id/dialpad_voice_call_button’) call_btn.click() except NoSuchElementException as e: print(f“UI元素定位失败: {e}”) # 备选方案使用ADB模拟拨号盘输入和拨打 # adb shell am start -a android.intent.action.CALL -d tel:13800138000 # 但这会跳过UI直接进入通话界面适合纯逻辑测试。实操心得UI定位是自动化测试中最不稳定的环节。一定要为关键操作添加显式等待WebDriverWait而不是固定的sleep。同时准备一个备选的ADB命令方案当UI定位因系统升级或厂商定制失败时脚本还能继续执行核心逻辑。3.2 验证通话建立UI与系统状态双保险点击拨打后如何判断电话真的打出去了不能只靠UI上的“通话中”字样。1. UI状态验证# 等待通话界面出现 WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.ID, ‘com.android.dialer:id/incall_end_call’)) ) # 检查是否有“通话中”等关键文本 page_source driver.page_source assert “通话中” in page_source or “Dialing” in page_source or “Calling” in page_source2. 系统状态验证更可靠这是关键步骤。通过ADB命令dumpsys telecom可以获取最权威的通话状态。import subprocess def get_call_state_via_adb(): “””通过ADB获取当前通话状态””” result subprocess.run([‘adb’, ‘shell’, ‘dumpsys’, ‘telecom’], capture_outputTrue, textTrue) output result.stdout # 在输出中查找关键信息 if ‘Call [ACTIVE’ in output: return ‘ACTIVE’ # 通话已接通 elif ‘Call [DIALING’ in output: return ‘DIALING’ # 正在拨号 elif ‘Call [DISCONNECTED’ in output: return ‘DISCONNECTED’ # 已挂断 else: return ‘IDLE’ # 空闲 # 在点击拨打后循环检查状态直到接通或超时 start_time time.time() timeout 30 while time.time() - start_time timeout: state get_call_state_via_adb() if state ‘ACTIVE’: print(“通话已成功接通”) break elif state ‘DIALING’: print(“正在拨号中…”) time.sleep(2) else: print(f“当前状态: {state}”) time.sleep(1) else: raise AssertionError(“在指定时间内未接通电话”)通过结合UI和系统层双重验证我们的测试断言就非常坚实了。3.3 通话中操作与挂断通话建立后我们可能需要测试一些功能比如静音、免提、保持、拨号键盘等。# 示例点击免提按钮 speaker_btn driver.find_element(AppiumBy.ID, ‘com.android.dialer:id/incall_speaker_button’) speaker_btn.click() time.sleep(1) # 可以再次通过dumpsys audio检查音频路由是否切换到扬声器 # adb shell dumpsys audio | grep “Devices:” # 挂断电话 end_call_btn driver.find_element(AppiumBy.ID, ‘com.android.dialer:id/incall_end_call’) end_call_btn.click()挂断后同样需要进行验证# 等待通话界面消失回到拨号盘或主界面 WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.ID, ‘com.android.dialer:id/dialpad_fab’)) ) # 系统状态验证 time.sleep(2) # 给系统一点处理时间 final_state get_call_state_via_adb() assert final_state ‘IDLE’, f“通话未正确结束当前状态: {final_state}”4. 进阶实战模拟复杂场景与音频验证基础的拨打通话流程自动化后我们可以挑战更复杂的场景这些才是体现自动化价值的所在。4.1 模拟来电接听测试测试接听功能需要另一台设备或一个可以发起呼叫的工具。如果没有真机可以借助一些模拟工具但更可靠的方法是使用ADB模拟来电。Android提供了一个隐藏的测试命令来模拟来电adb shell am start -a android.intent.action.CALL -d tel:10086但这其实是去电。模拟来电需要更底层的操作通常需要系统签名权限在普通App测试中很难实现。一个变通的方法是使用两台真机一台作为测试机A一台作为呼叫机B。编写脚本控制B机通过ADB或另一套Appium驱动拨打A机的号码。使用GSM模拟器或测试卡在实验室环境下使用专门的通信测试仪如Anritsu、Keysight的设备可以精确模拟网络信令触发被测手机的来电。这是最专业的方式。测试内建功能如果你的应用是微信、Skype这类VoIP应用来电本质上是网络信令。你可以在测试环境中让服务端或另一客户端主动向被测客户端发起呼叫邀请。4.2 弱网与网络切换模拟语音通话质量对网络非常敏感。我们可以使用工具模拟弱网环境。使用Android模拟器的网络限制如果你用的是模拟器可以在启动时或通过ADB设置网络速度和延迟。adb shell svc data disable # 关闭蜂窝数据 adb shell svc wifi enable # 开启Wi-Fi # 使用NetEm需要内核支持模拟延迟和丢包但这通常需要root权限使用系统开发者选项在手机开发者选项中有“网络链接调节”功能可以模拟2G、3G、高延迟网络等。可以通过ADB打开此界面但自动设置参数比较困难。使用硬件网络损伤仪在专业的测试实验室这是标准配置。使用代理软件如Charles、Fiddler对于VoIP应用其信令和媒体流走的是IP网络。可以在PC上设置代理让手机流量经过代理然后在代理软件上设置带宽限制、丢包率、延迟。这是对VoIP应用进行弱网测试最实用且成本较低的方法。测试脚本需要在通话建立后动态切换网络并同时检查UI上是否有网络状态提示如“网络质量不佳”。通话是否异常中断。通过获取通话日志adb logcat | grep -i audio或应用自身的日志分析是否有大量的音频包重传或解码错误。4.3 音频质量的基础验证完全自动化评估音频质量如MOS分需要专业的音频分析设备和算法但我们可以做一些基础检查音频路径验证确保通话时音频从正确的设备听筒、扬声器、蓝牙耳机输出/输入。可以通过adb shell dumpsys audio命令观察Selected output device和Active input device。静音功能验证点击静音按钮后通过ADB录制一段系统音频需要root权限分析音频能量是否接近为零。adb shell screenrecord --audio-sourcevoice-communication /sdcard/test.aac # 将文件拉取到电脑用音频分析工具如sox, audacity查看波形双工通话测试即双方同时说话。可以编写脚本让两端设备在通话中按特定模式播放测试音频如正弦波然后在另一端录制并分析检查是否有严重的剪裁或失真。这需要精确的时间同步实现起来比较复杂通常借助专业测试工具。对于大多数业务测试“音频是否正常”可以通过一个简单的“回声测试”来验证在A端播放一段已知的音频文件通过媒体音量检查B端是否能录制到清晰可辨的相同音频。这可以通过在测试设备上安装一个简单的音频播放/录制App并用Appium控制其配合主测试应用来完成。5. 脚本优化与框架整合单个测试用例跑通后我们需要考虑如何将其工程化融入团队的持续集成流程。5.1 使用Page Object模式封装将拨号盘、通话界面等抽象成Page类使脚本更易维护。class DialpadPage: def __init__(self, driver): self.driver driver self.dialpad_fab (AppiumBy.ID, ‘com.android.dialer:id/dialpad_fab’) self.digit_keys {str(i): f‘com.android.dialer:id/{[“zero”,“one”,“two”,“three”,“four”,“five”,“six”,“seven”,“eight”,“nine”][i]}’ for i in range(10)} self.call_button (AppiumBy.ID, ‘com.android.dialer:id/dialpad_voice_call_button’) def open_dialpad(self): WebDriverWait(self.driver, 10).until(EC.element_to_be_clickable(self.dialpad_fab)).click() def dial_number(self, number): for digit in number: if digit in self.digit_keys: key_locator (AppiumBy.ID, self.digit_keys[digit]) WebDriverWait(self.driver, 5).until(EC.element_to_be_clickable(key_locator)).click() time.sleep(0.1) def make_call(self): WebDriverWait(self.driver, 10).until(EC.element_to_be_clickable(self.call_button)).click() class CallScreenPage: # … 定义通话界面的元素和操作5.2 测试数据与配置外部化将设备信息、等待超时、电话号码等配置抽取到配置文件如config.yaml或.env中。# config.yaml devices: - udid: emulator-5554 platform_version: ‘14’ call_number: ‘13800138000’ - udid: ‘ABCDEF012345’ platform_version: ‘13’ call_number: ‘10086’ appium: server_url: ‘http://localhost:4723’ implicit_wait: 105.3 集成到CI/CD流水线在Jenkins、GitLab CI等工具中可以这样安排任务准备阶段CI Agent连接并检查测试设备状态adb devices。构建阶段安装测试依赖Appium Python客户端等。测试阶段启动Appium服务器。并行执行测试套件使用pytest-xdist。收集测试过程中的屏幕录像adb screenrecord、Logcat日志和Appium日志。报告阶段使用pytest-html或Allure生成美观的测试报告附上失败用例的截图和日志。清理阶段无论成功失败都强制关闭Appium会话释放设备。5.4 并行测试与资源管理当有多台设备时可以使用pytestappium-python-clientthreading或multiprocessing实现并行。更优雅的方式是使用Selenium Grid的思路搭建Appium Grid。一个Hub管理多个注册了不同设备的Node测试脚本只需将Remote命令指向Hub由Hub分配可用的设备。6. 常见问题排查与实战技巧在实际操作中你会遇到各种各样的问题。这里记录了几个最典型的“坑”和解决方法。6.1 元素定位失败问题这是最高频的问题。现象NoSuchElementException。排查检查上下文Context混合应用Hybrid App或Flutter应用中需要在Native和Webview上下文间切换。使用driver.contexts和driver.switch_to.context。使用更稳定的定位器优先使用ID或ACCESSIBILITY_ID。如果都没有尝试相对XPath避免使用绝对路径和可能变化的索引。添加智能等待永远不要只用time.sleep。使用WebDriverWait配合expected_conditions。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC element WebDriverWait(driver, 15).until( EC.presence_of_element_located((AppiumBy.ID, “some_id”)) )使用Appium Desktop或Inspect工具重新检查元素属性确认定位器没有写错。注意有些元素的ID在应用不同版本间可能会变。6.2 权限弹窗与系统对话框干扰现象脚本执行被“是否允许拨打电话”等弹窗打断。解决前置授权如前所述在测试开始前通过adb shell pm grant命令授予所有所需权限。自动处理弹窗如果无法前置授权可以编写代码检测并点击弹窗。但不同系统弹窗的定位器差异极大非常脆弱。一个相对通用的方法是使用ADB模拟按下“允许”键# 在可能出现弹窗的操作后尝试按下“允许” subprocess.run([‘adb’, ‘shell’, ‘input’, ‘keyevent’, ‘KEYCODE_ENTER’]) # 有时是回车键 # 或者更暴力地点击屏幕固定坐标不推荐兼容性差使用autoGrantPermissionsCapability在UiAutomator2Options中设置options.auto_grant_permissions TrueAppium会自动点击授权弹窗。但并非100%有效。6.3 设备兼容性与稳定性现象在一台设备上运行良好的脚本在另一台设备上失败。解决抽象设备操作将对设备的直接操作如ADB命令封装起来根据设备型号或系统版本进行适配。准备多套定位器为不同厂商的ROM准备不同的元素定位器映射表。增加重试机制对于不稳定的操作如网络请求、页面跳转使用重试装饰器。from retrying import retry retry(stop_max_attempt_number3, wait_fixed2000) def unstable_operation(): # 你的操作代码 pass定期重启设备/Appium Server长时间运行测试后设备可能会卡顿Appium Server也可能内存泄漏。在CI任务中每次任务开始前重启设备是个好习惯。6.4 通话状态检测的延迟与误判现象dumpsys telecom命令返回状态有延迟导致脚本误判。解决轮询结合超时如前文代码所示不要只检查一次。设置一个合理的总超时时间如30秒在超时前循环检查。增加缓冲时间在关键状态转换操作如点击挂断后等待2-3秒再检查系统状态给系统处理留出时间。多指标综合判断不要只依赖dumpsys telecom。同时检查UI元素是否存在、Logcat中是否有特定的通话状态日志adb logcat | grep -i “call state”进行综合判断。6.5 性能与资源泄漏现象长时间运行大量测试用例后设备变慢脚本失败率升高。解决务必在finally块或teardown方法中调用driver.quit()确保每次测试会话结束后释放Appium与设备之间的连接资源。清理后台进程测试开始前通过adb shell am force-stop package_name清理被测应用和其他可能干扰的应用。监控设备资源在CI脚本中可以定期运行adb shell top或adb shell dumpsys meminfo来监控CPU和内存使用情况发现异常及时报警。语音通话的自动化测试难点不在于拨号点击而在于对“状态”的精确感知和控制。它要求测试开发人员不仅懂UI自动化还要了解一点移动操作系统特别是Android的通信子系统知识并善于利用ADB这个强大的命令行工具。将Appium的UI操作与ADB的系统级命令结合起来才能构建出稳定、可靠的语音通话自动化测试方案。这套思路同样可以扩展到短信、联系人、相机等其他需要与系统深度交互的功能测试中。
