无代码合集 移动应用测试:挑战,类型和最佳实践

FunTester · 2020年07月02日 · 1032 次阅读

随着智能手机的普及,移动 app 测试越来越重要。现在很多互联网都把注意精力放在了移动端,移动 app 尽量提供完美的用户体验。但是诸如崩溃,冻结问题,加载时间慢,不直观的导航以及侵犯隐私之类的严重错误可能会触发用户立即卸载应用程序。

现在,移动应用程序已成为我们日常微时刻不可或缺的一部分,人们平均每天花费 3-4 个小时。移动应用在职业和个人生活中对每个人都起着关键作用。

因此,手机移动端测试在构建移动应用程序以提供流畅的用户体验和功能方面扮演着重要角色。

移动应用测试金字塔

软件测试的人都知道 Mike Cohn 的测试自动化金字塔。典型的金字塔由三层组成。顶部是自动化集成测试层的中间,是一个自动化的端到端测试层(包括用户界面测试),而底部是自动化单元测试层。手动测试不是测试金字塔的一部分。每一层指示每个阶段应编写的测试数量,并具有不同的大小。

对于移动应用程序测试,典型的金字塔结构不适用于移动测试自动化。与 Web 或桌面应用程序不同,移动应用程序由不同的设备,传感器和网络组成,需要不同的测试模型。

移动应用测试

移动应用程序的测试金字塔由四层组成,包括手动和自动步骤。金字塔的最顶层是手动测试,并为每个移动应用程序项目奠定了坚实的基础,随后是端到端测试,beta 测试以及包括单元测试的顶层。单元测试和端到端测试具有相同的颜色,代表自动化测试,而 beta 测试和手动测试则具相同的颜色,代表手动测试、Beta 测试层对金字塔来说是新的,但对每个移动应用程序项目都至关重要。

这个金字塔中最大的变化是手工测试是其中的一部分。移动测试需要大量的手动测试,而这不能被测试自动化或任何其他工具所取代。

端到端和单元测试层以及 beta 和端到端层也可以交换。端到端测试和单元测试的数量可能因项目而异,也因应用程序而异。

在金字塔的顶部,有单元测试。为移动应用程序编写单元测试并不像后端或 Web 应用程序那么容易。应用程序可以使用太多的 API 和传感器,因此模拟所有这些接口以编写有效的单元测试确实非常困难且耗时。在许多情况下,需要伪造或 mock 不同的 API,模块以使小型单元正常工作。从技术或经济角度来看,这是无效的。

移动应用测试的类型

功能测试

功能测试检查功能是否按要求工作。例如,它测试用户与应用程序的交互,例如启动应用程序,登录,播放歌曲,检查帐户余额和其他直接的用户流。

由于功能测试与应用程序的 UI 元素,数据库层,网络层以及其他方面交互,因此通常是耗时且复杂的过程。您需要在各种功能测试类型之间保持良好的平衡,以充分利用它。

回归测试

回归测试是检查新功能更新,补丁或配置更改时功能和非功能部分都没有带来新的响应或错误。回归测试确认开发锁进行的任何更改又要覆盖未更改的部分。

例如,许多软件即服务(SaaS)提供商将在每次软件更新时定期更新其功能或向其产品中添加新功能。为了确保其核心产品不受新功能的影响,这些公司将执行大量回归测试。

如果借助自动化测试,可以极大提升回归测试的效率,常用的开源框架有UiAutomator2appium,以及少量基于坐标和图像的录制工具。

性能测试

移动应用程序性能测试是确定系统在特定工作负载或任务下如何响应的过程。通常,性能测试会测试应用程序的速度、稳定性和可伸缩性。它在客户端和服务器端都执行。在服务器端,它检查响应时间,流资源密集型数据包,消息传递延迟,应用程序崩溃等变化。在客户端,它检查各种平台和手机上应用程序行为的通常差异,内存和 CPU 消耗,加载速度和电池问题。

最常用的测试工具是 Android SDK 自带的monkey,他最大的缺点就是不确定性,因为monkey的操作完全是无序的,即使操作十万次都不一定有一组操作是能够发现 BUG,且很难复现,极难排查问题,除非 app 出现崩溃和闪退等严重的现象。

目前比较流行的解决方案就是利用各家的云平台,通过云平台提供各类机型云真机,借助平台提供的基础脚本功能或者上传自己的测试脚本,设置一些简单的参数,即可等待云平台的测试报告。

安全测试

安全性对业务至关重要,当攻击者窃取客户数据时,安全性就成为移动应用程序开发和测试过程中非常重要的一部分。移动应用程序安全性测试是一个复杂的主题,需要许多不同领域的知识,例如客户端—服务器通信,软件体系结构和系统体系结构。由于其复杂的性质和所需的专门技能,安全测试最好由专家来完成。它包括诸如通过中间人攻击进行手动或自动渗透测试,模糊测试,扫描和审核软件的方法。

首先从代码安全说起,当前流行的 Android 开发语言有Javakotlin,后者由于是Google主推的,所以份额越来越大。目前针对代码安全的扫描工具:Checkstyle、FindBugs、PMD、Jtest 等。个人推荐findbugs,因为兼容性比较好,无论是 IDE 的插件或者 Jenkins 插件,基本上都是开箱即用,非常方便。跟其他代码管理工具搭配使用,案例 Demo 很多,资料也比较丰富。

其次 APP 的安全扫描工具有:Quick Android Review Kit (QARK),由领英开发,它是一款静态代码分析工具,可提供有关 App 安全威胁的信息,并给出简洁明了的问题描述;Zed Attack Proxy,全球最受欢迎的免费安全测试工具之一。它是一款开源安全测试工具,而且大部分控件显示支持中文;MobSF(Mobile Security Framework) 是一款自动化移动 App 安全测试工具,同时适用于 iOS 和 Android,可熟练执行动态、静态分析和 API 测试。

可用性测试

在可用性测试中,实际模拟用户检查移动应用程序的功能。该测试的主要重点在于简单,快速地使用应用程序,简单的入门以及用户对整个体验的满意度。

在测试环境中为用户提供了任务,并鼓励他们在尝试完成任务时大量思考。他们检查用户的不同习惯,以改善应用程序的用户体验。

兼容性测试

由于移动设备和平台的多样性,因此对移动应用程序进行兼容性测试是必不可少的。执行兼容性测试以检查应用程序在移动设备和浏览器组合中的行为是否符合预期。

兼容性测试中的以下实践可帮助覆盖最大数量的设备。创建设备兼容性库:获取市场上所有可用的设备或型号,并构建平台详细信息,设备支持的技术功能(音频/视频格式,图像和文档格式等),硬件功能的信息。设备以及设备支持的网络和其他技术功能。

将所有设备分为两个列表:完全兼容与部分兼容的设备。完全兼容的设备支持使所有应用程序功能无缝运行所需的所有技术功能,而部分兼容的设备可能不支持一个或几个功能,因此会导致错误消息。

浏览器和操作系统组合的测试基础架构是一项昂贵的事情。因此,这种方法是不可行且不可持续的。理想的方法是在云测试服务上测试功能,以便可以专注于测试而不必担心基础架构。也可以通过下载相应的WebDriver for Selenium使用Selenium编写自动测试脚本。

如果有足够的开发能力,也可以不使用第三方,也可以自己基于开源框架开发,最佳的实践无疑是Selenium Grid。现在,Selenium Grid可以并行运行测试用例。因为Selenium Grid有助于在本地、远程电脑上安装的特定浏览器上执行跨浏览器测试。然后可以利用Selenium中的并行测试功能来代替线性测试,从而降低总体项目成本,并在并行执行自动化测试时加快产品/功能迭代交付。

端到端测试

端到端测试是一种用于从头到尾测试应用程序流程是否按设计执行的方法。进行端到端测试的目的是识别系统依赖性,并确保在各种系统组件和系统之间传递正确的信息。整个应用程序都在真实的场景中进行了测试,例如与数据库,网络,硬件和其他应用程序进行通信。

用户验收测试(UAT)

用户接受测试(UAT)也称为 Beta 测试,是由真实用户执行的,通常用作产品发布之前的最终检查点。它使用户可以测试您的应用程序,并验证它是否对用户友好,是否按预期运行以及是否可以在现实环境中处理任务。通常,在 UAT 期间,项目经理,开发人员,质量检查团队和利益相关者可以进行最终检查。

移动自动化测试

移动测试自动化提供了以更高的测试覆盖率即时有效地测试移动应用程序的可能性。一旦测试自动化,就可以一次又一次地快速重复地执行它们。在几乎所有情况下,这都是具有较长维护寿命的软件产品的最具成本效益的方法。自动化的真正好处不仅在于测试的可重复性,还在于其执行可能甚至无法手动执行的测试的能力。

由于大多数公司都遵循敏捷开发实践,因此移动应用程序自动化测试非常适合敏捷过程。通过使测试可以并行完成,测试自动化可带来巨大的价值。尽早解决问题将节省大量时间,并使开发人员可以更快地完成产品的定型。

简而言之,移动自动化测试是一个常见问题的解决方案。自动化测试通过三种方式改善了业务结果:更高的测试效率,更高的测试效率和更短的迭代时间。

移动端主流测试框架有:Appium、UiAutomator2、Espresso、Robotium,根据流行程度排序。
appium 是近些年大火的测试框架,主要优点对于混合 app 和 H5 页面的自动化都提供了非常优秀的测试方案,而且解决了AndroidiOS量大平台的统一性问题,最值得推荐。
UiAutomator2 是 Google 退出的 Android UI 自动化测试框架,主要优势在于 Android 系统和原生 APP 的自动化测试,稳定性有保障,对于其他 APP 测试场景支持较好(如性能测试、遍历测试等)。
Espresso 是 Google 的开源自动化测试框架。它的优点是规模更小、更简洁,API 更加精确,编写测试代码简单,容易快速上手。最大的缺点是不能跨 App。另外也可以用作 APP 的单元测试。
Robotium 也是基于 Instrumentation 的测试框架,目前市场使用率逐步被前三者超越,由于其对使用者的要求较高,也是不能跨 app 的。

移动自动化测试工具

为了满足敏捷开发过程的需求,有很多移动自动化测试工具可以帮助团队以完全自动化的方式测试移动应用程序的各种参数,例如行为,性能,安全性等。这些测试工具中的一些在本地,混合和 Web 应用程序上具有竞争力。

自动化测试是增加有效性,效率和测试范围的最佳方法。测试自动化的真正好处来自这些测试的可重复性,也来自于无法手动执行的测试执行。

如何选择选择合适的的移动测试工具:

  • 跨团队协作功能(QA 和 Dev 都可以轻松使用相同的工具)。
  • 由于移动技术和平台各不相同,因此请始终执行工具可行性。
  • 选择同时支持平台模拟器和设备的工具
  • 在非功能性区域(例如中断),硬件方案(例如电池状态更改)等领域寻找自动化。
  • 始终在平台支持上进行优化,可能需要一种或多种工具来执行自动化。
  • 寻找多个设备支持和版本支持。
  • 寻找可以增加自动化价值的实用程序和可重用功能。
  • 与测试管理工具的集成执行对于工具成功至关重要。
  • 寻找数据驱动的自动化支持,因为执行迭代将增加覆盖范围和投资回报率。
  • 使用模拟器和真实设备进行移动应用测试

模拟器

模拟器会设置与真实设备的 OS 类似的测试环境,但无法模拟真实设备的硬件。因此,不会遇到硬件可能引起的所有问题。某些应用程序的运行不同硬件设备可能有所不同,这就是模拟器不太可靠的主要原因。

真实设备

在模拟器上运行测试不如在物理设备上进行的测试可靠。模拟器也不能模拟硬件功能,例如特定的芯片设置,处理能力和设备内存。它需要真实的设备才能进行完整的硬件和软件测试。

在云平台上进行设备测试

对于移动应用程序开发人员和测试人员而言,在所有不同的设备和操作系统组合上交付高质量的应用程序是一项艰巨的工作。这既耗时,复杂又昂贵。而且,随着新设备继续进入市场,开发人员需要找一种更简便的方法来跨它们进行构建和测试。

云设备测试使开发人员可以上传他们的应用程序,并在包括最新设备/操作系统组合在内各类测试设备上进行兼容性测试。

移动应用测试中的挑战

设备碎片

移动应用程序必须在各种设备和操作系统版本之间提供无缝的体验。质量检查工程师应对可能会给用户带来问题的硬件和软件更改具有很高的敏感性。团队必须考虑所有因素。当移动用户即使在引入新版本的 OS 或设备后仍继续使用旧版本的 OS 或设备时,碎片化尤其是一个挑战。

测试设备,操作系统和网络设置的每种组合都会创建大量测试用例。这要求开发团队执行采购和维护不断增长的移动设备池的工作。这些挑战是移动应用程序开发人员的主要障碍。

针对测试设备,我们首先考虑软件。系统:Android 或者 iOS 等,然后考虑不同系统的重要版本,Android 版本分布较广,还有各个厂商不同的定制系统以及定制系统的版本。其次考虑硬件,重点是屏幕尺寸、分辨率、CPU、内存、容量,在性能测试时还需要电池容量、充电器速率、发热情况等等。

负责的网络环境

大多数应用程序使用移动数据连接和 wifi。当用户的连接类型可能会不断改变,不幸的是,不同运营商不同的网络环境带来的网络策略导致用户网络情况复杂繁多。即使已经开发了测试的 API,也无法复制现实环境,这里面很可能隐藏着某些问题。对于质量检查团队来说,测试网络使用情况非常重要,需要提供不同网络情况的模拟的能力。

Charles 是一款非常有用的测试工具。不仅可以做接口抓包,也可以进行接口数据模拟。还有一个隐藏功能就是 Charles 可以模拟各种网络环境,不同速率、不同延迟,不同丢包率等,当然也提供 3G、4G 模拟。

应用程序复杂性和第三方集成

许多移动应用程序继承了大量第三方 SDK。这使得测试团队在整个测试场景的过程中在多个角色(或设备)之间切换。这些复杂的用例增加了适当测试应用程序所需的工作量。

处理能力和电池寿命

包含游戏或视频流组件的移动应用程序可能会很快耗尽电池寿命。随着用户设备的使用时间累加,设备的 CPU 处理能力和电池损耗也会随着时间推移发生变化,包括系统的碎片化等等原因都会导致在移动端性能测试过程中实现偏差。这会使性能测试报告缺乏可信力。


  • 公众号FunTester首发,更多原创文章:FunTester410+ 原创文章,欢迎关注、交流,禁止第三方擅自转载。

热文精选

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册