Android应用程序测试

作者:Android测试   发布时间:2021-09-15

理解 Android 应用程序测试 - 自动化或手动、本地或网络、使用物理设备或云进行测试、单元测试和 CI 集成。

从 2009 年到 2021 年 3 月,Android 在移动设备上的市场份额从不到 1% 增长到 71%。这意味着每三部智能手机中就有两部以上是安卓系统。除非您的公司为特定市场开发软件,否则 Android 可能是您客户受欢迎的操作系统。这意味着制作可在 Android 上查看的原生 Android 应用程序和网页,这意味着要对这些设备进行测试。Android 平板电脑市场份额约为 45%;自 2012 年以来,苹果平板电脑的份额从 85% 下降到 53%。

虽然手机产品已经成熟,但测试实践肯定不成熟,有各种各样的框架、语言、工具和方法来执行开发,尤其是测试。在此页面上,我们将提供 Android 测试的大局观、测试解决的风险和挑战,以及 Sauce Labs 产品如何帮助解决这些挑战。我们的重点是由应用程序创建者或 QA 专家创建的测试,因此本文不涉及 Beta 测试和众包测试。

“Android 测试”是什么意思?

手动测试。著名的测试类型,通常也非常有价值,是在物理设备上构建应用程序的新版本,并在真实服务器上端到端地运行软件。我们大多数人都熟悉这项工作,这可能由程序员、测试员或某种形式的客户代理完成,如用户验收测试或 UAT。一些小型组织,尤其是开发公司内部软件以在公司支持的单一型号 Android 设备上使用,可能会发现手动测试满足了他们的大部分需求。遗憾的是,对于较大的项目、团队和客户群,手动测试变得不够。在 Apple 设备仅由一家公司生产的情况下,Google 与许多制造商合作。因此,尤其是Android 是一个高度分散的 产品系列,兼容性测试解决。

兼容性测试。Android 拥有更广泛的操作系统、屏幕尺寸、硬件规格和向后兼容性。在这一点上,当今有数以万计的 Android 设备组合。兼容性测试是在一个配置上完成测试并在另一台稍微不同的机器上测试正确性的应用程序的过程。即使组织拥有足够大的设备库来维持此类测试,执行测试所涉及的时间也会令人望而却步。Dan Nosowitz 的碎片化图像给出了 Android 设备市场空间的一些概念——即使是前 12 名也只覆盖了大约 25% 的景观,而这项研究现在已经过时了。

此外,由于 COVID-19,大量测试是远程完成的,因此不可能按位置购买物理设备。执行有效兼容性测试的一种方法是使用模拟器、模拟器或云中的真实设备,这是 Sauce Labs 可以提供的服务。另一个是在执行测试自动化时轮换基于云的设备。

自动化测试。Selenium(用于移动网络)和Appium(用于原生 Android)和Espresso是三个代码库,它们将应用程序视为一个对象,允许程序员单击对象、获取屏幕上的文本等。Sauce 实验室可以提供虚拟设备来在这些设备上运行测试,不需要设备实验室。这些测试通常有两种形式:

单元测试. 通常用与生产代码相同的编程语言编写,这些隔离代码的各个方法来执行应用程序逻辑的小、离散位。例如,如果内部应用程序函数负责将用户输入的内容(字符串)转换为内部编程语言日期字符串,则单元测试将提供示例输入和预期结果的示例,包括边缘情况其中字符串为空白、所有空格、无意义等等。因为单元测试可以访问应用程序代码并且可以直接针对应用程序中小的逻辑位,所以它们非常快。成百上千个单元测试可以在几秒钟内运行。然而,单元测试不测试应用程序组件之间的交互,因此不应依赖它们来排除端到端测试。自动化 Android 应用测试

用户界面(端到端)测试。这些测试反映了手动测试的工作方式,从用户的角度出发并自动协商应用程序的各种用户路径。它们在图形用户界面、GUI 或 UI 级别运行。这意味着他们会执行应用程序的完整堆栈,从 UI 到前端业务逻辑再到任何类型的服务器交互。这意味着他们可以在技术堆栈的任何级别找到错误。这也意味着它们相对较慢。一整套 Android 测试可能涉及两千个用户界面操作。每次点击两秒,在一台设备上需要一个多小时。Sauce labs 提供网格产品; 16 台并行运行的设备一小时不到四分钟。由于延迟和维护工作,端到端测试通常保留用于测试用户体验中关键的部分。Selenium 和 Appium 以十几种不同的程序语言运行;Espresso 仅限于 Kotlin 或 Java。

测试框架。Selenium、Appium 或 Espresso 测试或“测试用例”本质上是一个计算机程序。这些单独的测试可能涵盖一个特性或一个特定的流程;这些测试的集合创建了“测试套件”。框架收集测试用例,按顺序运行它们(可能并行)并创建测试结果报告,将错误追溯到特定的测试和测试步骤。框架提供了架构的一个重要部分,因为它们集成了构建系统来检查新的构建,并抽象出结果。例如,框架可能支持 Web 和移动应用程序测试结果的单一视图。想想框架有点像旧的苏联俄罗斯笑话. 通常,在测试时,您会调用测试用例。使用框架时,框架会调用您!

持续集成。一旦测试自动化,它们就可以在构建后立即在每个构建上运行,发现由该更改引入的问题。持续集成 (CI) 系统可以在每次更改时运行,并了解更改的是谁以及更改内容,从而使调试和修复(或维护测试)变得轻而易举。这意味着可以针对整个回归套件快速验证小的、孤立的更改,并且无需大量人工回归测试工作即可推出。然后,如果出现问题,撤消该小更改会更容易。有各种各样的 CI 系统,如 Jenkins 或 Travis,它们有助于提取、构建新代码,并通过我们讨论的各种类型的测试对其进行练习。有关 Sauce Labs与 CI 服务器集成的更多信息。

性能测试。使用一个用户进行测试不太可能模拟生产中多个用户可能发生的负载。性能测试是针对性能的测试,包括负载测试,也就是针对多个用户的测试。这两者都涉及测试服务器,但页面呈现对于移动设备也很重要。浸泡测试涉及长时间运行系统以查看是否发生内存泄漏,并且可能涉及客户端或服务器。

安全测试。执行安全测试的两种主要方法是源代码的自动扫描和渗透测试。系统强化和社会工程(网络钓鱼)值得一提。移动应用程序是生产代码,应该受到同样的关注。

用于 Android 应用程序测试的示例 Java 测试脚本

为了让您开始,这里有一个示例 Java 测试脚本,用于使用 Appium 进行 Android 测试。

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import io.appium.java_client.android.AndroidDriver;
import java.net.URL;

public class SampleSauceCheckBoxTest {

 public static final String USERNAME = "YOUR_USERNAME";
 public static final String ACCESS_KEY = "YOUR_ACCESS_KEY";
 public static final String URL = "https://" + USERNAME + ":" + ACCESS_KEY + "@ondemand.saucelabs.com:443/wd/hub";

 public static void main(String[] args) throws Exception {

   DesiredCapabilities capabilities = new DesiredCapabilities();
   capabilities.setCapability("platformName", "Android");
   capabilities.setCapability("deviceName", "Samsung Galaxy S4 Emulator");
   capabilities.setCapability("platformVersion", "4.4");
   capabilities.setCapability("app", "http://saucelabs.com/example_files/ContactManager.apk");
   capabilities.setCapability("browserName", "");
   capabilities.setCapability("deviceOrientation", "portrait");
   capabilities.setCapability("appiumVersion", "1.5.3");

   WebDriver driver = new AndroidDriver<>(new URL(URL), capabilities);

   /**
    * Test Actions here...
    */

   driver.quit();
 }
}


本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-60725088-8054),我们将立即处理,马上删除。



沪ICP备07036474号-4 |

沪公网安备 31010702003220号

2015-2021 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd.