TG咨询弹窗出现了，不代表电话接得通；语音能播放，也不代表锁屏和后台状态可靠。云端运行应用的来电弹窗与语音链路模拟测试，最容易漏掉的是系统来电与应用内网络电话的区别，以及云端设备对通知、麦克风和扬声器的限制。
先明确测试对象：这里的“来电”可能是运营商电话，也可能是 VoIP 网络电话。两者使用的系统接口、通知路径和音频接管方式不同，不能用一次弹窗截图代替完整验收。
先分清来电入口：弹窗不是同一条链路
运营商电话由移动网络和操作系统处理；应用内通话通常由业务服务触发，再通过推送通知唤醒或提示应用。Android 常见相关机制包括 Telecom 框架与 FCM 推送；iOS 网络通话可能涉及 CallKit 与 APNs。具体行为取决于应用实现、系统版本和权限设置。
云端测试若只能在应用内模拟一个“来电事件”，就未必覆盖真实推送延迟、锁屏展示或系统来电界面。反过来，云设备也未必具备真实蜂窝网络能力。因此测试计划应标明验证的是运营商来电、VoIP 来电，还是仅验证应用界面。
五类容易遗漏的边界条件
应用状态与权限
- 前台、后台、进程退出：分别检查响铃、横幅或全屏界面、接听入口和拒接后的状态。强制结束应用后的表现与普通切后台不同，需按系统规则单独记录。
- 锁屏与通知权限：检查设备锁定、通知被关闭、专注或勿扰模式开启等条件。它们可能改变提示方式，不应把“没有全屏弹窗”一概判成同一种故障。
- 同时来电与重复推送：验证用户已接听后旧通知是否失效，以及短时间重复事件是否产生多个弹窗或重复振铃。
音频状态与传输质量
接通后要验证双向声音，而不只是通话计时器变化。检查麦克风授权、静音键、扬声器切换、耳机接入和音频焦点；音乐、导航等其他音源正在播放时，也要观察接听与挂断后的恢复情况。
若采用 WebRTC 等实时传输方案，语音还会受网络往返延迟、抖动和丢包影响。可在受控环境中逐档注入网络损伤，例如将往返延迟设在约 100—300 毫秒、抖动设在约 20—80 毫秒，并以 1%—5% 丢包作为探索性压力区间；这些是测试档位，不代表所有网络的实际表现。记录断续、静音、恢复时间和通话状态，避免只凭主观“听起来还行”判断。
云端执行时，环境本身也要纳入结论
云手机或远程模拟设备能扩大系统版本和屏幕状态的覆盖范围，但不同服务对麦克风输入、扬声器输出、锁屏和推送的支持不一。音频可能被虚拟设备替代或重定向，自动化脚本也可能无法真实验证双向采集。测试报告应区分“界面已验证”和“真实音频链路已验证”；后者必要时仍需在具备实际音频硬件的设备上复核。
- 写明来电类型、设备环境、系统版本、应用版本及所需通知和麦克风权限。
- 分别准备前台、后台、锁屏、进程退出四种状态，逐一触发测试来电。
- 记录推送到达、弹窗出现、接听、首段声音、挂断的时间点，并保存应用与服务端日志。
- 在接听后测试双向语音、静音、扬声器切换、网络变化和重复来电，再核对状态是否一致。
- 对云端无法提供的蜂窝网络或真实麦克风能力，明确标注未覆盖项，不用模拟结果替代实机结论。
用分层结果避免“看见弹窗就通过”
建议将验收拆成通知与界面、通话状态、双向音频、弱网恢复四项。云端运行应用的来电弹窗与语音链路模拟测试适合发现状态组合和界面问题，但测试边界必须写清：模拟器触发成功，不等于运营商来电可用；音频通道可打开，也不等于真实设备上的声音质量合格。
常见问题
云端模拟来电能代替真实电话吗？
不能一概替代。应用内 VoIP 事件可在适配的环境中验证；运营商电话涉及蜂窝网络和系统能力，需确认云设备是否支持，必要时使用实机补测。
只检查弹窗截图够不够？
不够。还要验证接听和拒接后的状态、推送时序、锁屏表现，以及麦克风到扬声器的双向声音。
弱网测试应重点记录什么？
记录延迟、抖动、丢包设置及其持续时间，并观察语音中断、静音、重连和状态恢复。结果只适用于所用设备、网络模拟方式和应用版本。