回答。

移动应用手动测试是通过用户在设备（或模拟器）上的操作来验证移动程序的运行过程，以确保符合开发要求。

问题历史：

随着智能手机的出现，开发和测试的重点从桌面和网络产品转向了移动设备。移动设备具有特殊的架构、有限的资源、变化的网络和独特的界面行为，增强了对在真实设备上进行测试的要求，而不仅仅是模拟器。

问题：

移动应用运行在不同版本的操作系统、设备模型、不同分辨率的屏幕和互联网速度上。错误通常在一个平台上出现而在另一个平台上不存在。一部分错误与多点触控、传感器、重启或在应用之间切换有关。

解决方案：

测试包括以下顺序步骤：

1. 准备设备，配置模拟器/真实设备。
2. 检查界面的业务逻辑和网络工作。
3. 测试在关闭Wi-Fi、来电、设备锁定时的行为。
4. 检查界面的适应性和响应速度。
5. 验证应用的安装、删除和更新。

关键特点：

• 需要在具有不同操作系统和分辨率的真实设备上进行测试。
• 重要的是要考虑连接状态变化、电话和通知时的行为。
• 需要包含资源依赖的用例场景（GPS、相机、内存、电池）。

有陷阱的问题。

在仅在模拟器上测试时，常常不会注意到哪些错误？

电池问题、性能问题、传感器问题、推送通知和与硬件交互的问题仅在真实设备上出现。

为什么重要在旧版本的操作系统上测试应用？

因为API的支持和系统功能（权限、通知）的行为有所不同；错误常常只在旧版本的Android或iOS上表现出来。

移动测试中的验证与桌面验证有什么不同？

移动测试中，必须检查对非标准场景（电话、SMS、网络丢失）的反应，而在桌面上并不相关。

常见错误和反模式

• 仅在模拟器中进行测试。
• 忽视不稳定场景（电量耗尽、网络丢失）。
• 设备和操作系统覆盖不足。

实例

负面案例

仅在iPhone 14和最新Android上通过模拟器进行测试。发布后，使用Android 7和小米的用户抱怨缺少推送通知和在回拨时卡死。

优点：

• 测试快速，测试周期短。

缺点：

• 生产中出现多个关键错误，失去客户，负面评价。

正面案例

在10台设备（不同品牌，不同版本的操作系统）的池中进行测试，尝试了来电、网络丢失、切换相机的场景。结果——在发布之前发现了错误，符合要求。

优点：

• 产品质量高，用户评价好。

缺点：

• 设备成本和更多的时间资源。