Tag: 黄瓜
通过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 […]
如何设置Bitrise CI以运行iOS的自动Appium和Cucumber UI测试
为什么要堆叠？ 在codequest中，一段时间以来，我们一直在使用Bitrise作为iOS应用程序的CI / CD工具。 最近，我们的团队不断壮大，并且我们已经获得了一个最有价值的新成员–质量检查工程师，他掌握了用Appium和Cucumber.rb（Ruby版本）编写UI测试的知识。 问题是–如何在Bitrise上进行全部设置，目前在这里只有自动化的单元测试运行并测试应用程序部署。 就像我们一样，大多数阅读此书的人可能正在寻求帮助。 令我们惊讶的是，即使是谷歌搜索也无法帮助我们找到逐步的指导。 因此，我将不涉及很多细节，也不用追逐。 我们的环境 下一步将需要一些细节。 可以这样说： 独角兽–这是我们的项目名称 Unicorn.xcworkspace –项目的工作区（我们使用Pods） 独角兽–要构建的Xcode方案名称 Unicorn.app –由构建创建的二进制文件的名称，可以在Xcode中检查（选择目标）➞构建设置➞产品名称 com.codequest.Unicorn –我们的应用程序捆绑包ID AppiumUITests / Unicorn –在git存储库中的此路径下，我们保留UI测试 我们不在git仓库中保留任何.app文件 在Bitrise中创建UI测试步骤 1.通过单击+工作流程按钮并设置名称来创建新的工作流程。
iOS XCUITest –黄瓜
在XCode中让iOS工程师对BDD感到兴奋。 免责声明：本主题与上下文有关，如何使用Cucumberish可以使iOS开发工程师或UI自动化测试团队受益。 本文旨在通过使用Cucumberish作为其本机iOS开发的一部分来使iOS工程师兴奋。 在介绍Cucumberish库之前，我想快速介绍一些初始要点。 什么是黄瓜/黄瓜/行为驱动开发（BDD） 黄瓜测试的结构 跨平台移动测试工具的一些注意事项 我是一名iOS工程师，并且一直在编写各种iOS自动化测试框架：UIAutomation（使用javascript），Calabash（使用ruby），Sen Testing（目标C），“ XCTest + Gherkin” cocoapods，以及目前的“ Cucumberish”。 我还找到了一种编写XCUITest来断言Google Analyics网络有效负载的方法。 这是一个非常有趣的主题，但是我将其保存在另一篇文章/演讲中……敬请期待。 1.什么是黄瓜/黄瓜/行为驱动的发展（BDD） Cucumber是一种软件工具，用于使用Gherkin语言执行行为驱动的测试（BDD）。 Gherkin Language本身与平台无关，它为产品所有者和业务分析人员提供了结构化的模板，以通过用例描述业务需求。 它的主要特征是“ Given-When-Then”子句的存在。 行为驱动开发（BDD） 与产品所有者和利益相关者合作以拟定可为客户带来价值的用例规范列表的过程。 这些规范使用Ghenn-When-Then Gherkin语言写入“功能”文件。 即使非工程师也很容易理解功能文件，这促进了整个组织的协作。 可以使用BDD工具（例如黄瓜，阿皮，黄瓜，葫芦，硒）将其自动化。 对于跨平台测试，功能文件是组织具有可在所有平台上使用的集中式规范的绝佳选择。 上面的BDD示例可以在Web和移动应用程序上使用。 在敏捷开发过程中常见。 2.黄瓜测试的结构 黄瓜测试套件包含一组功能文件。 它们每个都有一个“ .feature”扩展名。 每 功能文件包含一个或多个描述软件特定功能的方案。 使用多行用Gherkin编写的“步骤”来编写方案。 步骤定义是一小段代码 ，上面附加了一个模式 。 该模式用于将步骤定义链接到所有匹配的步骤，并且代码是Cucumber看到小黄瓜步骤时将执行的代码 。 [https://cucumber.io/docs/reference#step-definitions] 一旦定义了步骤，就可以继续为每个步骤编写测试/断言实现 。 请注意，如果使用适当的正则表达式格式，则可以使您的步骤对于测试套件更可重用。 3.关于跨平台移动测试工具的一些说明 在移动领域，市场上有一些工具试图通过引入单独的测试运行器来简化跨平台测试的复杂性。 iOS中使用的最受欢迎的是Calabash和Appium。 在我看来，以上问题是工程团队需要投资的额外开销。实现跨平台功能的另一种想法是，仅跨平台绑定通用功能文件，并允许灵活地选择最合适的测试运行器进行开发效率。 对于iOS开发，理想的情况是我们可以在XCode中执行Gherkin BDD功能文件，并且其步骤定义/实现可以用Swift编写。 哦，是的，还有一个更理想的标准：通过Cocoapods安装！ […]
