有一个很好的理由为什么测试Windows桌面应用程序是客户最请求的功能之一：世界上没有人拥有每月并行执行数千次测试的基础设施。Web测试基础设施相对简单：无头浏览器在Linux容器内启动只需几秒钟，运行成本仅为几分钱，并且在测试结束时立即丢弃。没有相应的方法来测试Windows桌面应用。当测试Windows应用时：每个测试都需要一个完整的虚拟机，因为Windows容器不包括运行应用的图形桌面。机器启动较慢。一个冷启动的Windows虚拟机需要2到3分钟来启动，而浏览器容器只需几秒。必须有人登录。Windows UI自动化（UIA），测试工具用来查找按钮和字段的可访问性接口，只在活跃的已登录桌面会话中工作。仅仅打开的机器是不够的。机器会记住事物。已安装的文件、注册表键、用户配置文件、保存的登录信息和闲散的进程在测试之间都能生存。每个应用程序都带来了自己的世界。安装程序、管理提示、许可依赖项、首次运行对话框、登录等。没有内置的可视性。浏览器提供了跟踪、日志和屏幕截图。而一台远程Windows机器只会交给你一无所获，除非你自己构建它。工具链假定使用Linux。Kubernetes、CI运行者和大多数测试基础设施都是围绕Linux容器设计的。我们的解决方案是停止将Windows机器视为服务器，而是将其视为手机：一个被一个测试索取、使用一次并丢弃的设备。架构基本架构借鉴了我们的移动测试基础设施，因为移动测试具备相同的限制：测试代码不能在正在测试的设备上运行，并且每个测试在运行时都需要一个设备。由于Windows机器在Kubernetes中被建模为设备，测试可以向我们的自定义设备调度程序请求一个具有DeviceClaim的虚拟机，获取其连接详情，通过WebdriverIO和Appium远程控制设备，并在测试结束时释放机器。Windows需要对设备模型进行两个扩展：设备不必再生活在Kubernetes集群内（GCE虚拟机完全生活在集群外），并且索赔可以返回桌面的连接地址，包括浏览器的CDP。否则，Windows运行程序遵循移动运行程序的生命周期逐步进行（索赔、心跳、记录、连接、运行、释放），测试通过同样的WebdriverIO和Appium配对与本地应用程序通信，并且私有Windows池与私有iOS设备的工作方式相同。与移动系统一样，它有三个部分：一个在Kubernetes中运行的控制器。它在Google Compute Engine（GCE）上保持一池Windows虚拟机，并将它们分配给测试。一个运行器，一个运行测试代码的Linux Pod。一个Windows虚拟机在测试的应用下运行，自动化工具和一个小型桌面代理。运行器通过三条连接与虚拟机进行通信。Playwright通过CDP（Chrome开发者工具协议）连接浏览器中的任何东西。Appium处理本地Windows应用。WebRTC（网络实时通信）流传输屏幕，以便人们可以实时观看测试并在之后回顾录制。像Android模拟器一样，每个Windows虚拟机都是一次性的。没有人登录到它、修补它或让它持续运行数周。一个测试索取它，使用一次后返回，新的虚拟机取而代之。一个Linux运行器Pod运行测试代码（@qawolf/flows/windows）。步骤1：测试从设备调度程序索取设备，设备调度程序在Kubernetes控制器中运行，并与Windows虚拟机协调。步骤2：调度程序将一个准备好的Windows虚拟机分配给测试。调度程序还通过GCE API保持一池温暖的Windows虚拟机准备就绪。测试然后通过三条连接与索取的虚拟机交流：CDP（Playwright）到浏览器，Appium（WebDriver）到Appium和WinAppDriver，通过UI自动化（UIA）驱动测试中的应用。虚拟机上的Go桌面代理将WebRTC屏幕流发送回运行器。因此现在，当用户启动运行时：测试在Linux运行器Pod中开始，请求Windows设备。调度程序从已经启动并登录的机器池中分配给它一个虚拟机。运行器接收该虚拟机的CDP、Appium和屏幕流的连接地址。待测试的应用被交付给虚拟机并启动。测试运行中。屏幕实时流动并被录制。测试完成，索赔被释放，虚拟机被销毁。新的虚拟机在池中取而代之。第一步共6步：测试在Linux运行器Pod中开始，请求Windows设备。运行器Pod（测试代码）、设备调度程序（Kubernetes）与来自温暖池的Windows虚拟机之间的序列。步骤1：运行器向调度程序发送DeviceClaim。步骤2：调度程序分配一个准备好的虚拟机。步骤3：调度程序返回虚拟机的CDP、Appium和屏幕流的连接地址。步骤4：