发布信息

移动测试:从硬件到软件,确保移动解决方案的质量与性能

作者:软荐小编      2024-07-30 15:07:47     87

计算机已风靡一时,改变了人类的思维、行为、学习和生存方式。

如今,移动解决方案已占领市场。人们不想打开笔记本电脑/PC 来执行所有功能,而是希望有一个手持设备可以快速执行所有功能。

因此,我们向客户提供的移动解决方案应该经过充分测试。本文面向已进行过移动测试或最近转向移动测试的人员。

移动测试的类型

移动设备上进行的测试大致有两种类型:

1.硬件测试:

设备包括内部处理器、内部硬件、屏幕尺寸、分辨率、空间或内存、摄像头、无线电、蓝牙、WIFI等。有时也简称为“移动测试”。

2.软件或应用程序测试:

测试在移动设备上运行的应用程序及其功能。它被称为“移动应用测试”,以区别于以前的方法。即使在移动应用程序中,也有一些基本的区别需要理解:

a) 原生应用程序:原生应用程序是为在移动设备和平板电脑等平台上使用而创建的。

b) 移动网络应用程序是服务器端应用程序,可通过连接移动网络或 WIFI 等无线网络使用不同的浏览器(如 Chrome、Firefox 等)访问移动网站。

c) 混合应用是原生应用和 Web 应用的组合。它们可在设备上或离线运行,使用 HTML5 和 CSS 等 Web 技术编写。

它们之间有以下几点区别:

原生应用具有单一平台亲和力,而移动 Web 应用具有跨平台亲和力。原生应用是在 SDK 等平台上编写的,而移动 Web 应用则是使用 HTML、CSS、asp.net、Java 和 PHP 等 Web 技术构建的。对于原生应用,需要安装,而对于移动 Web 应用,则不需要安装。原生应用可以从 Play Store 或 App Store 更新,而移动 Web 应用则集中更新。许多原生原生应用不需要互联网连接,但对于移动 Web 应用,这是必须的。与移动 Web 应用相比,原生应用的运行速度更快。原生应用是从 Google Play Store 或移动 Web 等网站下载的。本文的其余部分将介绍移动应用程序测试。

移动应用测试的重要性 由于以下原因,在移动设备上测试应用程序比在桌面上测试 Web 应用程序更具挑战性。

各种移动设备,具有不同的屏幕尺寸和硬件配置,例如硬键盘、虚拟键盘(触摸屏)和轨迹球。 各种各样的移动设备,例如 HTC、三星、苹果和诺基亚。 不同的移动操作系统,例如 Android、Symbian、Windows、Blackberry 和 IOS。 不同版本的操作系统,例如 iOS 5.x、iOS 6.x、BB5.x、BB6.x 等。 不同的移动网络运营商,例如 GSM 和 CDMA。 建议您经常更新(例如 Android - 4.2、4.3、4.4,iOS - 5.x、6.x),并在每次更新时执行新的测试,以确保应用程序功能不受影响。 同样,移动应用程序测试非常重要,因为某种产品的客户群往往是数百万,而且没有人能发现有缺陷的产品。 这通常会导致金钱损失、法律问题和品牌形象的不可挽回的损害。

移动和桌面应用程序测试之间的基本区别:移动应用程序测试与桌面测试有几个明显的不同之处

在桌面上,该应用程序已在 CPU 上进行了测试。在移动设备上,该应用程序已在三星、诺基亚、苹果和 HTC 等手机上进行了测试。移动设备的屏幕尺寸小于桌面。移动设备的内存小于桌面。手机使用 2G、3G、4G 或 WIFI 等网络连接,而桌面使用宽带或拨号连接。桌面应用程序测试的自动化工具可能不适用于移动应用程序。

移动应用测试的类型

为了解决上述所有技术问题,对移动应用程序进行了以下类型的测试。

可用性测试——确保移动应用程序易于使用并为客户提供令人满意的用户体验 兼容性测试——根据要求在不同的移动设备、浏览器、屏幕尺寸和操作系统版本上测试应用程序。 界面测试——测试应用程序的菜单选项、按钮、书签、历史记录、设置和导航流程。 服务测试——测试应用程序的服务,包括在线和离线。 低级资源测试:测试内存使用情况、临时文件的自动删除、本地数据库增长问题(称为低级资源测试)。 性能测试——通过将连接从2G、3G更改为WIFI、共享文档、电池消耗等来测试应用程序的性能。 操作测试——测试电池电量不足或商店升级应用程序时数据丢失时的备份和恢复计划。 安装测试——通过在设备上安装/卸载应用程序进行验证。 安全测试——测试应用程序以验证信息系统是否保护数据。 移动应用程序测试策略 测试策略应确保符合所有质量和性能指南。

以下是一些建议:

1)选择设备——分析市场,选择广泛使用的设备。(这个决定主要取决于客户。客户或应用程序构建者会考虑某些设备的流行度因素和应用程序的市场需求来决定使用哪个设备。测试哪款手机。

2) 模拟器——这些模拟器用于开发的初始阶段,因为它们允许快速高效地检查应用程序。模拟器是一种可以在不改变软件本身的情况下将软件从一个环境运行到另一个环境的系统。它复制了实际系统上的功能和工作原理。

移动模拟器的类型

设备模拟器 - 由设备制造商提供 浏览器模拟器 - 模拟移动浏览器环境 操作系统模拟器 - Apple 提供 iPhone、Microsoft Windows Phone 和 Google Android 手机模拟器 推荐工具

1)实验

Experitest 让您无论身在何处都可以即时访问大量真实/模拟的 iOS 和 Android 设备,让您轻松满足严格的移动应用交付时间表和可靠的自动化移动测试要求。

尝试新事物 => 访问 Experitest 网站

2)Kobiton

Kobiton 是一个价格合理、高度灵活的基于云的移动体验平台,可加速在真实设备上测试和交付原生 Android、Web 和混合应用以及 iOS。其新推出的脚本化自动化测试可以帮助团队轻松生成开放标准的 Appium 脚本,而无需具备编码专业知识。

使用移动设备模拟器的几个免费且简单的列表

i. 手机模拟器 – 用于测试 iPhone、Blackberry、HTC、Samsung 等手机。

移动设备模拟器 2 ii。MobiReady – 通过它,我们不仅可以测试我们的 Web 应用程序,还可以检查代码。

移动设备模拟器 3 iii. Responsivepx – 它检查网页的响应能力、网站的外观和功能。

移动设备模拟器 4 iv. Screenfly – 它是一个可定制的工具,用于测试不同类别的网站。

3)在移动应用程序完成令人满意的开发水平后,您可以继续在物理设备上测试更多基于真实场景的测试。

4) 考虑基于云计算的测试:云计算基本上是一种通过互联网在多个系统或网络上运行的设备,可以在其中测试、更新和管理应用程序。为了测试目的,它基于模拟器创建了一个云。移动环境,供网络访问移动应用程序。

基于云的移动测试

优势:

备份和恢复- 云计算会自动从远程位置备份您的数据,并轻松修复受影响的数据。此外,存储容量是无限的。可以从不同的设备和任何地方访问云。云计算具有成本效益,易于使用、维护和更新。快速部署。基于 Web 的界面。可以在多个设备上并行运行相同的脚本。

缺点:

控制力较弱 - 由于应用程序在远程或第三方环境中运行,因此用户对功能的控制和访问有限。互联网连接问题 - 设置通过互联网进行。网络问题会影响可用性和功能。安全和隐私问题 - 云计算是互联网。通过互联网进行的计算并不安全,因此数据黑客有更多机会。

5)自动和手动测试

如果应用程序包含新功能,请手动测试。如果应用程序需要测试一两次,请手动执行。自动化回归测试用例的脚本。如果反复进行回归测试,那么自动化测试很适合。处理复杂场景的脚本,如果手动执行则很耗时。有两种类型的自动化工具可用于测试移动应用程序:

基于对象的移动测试工具——通过将设备屏幕上的元素映射到对象来实现自动化。这种方法与屏幕尺寸无关,主要用于 Android 设备。

例如:- Ranorex、Hello Solutions 基于图像的移动测试工具——根据元素的屏幕坐标创建自动化脚本。

例如:Sikuli、Eggplant、RoutineBot 6)网络配置也是移动测试的重要组成部分。在不同的网络上验证应用程序(如2G、3G、4G或WIFI)非常重要。

测试移动应用程序的测试用例除了基于功能的测试用例之外,移动应用程序测试还需要特殊的测试用例,这些测试用例应涵盖以下场景。

电池使用情况 – 在移动设备上运行应用程序时,跟踪电池消耗非常重要。 应用程序速度 – 在不同设备、不同内存参数、不同网络类型等上的响应时间。 数据要求 – 用于安装和验证的数据 受限计划的用户是否能够下载它? 内存要求 – 下载、安装和再次运行应用程序的能力 – 确保应用程序不会因网络故障或其他任何原因而崩溃。 下载一些示例测试用例来测试移动应用程序。

测试移动应用程序中的典型活动和流程 测试范围取决于要检查的需求数量或对应用程序所做的更改程度。 如果更改很小,则将进行一轮健全性测试。 如果更改很大和/或很复杂,则建议进行全面回归。

示例应用程序测试项目:ILL(国际实验室学习)kuli仿真软件教程,一款旨在帮助管理员、出版商创建协作网站的应用程序。教师使用网络浏览器从一组功能中进行选择,以创建符合其要求的课程。

移动测试流程

步骤 1. 确定测试类型:作为 ILL 应用程序,它适用于浏览器,因此必须使用支持浏览器的不同移动设备来测试此应用程序。我们需要使用手动和自动化测试用例的组合,针对不同的浏览器进行可用性、功能性和兼容性测试。

第 2 步。手动和自动测试:该项目采用的方法是敏捷方法,迭代需要两周时间。每两周进行一次开发。团队将向测试团队发布新版本,测试团队将在 QA 环境中运行自己的测试用例。自动化团队创建一组用于基本功能的脚本,并运行这些脚本来帮助确定新版本是否足够稳定,可以进行测试。手动测试团队将测试新功能。

JIRA 用于编写验收标准;维护测试用例并记录/重新验证缺陷。一旦迭代完成,就会召开迭代规划会议,开发团队、产品所有者、业务分析师和 QA 团队将讨论哪些方面做得好,哪些方面需要改进。这个地方。

步骤 3. Beta 测试:QA 团队完成回归测试后,版本将进入 UAT。用户验收测试由客户完成。他们重新验证所有错误,以确保每个错误都已修复,并且应用程序按预期在每个浏览器中获得批准。

步骤 4. 性能测试:性能测试团队使用 JMeter 脚本和不同的应用程序负载测试 Web 应用程序的性能。

步骤5.浏览器测试:使用不同的模拟工具以及真实的移动设备在多个浏览器上测试Web应用程序。

第 6 步。发布计划:每 4 周后,测试将进入准备阶段,在这些设备上进行最后一轮测试,以确保产品已准备好投入生产。然后,产品将上线!

如何在 Android 和 iOS 平台上测试移动应用程序 测试移动应用程序 对于那些在 iOS 和 Android 平台上测试应用程序的人来说,了解两者之间的差异非常重要。iOS 和 Android 在外观、应用程序意见、编码标准、性能等方面存在许多差异。

Android 和 iOS 测试之间的基本区别您可能已经看过所有教程,这里我做了一些主要的区分,这反过来会帮助您进行测试:

1)由于市场上有很多 Android 设备,它们的屏幕分辨率和尺寸都不同,所以这是主要区别之一。

例如,与 Nexus 6 相比,您的应用布局和设计很有可能太小,导致该设备无法成功。因为在市场上众多手机中,只有少数设备具有类似的分辨率。iOS 上的分辨率概率为中低。

例如,直到iPhone 6及更高版本的出现,所有早期版本都只有类似的尺寸。

2) 示例 上面提到的要点是,Android 开发人员必须使用 1x、2x、3x、4x 和 5x 图像来支持所有设备的图像分辨率,而 iOS 仅使用 1x、2x 和 3x。然而,确保图像和其他 UI 元素在所有设备上正确显示是测试人员的责任。

3) 由于市场上充斥着 Android 设备,因此编写代码时必须确保性能稳定。因此,您的应用在低端设备上的运行速度很可能会很慢。

4) Android 的另一个问题是软件升级无法同时适用于所有设备。设备制造商决定何时升级其设备。使用新操作系统和旧操作系统测试所有内容变得非常困难。

同样,对于开发人员来说,修改代码以同时支持两个版本也成为一项繁琐的任务。

比如Android 6.0出来之后,就发生了一个很大的变化,这个操作系统开始支持应用级别的权限,进一步解释一下,用户还可以在应用级别更改权限(位置、联系人)。

现在测试团队有责任确保在 Android 6.0 及以上版本的应用启动器上显示权限屏幕,而在较低版本上不会出现权限屏幕。

5) 从测试角度来看,两个平台上的预生产版本(即 Beta 版本)测试有所不同。在 Android 上,如果用户被添加到 Beta 用户列表中kuli仿真软件教程,那么他就可以看到更新的 Beta 版本。在 Play Store 中,只有当他使用与添加为测试用户的相同电子邮件 ID 登录 Play Store 时,才能看到更新的 Beta 版本。

移动测试的关键因素我已经在 iOS 和 Android 平台上从事移动测试近 2 年,本教程中提到的所有关键点均来自我的个人经验以及从项目中遇到的一些问题中获得的。

定义自己的测试范围每个人都有自己的测试风格。一些测试人员只关注他们亲眼看到的东西,而其他人则对移动应用程序的幕后情况充满热情。

如果您在 iOS/Android 上进行测试,我建议您至少熟悉 Android 或 iOS 的一些常见限制/基本功能,因为它总能为我们的测试风格增添价值。我知道如果我不举一些例子会很遗憾。事情很难理解。

这里有些例子:

对于版本低于 6.0.1 的 Android 设备,我们无法在应用程序级别更改相机、存储等权限。对于版本低于 10.0 的 iOS,没有 Call Kit。我只是简单介绍了一下,Call Kit 用于呼叫应用程序接听的电话,并在用户来自 WhatsApp、Skype 等呼叫应用程序时显示。对于版本低于 10.0 的 iOS,我们会在全屏视图中看到这些呼叫作为通知横幅。你们中的许多人可能都面临一个问题,如果您想向钱包中充值,应用中的 Paytm 不会将您重定向到银行的支付页面。我们认为上述问题与我们的银行或 Paytm 服务器有关,但这只是我们的 AndroidSystemWebView 没有更新。对编程知之甚少总是对您有帮助的,可以与您的团队分享。简而言之,当应用程序在其中打开任何网页时,就应该更新 AndroidSystemWebView。测试范围不要限制你的测试测试不仅限于探索移动应用程序和记录错误。 作为 QA,我们应该了解所有到达服务器的请求以及从服务器得到的响应。

配置 Putty 以查看日志或验证日志的添加逻辑,具体取决于您的项目中使用的内容。它不仅可以帮助您了解应用程序的端到端流程,而且还可以让您在测试时做得更好,因为您现在有了更多的想法和计划。

移动服务器浮动图原因:世界上没有无缘无故的事情发生。任何言论都应该有正当理由。分析日志的原因是,日志中发现了很多异常,但它们对 UI 没有任何影响,所以我们没有注意到。

那么,我们应该忽略它吗?

不,我们不应该。它对用户界面没有影响,但可能是一个未来问题。如果这些异常继续蔓延,我们可能会看到我们的应用程序崩溃。正如我们在最后一句关于应用程序崩溃中提到的那样,这导致 QA 可以访问该项目的 crashlytics。

Crashlytics 是一个记录崩溃情况以及时间和设备型号的工具。

现在的问题是,如果测试人员已经看到应用程序崩溃,那么他为什么还需要担心 crashlytics?

答案很有趣。有些崩溃可能在 UI 上看不到,但它们会记录在 crashlytics 上。可能是由于内存崩溃或某些致命异常,可能会影响以后的性能。

跨平台测试跨平台交互测试非常重要。

举一个简单的例子,假设你正在开发一个聊天应用程序,例如 WhatsApp,它支持发送图片和视频,该应用程序基于 iOS 和 Android 平台构建(开发人员可能已经同步准备好,也可能还没有)

确保测试 Android 和 iOS 之间的通信,原因是 iOS 使用“Objective C”,而 Android 程序基于 Java,并且由于它们都是在不同的平台上构建的,因此有时需要额外的修复在应用程序中识别来自不同语言平台的字符串。

注意您的移动应用程序的大小Mobile Tester 的另一个重要提示是每次发布后继续检查您的应用程序的大小。

我们应该确保应用程序的大小不会达到这样的程度:即使作为最终用户的我们也不会因为其过大而愿意下载该应用程序。

测试应用升级场景 应用升级测试对于移动测试人员来说非常重要。确保您的应用不会因为开发团队造成的版本号不匹配而导致升级失败。

数据保存也同样重要,因为用户在升级应用程序时应该保留在以前版本中保存的任何偏好设置。

例如,用户可以在PayTm等应用程序中保存自己的银行卡信息。

您的设备的操作系统可能不支持该应用程序听起来不错?

是的,许多设备可能不支持您的应用。你们中的许多人一定知道,供应商在我们之上编写了自己的包装器,并且您的应用的任何 SQL 查询都可能与设备不兼容,因此它会抛出异常。如果发生异常,甚至可能导致手机上的应用无法启动。

这里的重点是 – 尝试在您自己的设备上使用您的应用,而不是在办公室使用的设备。您很可能会在应用中发现一些问题。

应用程序权限测试列表中的下一个是移动应用程序权限测试。几乎每隔一个应用程序就会要求其用户访问其手机的联系人、相机、图库、位置等。我见过一些测试人员这样做,如果不测试这些权限的正确组合,那将是一个错误。

我记得一个真实的例子,当时我们正在测试一个聊天应用程序,该应用程序具有共享图像和音频文件的所有功能。存储权限设置为否。

现在当用户点击相机选项时,除非将存储权限设置为 YES,否则不会打开相机。这种情况被忽略,因为 Android Marshmallow 有此功能,如果将存储权限设置为 NO,相机将无法使用。

范围比我们在上面几段中讨论的还要广。我们应该确保应用程序不会请求任何未使用的权限。

任何熟悉软件行业的最终用户都不会下载要求过多权限的应用。如果您已从应用中删除任何功能,请确保删除该功能的权限屏幕。

与市场上类似和流行的应用程序进行比较 故事寓意 – 如果您有疑问,请不要自行得出结论。与同一平台上的其他类似应用程序进行比较可以进一步证明您相信测试的功能正常运行。

全面了解苹果的拒绝标准 最后,你们中的大多数人可能都遇到过自己的产品被苹果拒绝的情况。我知道这个话题不会引起大部分读者的兴趣,但了解苹果的拒绝政策总是有好处的。

作为测试人员,我们很难满足技术要求,但还是有一些拒绝标准测试人员可以处理。

始终保持主动 作为一名测试人员,不要让开发团队/经理把事情交给你。如果你对测试充满热情,那么“始终保持主动”。尝试参与活动发生的代码,并在进行桶测试之前参与其中。

最重要的是,使用 JIRA、QC、MTM 或来自客户和业务分析师的票据关注项目的所有最新更新。此外,如果需要修订,请准备好分享您的观点。这适用于所有在各个领域和平台上工作的测试人员。

除非我们认为该产品不是我们自己的,否则我们永远不会对新的改进或现有功能的更改提出建议。

让您的应用长时间(12-24 小时)处于后台,我知道这听起来很奇怪,但是幕后有很多逻辑是我们所有人都不知道的。

我分享这个是因为我看到过应用程序在启动后崩溃,比如在后台状态大约 14 小时后。原因可能取决于开发人员如何编码。

相关内容 查看全部