Guide to Mobile Testing

移动应用已经风靡全球，在移动互联网如此普及的今天，移动测试的重要性不言而喻。个人认为移动应用现在是大部分互联网公司的主要业态，在竞争激烈的现时，移动应用的质量可能会影响某个产品的成败与存亡，在去测试化思潮如此普遍的今天，移动端应用应该是最不可能砍掉测试人员的。因为

• 移动应用的质量是第一大事
• 竞争越激烈，好的质量越重要
• 测试移动应用的效率目前还是偏低，用高薪的开发人员去兼任测试职能有点得不偿失
• 移动端更新成本相对较高，测试充分再发出去才能尽可能地规避更新应用进行bugfix的风险

诚然，有些公司在推进去测试化，但那些公司可能是

• 所在行业垄断性质明显，没有其他公司可以进行正面竞争，比如微软
• 公司和用户对线上问题忍耐度相对较高，应用形态相对单纯，试错成本相对较低，比如之前的头条
• 行业已过高速增长期但存量竞争激烈，产品基本处于维护阶段，不需要投入太多的开发和测试资源，比如腾讯的某些产品

从这里开始就是翻译了，原文地址在：https://medium.com/@iamfaisalkhatri/guide-to-mobile-testing-d0dd2d9b59f1

所以大部分情况下，移动端的测试以及质量提升是需要专职测试人员进行负责和统筹的，所以不必焦虑。相反，了解一些基本的移动端测试知识是一件较为必要的事情。

质量是关键

我们需要检查所有内容以及所有可能的排列和组合，以免出现任何bug。由于移动设备也存储了最终用户的个人数据，因此有必要对安全性和数据完整性进行检查。

测试应用程序的性能同样重要，因为如今人们对应用程序的速度更感兴趣。如果功能能用，但应用响应时间过长，可能无法吸引用户。因此，应用程序的性能测试也是需要考虑的重要因素。

谈到测试移动应用程序，我认为我们应该首先弄清楚测试策略，因为它可以帮助我们分解测试阶段并进行高质量的测试，并帮助我们避免漏测一些重要内容。

定义测试策略

首先我们需要弄清楚移动应用的类型

• 原生应用：离线可以直接用安装包进行安装，一般情况下可以在应用商店下载
• 移动web应用：比如h5应用，基本是用html+css+js进行开发的，可能长得跟原生应用很像，但基本上不是一回事
• 混合应用：既有原生也有移动web的应用，一般情况下对开发人员比较友好，毕竟web应用比原生应用开发要容易一点点

我们以混合应用为例在说明一下如何定义我们的测试策略，在进入细节之前，我们先来了解一下测试类型的相关知识。

测试类型

理想情况下，虑到混合应用程序，我认为应该考虑以下测试类型

1. 功能测试。
2. 性能测试
3. 安全测试
4. 可用性测试
5. UI/UX 测试

何时以及如何开始测试

由于我们处于当今软件世界虔诚地遵循敏捷的时代，因此最好尽早开始测试。

测试应该在软件开发生命周期的每个阶段进行，而不仅仅是在功能完全开发时进行。

话虽如此，请始终确保开发人员正在编写单元测试。还应涵盖集成和服务层测试。只写测试没有帮助，代码覆盖率报告应该显示单元测试覆盖率至少大于 80%，如果有可能的话，可以逐渐增加到 100%。有一条流水线可以帮助我们轻松监控生命周期并在每个阶段采取纠正措施，这很好。因此，除非构建是绿色的，否则继续进行测试并尽快进行所需的修复是不好的。

测试计划

有一个测试计划是很好的，因为它会更容易检查所有的测试活动，所以我们不会遗漏任何东西，顺利地执行测试并提供高质量的输出。

第一个也是最重要的情况是用户是否能够使用 PlayStore/App Store 成功安装应用程序。

接下来，是检查安装成功后应用程序是否正确打开。

以下是我们在测试移动应用程序时需要注意的所有测试活动的一般列表：

• 搞清楚在预期发布应用程序的地区广泛使用的移动操作系统平台。
• 根据从第 1 步得出的结果 — 检查哪些都是该地区流行的移动设备，并相应地列出所有流行的设备。
• 从第 2 步生成的列表中，取出前 5 个设备并考虑将它们用于测试目的。此外，请确保您采用大屏幕和小屏幕尺寸的组合，以便更好的去覆盖ui/ux的检查项。
• 考虑操作系统版本也很重要，例如，对于之前在上述步骤中考虑的地区和操作系统，iOS 版本 14 和 15 是该地区流行的版本。因此，在这种情况下，请确保您在 iOS 版本 14 和 15 上进行测试。大多数时候漏掉的另一件重要的事情是最低版本支持。因此，如果您的应用程序支持 iOS 版本 12 作为最低版本，请确保在大小屏幕设备上对 iOS 版本12进行一轮充分的回归测试。根据我的经验，大约 1-2% 的一些讨厌的 bug 来自这里。
• 从自动化的角度来看，如果您可以在选定的设备上并行运行测试并根据上述步骤中设置的标准选择一些最新的设备，那就太好了。因此，从回归的角度来看，最好所有的端到端测试都可以用自动化方式运行，并在出现任何问题时自动告警。
• 由于某些原因，无法将某些测试用例作为自动化的一部分进行覆盖，因为我们都知道并非所有内容都可以实现自动化，那么可以在手动探索性测试活动中进行覆盖。

`

下面是一些额外的检查项：

• 从一个界面移动到另一个时，不会多次调用相同的 API。
• 抖动抑制也是一个重要的检查项，因为它最终会影响应用程序的性能。例如在特定屏幕上多次执行下拉刷新，并在每次完成刷新时发送请求检查。这里的预期结果是虽然用户多次下拉刷新，但刷新屏幕的请求应该只在特定的时间间隔发送，而不是每次发送。这将确保应用程序的性能不会因为几秒钟内的多个请求而受到影响。
• 注意 UI 字体/颜色和文本大小是很好的，因为在移动应用程序中它对最终用户很重要，甚至背景颜色/字体/字体大小的视觉变化也会影响应用程序的整体使用。因此，检查颜色组合、字体、字体大小等的一致性是必要的。
• 我建议让 UI/UX 人员参与测试会话，以便他们可以公平地向我们展示问题和还原度的差异，防患于未然。
• 通过在 1-2 台不同的设备上手动运行应用程序来检查应用程序的功能和性能。
• 还应检查前端生成的步骤日志。因为如果生产环境中出现任何问题，日志将有助于问题的定位
• 进入日志时，请检查是否有任何个人信息 (PII) 未记录在日志中，因为这会导致法律后果。
• 我们还可以检查应用程序的导航和 Web 视图中链接的打开情况，因为它是一个混合应用程序，我们应该期望应用程序中的所有链接都应该在 Web 视图中打开，而不是在外部浏览器上打开
• 检查应用程序是否正确发送通知，并且这些通知是否正确显示在手机的通知区域中。
• 我们可以检查通知消息是否将用户导航到应用程序中的相应区域。
• 如果用户正在运行其他应用程序并且此应用程序的通知出现在两者之间，它会是什么样子？除非它是用户友好的，否则这可能是最终用户的痛点，最终可能导致用户卸载应用程序。

其他的通用型测试

手机电池使用场景：

• 检查应用程序是否大量消耗电池，因为这会导致最终用户卸载应用程序。预期结果是应用程序在工作时应使用最少的电池。
• 测试app在后台时的电池使用情况。它也应该是最小的。

与移动设备闲置相关的场景：

• 如果您在应用程序中实现了登录功能，您可以在应用程序被用户闲置一段时间并进入后台后检查应用程序是否有注销用户。
• 如果您有一个支付相关的应用程序，例如，如果手机闲置一段时间后执行支付，那么该应用程序应该可以顺利运行并成功执行所需的交易。
• 在手机闲置的情况下，App不应该消耗大量电池，并且我们可以检查手机是否发热，因为这会导致负面评论并影响整体业务。
• app进入后台一段时间以后用户尝试去唤醒并继续使用时应用程序应该有什么样的表现？这纯粹是一个技术方案，可以与团队讨论并根据技术要求相应实施。

锁屏相关场景：

• 我们还可以检查手机锁定场景，例如，在应用程序中获取任何数据时，应用程序需要很长的时间，同时如果用户手机被锁定，那么应用程序应该在后台保持活动并执行用户需要的进行的操作。
• 另一种情况是，如果用户在正在进行的交易期间故意锁定手机，在这种情况下也应该预期交易成功完成并且交易不会被取消。
• 另一个要检查的情况是手机在使用应用程序时锁屏了，我们可以再次检查电池使用情况，电池消耗应该最小。

联网/WiFi 和定位服务相关的场景：

• 当手机上的网络关闭时，我们可以检查应用程序在某些交易过程中是否会中断。在这里，预计应该向用户显示带有“No Internet”的提示。
• 接下来，我们可以检查网络何时恢复并且用户再次在线，在这种情况下，应用程序应该恢复正常工作并且不应该显示“No Internet”的提示。
• 用户应该能够在连接到 WiFi 和移动网络时使用该应用程序。
• 另一个检查点是通过将手机连接到移动热点并检查应用程序是否运行顺畅，虽然这种情况不需要深入测试，但是执行此测试是好的。
• 我们可以通过突然打开飞行模式来检查应用程序的行为。如果应用程序具有某些依赖项，例如与智能手表相关的应用程序，则设备应断开连接且不会出现任何错误消息，并且应运行流畅而不会导致应用程序崩溃。
• 同样，通过关闭飞行模式，一切都应该恢复正常，只需最少的用户干预。
• 我们可以通过打开/关闭手机中的定位服务并检查应用程序是否能够分别发现位置服务打开/关闭，并在应用程序中显示适当的获取权限消息

总结

总之上面的检查项都来自作者的既往的经验，更多的测试内容就需要大家自行添加了。

到这里翻译就结束了。

喜加一

这里我补充一点，也是容易忽视的一点：移动应用如果是运行在手机上的，那么在程序运行过程中的一些硬中断测试也是需要的，比如使用过程中电话打入，突然没电了，突然弹出强制升级更新等等。