伴随着众多新功能的发布，Appium的自动化后台架构经历了重大发展。随着Appium的出现，测试工程师可以覆盖移动应用、桌面应用、Flutter应用等。
在Testµ会议的这一富有洞察力的会议中，Thoughtworks首席顾问Sai Krishna和Thoughtworks首席顾问Srinivasan Sekar分享了Appium终局和下一步的发展。
Sai Krishna拥有12年的专业知识，是ThoughtWorks的首席顾问。他花了大量的时间来开发自动化框架和测试移动应用。他喜欢为开源技术做贡献。他积极参加Appium的工作，是Appium组织的成员。
在ThoughtWorks，Srinivasan Sekar是一位拥有11年经验的首席顾问。他擅长创建自动化的框架。他评估了几个移动和网络应用。他喜欢添加开源项目。他是Appium的成员。
Srinivasan通过分享指数开始了演讲。
- Appium的现状
- Appium 2.0 Arch
- Appium驱动程序
- Appium插件
- Appium CLI
- Appium测试支持库
Srinivasan继续安装Appium 1.x。Sai讨论了他在设置Appium 1.x时遇到的一些困难。在Appium 1.x的整个发展过程中，有许多驱动程序可以帮助Windows本地应用程序和Mac本地应用程序实现自动化。
在过去的七到八年里，在Appium 1.x中，不包括安卓和iOS，你是否遇到了你想开发的需求和你的驱动，用于特定的用例？ Srinivasan问道。
Appium驱动程序
在过去几年中，任何构建自定义驱动程序的人可能都会遇到很大的困难，因为必须分叉许多模块。Appium包含大量的模块，分布在多个来源。
Appium 2.0的测试版本已经有一段时间了。Appium 2.0的主要目标是改善围绕Appium的用户和开发社区。其中一个问题包括当你理想地打算在原生的iOS应用程序上实现自动化时的chrome驱动。Appium 2.0就是来帮助解决这个问题的。你得到了你想用Appium 2.0检查出来的东西。
上面的幻灯片提到了由社区维护的可用驱动程序。
Appium服务器只是裸机。你必须在Appium服务器之外安装你选择利用的自动化的驱动程序。因此，如果是安卓系统，你可以在Espresso驱动和UI自动化工具中选择。明天，如果你决定不使用UI自动化工具，你可以简单地删除它，继续进行UI测试驱动的工作。在Appium 1.x中，情况不是这样的。
如果Appium有任何问题修复，1.x用户必须等待很长时间才能下载最新版本的软件。因此，如果有哪怕是一个小的错误修复，Appium服务器也会花上不少时间。
为了改善用户和开发者的体验，为开发者社区建立驱动是一件很麻烦的事情。在不了解内部代码基础的情况下，人们可以设计他们的驱动程序。你可以创建和维护你的驱动程序，独立于Appium服务器运行，并有其发布周期。
- Appium 2.0创建了自定义的Appium驱动程序，它与核心模块隔离。
- 它是一个与Appium服务器解耦的驱动程序。
Appium插件
被称为Appium插件的小块代码与Appium服务器互动。你是否曾有过需要改变Appium命令的时候？赛以同样的方式提出了他的问题。然后，Srinivasan在Appium插件中对此开发了一个答案。人们可以不使用按id查找元素，而是构建他们的命令，并通过使用按图像查找元素来覆盖它。你可以开发你独特的命令，每个命令都有其生命周期。你甚至不需要去打扰Appium服务器。
Appium服务器会启动它的激活，跟随你的内置命令，并管理它的生命周期。因此，你可以让一个插件与运行在移动设备上的服务器对话，而不是让驱动程序通过运行在移动设备上的服务器连接到你的被测应用程序。因此，除了替换或重写整个Appium命令外，你还可以编写你的自定义命令。Appium插件解决了这些使用场景。
Appium插件架构
Srinivasan进一步详细介绍了关于该插件的架构。Appium 2.0遵循与1.x相同的客户-服务器架构，这是众所周知的。因此，客户可以使用IBM支持的任何语言。因此，在用各种选择或能力初始化驱动程序后，我们定位一个元素，对该元素执行一个动作，然后终止驱动程序。
它在一个用我们选择的任何编程语言编写的直截了当的客户端应用程序中与服务器互动。根据我们给定的能力，它调用驱动程序，向驱动程序发送指令，而运行在设备上的驱动程序则初始化服务器。
因此，安装在设备上的服务器与被测试的应用程序进行通信，然后再将响应发回给驱动程序，后者再将其传送给服务器，然后再发送给客户端。因此，一切都使用W3C标准所定义的网络驱动协议来完成。因此，这是只有驱动程序存在时的通常流程。
将有两个服务器同时运行：在你的Mac、Windows或Linux电脑上的Appium服务器和在移动设备、仿真器或模拟器上运行的服务器。Appium服务器与这些服务器上的驱动程序进行通信。驱动程序首先与设备的内部服务器进行通信，然后再与测试的应用程序进行通信。因此，该插件现在已经可以使用了。这是一个小的代码，可以与Appium的生命周期互动或配合。
- 在Appium服务器对象开始监听请求之前更新它。
- 插件增加了任意的功能，在实际的Appium命令之前或之后执行。
- 插件改变了Appium服务器，以引入新的命令并分发它们。
上面的幻灯片显示了由社区维护的可用插件。
Srinivasan进一步给出了一个现场演示。要了解他演示的内容，请看完整的视频。
Appium 2.0的好处
- 与Appium服务器解耦的驱动程序有助于Appium用户根据自己的需要，只安装自己选择的特定Appium驱动程序。
- 使用Appium 2.x，创建自定义的Appium驱动程序将变得更加容易。
- 与Appium 1.x相比，任何Appium驱动程序的小更新或错误修复都可以尽快使用，而无需等待新的服务器发布。
Srinivasan和Sai的会议确实很有见地。会议结束时，与会者提出了一些问题。以下是问答内容。
- 在进行E2E移动测试时，需要关注的主要领域是什么？
Srinivasan：它似乎正在发挥作用。因为它以自己的速度前进，它试图在集成测试中测试功能的每个方面，同时保持功能范围尽可能少。在设备上运行的功能测试结束时，要有尽可能少的测试，你可以集中在重要的部分，也就是涉及到本地功能的地方。
- 在浏览器自动化方面有很多工具的发展（Cypress/Playwright）。你对移动自动化中的一些新的自动化工具有什么看法？
Srinivasan:Appium已经在功能自动化的市场上占据了一段时间。谷歌对它进行了大量的投资，并被广泛用于创建本地应用程序。一些工具被引入但无法使用，例如Appium对跨平台的支持，尽管Espresso仍然可用。而现在，也许在市场上有点过时了，flutter有它的集成，一个建立在已废弃的flutter驱动之上的包。
- 虽然最近windows应用程序的测试已经很少了，但我们是那些拥有传统系统的公司之一。我们正面临着不确定性，因为Appium使用的WinAppDriver已经不再被积极维护了，在这方面有什么进展吗？
Sai Krishna。当Appium开发团队没有积极维护AppDriver时，它是由微软团队维护的。我记得从微软负责虚拟机驱动的一位经理那里看到过一个主题。他们宣称，他们将积极浏览它。但我不确定这有多远。然而，WinAppDriver和它与微软的关系并没有被Appium开发团队所维护。
