通过Appium实现iOS并行化-一种优雅的方式

没有值得拥有的东西，变得容易。 直到2017年6月，iOS Parallelisation也是如此。

XCode的限制是每个运行者仅允许一个模拟器，这是UI自动化开发人员的主要限制，这导致反馈周期变慢。 进行15个小时的约500次测试的回归套装只是一种常态。 在您决定去还是不去之前十五小时！

随着“移动优先”或“仅移动”趋势的发展，IOS自动化很快成为加快发布周期的瓶颈。 然后，Facebook的FBSimulatorControl带来了一线希望。

FBSimulatorControl是一个macOS库，用于同时管理，引导和与多个iOS模拟器进行交互。

尽管该解决方案非常出色，但对于围绕Appium和Cucumber构建的自动化框架却很少使用。 将数百个测试迁移到该框架是一个成本更高的解决方案。

这使UI自动化开发人员充满信心，认为iOS并行化是可能的，而Apple的支持将指日可待。

年份2016

在TestVagrant，与Cucumber和Appium一起工作时，我们一次又一次地面对多个客户的相同问题。

• 我们如何将功能/测试分发到可用设备上？
• 我们如何在所有可用设备上运行所有功能？
• 我们如何运行诸如Driver-Customer之类的应用间场景？
• 我们如何自动检测和管理设备以及维护Appium服务器和Webdriver实例？
• 我们如何构建有助于快速决策的报告？
• 我们如何鼓励很少或没有编程经验的qa为自动化做出贡献？

到2016年底，我们已解决了大部分问题，但有些零散的问题。 然后，我们意识到这些不仅是我们面临的挑战，还是整个致力于黄瓜和Appium的社区的绊脚石。

我们将所有解决方案归为一个单一的框架，称为

Optimus，一个开源的移动自动化框架。

Optimus Framework是一个包含多个项目的生态系统，它可以

• 自动发现已连接的设备（物理设备，仿真器，模拟器）
• 以多种模式运行黄瓜功能； 分布和碎片化。
• 运行应用间测试
• 生成近乎实时的报告，以加快分析速度。

在过去的两年中擎天柱 演变为适用于Appium和Cucumber的近乎完整的移动自动化框架。 但是它错过了一项关键功能，即并行运行iOS测试。

年份2017

终于在2017年，XCode正式在单个iOS主机上支持了多个模拟器，并且Appium社区足够快地支持并行iOS测试。

然后，社区中出现了一些解决方案，使iOS并行化成为可能，但是设置很麻烦，例如

• 为连接的设备管理多个WebDriverAgent。
• 通过唯一的服务器实例路由Appium命令。

作为质量检查人员，我们认为应该减轻设置方面的麻烦，并且不应成为自动化的障碍。

Optimus提取了所有设置机制，并允许团队在几分钟内建立Device Lab。

通过对擎天柱的一些调整，我们确定可以在iOS模拟器和设备上并行运行黄瓜功能。

擎天柱3.0

借助Optimus 3.0，自动化团队现在可以在iOS设备上并行运行其测试服，而无需担心基础设置。 这是它的一瞥。

方便的资源

Optimus — https://github.com/testvagrant/optimusTemplate

Wiki-https://github.com/testvagrant/optimusTemplate/wiki

Gitter — https://gitter.im/optimus_support/optimus

如果以上资源都无法派上用场，请通过[e-mail]向我们喊叫