将酱汁添加到Xcode UI测试：XCUITest +酱汁实验室

XCBlog上的原始帖子在这里

Sauce Labs刚刚宣布支持在其自己的设备场中运行XCUITests。 他们已经在官方博客上宣布了支持。 随着苹果自己的Xcode UI测试框架变得越来越流行，云测试服务不能像Sauce Labs，BrowserStack，Perfecto这样的供应商不能忽视这一事实。 在上一篇文章中，我们看到了XCUITests的各种基于云的设备测试选项。 长期以来，Sauce Labs通过支持和维护Appium一直在帮助社区。 由于本机移动测试自动化框架（例如XCUITest和Expresso）开始流行，因此它们也必须转换齿轮并提供支持。 苹果于2015年推出了Xcode UI测试框架，最后，Sauce Labs支持在其真实设备云上执行这些UI测试。 Sauce Labs已在XCUITest和Real Device Cloud上广播了网络研讨会，以演示我们如何在云设备上设置XCUITest。 不幸的是，我无法参加实时网络研讨会，向主持人提问，但后来我观看了整个视频。 在这篇文章中，我将分享我对此过程的想法，以及可能会给Sauce Labs回答的一些问题。

流程

观看了XCUITest和Real Device Cloud上的整个网络研讨会之后，我了解了在Real Device Cloud上运行XCUITest的过程。 您可以在Sauce Labs Youtube频道上观看在线研讨会，也可以在下面观看。

我将留给您观看网络研讨会，现场演示并了解在Sauce Labs真实设备云上执行XCUITests的过程。

总而言之，该过程涉及以下步骤

• 使用Swift或Objective-C为iOS应用编写XCUITests
• 准备两个.ipa文件，一个用于您的主应用程序，另一个用于XCUITest运行器应用程序
• 使用Sauce Labs Web界面上传这些文件，以便Sauce Labs可以查看那些应用程序
• 使用设备标识符从Web界面中选择要在其上运行测试的设备
• 下载XCUITest Runner JAVA应用程序Runner.jar，该应用程序通过传递您的凭据来运行测试。
• Java应用程序会将您的凭据，到IPA文件，设备，数据中心的路径作为参数，并触发对指定设备的测试。
• 然后，您可以查看测试结果，运行设备云的测试屏幕截图和视频。

您可以在上面显示的网络研讨会中看到所有这些工作，因此值得一试。

好处

在实际设备上运行XCUITest肯定有一些明显的好处。 由于iOS模拟器不涉及任何硬件接口。 一些好处是

• 来自真实设备的反馈非常有价值，因为这些是真实用户使用的设备。
• 可以选择最常用的设备并对它们并行运行测试
• 无需购买即可在一周内访问新推出的设备。
• 我们可以从具有hasipa资产的任何Linux或macOS Continuous Integration服务器上触发测试。
• 共享测试结果似乎非常容易。

Sauce Labs与Perfecto，AWS Device Farm等其他供应商不同，Bitbar在使事情正常运行方面做得非常出色，但是，当公司进行过多的UI测试时，总是会遇到一些问题。 不一定总是正确构建iOS应用程序。

问题

我们所有人都知道，UI测试是非常缓慢，脆弱，昂贵且不可维护的事情。 许多测试金字塔表明，我们应该将UI测试数量保持在非常低的水平。 在iOS自动化应用程序测试中，几乎没有什么可以在设备与模拟器上找到运行测试，只要它不涉及硬件或像素完美测试即可。 无论如何，针对真实设备和模拟器的自动化是完全不同的主题。 我总体上对云设备测试有一些疑问

CI / CD和DevOps

相当常见的问题是，实际的设备UI测试在哪里适合DevOps或CI / CD管道。 移动DevOps和CI / CD面临独特的挑战，并且使用的工具与Web应用程序不同。 特别是对于iOS CI / CD，我们必须在内部或在云中使用macOS服务器。 大多数公司将持续集成外包给TravisCI，CircleCI，BuddyBuild等广泛使用的供应商。 另一个选择是内部管理macOS服务器，这非常具有挑战性。 云设备测试服务始终需要从另一个云或公司内部基础结构进行连接。 这种建立连接的过程为管理基础架构增加了另一组挑战，并使整个流程变慢。 具有更多UI测试的团队使管道变得越来越慢和脆弱。

如果采用“酱汁实验室”方法，我们必须准备两个听起来太冗长的IPA文件。 存档iOS应用程序和准备IPA文件需要花费大量时间。 如果要在Sauce Labs上运行这些应用程序，则涉及代码签名和编译所有iOS应用程序资产，这将是耗时且令人沮丧的过程。 它还需要大量的配置和脚本来往返于服务。

并行设备

自Xcode 9以来，Apple的xcodebuild工具使并行测试变得更加容易。我们只需要传递不同的目标参数，而XCUITest将在这些目标上进行并行测试。

Sauce Labs有大量的iOS设备，但是，XCUITestRunner Java应用程序的工作方式是，我们一次只能传递一个设备。 知道我们是否可以传递一系列设备，以便一次执行命令会触发多个设备上的测试，将是一件很有趣的事情。

测试和Xcode方案的子集

网络研讨会观众的问题之一是，是否有可能在设备云上运行XCUITests的子集。 答案是肯定的，但是我们必须创建另一个测试包和IPA文件，其中包含那些选定的测试。 XCUITests在应用程序目标和方案的基础上工作。 为了创建子集，我们必须创建单独的方案并为该方案选择测试。 这意味着这需要另一个测试包和另一个IPA文件。 但是，不可能动态选择要在Sauce Labs上运行的测试。

通过专用网络模拟数据

XCUITest能够使用专用网络上托管的模拟数据。 将涉及多个批准的第三方服务接入公司专用网络将是非常棘手的。 值得一提的是，酱汁实验室将如何使用Sauce Connect处理这种情况。

代码签名

为了将iOS应用程序部署到设备中，必须使用有效的Apple开发人员证书对它进行代码签名。 我们必须先编写代码签名iOS应用程序，以准备要上传到Sauce Labs的IPA。 我假设Sauce Labs然后拆除所有签名并重新签名应用程序，以部署在设备上以执行XCUITests。 对于测试而言，代码签名过程并不重要，但值得注意的是，用于测试的代码签名标识将不同于用于将应用分发到App Store的原始代码签名。

iOS中的JAVA

Sauce Labs引入了XCUITestRunner Java应用程序来触发XCUITest，但是，这种语言与iOS应用程序开发无关。 几乎没有什么要注意的，Java不是脚本语言，并且未预先安装在通常用于持续集成的任何macOS服务器或Linux服务器上。 我不知道为什么Sauce Labs选择了Java来构建TestRunner应用程序。 使用bash或类似的脚本语言可以轻松完成此操作。

安全

为了在Sauce Labs上执行XCUITest，我们必须准备应用程序的可执行二进制文件。 这个文件充斥着从事iOS开发工作数月之久的鲜血，汗水和眼泪。 它基本上是准备提交给App Store的应用程序。 了解iOS应用程序的安全性非常重要，这样您的IPA文件不会被泄露或滥用。 Sauce Labs应该添加一些安全性或加密机制，以便用户可以安全地将IPA上载到Sauce Labs门户。

仿真器

如网络研讨会中所述，Sauce Labs希望将来增加对Simulator的支持。 使用Xcode 9，当使用命令行运行时，XCUITests可以在任何macOS服务器内无头运行。 几乎不需要启动模拟器。 只是想知道，当大多数基于云的CI服务（例如TravisCI，CircleCI）将其内置时，在云中使用模拟器会有什么好处。

BDD

在回答有关BDD样式支持的问题之一时，它说XCUITest不支持BDD样式测试，但是，市场上有许多工具可以实现这一点。 您可以在此处阅读有关Swift的BDD框架的更多信息。

结论

通过在实际设备实验室中提供对XCUITests的支持，Sauce Lab做得很好。 它清楚地表明XCUITest框架最近变得非常流行，并且像Sauce Labs这样的云测试公司开始支持它。 您可以通过配置XCUITest在设备上运行并查看其是否满足您的需求，来利用Sauce Labs设备的优势。 如果Sauce Labs可以回答我上面提到的一些问题，那就太好了。

像XCBlog的 XCTEQ 发布的帖子一样 ？ 您可能还喜欢我们的一些服务，例如访客博客或Mobile DevOps（CI / CD）或测试自动化。 在 Github 上 搜索我们的 服务 ，开源项目， 或者在 Twitter ， Facebook ， Youtube 和 LinkedIn 上关注我们 。 下载我们的 XCBlog iOS应用程序以离线阅读博客。

X CTEQ 是一家专门从事基于Mobile DevOps，CI / CD，Mobile，AI / ML的测试自动化Checkout XCTEQ产品和服务的公司， 网址 为 http://www.xcteq.co.uk 或写信给我们[e-mail]。英国..