• 1
  • 0
分享

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

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

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

移动应用测试金字塔

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

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

移动应用测试

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

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

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

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

移动应用测试的类型

功能测试

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

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

回归测试

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

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

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

性能测试

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

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

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

安全测试

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

首先从代码安全说起,当前流行的Android开发语言有Java、kotlin,后者由于是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页面的自动化都提供了非常优秀的测试方案,而且解决了Android和iOS量大平台的统一性问题,最值得推荐。

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处理能力和电池损耗也会随着时间推移发生变化,包括系统的碎片化等等原因都会导致在移动端性能测试过程中实现偏差。这会使性能测试报告缺乏可信力。


版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 背景与问题接口,解决了从协议发起,到后台业务逻辑的测试,但是忽略了重要的部分:前端展现和交互。我们需要通过自动化回归测试,来解决端到端测试的问题,即从客户端发起到服务端完成,整个业务落成,而不仅仅是服务端的功能。界面自动化,聚焦于界面业务逻辑和交互测试,对于海量的数据组合测试,不是重点目标。当前端界面、业务逻辑发生改变,就需要通过界面自动化回归测试,来解决系统回归和覆盖的问题。自动化测试是未来发展的趋势录制回放工具与测试脚本通过录制来生成自动化的测试脚本:对象库:基于脚本与对象库分离参数化:对脚本进行参数化,可以实现相同的脚本执行不同的数据和测试用例测试脚本:定义了整个的测试过程。使用关键字视...
            14 14 1560
            分享
          •   当地时间7月21日,印度财政部向印度议会通报,包括小米、vivo、OPPO在内的多家中国主要智能手机制造商逃避关税,并在印度非法汇款了至少800亿卢比(约70.2亿元),而印度税务机关只追回了这些公司逃税总额的18%。  印度政府在给印度法院的书面答复中表示,小米公司在2019-2020年度逃税总额为65.3亿卢比,在2020-2021年度逃税总额为2.399亿卢比,在2022-2023年度的逃税总额为46.1亿卢比,即2019-2023年期间累计逃税总额为113.799亿卢比。  2017年至2021年间,OPPOMobilePvtLtd。的逃避关税价值达到了440.3亿卢比。  在总计...
            0 0 1102
            分享
          • web页面问题定位:第一步:前后端判断先判断是前端还是后端的问题,如果是接口请求响应数据是正常的,则进一步定位前端问题。前端问题可以通过F12打开调试模式,切换到source 页面进行查看是否是js文件内的语法错误,或者是资源文件位置未找到等问题第二部:后端具体原因分析后端接口请求异常,则可通过状态码进行判断400--请求语法错误,也就是前后端语法定义不一致401--未授权403--服务端拒绝访问404--资源不存在500--服务器内部错误如果遇到磁盘满了,就需要看应用程序是否活着,如果活着则返回500(服务器处理异常),若是应用程序已经死了,则返回400资源不存在了app端和服务端问题定位:...
            0 0 2523
            分享
          • 压测,在很多项目中都有应用,是测试小伙伴必备的一项基本技能,刚好最近接手了一个小游戏的压测任务,一轮压测下来,颇有收获,赶紧记录下来,与大家分享一下,希望大家能少踩坑。一、压测的时机压测的时机很重要,如果时间选择不对,可能会做无用功,简单总结下5个常见的压测场景:1、活动上线前压测活动类的项目,常规操作是在活动上线前,对系统进行一个摸高压测,根据预估的流量,对系统配置进行优化调整,保证活动期间,系统能正常运行。本次的小游戏项目,就属于活动类,在上线前进行了压测。2、项目上线稳定后,对系统评估系统上线后,随着用户量不断增加,承受的压力会越来越大,为了让系统在未来的时间内稳定运行,需要通过压测对系...
            1 0 3329
            分享
          • 一、前言测试的面试相对于开发的面试来说,对于技术的询问其实相对来说较少的,主要针对以下几个方面。测试理论,接口,数据库,linux,自动化,性能、个人情况这几大块。二、常见问题1、软件测试理论基础①、什么是软件测试?在规定条件下对程序进行操作,发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。②、软件测试主要测试用例设计方法是什么?白盒测试:逻辑覆盖、循环覆盖、基本路径覆盖黑盒测试:等价类、边界值、因果图、状态图法、错误猜测、测试大纲、随机测试、场景。③、测试计划、方案以及测试报告主要包括哪些方面?测试计划主要包括:测试范围(功能性测试;非功能性测试)测试通过/失败的标准(通...
            16 18 2602
            分享
      • 51testing软件测试圈微信