1. 项目概述与核心价值最近在做一个涉及实时语音通话功能的App测试项目团队里的小伙伴们被手动测试折腾得够呛。想象一下测试人员每天要做的就是拿起A手机拨号拿起B手机接听对着话筒“喂喂喂”然后挂断再换一组号码、换一种网络环境重复。不仅枯燥而且通话时长、音质、延迟这些关键指标全靠耳朵听、手动记效率低不说数据还很不准。更头疼的是一旦要测多设备并发或者弱网下的异常场景手动测试几乎无法覆盖。这种痛点我相信很多做社交、会议、客服类App的测试同行都深有体会。正是在这种背景下我们决定用Appium把语音通话的测试给自动化了。这不仅仅是把“点击拨号按钮”这个动作自动化那么简单它的核心价值在于构建一个可重复、可量化、可扩展的测试闭环。通过脚本我们可以精确模拟用户从发起呼叫、建立连接到结束通话的全流程并能自动采集通话过程中的关键数据比如端到端延迟、音频丢包率甚至是利用简单的语音识别来校验通话内容是否正确。这样一来回归测试的覆盖率上去了夜间可以跑大量的压力测试场景释放了人力更重要的是测试结果从“感觉还行”变成了“延迟小于200ms丢包率0.5%”这样的客观数据为产品质量提供了坚实保障。2. 环境搭建与工具链选型工欲善其事必先利其器。在开始写自动化脚本之前一个稳定、兼容的环境是基石。这里我结合自己的踩坑经验把环境搭建的要点和背后的“为什么”讲清楚。2.1 核心工具安装与版本协同首先明确我们的技术栈Appium Server 作为测试引擎Appium ClientPython版作为脚本编写端Android SDK/ADB 用于与设备通信一部安卓真机或模拟器作为被测对象。Node.js与Appium ServerAppium Server是基于Node.js的所以第一步是安装Node.js。这里有个关键点不要追求最新版本。我曾因为用了太新的Node.js导致与某个版本的Appium不兼容出现各种诡异的启动错误。建议使用Node.js的LTS长期支持版本比如18.x。安装完成后通过npm安装Appium Servernpm install -g appium。安装后可以通过appium -v和appium driver list来验证安装并确保uiautomator2这个驱动用于安卓已安装。Python与Appium ClientPython环境推荐使用3.8或3.9同样以稳定为主。使用pip安装必要的包pip install Appium-Python-Client。这个库是我们编写脚本时用来向Appium Server发送指令的桥梁。Android SDK与ADB这是与安卓设备通信的核心。建议直接下载Android Studio它自带SDK Manager可以方便地安装所需的Platform-Tools包含ADB和系统镜像。安装后请务必将SDK的platform-tools目录添加到系统的PATH环境变量中。验证方式是在命令行输入adb version能显示版本号即成功。这里有个大坑如果你电脑上同时存在多个ADB比如某些手机助手自带的可能会产生冲突导致设备无法识别。解决方法是统一使用Android SDK里的ADB并确保它在PATH中的顺序最靠前。被测设备准备真机优于模拟器。真机请开启“开发者选项”和“USB调试”。模拟器可以使用Android Studio自带的AVD Manager创建。特别注意无论是真机还是模拟器建议在开发者选项里将“窗口动画缩放”、“过渡动画缩放”、“动画程序时长缩放”这三项都设置为“关闭动画”。这能显著减少脚本执行中因等待动画结束而导致的超时失败。2.2 必备辅助工具元素定位的“眼睛”写UI自动化脚本70%的时间可能花在元素定位上。光靠猜和试是不行的你需要好用的侦查工具。Appium Inspector这是Appium官方提供的图形化元素定位工具。新版Appium Server2.0通常自带。它的作用是连接到你的设备实时显示当前界面的UI层级树让你可以点击查看任意元素的属性如resource-id, text, class, content-desc等。在编写定位代码前先用Inspector探查清楚事半功倍。使用技巧启动Inspector时需要的desired_capabilities配置几乎和你的测试脚本一致这意味着你可以直接把脚本里的配置参数复制过来用。UIAutomatorViewer这是Android SDK自带的老牌工具位于SDK的tools/bin目录下。在某些情况下特别是对于老旧设备或Appium Inspector无法正常连接时它可能更稳定。它的功能与Appium Inspector类似。ADB命令行这是我们的“瑞士军刀”。除了安装应用adb install、启动应用adb shell am start在语音通话测试中它有大用场。例如我们可以用adb shell dumpsys telecom来获取通话状态用adb shell logcat来抓取应用和系统的音频相关日志甚至可以用adb shell input keyevent来模拟物理按键如挂断键。熟练掌握ADB能让你的自动化脚本能力提升一个维度。注意环境搭建完成后务必做一个“端到端”的连通性测试启动Appium Server - 使用ADB确认设备已连接 - 写一个最简单的打开拨号盘的脚本并运行。确保这一步通了再开始后续复杂的业务逻辑开发否则调试起来会非常痛苦。3. 权限处理与拨号核心逻辑实现语音通话功能涉及敏感的硬件麦克风、听筒和系统权限打电话自动化脚本必须妥善处理这些权限问题并稳定地模拟用户拨号操作。3.1 自动化权限授予策略安卓应用在首次使用麦克风或电话功能时会弹出系统权限弹窗。如果脚本不处理就会卡在这里失败。我们有几种策略Desired Capabilities 预授权在初始化驱动时通过desired_capabilities参数让Appium自动处理。这是最推荐的方式。desired_caps { platformName: Android, deviceName: your_device_name, appPackage: com.yourcompany.dialer, appActivity: .MainActivity, autoGrantPermissions: True, # 自动授予所有弹窗权限 # 或者更精细的控制 # autoAcceptAlerts: True, # 自动接受所有弹窗包括权限和非权限 }autoGrantPermissions: True会让Appium自动点击权限弹窗的“允许”按钮。但要注意有些应用在非首次启动时也会因权限问题弹窗这个参数同样有效。ADB命令预授权在测试开始前通过ADB命令直接授予权限。这种方式更底层不依赖Appium。adb shell pm grant com.yourcompany.dialer android.permission.RECORD_AUDIO adb shell pm grant com.yourcompany.dialer android.permission.CALL_PHONE adb shell pm grant com.yourcompany.dialer android.permission.MODIFY_AUDIO_SETTINGS你可以把这些命令写在脚本的setUp方法里。好处是绝对可靠缺点是需要提前知道应用包名和具体的权限名。脚本动态处理如果上述方法失效或者你只想在特定时机授权可以在脚本中检测并点击权限弹窗。但这需要定位弹窗元素稳定性较差作为保底方案。实操心得对于内部测试包我强烈推荐方法2ADB预授权干净彻底。对于无法预知权限场景的情况方法1autoGrantPermissions是首选。务必在真机上测试权限处理逻辑因为模拟器的权限行为可能与真机有差异。3.2 拨号操作的元素定位与交互拨号界面通常包含数字键盘、拨号按钮、联系人输入框等。定位这些元素是第一步。使用Appium Inspector定位打开拨号盘用Inspector查看。理想的定位依据是resource-id安卓或accessibility idiOS/安卓因为它们是唯一且稳定的。例如数字键“1”的id可能是com.android.dialer:id/one。编写稳健的拨号脚本假设我们测试拨打号码“10086”。from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy import time # ... desired_caps 配置 ... driver webdriver.Remote(http://localhost:4723, desired_caps) time.sleep(2) # 等待应用启动稳定 try: # 1. 点击拨号盘按钮如果不在默认页 # 先判断元素是否存在再点击增加容错 dial_pad_btn driver.find_elements(AppiumBy.ID, com.android.dialer:id/dialpad_fab) if dial_pad_btn: dial_pad_btn[0].click() time.sleep(1) # 2. 输入号码使用ID定位每个数字键 number_mapping { 1: com.android.dialer:id/one, 0: com.android.dialer:id/zero, # ... 其他数字 } for digit in 10086: element_id number_mapping.get(digit) if element_id: driver.find_element(AppiumBy.ID, element_id).click() time.sleep(0.2) # 短暂间隔模拟人手速 else: print(fWarning: No mapping for digit {digit}) # 3. 点击拨打按钮 call_button driver.find_element(AppiumBy.ID, com.android.dialer:id/dialpad_floating_action_button) call_button.click() print(拨号指令已发送) # 此时系统会跳转到通话界面 except Exception as e: print(f拨号过程发生异常: {e}) # 这里可以添加截图逻辑方便后期排查 driver.save_screenshot(dial_failed.png)关键点解析find_elements与find_elementfind_elements返回列表即使找不到元素也是空列表不会抛异常。用于先判断元素是否存在非常适合处理界面状态不确定的情况。等待策略直接使用time.sleep是最简单但不推荐的方式因为它固定等待浪费时间。在实际项目中应该使用显式等待WebDriverWait让脚本在元素出现或可点击时才进行下一步效率更高。异常处理与日志一定要用try...except包裹核心操作并记录详细的日志或截图。当脚本在CI/CD上夜间运行时这些信息是定位问题的唯一线索。4. 通话状态监控与断言机制拨号成功只是开始自动化测试需要验证通话是否真正建立、通话质量如何。这就需要我们监控通话状态并设计断言Assertion来判定测试用例的成功与否。4.1 利用ADB监控通话状态UI上“正在通话”的界面可能因手机厂商定制而千差万别通过UI元素判断不稳定。更可靠的方式是通过ADB查询系统底层的通话状态。import subprocess def get_call_state_via_adb(device_id): 通过ADB命令获取当前通话状态。 返回IDLE(空闲), RINGING(响铃), OFFHOOK(摘机包括拨号、通话中) # 如果有多个设备需要指定 -s 参数 device_prefix f-s {device_id} if device_id else cmd fadb {device_prefix}shell dumpsys telecom try: result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue, timeout5) output result.stdout # 在输出中查找关键行 if Call 1: DOWN in output or Calls in call manager: in output and num0 in output: return IDLE elif RINGING in output: return RINGING elif ACTIVE in output or DIALING in output: return OFFHOOK else: # 如果解析失败可以尝试更通用的方法检查是否有进程在使用电话相关服务 cmd_check fadb {device_prefix}shell ps | grep telephony result_check subprocess.run(cmd_check, shellTrue, capture_outputTrue, textTrue) if result_check.stdout: return OFFHOOK # 可能存在通话 return UNKNOWN except subprocess.TimeoutExpired: print(ADB命令执行超时) return ERROR except Exception as e: print(f获取通话状态失败: {e}) return ERROR # 在拨号后使用该函数进行验证 call_button.click() print(拨号指令已发送等待通话建立...) time.sleep(3) # 等待系统处理拨号请求 max_wait 30 # 最大等待30秒 start_time time.time() while time.time() - start_time max_wait: state get_call_state_via_adb() if state OFFHOOK: print(通话已成功建立) break elif state IDLE: print(通话未接通或已挂断。) # 这里可以结合UI判断是否是对方未接听等场景 break time.sleep(2) # 每2秒检查一次 else: print(错误在指定时间内未检测到通话建立。) # 标记测试用例为失败为什么用dumpsys telecom因为它是安卓系统Telecom框架的服务所有通话包括第三方VoIP应用如果它们集成得当的状态理论上都会在这里管理。相比解析UI这种方法更接近事实本源不受皮肤和主题影响。4.2 设计多维度的断言条件一个健壮的通话自动化测试用例其断言不应该只有“接通了”这么简单。我们需要从多个维度验证状态断言如上所述核心断言是通话状态必须从DIALING拨号中转变为ACTIVE通话中。这是最基本的要求。时长断言测试通话保持功能。脚本可以在通话建立后等待一个预设的时长例如30秒然后再次检查通话状态是否仍为ACTIVE。如果中途断线测试失败。UI辅助断言虽然不作为主要依据但可以辅助验证。例如检查通话界面是否显示了正确的联系人姓名或号码通过定位对应的TextView。这可以验证呼叫的目标是否正确。音频通道断言进阶通过ADB命令adb shell dumpsys audio可以查看当前的音频路由AudioFocus。我们可以检查在通话建立后音频焦点是否被我们的应用或电话应用获取并且路由到了听筒或扬声器取决于测试场景。这能验证音频硬件是否被正确调用。一个综合断言逻辑的示例片段# 假设通话已建立状态为 ACTIVE assert get_call_state_via_adb() OFFHOOK, 主断言失败通话未处于接通状态 # 等待并断言通话能持续一段时间 hold_duration 10 print(f开始保持通话 {hold_duration} 秒...) time.sleep(hold_duration) assert get_call_state_via_adb() OFFHOOK, f通话未能保持 {hold_duration} 秒 # 可选UI断言检查通话界面显示的正确号码 if driver.find_elements(AppiumBy.ID, com.android.dialer:id/contact_name_or_number): displayed_number driver.find_element(AppiumBy.ID, com.android.dialer:id/contact_name_or_number).text assert 10086 in displayed_number, f显示号码不匹配期望包含10086实际为{displayed_number} print(UI号码显示正确。)5. 挂断操作与测试数据清理测试用例需要有始有终挂断操作和清理环境是保证测试可重复执行的关键。5.1 多种挂断方式及其适用场景挂断电话至少有三种可靠的自动化实现方式各有优劣通过UI元素点击挂断按钮这是最接近用户操作的方式。# 定位通话界面的大红色挂断按钮 end_call_button driver.find_element(AppiumBy.ID, com.android.dialer:id/incall_end_call) end_call_button.click() print(通过UI点击挂断。)优点完全模拟用户。缺点按钮的ID可能因ROM不同而变化稳定性最差。发送ADB输入事件模拟按下“挂断键”安卓系统有一个虚拟的“结束通话”键值。import subprocess subprocess.run(adb shell input keyevent KEYCODE_ENDCALL, shellTrue) print(通过ADB模拟挂断键挂断。)优点通用性强几乎在所有安卓设备上都有效。缺点这是一个全局事件如果当时有其他应用在前台并响应了这个键值可能会产生意外效果。使用Appium的press_keycode方法原理同ADB命令但通过Appium驱动执行。from appium.webdriver.extensions.android.native_key import AndroidKey driver.press_keycode(AndroidKey.ENDCALL) print(通过Appium发送挂断键码。)优点比ADB命令更“优雅”属于WebDriver协议的一部分。缺点需要导入特定的Keycode枚举。实操心得在实际项目中我通常会采用**“UI优先ADB兜底”**的策略。先尝试用UI方式挂断如果找不到元素可能界面已变化则捕获异常转而执行ADB命令挂断。这样既保证了在正常情况下的模拟真实性又有了保底的可靠性。5.2 通话记录清理与测试隔离自动化测试尤其是会往服务器或本地数据库写入数据的测试必须考虑数据清理防止测试数据堆积影响后续测试或产生脏数据。清理本地通话记录对于手机自带的拨号应用通话记录会保存在本地。我们可以通过ADB命令删除这些记录或者更简单地在测试开始前/后直接清除拨号应用的数据。# 方法1通过ADB清除应用数据相当于恢复出厂设置会清空所有数据包括设置 subprocess.run(adb shell pm clear com.android.dialer, shellTrue) # 注意这非常暴力会清空所有数据包括已保存的设置。慎用 # 方法2更精细地通过Content Provider删除需要知道具体URI较复杂 # adb shell content delete --uri content://call_log/calls使用隔离的测试账号/号码如果测试的是像微信语音这样的网络通话强烈建议使用专门为此自动化测试创建的、隔离的测试账号。这些账号只用于自动化测试不与真实业务数据混淆。脚本应在setUp中登录测试账号A在另一台设备或模拟器上登录测试账号B。脚本层面的清理在测试用例的tearDown方法中无论测试成功还是失败都应执行清理操作。例如强制挂断所有通话通过多次发送KEYCODE_ENDCALL返回到应用主界面甚至重启应用为下一个测试用例提供一个干净的环境。def tearDown(self): # 确保通话被挂断 try: self.driver.press_keycode(AndroidKey.ENDCALL) except: pass # 强制回到主屏幕 self.driver.press_keycode(AndroidKey.HOME) # 如果应用进程还在可以终止它 subprocess.run(fadb shell am force-stop {self.desired_caps[appPackage]}, shellTrue) # 最后退出驱动 if self.driver: self.driver.quit()6. 进阶音频质量检测与网络模拟基础的接通/挂断自动化只是第一步。要真正评估语音通话功能的质量我们需要向“质量保障”迈进即自动化地评估通话的音频质量。6.1 利用ADB进行简单的音频活动检测虽然无法直接通过Appium分析音频流内容但我们可以通过ADB间接判断音频系统是否在工作。检查音频进程通话建立后系统会有相关的音频处理进程如mediaserver,audioserver活跃或者电话应用本身会持有音频焦点。adb shell ps | grep -E ‘(mediaserver|audioserver|audio)’通过对比通话前后这些进程的状态或资源占用可以侧面验证音频通道是否被激活。监控Logcat中的音频相关日志安卓系统的音频子系统会输出大量日志。我们可以过滤关键字来观察。import subprocess # 开始通话 # ... # 同时在另一个线程或进程中开始收集日志 log_process subprocess.Popen( [adb, logcat, -s, AudioTrack:V, AudioRecord:V, AudioFlinger:V], stdoutsubprocess.PIPE, stderrsubprocess.PIPE, textTrue ) # 运行一段时间通话测试... # 然后终止日志收集 log_process.terminate() stdout, _ log_process.communicate() # 分析stdout中是否有音频数据开始/停止、缓冲区变化等关键信息 if start() in stdout and AudioTrack in stdout: print(检测到音频播放活动。) if start() in stdout and AudioRecord in stdout: print(检测到音频录制活动。)这种方法需要你对安卓音频日志有一定的了解用于判断音频链路是否打通非常有效。6.2 集成第三方SDK进行音频分析概念对于要求更高的测试比如需要测量端到端延迟、丢包率、MOS分可以考虑在测试端集成音频分析SDK。但这通常超出了UI自动化的范畴需要开发专门的测试桩Test Stub或使用云测平台的服务。一种可行的思路在两端主叫和被叫的测试环境中预装一个自定义的“音频分析助手”App。通话建立后自动化脚本通过ADB或广播通知这个助手App开始播放一段标准的测试音频例如一段特定的正弦波或语音。另一端的助手App同时开始录音。通话结束后助手App分析录音文件通过算法如互相关算法计算出音频从发送到接收的延迟并分析音频失真程度。自动化脚本再从助手App拉取分析结果作为测试断言的一部分。这实现起来比较复杂属于专项测试的范畴。但对于核心的语音通话产品这种投入是值得的。6.3 使用网络模拟工具测试弱网场景语音通话质量与网络状况强相关。自动化测试必须覆盖弱网、高延迟、高丢包等场景。工具选择Charles/ Fiddler适合模拟手机HTTP/HTTPS代理下的网络状况但对纯TCP/UDP的语音流如WebRTC可能不直接生效。Android Emulator 自带网络模拟Android Studio的模拟器可以直接设置网络速度和延迟非常方便。硬件设备网络损伤仪最真实但成本高用于实验室环境。软件方案netem(Linux) 或Network Link Conditioner(macOS)如果你使用电脑开热点给手机可以在电脑端用这些工具模拟网络损伤。在自动化脚本中集成网络模拟以使用netem为例你可以在测试用例的setUp中执行Shell命令来设置网络规则在tearDown中清除规则。import subprocess class TestVoiceCall: def setUp(self): # 设置200ms延迟1%丢包的网络环境 subprocess.run(sudo tc qdisc add dev eth0 root netem delay 200ms loss 1%, shellTrue) # ... 其他初始化 def test_call_in_poor_network(self): # 执行通话测试 # 断言条件可以放宽例如允许更长的连接建立时间 pass def tearDown(self): # 清除网络模拟规则 subprocess.run(sudo tc qdisc del dev eth0 root, shellTrue) # ... 其他清理重要提示网络模拟会影响整个设备的网络请确保在独立的测试机或模拟器上进行避免影响开发环境。7. 常见问题排查与实战技巧即使环境搭建完美脚本逻辑严谨在实际运行中还是会遇到各种“坑”。下面是我总结的一些高频问题和解决思路。7.1 元素定位失败与动态内容处理这是UI自动化最常见的问题。问题脚本报错NoSuchElementException。排查确认界面首先通过driver.get_screenshot_as_file(debug.png)截图或者用driver.page_source打印当前页面XML源码确认是否真的跳转到了你期望的界面。检查定位符用Appium Inspector重新连接设备查看目标元素的属性是否变了。特别是resource-id有些应用在不同版本或不同状态下会动态生成。等待时机元素还没加载出来你就去点击了。永远不要只用time.sleep。改用显式等待。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from appium.webdriver.common.appiumby import AppiumBy # 等待最多10秒直到拨号按钮出现并可点击 wait WebDriverWait(driver, 10) dial_button wait.until(EC.element_to_be_clickable((AppiumBy.ID, com.android.dialer:id/dialpad_fab))) dial_button.click()备用定位策略如果ID不稳定尝试用其他属性组合定位比如XPath但尽量少用性能差且易变、accessibility id对于有内容的元素、class name配合text等。处理动态ID如果ID是动态的包含时间戳或随机数尝试用XPath的contains、starts-with等函数进行模糊匹配。# 例如ID是‘button_123456’其中数字部分动态变化 driver.find_element(AppiumBy.XPATH, //*[contains(resource-id, button_)])7.2 权限弹窗与系统弹窗干扰问题测试被突如其来的“是否允许应用访问通讯录”、“是否允许录音”等弹窗打断。解决首选如前所述在desired_capabilities中设置autoGrantPermissions: True或autoAcceptAlerts: True。备选如果上述无效可以写一个通用的弹窗处理函数在每次操作后检查并处理。def handle_alert_if_present(driver): try: # 尝试查找常见的允许/确定按钮可能需要适配不同系统 allow_btn driver.find_element(AppiumBy.ID, com.android.packageinstaller:id/permission_allow_button) # 或者用更通用的定位包含‘允许’或‘ALLOW’文字的按钮 # allow_btn driver.find_element(AppiumBy.XPATH, //*[contains(text, 允许) or contains(text, ALLOW)]) allow_btn.click() return True except: return False # 在关键操作后调用 dial_button.click() time.sleep(1) # 给弹窗一点时间弹出 handle_alert_if_present(driver)7.3 跨设备同步与时序问题问题主叫脚本已经拨号但被叫脚本还没准备好接听导致呼叫超时失败。解决状态同步不要依赖固定的sleep。主叫拨号后可以轮询查询自身状态是否为DIALING或OFFHOOK确认拨号请求已发出。被叫端则轮询检查来电状态RINGING。使用简单的网络同步如果两台设备在同一个网络可以搭建一个极简的HTTP服务作为“协调器”。主叫拨号后向协调器发送“我已拨号”的信号被叫端轮询协调器收到信号后再开始执行接听检查。这比单纯靠时间同步要可靠得多。增加重试和超时机制任何可能失败的操作如点击按钮、检查状态都应该包裹在重试逻辑中。from selenium.common.exceptions import NoSuchElementException, TimeoutException import time def click_with_retry(driver, locator, max_attempts3): for attempt in range(max_attempts): try: element driver.find_element(*locator) element.click() return True except (NoSuchElementException, Exception) as e: if attempt max_attempts - 1: raise e print(f点击失败第{attempt1}次重试...) time.sleep(2) return False # 使用方式 click_with_retry(driver, (AppiumBy.ID, com.android.dialer:id/some_button))7.4 性能优化与稳定性提升减少对UI的依赖能用ADB命令完成的操作优先使用ADB。例如挂断电话用KEYCODE_ENDCALL比找UI按钮稳定得多。启动应用也可以用adb shell am start。使用resetOnSessionStartOnly在desired_capabilities中设置resetOnSessionStartOnly: True。这会让Appium在第一次启动应用时执行重置如清除数据但在同一个会话内的后续测试中不再重置。这可以节省大量时间特别是你的测试用例需要依赖上一个用例的状态时需谨慎设计用例顺序。合理管理会话对于一组相关的测试用例尽量复用同一个driver会话而不是每个用例都重新启动应用。在setUpClass和tearDownClass中管理驱动生命周期。把这些技巧融入到你的脚本和测试框架中能极大提升自动化测试的稳定性和执行效率让它从“偶尔能跑通”变成“持续稳定运行”的可靠质量守护环节。