APP中断测试知多少我见过太多这样的线上问题用户正在填一笔转账表单电话进来了接完电话切回应用表单数据全没了或者是应用白屏了一两秒又或者更狠一点——直接崩溃回到桌面。这类问题在开发自测阶段往往很难发现因为自测时大家都专注于「功能能不能跑通」很少有人真的在同一时间让电话打断、锁屏、低电量弹窗轮番上阵。这正是APP中断测试要补的窟窿。中断测试Interruption Testing简单说就是验证应用在被电话、短信、通知、锁屏、系统弹窗、应用切换、内存回收等事件打断之后进程、页面、数据、交互都能按照预期恢复正确。这篇文章面向的是移动端测试工程师、质量团队负责人以及那些想让自己的应用更抗造的客户端开发者。我会把中断源的分类、用例设计、执行方法、自动化思路、典型缺陷根因一路拆开讲把我这几年在APP中断测试上踩过的坑和沉淀下来的经验都倒出来。1. 中断测试到底在测什么先搞清楚打断的性质很多人把中断测试等同于打电话进来那视角太窄了。真正的中断测试要覆盖的是所有能让应用从活跃状态被强行拉走的场景而这些场景在系统层面都会触发一连串生命周期回调。搞清楚这一层后面设计用例才有坐标系。1.1 一类是被系统打断一类是被用户打断我习惯先把中断事件分成两大家族。第一类是系统级打断特点是不由用户主动发起应用被动响应。典型代表是来电尤其在Android平台上电话呼入属于高优先级事件会直接抢占应用的音频焦点和显示焦点其他还有低电量弹窗、系统升级提醒、日历闹钟、后台下载完成通知以及Android在资源紧张时向应用发出的onTrimMemory回调。这类打断的危险性在于应用可能根本没有准备正在播放的声音突然停了正在录制的视频被系统收走了麦克风正在进行的定位突然拿不到权限。第二类是用户级打断特点是用户主动触发系统行为应用需要配合让路。包括按Home键、拉出控制中心、打开最近任务、切到其他应用、开启分屏或画中画、下拉状态栏以及手机锁屏再解锁。这类打断看似温和其实最容易暴露问题因为用户切走再切回的时间、路径完全不可预测系统可能在这段时间里把应用进程杀了也可能恢复了但状态丢了。把这两类分开的意义在于它们的测试手段、期望结果、自动化脚本编写方式都不一样。系统级打断通常需要真机配合特定条件去触发用户级打断在模拟器上就能完成大半后续我会分别展开。1.2 生命周期回调是中断测试的底层坐标系不管你测的是Android还是iOS中断测试的本质都在验证一件事应用在「活动状态 - 非活动状态 - 回到活动状态」这个过程中有没有完整保存现场、有没有正确重建现场。Android这边的关键回调链是这样的当电话打进来Activity会先走onPause如果用户接听或跳转到通话界面再走onStop如果内存紧张系统可能直接杀死进程但会先调用onSaveInstanceState把UI状态暂存起来等用户回到应用如果是同一个进程还在走onRestart - onStart - onResume如果进程已经被杀了那就要走完整的onCreate并在onRestoreInstanceState里恢复之前存档的界面状态。iOS侧稍有区别但逻辑一致。应用进入后台会先触发applicationWillResignActive如果完全退出活跃状态再触发applicationDidEnterBackground回到前台时反过来走applicationWillEnterForeground和applicationDidBecomeActive。如果你用的是UIScene生命周期还要关注sceneWillResignActive、sceneDidEnterBackground这一组回调。需要特别注意的是iOS系统对后台应用的管理比Android更霸道很多应用还没进入onDisconnect就被挂起了所以恢复时的状态校验要做得更保守。理解了这条坐标轴中断测试的每一步校验就有了依据中断发生时UI有没有正常响应回调去暂停动画、保存草稿、释放独占资源恢复时UI有没有按照回调顺序去拉取最新数据、恢复现场、重新申请系统资源。不用把几十个回调顺序背下来但必须清楚自己应用在onPause/onStop/onSaveInstanceState里到底写了什么没写什么通常问题就藏在这些没写的地方。2. 按照中断源拆一张用例地图从电话、通知到低电量中断源太杂如果没有一张清单测试就容易漏。我习惯把中断源拆成通信类、系统事件、硬件状态、网络事件四大块每一块再结合应用自身的页面特点去扩充用例。2.1 通信类中断的边界条件通信类是我们最熟悉也最容易想当然的一块。来电、短信、语音通话通知、视频通话请求、VoIP后台推送这些都算。但你要把边界条件想清楚否则只测一个「来电接听」就完事等于白测。拿来电来说至少要覆盖这几个分支来电时应用在首页避免或接听恢复后页面正常来电时应用正在播放视频或音乐中断后播放状态是暂停还是继续播放音量是否正确恢复来电时应用正在录音或通话音频焦点被抢占后录音有没有停止、应用内通话有没有进入保持状态来电时应用正在做网络请求请求是超时重试还是被系统直接挂起多个来电连续打入或者来电和短信同时到达应用能否处理叠加事件短信和普通通知类的测试则要关注通知栏交互用户下拉通知栏点开某条通知、滑动删除通知、点击通知跳转到对应页面返回原应用时页面状态是否正常。这里最容易出问题的不是Android端反而是iOS端因为iOS的通知弹出方式更多样Banner样式、提醒样式、锁屏样式恢复动画和焦点切换逻辑不完全一样。VoIP类和音视频通话类应用建议把通信中断测试升级为核心用例因为这类应用和系统电话共享麦克风、扬声器、听筒等音频硬件。我遇到过一个很典型的场景应用内视频通话中接入系统来电挂断系统电话后应用的声音从扬声器变成了听筒或者干脆没有声音。这种问题在开发环境很难发现因为开发同学很少会用两套通话链路在真机上互相抢占。2.2 系统事件与权限弹窗的重叠场景系统事件里闹钟、日历提醒、低电量弹窗这老三样必须进用例库但更值得关注的是「系统弹窗叠加应用自身弹窗」的场景。应用经常会在进入页面的瞬间弹出权限请求、版本更新、运营活动、优惠券、评分引导之类的自定义弹窗。如果这时候恰好来一个系统低电量弹窗或者来一条通知横幅弹窗之间的层级关系就可能乱套应用弹窗被系统弹窗盖住后用户明明点了「确定」回调走的却是「取消」事件或者系统弹窗消失后应用弹窗还停留在界面上把后面的按钮全挡住了。这种叠加场景用表格记录最好使每一行就是一个组合中断源A | 中断源B | 前置页面/状态 | 操作步骤 | 期望结果 低电量弹窗 | 应用版本更新弹窗 | 首页弹窗未点击 | 请求获取定位权限 | 两个弹窗依次关闭页面按钮可点 来电横幅 | 应用内悬浮球 | 播放视频页 | 接听并挂断 | 悬浮球位置不漂移视频不自动跳转 日历提醒 | 输入法键盘唤起 | 搜索框聚焦 | 点击提醒返回 | 键盘状态保持输入框内容不丢这类用例对测试人员的要求比较高因为你需要有意识地在「最不合适的时机」制造中断还要在恢复后按按钮、滑动、输入验证真实的可操作性而不能只截个图看个大概。2.3 硬件层面的中断电量、息屏、关机硬件状态的变化也很容易被漏掉尤其在模拟器上根本摸不到。息屏再亮屏是最基础的但你要分清楚息屏前应用处于哪个状态视频通话中息屏、导航中息屏、录音中息屏、全屏游戏中息屏这些场景下系统可能会做不同的调度。比如某些机型息屏后为了省电会杀掉正在后台运行的应用恢复点亮屏幕时应用就直接重启了有些应用息屏后没有释放相机再次亮屏时相机预览卡死或黑屏。低电量这个中断源就更值得玩了。真正的低电量弹窗出现时应用可能正在播放视频、正在上传大文件、正在后台下载。你要重点验证这几种行为低电量弹窗是否导致应用内视频播放暂停上传任务是被系统挂起还是自动停止弹窗出现后应用有没有出现明显的卡顿或内存抖动。关机重启是所有中断里最重的一档它实际上验证的是进程被杀后应用能否从零重建。测试时先把应用切到后台然后长按关机键等手机完全关机重启再打开应用看是直接恢复现场还是回到了启动页。这里一个典型的缺陷是应用宣称支持「进程被杀恢复而不用重新登录」但实际重启后登录态失效或者用户详情页数据被重置成默认值。除了这些还有耳机插拔、蓝牙断开、USB数据线拔插这类外设中断。尤其是做音视频、IoT、运动健康类的APP耳机拔掉后播放状态是暂停还是外放、蓝牙手柄断开后游戏操作是否重置这些都要纳入用例范围。耳机插拔有一个常见坑应用检测到耳机拔出后暂停了播放但用户重新插入耳机播放并不会自动恢复需要手动去点播放键如果UI上还显示「正在播放」这就前后端状态不一致了。3. 一次完整的中断测试执行从设计到落库有了中断源地图之后最理想的做法是把每一类中断源和应用的页面状态做一个交叉矩阵然后按风险优先级去排执行顺序而不是想到哪测到哪。我下面按我自己的执行习惯来拆解。3.1 场景权重与优先级排序中断用例是测不完的因为页面状态和中断源的组合是乘法关系。所以必须先定义风险权重。判断优先级我按照三个维度打分第一用户真实发生的频率高不高比如首页来电、切后台回前台这种天天发生权重最高第二发生之后影响严不严重转账中来电、录音中来电、提交订单中来电都属于影响严重第三发生之后是否容易恢复有些卡顿重启一下就好有些直接造成数据丢失或白屏循环。按这套逻辑P0级用例通常包含这么几类登录/支付/表单页被来电打断并接听恢复后数据与操作状态正确音视频播放页被高优先级通知打断声音暂停并恢复正确应用处于后台时被系统杀死通过内存清理模拟再打开能走启动流程录音、导航、运动记录类页面锁屏亮屏后核心功能正常P0之外的场景打到P1或P2按版本节奏去回归。如果团队测试资源紧张至少保证P0用例每个迭代跑一遍其他再慢慢补。3.2 在真机和模拟器上分别怎么执行模拟器和真机各有不可替代的价值不要妄图用一台模拟器解决所有问题。模拟器的优势是环境可控、命令干净、执行速度快。比如在Android模拟器上你可以在终端里敲命令模拟各种状态变化一套脚本反复跑非常适合做自动化回归。但模拟器也有致命短板它无法真实模拟通话模块频繁切换时信号和音频栈的行为低电量弹窗在某些模拟器上跟真机表现也不一致息屏后是否杀进程更取决于宿主机的配置所以通信类、硬件类的中断必须留到真机上做。真机上执行中断测试我一般准备两台设备一台旗舰机、一台低端机。旗舰机保证测试提效低端机用来观察内存紧张、性能下降时的表现。每一台设备都固定系统版本并且关闭自动更新避免莫名弹窗干扰测试结论。执行时建议全程开录屏并且在边栏实时抓日志。很多人忽略录屏的价值等到缺陷无法复现的时候才后悔。录屏不仅能还原操作路径还能通过慢放确认动画中断、焦点跳转、白屏闪烁这些细节这些在肉眼下就是一闪而过。3.3 用日志和时间轴验证生命周期调用中断测试不只是看「黑盒结果」更要确认「系统内部的事件顺序对不对」。所以每次执行后都要拉品牌对应的日志做二次确认。在Android上几步就能拿到关键线索# 抓取系统核心事件的日志 adb logcat -b all -d /tmp/interruption_test.log # 关注 ActivityManager 相关的生命周期切换 adb logcat -d | grep ActivityManager # 关注应用崩溃和 ANR adb logcat -d | grep -E FATAL|AndroidRuntime|ANR in # 关注内存回收事件 adb logcat -d | grep -E am_kill|am_anr|am_proc_died|trim_memory在 iOS 上用 Xcode 附带的 Console.app 看系统日志重点过滤application lifecycle、scene lifecycle和崩溃堆栈关键词。如果你用的是 Flutter 或 React Native 跨端框架还要在代码侧打印生命周期状态变化把AppLifecycleState的变化时间点打出来才能确认框架层有没有把状态正确透传给业务逻辑。把日志的时间和操作的时序对齐之后你就能看到类似下面这种情况用户在屏幕上按Home键系统立刻让Activity走onPause和onStop过了两三秒系统又发了一个onTrimMemory如果这时应用进程被杀日志里会有 am_proc_died 记录用户再点开应用进程重新创建走完整的onCreate流程。如果页面恢复后显示的数据是空的回头看日志十有八九是onSaveInstanceState里没有把数据写进去或者onRestoreInstanceState里读取逻辑写错了分支。3.4 中断后状态校验的检查清单每次中断恢复后我都会按一套固定检查清单去核对现场而不是光看页面还在不在。这里把我常用的清单列出来你可以直接拿去改页面是否还停留在中断前所在的位置有没有跳转回首页输入框内容是否保留草稿和搜索历史有没有丢失列表滚动位置是不是还在原处还是被拉回了顶部视频/音频的播放进度是否准确是暂停还是继续进度条有没有跳变录音、上传、下载任务的进度和状态是否一致有没有卡在「正在上传」但实际已断网计时器类内容是否回到正确值比如秒杀倒计时被中断后是否存在多算或漏算全屏页面如视频、摄像头预览、直播房间的方向和尺寸有没有被系统UI打乱后台进程的存活状态杀掉进程再进、不杀进程返回两条路径分别验证内存水位连续多次中断-恢复后有没有明显内存增长是否触发OOM崩溃和ANR日志中是否有新增告警其中第3条滚动位置的问题我印象特别深刻。很多应用在Activity重建之后默认回到列表顶部用户翻到第50条看到一半被一个通知打断回来后直接回到顶部。这不算崩溃但绝对影响体验。正确做法是在onSaveInstanceState里保存recyclerView/pager的position恢复时通过scrollToPosition滚回去。如果你们家的列表页没有做这个处理建议排期补上而不是等到用户投诉。4. 自动化做中断测试现实可行的路径与代价谈到中断测试很多人第一反应是要做自动化。但我得说句实话全自动中断测试的投入产出比在绝大多数团队里是负数。原因在于中断场景的分支太多断言太难写系统弹窗和真实来电难以在测试环境稳定复现。所以更现实的方案是「半自动 自动化辅助」。4.1 传统UI自动化的局限用Espresso或XCUITest跑常规UI自动化时框架会在同一个测试进程内模拟点击和断言但它默认不会真的插入一个电话进来也不会触发低电量弹窗。虽然Espresso里有模拟Activity回收的工具XCUITest里有app.deactivate()模拟按Home键的API但这些只是整个中断矩阵里极小的一部分。所以我的建议是不要把中断测试自动化当作一个全自动体系来搭建而是把它拆成「中断源制造」和「恢复状态断言」两步。中断源制造自动化恢复后的核心断言自动化中间的人肉环节保留这是最稳妥的落地方案。4.2 一种低成本的半自动截图比对方案我现在在Android项目里常用的一套方式是让脚本去触发中断源然后用UiAutomator截取恢复后的页面和预先生成的基准截图做比对。比对不是像素级比而是比对关键区域的UI元素是否在、是否出现崩溃弹窗或错误页。像素级比对在动效和系统UI差异面前会产生大量误报不值得。实际操作是这样一个流程先把应用启动到目标页面等待页面完全渲染通过adb命令制造中断事件下面是几个常用命令等待恢复时间触发返回应用自动截图把截图自动归档到用例对应的目录测试人员列出需要校对的关键点比如按钮文本、空态文案、错误提示写成一个轻量断言脚本截图和断言结果一起上报到缺陷平台用这种方式你既享受了自动化的效率又保留了人对画面语义的判断力。真实的缺陷往往不在「页面崩没崩」而在「数据对不对」这不是截图比对能全包的但截图至少可以帮你过滤掉90%正常路径。4.3 基于系统命令快速制造中断源在 Android 模拟器和已开USB调试的真机上这几个命令能帮你快速制造多种中断源# 模拟按HOME键切后台再回前台 adb shell input keyevent KEYCODE_HOME # 模拟锁屏 adb shell input keyevent KEYCODE_SLEEP adb shell input keyevent KEYCODE_WAKEUP # 模拟打开最近任务 adb shell input keyevent KEYCODE_APP_SWITCH # 模拟低电量状态设到15%触发低电量模式 adb shell dumpsys battery unplug adb shell dumpsys battery set level 15 # 模拟恢复电量状态 adb shell dumpsys battery reset # 模拟飞行模式 adb shell settings put global airplane_mode_on 1 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE # 模拟来电需要在AndroidManifest里加权限或使用模拟工具 adb shell am start -a android.intent.action.CALL -d tel:10086 # 模拟后台kill当前进程验证进程被杀后的恢复 adb shell am kill com.example.yourapp adb shell am kill-all # 发送内存紧张回调 adb shell am send-trim-memory com.example.yourapp RUNNING_CRITICAL这套命令最好在一个bash脚本里编排每个命令之间加sleep再配合screencap截图就能形成一条半自动化的中断回归链路。iOS这边就没这么方便了模拟器无法真实触发系统电话。我的经验是把iOS的自动化重点放在「用户级中断」上用XCUITest的app.deactivate()拉后台再activate()回前台其余系统级中断在真机上手测。XCUITest里有一段很典型的基础脚本let app XCUIApplication() app.launch() // 进入目标页面后调用 deactivate 模拟回后台 app.deactivate() // 等几秒再切回前台 app.activate() // 断言关键控件存在且状态正确 XCTAssertTrue(app.staticTexts[title_label].exists)实际项目里这段脚本要维护比较多的页面状态和等待条件建议只在几个P0页面上用不要贪多。4.4 数据驱动的中断用例编排一旦中断源可用脚本制造下一步就可以把用例矩阵做成数据驱动。也就是说用例不再是一条条硬编码在测试代码里而是一张CSV表格每一行写明前置页面、中断命令、中断持续时间、恢复方式、期望结果、归属模块。测试框架读取这张表格逐行执行并记录结果。这样做的好处是当新版系统新增了一种中断行为或者你们发现了一个新的中断场景只需要在表格里加一行就能纳入回归范围。而且业务测试同学不需要懂代码也能参与用例维护。我见过有的团队套用了这套思路把中断用例直接生成到企业内部的用例管理平台每次新版本发版前自动跑一遍P0集合效率比之前人肉点按高出一大截前提还是你要先把页面跳转的稳定性问题解决掉否则自动化脚本本身会因为各种偶发弹窗而中断失败。5. 中断测试里最值得记录的失败样本与根因纸上谈兵再多也不如看几个真实的缺陷有意思。下面这几个案例是从我多年测试生涯中挑出来的样本细节做了脱敏但根因和排查路径都是实打实的。5.1 视频通话中断后音频路由不恢复某视频通话应用在接听系统来电并挂断后扬声器突然没有声音了只有听筒有声音。用户侧感知是「对方声音变小了像被捂住了」。排查逻辑是这样的通过logcat确认通话过程中应用正确释放了麦克风、暂停了推送流但恢复时并没有主动把音频输出路由重新设置成扬声器。系统的音频焦点被系统通话抢占后应用侧没有在onResume回调里重新requestAudioFocus也没有重新选择音频输出设备所以系统保留了听筒模式。这个案例给我们的教训是所有涉及音频硬件的应用中断测试必须检查中断恢复后的音频路由扬声器/听筒/耳机/蓝牙并且要在代码里明确处理audio focus的重新获取。测试人员在用例里也要加上「恢复后拨号或播放本地声音文件验证外放」这一步光听个响还不够要录下来或者看音量指示。5.2 表单页被系统回收后重进崩溃另一个高频崩溃来自一个表单填写页用户填写到一半切到其他应用过了一段时间后系统内存紧张应用进程被系统回收用户再点回应用直接崩溃。复现路径虽然长但根因很清晰页面里动态创建了若干自定义View这些View没有在onSaveInstanceState里保存状态Activity被重建时这些自定义View找不到对应的实例导致空指针。更细一层页面里的EditText虽然没有直接写在XML中但代码里创建时没有设置一个稳定的id于是系统在自动保存和恢复View状态时发生错乱。修复方案是给动态创建的View设置SparseArray等结构妥善保存并且覆盖onSaveInstanceState与onRestoreInstanceState做自定义处理。这个案例提醒我们中断测试里必须加入「长时间切后台后重新进入」的场景而且要用内存压力把进程杀掉才能暴露出这类只在「进程存活但Activity被重建」或者「进程被杀后完全冷启动」两条路径下出现的问题。5.3 半屏来电打断手势交互的状态错乱某视频播放器应用在横屏全屏播放状态下接到半屏来电。用户没有接听而是点了一下「拒绝」并上滑结果来电结束后播放器却莫名其妙退出了全屏控制栏也变了一个状态。这类问题的根因往往不在播放器本身而在「界面焦点被强制切走后横竖屏方向、沉浸式状态栏、手势监听器没有重新恢复」。系统来电会把状态栏强制拉出来恢复时如果应用没有重新进入沉浸模式界面就会出现体系性的错乱。解决思路是在onResume中重新校验应用预期的系统UI状态通过WindowInsetsController或系统UI flags把当前应当处于的沉浸式状态重新设置一遍。测试执行时不要只验证「能回页面」还要验证横竖屏、全屏/半屏、控制栏显隐这些子状态。把这类子状态检查写进中断恢复清单里能抓出一大批隐藏很深的UI状态缺陷。5.4 从偶现难复现到稳定复现的经验中断类缺陷最大的痛点是偶现、难以稳定复现。我处理这类问题时有一套固定流程。第一步拿到用户的复现时间线把「中断前在做什么、中断是什么、恢复后看到什么」三段录清楚。第二步在测试机上复制同一系统版本尝试用自动化脚本模拟同一中断源连续跑20次。如果仍然偶现就加入「强制杀进程」这个变体中断发生后不等用户手动返回而是直接am kill把进程干掉再冷启动看是否能恢复。第三步如果还是不能稳定复现缩小环境变量关掉其他后台应用、设置静态IP、关闭所有系统动画把内存变化、CPU占用、时间点全部记录进来。很多「偶现」最后都被证明是某个后台任务或某个第三方SDK在特定时机触发导致的。比如一个广告SDK在应用切后台后尝试刷新素材如果它和主进程的内存清理撞在一起就会导致UI线程卡顿恢复时页面看起来像白屏。这种场景只有长期开着日志跑回归才能抓住所以测试人员一定要养成「中断场景随手开日志」的肌肉记忆。6. 中断测试的执行节奏与团队落地前面讲的都是「怎么测」但真正让中断测试持续发挥价值还要解决「什么时候测、谁来测、缺陷怎么和开发对齐」这些组织层面的问题。6.1 放在哪个阶段做中断测试不应该放在版本发布的最后一刻才做那时候发现的问题基本没有修复时间只能硬着头皮上线。我的建议是把它拆成两档节奏第一档是「提测冒烟包」。每次版本提测时由测试人员执行15分钟的核心中断用例集覆盖P0场景首页来电接听、表单页切后台再回前台、播放页通知打断、后台被杀恢复。这一档的目的不是找全所有问题而是堵住那些最基础、影响面最大的低级缺陷。第二档是「专项回归包」。每个大版本比如上线前一周安排半天到一天的时间由专人按照完整的中断源矩阵过一遍配合录屏、日志、性能统计一起做。这一档适合发现那些需要特定组合才能暴露的问题比如「低电量弹窗 应用内浮窗 横屏状态」这种三变量叠加。如果你们团队走敏捷迭代每两周一个迭代那专项回归可以放在每个迭代的倒数第三天留出两天给开发修问题。硬性问题最好在迭代内解决否则就转成缺陷线索进入技术债务管理而不是无脑拖到下一个迭代。6.2 测试人员怎么跨端协作现在的应用基本没有单端的了Android、iOS、甚至小程序和鸿蒙都得上。我的经验是国际化组织测试用例时按照「同一套业务场景 各自平台特性」来拆。举例说明一个视频播放应用其中「播放中来电暂停」这个业务场景Android和iOS都要测这是共享部分但Android侧要额外关注「来电时Activity被重建」「低内存时后台播放进程被回收」「高通/联发科各家的音频栈差异」而iOS侧要重点关注「来电时CarPlay/蓝牙音频切换」「后台音频权限被系统回收」等特性。跨端协作时最好有一个人统筹维护这份矩阵保证两端用例覆盖对称。不要出现Android覆盖了50个场景、iOS只覆盖了10个的场景否则用户会拿脚投票的。我还特别建议测试人员和开发一起分享中断测试结果而不仅仅是把缺陷单丢给开发。如果能在评审会上花二十分钟把「打断-恢复」的日志时间线和视频慢放展示出来开发对缺陷的理解深度完全不一样修复质量也会高很多。那种只写「用户来电后页面白屏」的缺陷单开发真的不知道从哪里下手。6.3 几个容易忽视的边界补充最后补充几个我在实际执行中经常发现被漏掉的边界场景。第一个是「资源竞争类中断」比如在地图导航同时放着音乐的时候有一条语音消息进来导航音量、媒体音量、通话音量被同时牵扯。这种场景需要由系统音量面板配合验证很多导航类应用在这里出现过声音忽大忽小的问题。第二个是「长时间后台挂起」切到后台不是等3秒就切回来而是要等30分钟、1小时甚至一晚上。很多应用短时间切后台正常长时间后台挂起后再回来要么连接彻底断开要么卡在某个请求上一直转圈。测试时建议在后台停留时长上做一个分布30秒、5分钟、30分钟、60分钟各取一部分用例。第三个是「恢复后的首次交互」中断恢复后用户第一下触摸屏幕焦点是否正确、点击是否被吞掉、键盘是否能正常弹出。经常有应用恢复后界面看着正常但用户点一下按钮没反应再点一下才有响应。这是因为过渡动画和触摸事件消费机制在中断恢复时出了错第一下触摸被用于结束动画导致丢失。这种问题在自动化里面很难测因为自动化的点击等待逻辑经常会自动重试掩盖了这个问题所以必须靠人肉执行验证。第四个是「弱网叠加中断」在飞行模式开关切换的瞬间恰好来了一个来电恢复后的网络重连机制和应用的中断恢复机制会同时工作很容易出现网络请求风暴或者崩溃。这个场景建议在专项回归里由真机执行不要为了省时间绕开它。做中断测试这些年我最大的体会是它不像功能测试那样能带来立竿见「bug数」的快乐但它对应用口碑的提升是实打实的。用户可能记不住你的应用功能有多丰富但他一定会记得打电话回来时数据还在的那种安心感。如果你现在正要从零搭一套中断测试体系我建议先从P0用例开始哪怕刚开始只有十个用例先跑起来再慢慢扩充。把中断测试融入日常回归节奏比单纯追求用例数量重要得多。