移动应用程序中的中断测试
托马斯·汉密尔顿
什么是中断测试？
中断测试 是移动应用测试的一个分支，主要关注应用如何响应中断并恢复到之前的状态。中断可能来自应用外部——操作系统、硬件或其他应用——测试旨在验证控制权恢复后，数据、屏幕状态或正在进行的事务是否丢失。
中断测试适用于任何类型的应用程序——Web、移动、独立应用程序等等。设备、网络和配置的多样性使其显得尤为重要。 通过手机捐款 比其他应用更受欢迎。
为什么需要中断测试？
开会时几乎总会发生的一件事是什么？被打断，对吧？有些人被打断时连眼睛都不眨一下，有些人需要一分钟才能回过神来，还有些人会完全失去思路。简单来说，中断测试就是为了找出你的应用程序会表现出哪种行为。
暂时抛开所有措辞，来看另一个实际场景。假设你有一个手电筒，你打开它。电池没电了，这中断了它当前的工作状态。更换电池后，手电筒应该恢复正常工作。这就是使用场景。中断测试就是专门测试这种情况是否发生的测试方法。
商业案例很简单。中断总是发生在最糟糕的时刻——付款进行中、上传过程中、表单填写过程中——用户一旦丢失了工作成果，就很少会再次尝试。恢复后崩溃、屏幕空白、重复交易和表单输入丢失等缺陷，只有在中断的情况下才会暴露出来，因此，即使经过不会中断任何操作的功能测试，这些问题也不会被发现。
移动应用程序中的中断类型
干扰因素大致可以分为几类，如下图所示。
我们都熟悉日常生活中常见的各种干扰。以下列举其中一些：
- 电量不足
- 电池已充满——充电时
- 来电
- 收到的短信
- 来自另一个移动应用程序的通知
- 插入电源即可充电
- 充电中已拔出电源插头
- 设备关闭
- 应用程序更新提醒
- 响闹
- 网络连接丢失
- 网络连接恢复
此列表并不详尽，但涵盖了最常见的场景。一种实用的分类方法是按来源分类：设备相关事件（例如电池电量和充电）、用户发起的事件（例如接听电话或切换应用程序）以及外部事件（例如在电梯或隧道中信号丢失）。
中断情况下的解决方法
发生这些中断时，预期行为是以下四种情况之一：
- 在后台运行： 当应用程序处于后台运行时，中断事件会接管控制权。中断结束后，应用程序才会重新获得控制权。例如，当您在 iBooks（或类似应用程序）上阅读电子书时，接听电话或进行 FaceTime 通话。当您接听电话时，iBooks 会等待通话结束，然后在通话结束后恢复运行。
- 显示提醒： 提示消失后，您继续正常工作。应用顶部会显示“已收到短信”的消息。用户不会理会，继续正常使用应用。其他移动应用的提示，例如 Facebook 上的新好友请求或 WhatsApp 消息，也属于此类。但如果用户选择阅读消息，则会按照第 1 点所述的方法进行处理。如果忽略提示，应用状态保持不变。
- 呼吁采取行动： 闹钟必须关闭或稍后提醒后才能继续工作。应用更新消息也一样，您必须先取消或接受更改才能继续操作。低电量提醒也是如此——您可以选择照常使用，或者如果设备支持，也可以进入低功耗模式。
- 没有影响： 例如，当网络连接可用时，您的设备会连接到该网络。此外，当您将设备插入电源充电时，无需任何提示或操作步骤。它很可能会在您继续使用应用程序的同时自动完成充电。
因此，根据您要测试的中断类型，了解其行为并检查您的应用程序是否满足要求。此外，上述行为并非适用于所有应用程序和设备。请务必了解您的移动应用程序的具体细节。
中断测试用例并给出预期结果
一旦就预期解决方案达成一致，每次中断都将成为一个普通的测试用例，包含触发条件、操作步骤和可验证的结果。下表展示了上述四种解决方案如何转化为具体场景。
| 打断 | 测试场景 | 预期结果 |
| 来电 | 当表单填写到一半时触发通话，接听电话，然后结束通话。 | 应用程序切换到后台运行，并在同一屏幕上恢复运行，已输入的数据保持不变。 |
| 收到短信或推送通知 | 视频上传或录制过程中发送消息，请忽略横幅提示 | 横幅出现和消失；应用程序状态未发生变化。 |
| 响闹 | 允许预定的警报在会话进行期间触发，然后将其关闭。 | 警报系统会先发出操作指令，然后应用程序才会从停止的地方继续运行。 |
| 低电量警告 | 交易过程中将设备电量耗尽至警告阈值 | 显示警告信息，交易不会被取消，低电量模式不会导致屏幕损坏。 |
| 网络连接丢失 | 请求过程中禁用连接，然后恢复连接。 | 显示清晰的消息，未发生崩溃，请求在恢复过程中安全完成或安全失败。 |
| 充电时已插入或未插入电源 | 在会话期间连接和断开充电器 | 无影响——应用程序继续运行，未见明显变化。 |
| 应用程序更新提醒 | 应用程序使用过程中弹出更新提示 | 用户可以取消或接受，无论用户选择哪种方式，底层屏幕都会保持不变。 |
针对每个关键屏幕，每次中断都保留一行记录，而不是针对整个应用程序的每次中断都保留一行记录。支付屏幕、登录屏幕和长表单的故障方式各不相同，使用一个通用的案例可以隐藏这些差异。
现在我们了解了什么是中断测试以及在进行中断测试时要验证什么，现在是时候讨论如何进行中断测试了。
如何进行中断测试
看看这个声明：当用户接到来电时，iBooks 必须在后台运行。
你不认为这是iBooks应用程序的一项功能性要求吗？反正我是这么认为的。
因此，中断测试是 功能测试 对于移动应用程序而言，中断测试的执行方式与其他移动应用程序测试框架和工具相同。测试人员的技能在于构思这些测试场景。场景构思完成后，即可设计测试用例并执行，其方式与其他任何测试完全相同。
实际上，该步骤简短且可重复：
- 列出关键用户流程——登录、支付、上传、填写长表单、媒体播放。
- 将上面列表中所有可能的中断情况映射到每条行程中。
- 与产品负责人商定每对产品的预期分辨率，因为没有通用的默认值。
- 在风险最大的时刻执行中断操作，而不是在空闲时刻，然后再恢复执行。
- 恢复后，不仅要验证应用程序是否仍然打开，还要验证其状态、数据、会话和内存。
有关该学科的更多信息，请参阅…… 移动测试 教程和示例案例 移动应用测试.
模拟中断的工具和技术
上述场景需要按需生成，而不是等待生成，而每个平台都提供了实现这一目标的方法。
- Android 模拟器扩展控制： 模拟器侧面板模拟来电、短信、电池电量和充电器状态以及蜂窝信号强度，因此无需第二个手机即可启动大多数中断列表。
- iOS模拟器和 Xcode: 连接性和硬件状态可以通过模拟器和设备设置进行更改，而配对的物理设备可以涵盖模拟器无法提出的呼叫场景。
- 第二个物理设备： 使用另一部手机拨打或发送短信给被测设备仍然是重现真实中断的最可靠方法，尤其是在对时间要求较高的情况下。
- 设备设置： 飞行模式、Wi-Fi 开关、勿扰模式、省电模式和定时闹钟涵盖了实际硬件上的连接和电源中断情况。
- 自动化框架： 用于其余功能套件的同一自动化堆栈可以在中断前后驱动应用程序，因此恢复检查是断言而不是人为检查的。
- 真实设备云： 托管设备集群扩大了对不同制造商和操作系统版本的覆盖范围，这很重要，因为中断处理是供应商定制差异最大的领域之一。
无论采用何种机制，都要在测试用例中记录中断发生的确切时刻。“上传过程中中断”和“上传后中断”是不同的测试，具有不同的故障模式。
中断测试的最佳实践
一些习惯能将一个有用的中断套件与一个走过场的例行公事区分开来。
- 在最糟糕的时刻打断： Target 事务提交或文件写入的瞬间，状态最为脆弱。
- 测试的是恢复过程，而不是中断本身： 缺陷几乎总是在控制恢复后出现，因此断言应该在恢复的屏幕上进行。
- 涵盖网络变化的两个方向： 失去连接和重新建立连接是两回事，后者通常被忽略。
- 改变持续时间： 两秒钟的警报和十分钟的通话会推动应用程序经历不同的生命周期路径，包括从内存中被驱逐。
- 适用于各种操作系统版本和低端硬件： 在资源受限的设备上，后台驱逐机制会更加激进，从而暴露旗舰手机所隐藏的缺陷。
- 将重复性工作自动化： 连接和电池中断自动处理，无需人工干预，即可处理呼叫和警报情况。
- 关注资源使用情况以及状态： 即使屏幕显示正常，恢复时出现内存泄漏或电池电量耗尽的中断也是一种缺陷，这使得这项工作与……联系起来。 移动应用程序性能测试.
中断测试与恢复测试不一样吗？
不它不是。 恢复测试 验证故障恢复是否成功。中断并不一定意味着故障——它仅仅是一种中断。trac化。
这就像英语中逗号和句号的区别。区别仅在于技术层面，但道理却很清晰。恢复测试考察的是应用程序在发生故障后能否恢复；中断测试考察的是当其他任务接管前台时，应用程序是否还会出现任何故障。
这就是开始进行中断测试（移动应用程序测试中一个重要且直观的分支）需要了解的内容。
