NativeScript 开源功能测试框架

在 NativeScript 的 2.5 版本发布中，我们重点介绍了开源项目背后的功能测试框架以及所有测试，这些测试包括我们使用的示例和演示应用程序。这些测试已经使用了超过两年，并经过多次重写以改进和反映 Android 和 iOS 平台以及工具的变化。让我们先回答一些基本问题，然后深入探讨。

UI 测试框架

为什么我们需要一个？

由于 NativeScript 是用于构建原生移动应用程序的框架，我们需要确保使用 NativeScript 创建的应用程序能够按预期运行并执行。为了解决这个问题，我们决定构建一个基于 Appium 和 TestNG 的端到端测试框架，同时提供以下功能：

管理模拟器、仿真器和真实设备；
以灵活的方式验证图像；
测试结果、日志和屏幕截图；
以及当无法使用辅助功能时，通过图像定位元素。

什么是 NativeScript 测试框架？

它是一个通用的跨平台移动自动化框架，适用于任何类型的 Android 和 iOS 移动应用程序：原生、混合，甚至游戏。

该框架是 **通用的**，因为它可以用于原生应用程序（无论它们是否使用 NativeScript 开发）和混合应用程序。它还可以通过图像定位和交互与没有辅助功能的应用程序或组件（例如游戏或图表）进行交互。

它也是 **跨平台的**，因为每个测试都可以在 Android 和 iOS 上执行，无论它是模拟器、仿真器还是真实设备，都没有限制。此外，它可以创建和删除模拟器和仿真器，以及管理它们上的应用程序（即安装或卸载、启动或停止、重启或在后台运行）。然而，这里的限制是，在 iOS 上运行的测试只能从 macOS 主机上执行。

该框架还 **不需要修改** 被测应用程序，因为它基于 Appium，并包含对特定元素或整个屏幕进行图像比较的功能，以及对容差、来自所有类型设备的每项测试的日志、服务器和测试执行日志、屏幕截图和预定义报告模板的设置。

轻松入门

开始使用测试框架最简单的方法是下载其官方演示。

git clone https://github.com/NativeScript/functional-tests-demo.git
cd functional-tests-demo

注意：请注意该框架的先决条件和设置。此外，为了能够运行演示测试，还需要 Maven。

如果所有先决条件都已满足，并且相应的模拟器/仿真器可用，那么只有两条命令就能成功运行演示测试。为此，请在演示项目根目录中打开一个终端/命令提示符，然后

安装在 libs 文件夹中准备好的测试框架库

mvn install:install-file -Dfile=libs/functional.tests.core-0.0.5.jar -DgroupId=functional.tests.core -DartifactId=functional.tests.core -Dversion=0.0.5 -Dpackaging=jar

在 android 6.0 (API 23) 模拟器上执行原生应用程序演示测试

mvn clean test -P nativeapp.emu.default.api23

或在 iPhone 7 iOS 10.0 仿真器上执行原生应用程序演示测试

mvn clean test -P nativeapp.sim.iphone7.ios10

nativescript functional testing framework

执行后，可以通过详细的 HTML 格式的报告查看测试结果。该报告包含一个饼图图表，总结了通过、跳过和失败测试的百分比，一个包含 TestNG 套件中所有测试类的列表（作为左侧的导航窗格），以及所选类的测试方法显示在右侧。每个测试方法名称都用绿色表示通过、红色表示失败或黄色表示跳过 - 如果展开，则会显示测试日志、有关开始/结束时间和持续时间的简要信息。如果图像验证失败，结果模板将以缩略图形式显示实际图像、差异图像和预期图像。

该报告位于：functional-tests-demo/target/surefire-reports/html/index.html，来自 Appium、设备和测试本身的日志位于：functional-tests-demo/target/surefire-reports/logs/，屏幕截图图像位于：functional-tests-demo/target/surefire-reports/screenshots/。

演示详细信息

结构

该演示代表一个 Maven 项目，其 pom.xml 文件包含有关其依赖项、如何构建它以及可用于执行的配置文件的信息。它可以导入到 IntelliJ IDEA 社区版等 IDE 中。

testapp 文件夹是放置被测应用程序的地方。在演示中，有

原生 android 应用程序 nativeapp.apk，
混合 android 应用程序 hybridapp.apk，
原生 iOS 应用程序，为仿真器构建并归档为 .tgz nativeapp.tgz，
混合 iOS 应用程序，为仿真器构建并归档为 .tgz hybridapp.tgz。

resources 文件夹包含一些子文件夹

**config** - 这里包含 .properties 文件，这些文件按应用程序分组，并包含我们想要执行测试的每个应用程序和设备配置的基本信息。这里有必需的设置和可选设置，完整列表可以在此处找到，
**images** - 该文件夹旨在收集所有预期图像，以便对它们进行图像验证，以及用于定位屏幕区域的图像，同样按应用程序和设备名称分组，
**report** - 这里包含一个 .xsl 文件，用于生成前面提到的 HTML 报告，
**suites** - 这里包含描述要执行哪些测试的 TestNG 套件文件。这些套件文件与配置文件一起用于在 pom.xml 文件中描述要执行命令行的 Maven 配置文件。

在 libs 文件夹中，有一个测试框架，它是一个预先构建的 .jar 库，包含所有依赖项，并且不出所料，测试的源代码位于 src 文件夹中。

让我们看一下原生应用程序示例

在 pages 包中，有一个 HomePage 类，它表示被测应用程序的主页（在本例中是一个单页面应用程序）。该类最重要的部分是它继承了功能测试框架中的 BasePage 类。

public class HomePage extends BasePage {
    public HomePage() {
       super();
    }
}

这使您可以轻松访问诸如 app、client、find、gesture、locators、log、settings 等字段，以及诸如 navigateTo()、navigateBack() 和 hideKeyboard() 等方法。然后，您可以通过简单地调用 this.find.byText("TAP"); 或 this.find.elementsByLocator(this.locators.textViewLocator()); 来定位元素，如该类所示。

在 tests 包中，有一个 SmokeTests 类，它包含测试方法。这里关键的一点是它继承了功能测试框架中的 UIBaseTest 类。

public class SmokeTests extends UIBaseTest {
}

UIBaseTest 类通过 TestNG 注释（如 @BeforeSuite、@BeforeMethod、@AfterMethod 等）实现钩子，并负责启动 Appium 服务器、启动模拟器/仿真器、启动 Appium 客户端，以及分别停止它们。此外，它还提供了各种方法来比较应用程序的当前屏幕，就像这样简单：this.assertScreen();

混合应用程序示例遵循相同的逻辑。

它旨在演示如何通过位于 resources 文件夹中的图像定位和交互与元素进行交互。接下来的几行代码展示了如何声明和初始化一个 Sikuli 类型的字段，定位屏幕区域，并在其上执行点击手势

Sikuli sikuli = this.context.sikuliImageProcessing;
UIRectangle uiRectangle = sikuli.findImageOnScreen("device_platform", 0.9D);
uiRectangle.tap();

要执行混合应用程序示例测试，请在演示项目的根目录中打开一个终端/命令提示符窗口，然后

在 android 6.0 (API 23) 模拟器上执行混合应用程序演示测试

mvn clean test -P hybridapp.emu.default.api23

或在 iPhone 7 iOS 10.0 仿真器上执行混合应用程序演示测试

mvn clean test -P hybridapp.sim.iphone7.ios10

框架如何完成所有这些工作？

测试框架的核心是 Appium 的 java 客户端、TestNG 框架和 Sikuli 库，这些库使我们能够实现图像定位功能。测试框架本身通过 Gradle 进行构建，但是我们的演示和测试目前使用的是 Maven。

值得一提的是框架实现中的几个关键点，例如测试 Context。这个类提供了对诸如 app、client、device、gestures、locators、log、settings 等字段的直接访问。该设备抽象允许对设备操作进行单点管理，无论它是 Android 模拟器、iOS 仿真器还是真实设备 - 这些操作都在内部处理。

一个有趣的事实是，图像验证功能不是来自第三方来源，而是相反 - 我们自己的实现，它逐像素比较两个图像，将差异用红色绘制，并提供一个差异图像。该 Settings 读取测试套件的配置文件，并作为执行的入口。

框架在行动

这个功能测试框架在 NativeScript CI 中成功发挥作用，它使我们能够针对 20 多个应用程序执行 2000 多项测试，这些测试分布在 600 多个构建中，涵盖 Android 4.2 到 7.1 以及 iOS 8 到 10。这些测试分布在 10 台构建机器上，涉及 15 台以上的真实设备。

现在功能测试框架是开源的，我们希望它对 NativeScript 用户以及所有需要为移动应用程序自动执行测试的人员都有用。这是一个持续的努力，也是 NativeScript QA 团队在确保 NativeScript 稳定发布过程中长期投入的成果，因此，我们非常乐意听到您的想法、反馈和贡献！

相关链接

NativeScript 的开源功能测试框架