移动应用程序性能测试

⚡ 智能摘要

移动应用性能测试衡量应用程序的启动速度、电池和内存消耗量、API响应速度以及在不可靠的网络环境下的运行情况。

  • 🔘 三类: 设备性能、服务器或 API 性能以及网络性能共同决定了移动端的每一个瓶颈。
  • ☑️ 设备信号: 启动时间、电池消耗、内存消耗、硬件差异和后台恢复是设备的核心检查项目。
  • 服务器信号: 有效载荷大小、每次操作的 API 调用次数,以及服务器停机时的故障转移计划(需记录在案)。
  • 🧪 网络信号: 抖动、丢包和速度变化都应该产生清晰的信息,而不是屏幕冻结。
  • 🛠️ 工具: RobotiumMonkeyRunner 和 Automator 也出现在这里,尽管前两个程序已经停止维护。
  • 📊 准备: 一份涵盖内存、响应时间、并发性和抗崩溃能力的检查清单决定了构建版本是否可以发布。

移动应用性能测试,涵盖设备、服务器和网络层面。

对于任何移动应用来说,性能都至关重要。如果您的应用性能不佳,最终用户就会卸载它,转而寻找其他性能更好的应用。

您的移动应用程序在发布给最终用户之前需要经过彻底的测试。

移动应用程序测试策略

手机或任何智能设备上的应用程序性能通常通过以下三个类别来衡量。

  • 设备性能
  • 服务器/API 性能
  • 网络性能

下图将这三层结构与其对应的检查点进行了映射。

移动应用测试策略图,将设备、服务器和网络性能检查分开进行。

设备性能

当客户遇到应用程序运行缓慢时,他们会感到恼火。

为了评估设备性能,您需要检查以下各项:

  • 应用启动: 您的应用需要多长时间才能启动?这是用户判断的第一个性能参数。一般来说,用户点击应用图标后,第一个屏幕应在 1-2 秒内显示。
  • 使用应用程序时的电池续航时间: 某些手机​​应用在持续使用的情况下会消耗大量电量并导致手机发热。这通常发生在应用占用资源过多,从而加重处理器负担时。
  • 内存消耗: 日期 测试与验证 一个应用程序,应该检查应用程序的内存消耗。通过在应用程序中实现某些功能,内存消耗也会增加。例如,在 Android 应用程序在实施推送通知时,内存消耗就会增加。

    在某些情况下,我们观察到整个操作系统的内存使用率仅为 14%,但新应用却消耗了 11%。因此,在将应用部署到现实世界或交付给客户之前,必须处理这些因素。

  • 硬件/软件差异: 在测试移动应用时,必须检查不同设备上的应用。可能出现的情况是,应用在一台设备上运行顺畅,但在另一台设备上却不顺畅。例如,不同供应商的 Android 设备,我们可以在三星、HTC 和联想手机上测试该应用。同样,该应用需要使用不同的 RAM 和处理器规格(如 1 GB 或 2 GB)进行测试。
  • 与其他应用配合使用: 当被测应用与其他应用并行运行时,应该不会产生干扰。检查的最佳方法是切换被测应用和其他应用。
  • 应用在后台运行: 当从后台检索应用程序时,它应该保持之前的状态。如果这种情况处理不当,则会导致数据丢失。相关的生命周期案例将在后续章节中介绍。 中断测试.

服务器/API 性能

当应用程序通过 API 与服务器交互时,响应时间对性能至关重要。要评估服务器性能,您需要检查以下内容:

  • 服务器收发数据: 应用程序应高效处理从服务器发送的数据,加载数据的时间不应过长。某些应用程序会以特定格式发送数据,因此在应用程序中显示数据之前,需要将其转换为相应的格式。在此过程中,应用程序有时会变慢,响应时间也会延长。
  • 应用生成的 API 调用: 被测应用对服务器的调用次数应较少。在某些情况下,同一功能会进行多次 API 调用。为了获得更好的性能,应使用较少的调用次数来处理这种情况。
  • 服务器停机时间: 如果服务器因任何原因宕机或无法访问,我们可以将数据保存到本地数据库中。因此,无论何时服务器宕机,我们都可以显示存储在本地数据库中的数据。另一种解决方案是使用故障转移数据库服务器,即如果其中一台服务器宕机或处于维护阶段,则应启用备用服务器进行切换。故障转移/备用服务器应与主服务器保持持续的复制和同步。

网络性能

需要测量应用程序在不同网络和网络属性上的性能。

对于网络性能,您将检查以下内容。

  • 紧张: 当网络上的信息接收出现延迟时,就称为抖动。这是无连接网络或分组交换网络的问题。由于信息被分发到数据包中,因此数据包可以从发送方通过不同的路径传输到接收方。当数据到达预定位置时,它会变得比最初发送时更混乱。在出现抖动的情况下,移动应用程序应该有足够的能力来处理它。

    您需要向最终用户显示适当的通知,提示他们重新发送请求或等待系统再次响应。

  • 数据包丢失: 如果数据包完全丢失,应用程序应该能够重新发送信息请求或相应地生成警报。如果数据不完整,则用户将无法理解应用程序中显示的信息。这可能会给用户带来压力。因此,最好显示适当的消息或提示用户重试。
  • 网络速度: 该应用需要在多种不同速度的网络环境下进行测试。测试应涵盖 3G、4G 和 5G 网络,包括 Wi-Fi 和移动网络。此外,还应密切监控应用的运行情况,尤其是在两种网络都可用且应用在不同网络之间切换时。

    例如,用户在手机网络从 4G 切换到 Wi-Fi 或反之亦然时,应用程序可能会出现问题。在这种情况下,应用程序会无响应,可能需要重启应用程序才能继续使用。

移动应用程序性能故障排除

在发现问题后 性能测试是时候了 trace 并纠正错误。

问题1)移动应用程序滞后或响应迟缓。

造成这种延迟的原因可能是 RAM、缓存等。

您需要终止不必要的进程或清除缓存。解决连接问题可能会解决一些造成延迟的问题

问题 2)应用程序重启、锁定、冻结或无响应。

可以通过以下步骤修复

  • 优化应用程序代码
  • 软件应该修补并更新。
  • 自动恢复
  • 使用外部卡时管理 RAM 或某些情况下的 ROM
  • Wiping 缓存分区
  • 验证应用程序与其他第三方应用程序和 API 的兼容性
  • 地图ping 根据设备选择的移动应用程序

有用的移动应用测试工具

移动应用测试工具 根据设备或移动操作系统的不同而不同。一些常见的移动应用性能测试工具包括

ANDROID

  • Robotium 就像 Selenium 适用于移动应用程序。测试人员可以录制和播放执行测试所需的几个步骤。
  • 猴子赛跑者 MonkeyRunner 可以在连接到 PC 或模拟器的真实设备上运行测试。该工具有一个 API,允许从外部控制智能手机、平板电脑或模拟器 Android 码。

⚠️ 版本说明: 以上皆是 Android 条目为旧条目。 Robotium 自 2016 年以来就没有发行过任何作品,而且 Google 标记 MonkeyRunner 已停止维护,引导团队使用 UI Automator 及其 uiautomator查看器 改用检查员。

苹果

  • 自动化器(Mac) Automator 是苹果公司开发的一款应用程序。 macOS它支持通过点击(或拖放)方式创建工作流程,将重复性任务批量自动处理,从而加快修改速度。与人工逐个修改文件相比,这节省了时间和精力。

挑战

性能测试面临的主要挑战包括

  • 组织不同的移动平台及其操作系统
  • 模拟 3G、4G、5G 或 Wi-Fi 等连接方式。
  • 移动设备的限制,例如电池和资源消耗
  • 手机可用性
  • 运行相同应用程序的各种尺寸的移动设备

设置移动应用性能测试环境

要配置测试环境,您需要-

  • 了解需要测试的移动应用程序
  • 识别应用程序需要运行的不同操作系统
  • 构建测试设置
  • 构建模拟器或模拟器
  • 原型ping 实际设置
  • 选择合适的工具进行测试

移动应用程序性能测试清单

测试移动应用程序的性能是发布前的一个重要措施。性能测试是为了检查

  • 使用该应用程序需要多少 RAM?
  • 验证不同网络和环境下APP的速度和响应时间。
  • 确保多种网络条件下的真实用户体验
  • 确保在存在多个连接的情况下也能实现所需的结果
  • 确保应用程序不会崩溃。
  • 确保移动应用程序在使用数据、Wi-Fi 或其他连接时正常运行
  • 监控正常运行时间和移动 API 使用瓶颈
  • 确保最大同时用户数
  • 最后,检查移动应用程序的极限

常见问题

对于中端设备而言,两秒以内是通常的目标,这与上述规则相符。应测量第 95 百分位数而非平均值,因为实际投诉主要集中在响应速度慢的设备上。

ANR 是应用程序无响应事件,当以下情况发生时会触发: Android 主线程阻塞。无崩溃率是指未发生崩溃而结束的会话所占的比例。 Google Play 会降低超过其公布阈值的应用的优先级。

每秒 60 帧是滚动和动画的基准,而新型显示器则力求达到每秒 90 帧或更高。丢帧(也称为卡顿)即使没有崩溃,也会给人一种画面质量差的感觉。

机器学习会针对每个设备型号建立每个指标的基线,因此,回归测试会针对类似的硬件进行标记,而不是针对一个全局数值。它还会对慢速设备进行聚类分析。 traces,对影响会话次数最多的瓶颈进行排名。

Copilot 能很好地构建重复性框架,例如加载脚本框架或用于捕获内存样本的循环。阈值和设备选择会反映您的产品特性,因此在信任任何生成的断言之前,请务必仔细检查。

两者兼备。模拟器可以在流水线内提供低成本、可重复的网络和 API 运行。而真机则需要模拟电池消耗、过热降频以及厂商特定的行为,这些都是模拟器无法忠实再现的。

JMeter 是常用的开源工具,用于在应用程序使用的同一端点上驱动并发请求。它衡量服务器容量,而设备端工具永远无法获取这些信息。

构建过程会自动检查启动时间、内存或包大小的记录限制。超出此限制会导致构建失败,以便在合并时而不是发布后捕获回归问题。

总结一下这篇文章: