iOS UI测试的许多开发人员可能都熟悉测试运行时间的问题。 Badoo每次回归运行都会为iOS应用程序运行1400多个端到端测试。 这些是30分钟内通过的40多个机器小时的测试。
Badoo的
Nikolai Abalov分享了他如何将测试执行速度从1.5小时缩短到30分钟； 他们如何通过访问设备服务器来展开紧密相关的测试和iOS基础架构； 如何使其更易于并行运行测试，以及如何使测试和基础架构更易于支持和扩展。
您将了解与fbsimctl之类的工具并行运行测试是多么容易，以及将测试和基础架构分开可以使托管，支持和扩展测试变得更加容易。
最初，尼古拉（Nikolai）在海森堡（Heisenbug）会议上介绍了一份报告（您可以观看
视频 ），现在，对于哈勃（Habr），我们制作了该报告的文本版本。 接下来是第一人称叙述：
大家好，今天我将讨论iOS的缩放测试。 我叫Nicholas，我主要在Badoo处理iOS基础架构。 在那之前，他在2GIS工作了三年，从事开发和自动化工作，尤其是他写了Winium.Mobile-Windows Phone的WebDriver的实现。 我被带到Badoo从事Windows Phone自动化方面的工作，但一段时间后，该公司决定暂停该平台的开发。 我为iOS的自动化工作提供了有趣的任务，今天我将告诉您。
我们要谈什么？ 该计划如下：
- 问题的非正式陈述，使用的工具的简介：如何以及为什么。
- 在iOS上进行并行测试及其开发方式（尤其是根据我们公司的历史，自2015年我们开始进行iOS开发以来）。
- 设备服务器是报告的主要部分。 我们用于并行测试的新模型。
- 我们通过服务器获得的结果。
- 如果您没有1500个测试，那么您可能不一定需要设备服务器，但是您仍然可以从中获得一些有趣的东西，我们将讨论它们。 如果您有10到25个测试，则可以应用它们，这仍将提供加速或更高的稳定性。
- 最后，汇报情况。
工具
首先是关于谁使用什么的一些知识。 我们的堆栈有点不标准，因为我们同时使用了Calabash和WebDriverAgent（在使我们的应用程序自动化并同时通过WebDriverAgent完全访问系统和其他应用程序时，这为我们提供了速度和Calabash后门）。 WebDriverAgent是iOS的WebDriver的Facebook实现，由Appium内部使用。 Calabash是用于自动化的嵌入式服务器。 我们使用Cucumber以易于阅读的形式编写测试。 也就是说，在我们公司中为伪BDD。 并且因为我们使用了Cucumber和Calabash，所以我们继承了Ruby，所有代码都写在上面。 有很多代码，您必须继续用Ruby编写。 为了并行运行测试，我们使用由Badoo的一位同事编写的工具
parallel_cucumber 。
让我们从我们拥有的开始。 当我开始准备报告时，有1200个测试。 到它们完成时，已经是1300个，而我到达这里时已经有1400个测试，这些测试是端到端测试，而不是单元测试和集成测试。 他们在一台模拟器上占用了35-40个小时的计算机时间。 他们在一个半小时前通过了。 我会告诉你他们如何在30分钟内通过测试。
我们公司拥有一个工作流，其中包含分支机构，评论以及在这些分支机构上运行测试。 开发人员向我们应用程序的主存储库创建大约10个请求。 但是它也具有与其他应用程序共享的组件，因此有时会有十多个。 结果，每天至少要进行30次测试。 自从开发人员推动开发之后，他们就意识到他们开始使用错误，重新加载，所有这些都开始了完全的回归，仅仅是因为我们可以运行它。 在同一基础结构上，我们启动了其他项目，例如Liveshot，该项目以所有语言在主要用户脚本中获取应用程序的屏幕截图，以便翻译人员可以验证翻译的正确性，是否适合屏幕等。 结果，此刻大约需要半小时的机器时间。
首先，我们希望开发人员和测试人员信任自动化并依靠自动化来减少手动回归。 为了做到这一点，有必要从自动化中实现快速，最重要的是稳定可靠的操作。 如果测试在一个半小时内通过，开发人员将厌倦等待结果，他将开始执行另一项任务，他的工作重点将转移。 而且当一些测试失败时，他对必须回来，转移注意力并修复某些东西感到非常不满意。 如果测试不可靠，那么随着时间的流逝，人们开始将其视为障碍。 尽管代码中没有错误，但它们不断下降。 这些是片状测试，某种障碍。 因此，在这些要求中已公开了这两点：
- 测试应花费30分钟或更长时间。
- 他们必须稳定。
- 它们必须具有可伸缩性，以便我们可以增加半个小时来添加另外一百个测试。
- 基础设施应易于维护和开发。
- 在模拟器和物理设备上，所有操作都应以相同的方式启动。
我们主要在模拟器上而不是在物理设备上运行测试，因为它更快，更稳定且更容易。 物理设备仅用于真正需要此功能的测试。 例如，相机，推送通知等。
如何满足这些要求并做好一切？ 答案很简单：我们删除了三分之二的测试！ 该解决方案适用于30分钟（因为仅剩余三分之一的测试），易于扩展（可以删除更多测试）并提高了可靠性（因为我们删除的第一件事是最不可靠的测试）。 这就是我的全部。 有什么问题吗
但认真的说，每个笑话都有一些道理。 如果您有很多测试，则需要对其进行回顾，并了解哪些测试带来了真正的好处。 我们有不同的任务，所以我们决定看看可以做什么。
第一种方法是根据覆盖率或组件筛选测试。 即，根据应用程序中的文件更改选择适当的测试。 我不会谈论这个，但这是我们目前正在解决的任务之一。
另一种选择是加快和稳定测试本身。 您进行特定的测试，看看哪些步骤花费最多的时间，以及是否可以以某种方式优化它们。 如果其中一些经常非常不稳定，则应进行纠正，因为这会减少测试重新启动的时间，并且一切都会更快。
最后，还有一个完全不同的任务-并行化测试，将它们分布在大量的模拟器上，并提供可扩展且稳定的基础结构，以便并行进行很多工作。
在本文中，我们将主要讨论最后两点，最后，在技巧和窍门中，我们将谈到速度和稳定性。
iOS并行测试
让我们从总体上针对iOS（尤其是Badoo）的并行测试的历史开始。 首先，使用简单的算术，但是，如果我们比较尺寸，则公式中会出现错误：
一台模拟器进行了1300次测试，总共需要40个小时。 然后我的领导人萨蒂什（Satish）来说他需要半个小时。 您必须发明一些东西。 X出现在公式中：要运行多少个模拟器，所以一切都在半小时内完成。 答案是80个模拟器。 随即出现了问题，将这80个模拟器放在哪里，因为它们在任何地方都不适合。
有几种选择：您可以转到SauceLabs，Xamarin或AWS Device Farm等云。 您可以在家中考虑所有事情，并做得很好。 鉴于本文存在，我们在家里做得很好。 我们之所以这样决定，是因为这样规模的云将非常昂贵，而且还存在iOS 10出现而Appium发布了将近一个月的支持的情况。 这意味着在SauceLabs中，一个月以来我们无法自动测试iOS 10，这根本不适合我们。 此外，所有云都是关闭的，您不能影响它们。
因此，我们决定自己做所有事情。 我们始于2015年，当时Xcode无法运行多个模拟器。 事实证明，他不能在同一台计算机上的一个用户下运行多个模拟器。 如果您有很多用户，则可以根据需要运行模拟器。 我的同事蒂姆·鲍沃斯托克（Tim Bawerstock）提出了一个模型，在该模型上我们可以生存很长时间。
有一个代理（TeamCity，Jenkins Node等），它运行parallel_cucumber，该代理通过ssh进入远程计算机。 图为两个用户的两辆车。 所有必需的文件（例如测试）都将通过ssh复制并在远程计算机上运行。 测试已经在当前桌面上本地运行模拟器。 为此，您必须首先进入每台计算机，例如，创建5个用户，如果要5个模拟器，则让一个用户自动登录，其余用户打开屏幕共享，以便他们始终拥有一个桌面。 并配置ssh守护程序，以便它可以访问桌面上的进程。 以这种简单的方式，我们开始并行运行测试。 但是，此图中有几个问题。 首先，测试控制着模拟器，它们与模拟器本身位于同一位置。 也就是说，它们必须始终在罂粟花上运行，它们会消耗本可用于运行模拟器的资源。 结果，您的机器上的模拟器更少了，它们的成本也更高。 另一点是，您需要转到每台计算机上，配置用户。 然后您就偶然发现了全局限制。 如果有五个用户并且他们提出了很多流程，那么描述符将在系统中结束。 达到极限后，尝试打开新文件并启动新进程时测试将开始下降。
在2016-2017年，我们决定改用稍有不同的模型。 我们观看了Facebook
的Lawrence Lomax的
报告 -他们介绍了fbsimctl，并部分地告诉了基础架构如何在Facebook上工作。
Viktor Koronevich也有关于此模型的
报告 。 情况与上一张没有太大不同-我们刚刚摆脱了用户，但这是向前迈出的一大步，因为现在只有一个桌面，启动的进程更少，模拟器变得更便宜。 此图中有3个模拟器，而不是2个，因为已经释放了资源来启动另一个模拟器。 我们一直使用这种模型很长时间，直到2017年10月中旬才开始切换到远程设备服务器。
所以看起来像铁。 左侧是装有Macbook的盒子。 为什么我们对它们进行所有测试是一个单独的大故事。 在插入铁盒的Macbook上进行测试不是一个好主意，因为它们在下午的某个地方开始过热，因为当它们停留在表面时热量不会很好地散发出去。 测试变得不稳定，尤其是在加载时模拟器开始崩溃时。
我们的决定很简单：我们将笔记本电脑放在“帐篷里”，通风面积增加，基础设施的稳定性突然增加。
因此，有时您不必处理软件，而是四处转动笔记本电脑。
但是，如果您看这张照片，可能会碰到一些电线，适配器和锡。 这是最重要的部分，而且仍然很好。 在软件中，正在与基础架构进行完整的测试交织，并且不可能继续这样生存。
我们确定了以下问题：
- 测试与基础架构密切相关，启动了模拟器并管理了其整个生命周期。
- 这使扩展变得困难，因为添加新节点意味着要为测试和运行模拟器进行设置。 例如，如果您想更新Xcode，则必须直接在测试中添加解决方法，因为它们在不同版本的Xcode上运行。 如果出现堆似乎可以运行模拟器。
- 测试与模拟器所在的机器绑定在一起，这会花费一分钱，因为它们必须在罂粟花上运行，而不是便宜的* nix。
- 而且深入研究模拟器总是非常容易的。 在某些测试中，我们转到了模拟器的文件系统，在其中删除了一些文件或对其进行了更改，一切都很好，直到在三种不同的测试中以三种不同的方式完成了该过程，然后意外的是，如果不幸的是，第四个在以后开始崩溃那三个。
- 最后一刻-资源没有以任何方式翻遍。 例如，有四个TeamCity代理，每台都连接了五台计算机，并且只能在五台计算机上运行测试。 由于没有集中式资源管理系统，因此，当只有一项任务发生时，它会在五台计算机上运行，而其他15台计算机都处于空闲状态。 因此，构建花费了很长时间。
新模式
我们决定改用漂亮的新车型。
在TeamCity代理所在的一台计算机上删除了所有测试。 如果您愿意，该机器现在可以在* nix上，甚至可以在Windows上。 他们将通过HTTP与我们称为设备服务器的某些事物进行通信。 所有模拟器和物理设备都将位于此处，测试将在此处运行，通过HTTP请求设备并继续使用它。 该图非常简单，图中只有两个元素。
当然，实际上，ssh和更多内容仍留在服务器后面。 但是现在它并不困扰任何人，因为编写测试的人员在此图中位于顶部，并且他们具有某种用于本地或远程模拟器的特定界面，因此很好。 现在我在下面工作，一切如故。 我们必须忍受它。
它有什么作用？
- 一是责任分工。 在测试自动化的某个时刻，您应该将其视为正常发展。 它采用与开发人员相同的原理和方法。
- 结果是一个严格定义的界面：您不能直接使用模拟器执行任何操作，为此您需要在设备服务器中打开一个票证，我们将找出如何最佳地做到这一点而不破坏其他测试。
- 测试环境变得更便宜了，因为我们在* nix中提出了它，它比服务罂粟便宜得多。
- 出现了资源共享，因为每个人都可以与之进行单层通信，因此可以规划位于其后的计算机的分布，即 在代理之间共享资源。
像以前一样描绘了上面的内容。 左侧是常规时间单位，例如数十分钟。 有两个代理，每个都连接7个模拟器，构建0时需要40分钟。 20分钟后，另外一个到达，并花费相同的时间。 一切似乎都很棒。 但是，那里有灰色方块。 他们的意思是我们因为没有使用可用资源而损失了金钱。
您可以执行以下操作：第一个构建版本进入并看到了所有免费的模拟器，已分发，并且测试加速了两次。 没事做 实际上，这经常发生是因为开发人员很少在同一时间推动他们的早午餐。 尽管有时会发生这种情况，并且“检查器”，“金字塔”等开始出现。 但是，在大多数情况下，只需为所有资源安装集中式管理系统，即可获得两次免费加速。
继续进行此操作的其他原因：
- 黑匣子，即现在的设备服务器是黑匣子。 编写测试时，您只会考虑测试，并认为此黑匣子将一直有效。 如果它不起作用，您只需去敲门应该做的人，就是我。 我必须修复它。 实际上，不仅我自己，整个基础架构中还涉及几个人。
- 您不能破坏模拟器的内部。
- 您无需在计算机上放置一百万个实用程序就可以启动所有内容-您只需放置一个可以将所有工作隐藏在设备服务器中的实用程序。
- 更新基础架构变得更加容易，我们将在最后讨论该基础架构。
一个合理的问题：为什么不使用Selenium Grid？ 首先，我们有很多遗留代码，1,500个测试，13万行针对不同平台的代码。 所有这些都由parallel_cucumber控制，它创建了测试之外的模拟器的生命周期。 也就是说，有一个特殊的系统加载了模拟器，等待其准备就绪并进行测试。 为了不重写所有内容，我们决定不使用Selenium Grid。
我们也有许多非标准操作，并且很少使用WebDriver。 在Calabash上测试的主要部分，仅和WebDriver辅助。 也就是说，在大多数情况下，我们不使用硒。
而且，当然，我们希望一切都变得灵活，易于原型制作。 因为整个项目只是以他们决定进行测试的想法开始，并在一个月内实施，所以一切都开始了，这成为了我们公司的主要决定。 顺便说一句，我们首先用Ruby编写，然后将设备服务器重写为Kotlin。 测试结果是在Ruby上进行的，而服务器在Kotlin上进行的。
设备服务器
现在，有关设备服务器本身的更多信息，以及它如何工作。 首次开始研究此问题时，我们使用了以下工具：
- xcrun simctl和fbsimctl-用于管理模拟器的命令行实用程序（第一个正式来自Apple，第二个正式来自Facebook，使用起来更方便）
- 同样来自Facebook的WebDriverAgent，用于在推送通知或类似内容到达时在流程外启动应用程序
- ideviceinstaller, - .
, device server, . , fbsimctl , xcrun simctl ideviceinstaller, , fbsimctl WebDriverAgent. - . : - , Facebook . , fbsimctl . :
, .
, .
? , curl list, :
JSON, , . , .
, approve — , . open deep links . , , fbsimctl. , :
, . - . : . , , .
- — . liveshot' iPhone X, iPhone 5S, iPhone 6s. .
- - WebDriverAgent XCUI- , .
- . - iOS 8 , , . device server iOS 8, , , - . fbsimctl.
- , cookies , , , .
- — . , device server , , , , . , . , .
, - , . — , . — , , , .
: Test Runner, ; Device Provider, Device Server, ; Remote Device — ; Device Server — -. , - - fbsimctl WebDriverAgent.
? Test Runner capability, iPhone 6. Device Provider, device server, , - , , , . Device Server . RemoteDevice .
, fbsimctl. , , headless-. , , headless-. - , . , , , syslog SpringBoard .
, XCTest, WebDriverAgent, healthCheck, WebDriverAgent , . , «ready» . healthCheck. , .
fbsimctl. . , WebDriverAgent, . .
— , device server, , , . (release), , , . . , device server , Test Runner . , -, , - .
— . . 30 60. , . , 30 . : , ?
. — . , .
. , , . Separation of Concerns — , , .
. , , Xcode 9, . Xcode 9.2, , — . , - .
Test Runner, rsync, ssh . - *nix, Docker-.
: device server
( GitHub ) , ssh, . device server, ssh, .
提示与技巧
现在，最重要的是我们在创建设备服务器和此基础结构时发现的各种技巧和有用的东西。
首先是最简单的。 您还记得，我们有一台MacBook Pro，所有测试都在笔记本电脑上运行。 现在，我们在Mac Pro上启动它们。
这是两种配置。 这些实际上是每个设备的最高版本。 在MacBook上，我们可以稳定地并行运行6个模拟器。 如果您尝试同时加载更多内容，则模拟器会因其严重加载处理器，具有互锁等事实而开始失败。 您可以在Mac Pro上运行18个内核-这很容易计算，因为12个内核而不是4个。 我们乘以三-您得到约18个模拟器。 实际上，您可以尝试多运行一些，但是必须以某种方式将它们及时分开，例如，不能在一分钟内运行。 尽管这18个模拟器会有一个窍门，但这并不是那么简单。
这就是他们的价格。 我不记得卢布多少钱，但很明显它们很贵。 MacBook Pro的每个模拟器的成本将近400英镑，Mac Pro的每个模拟器将近330英镑。 每个模拟器已经节省了约70英镑。
此外，这些Macbook必须以某种方式安装，它们必须在磁铁上充电，必须将磁铁粘在磁带上，因为有时它们会掉下来。 而且您必须购买适配器来连接以太网，因为Wi-Fi铁盒中附近的许多设备实际上都无法正常工作，因此变得不稳定。 适配器的价格约为30英镑，如果将其除以6，则每台设备将另外获得5英镑。 但是，如果您不需要这种超级并行化，则只有20个测试和5个模拟器，购买MacBook实际上更容易，因为您可以在任何商店找到它，而且您必须订购并等待高端Mac Pro。 顺便说一下，它们使我们的价格便宜一些，因为我们将它们批量购买并且有某种折扣。 您也可以购买内存较小的Mac Pro，然后升级自己，节省更多。
但是，使用Mac Pro，只有一个窍门。 我们必须将它们分成三个虚拟机，然后将ESXi放在其中。 这是裸机虚拟化，即安装在裸机上而不是主机系统上的管理程序。 他本人是主机，因此我们可以运行三个虚拟机。 而且，如果您在macOS上安装了某种常规虚拟化功能（例如Parallels），则由于Apple许可限制，您将只能运行2个虚拟机。 我不得不将其分解，因为管理模拟器的主要服务CoreSimulator原来具有内部锁定，并且同时根本没有加载6个以上的模拟器，它们开始等待队列中的某些东西，并且18个模拟器的总加载时间变得无法接受。 顺便说一句，ESXi的价格为0英镑，当某事一文不值时，它总是很不错的，但它运行良好。
我们为什么不做游泳池呢？ 部分原因是我们加快了模拟器的重置速度。 假设测试崩溃了，您想彻底清理模拟器，以使下一个模拟器不会由于文件系统中残留的晦涩文件而崩溃。 最简单的解决方案是关闭模拟器，明确擦除（擦除）并引导（引导）。
非常简单，只需一行，但需要18秒。 而六个月或一年前，它花费了将近一分钟。 感谢苹果公司对此进行了优化，但是您可以更棘手。 下载模拟器并将其工作目录复制到备份文件夹。 然后关闭模拟器，删除工作目录并复制备份，然后启动模拟器。
结果是8秒：下载速度提高了两倍以上。 同时，没有什么复杂的事情要做，也就是说，在Ruby代码中，它实际上需要两行。 在图片中，我举了一个例子，可以轻松地将其翻译成其他语言。
下一个把戏。 有一个Bumble应用程序，它与Badoo相似，但是概念稍有不同，更加有趣。 在那里，您需要通过Facebook登录。 在所有测试中，由于每次都使用池中的新用户，因此必须从上一个用户注销。 为此，我们使用WebDriverAgent打开Safari，转到Facebook，然后单击“注销”。 看起来不错，但是每次测试都花了将近一分钟。 一百个测试。 额外一百分钟。
此外，Facebook有时喜欢进行A / B测试，因此他们可以更改定位器，按钮上的文本。 突然，一堆测试将失败，每个人都会非常不高兴。 因此，通过fbsimctl我们创建了list_apps，该应用程序查找了所有应用程序。
查找MobileSafari：
并且有一个到DataContainer的路径，它有一个包含cookie的二进制文件：
我们只是删除它-需要20毫秒。 测试开始更快通过100分钟，变得更加稳定，因为它们不能因为Facebook而失败。 因此，有时不需要并行化。 您可以找到要优化的地方，只需100分钟即可轻松完成，无需执行任何操作。 在代码中，这是两行。
下一步：我们如何准备主机以运行模拟器。
在第一个示例中，许多启动Appium的人都熟悉禁用硬键盘。 在模拟器中输入文本时，模拟器习惯于连接计算机上的硬件键盘，并完全隐藏虚拟键盘。 Appium使用虚拟键盘输入文本。 因此，在对输入测试进行本地调试之后，其他测试可能由于缺少键盘而开始失败。 使用此命令，您可以禁用硬键盘，我们在举起每个测试节点之前执行此操作。
下一段与我们更相关，因为该应用程序与地理位置有关。 通常，您需要运行测试以使其最初被禁用。 您可以在LocationMode中设置3101，为什么呢？ Apple的文档中曾经有一篇文章，但是后来由于某种原因将其删除。 现在，这只是我们所有人都希望并不会破坏的代码中的一个魔术常数。 因为一旦中断，所有用户都会在旧金山，因为fbsimctl会在加载时放置此类位置。 另一方面，我们将很容易发现，因为每个人都会在旧金山。
接下来是禁用Chrome，它是围绕着模拟器的带有各种按钮的框架。 运行自动测试时，不需要它。 以前，将其关闭可让您从左到右放置更多模拟器，以了解所有事情如何并行进行。 现在我们不这样做，因为一切都是无头的。 多少人不上车，模拟器本身将不可见。 如果有必要，则可以从所需的模拟器中进行流式传输。
您还可以打开/关闭一组不同的选项。 其中，我只会提到SlowMotionAnimation，因为我在工作的第二天或第三天非常有趣。 我进行了测试，并且它们都开始超时。 他们没有在检查员中找到要素，尽管他是。 原来，那时候我启动了Chrome，按cmd + T打开一个新标签页。 在这一点上，模拟器变得活跃并拦截了团队。 而对于他来说，cmd + T会使所有动画的调试速度降低10倍。 如果要在人们可以访问的计算机上运行测试，也应该始终自动关闭此选项，因为它们可能通过减慢动画速度而意外破坏测试。
对于我来说，最有趣的事情可能是对所有这些基础结构的管理，因为我不久前才这样做。 60个虚拟主机（实际上是64 + 6个TeamCity代理）谁也不想手动推出。 我们找到了
xcversion实用程序-现在它是fastlane的一部分，fastlane是可以用作命令行实用程序的Ruby gem：它部分地自动执行Xcode的安装。 然后，我们用Ansible编写了剧本，将fbsimctl滚动到所需版本，Xcode的所有位置，并为设备服务器本身部署配置。 并且Ansible用于删除和更新模拟器。 当我们切换到iOS 11时，我们离开了iOS10。但是当测试团队说它完全放弃了对iOS 10的自动测试时，我们只是通过Ansible并清理了旧的模拟器。 否则，它们将占用大量磁盘空间。
如何运作？ 如果仅使用xcversion并在60台计算机上分别调用它，则将花费大量时间，因为它会访问Apple网站并下载所有图像。 要更新停放的计算机，您需要选择一台工作计算机，并使用必需的Xcode版本在其上运行xcversion install，但不要安装任何内容或删除任何内容。 安装包将下载到缓存中。 可以对任何版本的模拟器执行相同的操作。 安装包位于〜/ Library / Caches / XcodeInstall中。 然后，您使用Ceph加载所有内容，如果不存在，请在此目录中启动某种Web服务器。 我已经习惯了Python，所以我在机器上运行Python Python服务器。
现在，在开发人员或测试人员的任何其他计算机上，您都可以安装xcversion并指定指向提升的服务器的链接。 它将从指定的机器下载xip（如果局域网速度很快，那么这几乎会立即发生），打开包装，确认许可证-通常，它会为您做所有事情。 将有一个可以正常运行的Xcode，可以在其中运行模拟器和测试。 不幸的是，我们对模拟器的使用并不方便，因此您必须进行curl或wget的操作，将包从该服务器下载到同一目录中的本地计算机，然后运行xcversion模拟器--install。 我们将这些调用放入Ansible脚本中，并且每天更新60台计算机。 主要时间是通过网络文件复制进行的。 另外，我们当时正在行驶，即部分汽车已关闭。 我们重新启动了Ansible两到三次，以赶上搬家过程中缺少的汽车。
简要汇报。 在第一部分：在我看来，优先事项很重要。 也就是说，首先您应该具有测试的稳定性和可靠性，然后是速度。 如果您只追求速度，开始并行化所有内容，那么测试将快速进行，但是没人会看它们，它们只会重新启动所有内容，直到所有内容突然通过为止。 甚至在测试中得分并推向高手。
下一步：自动化是相同的发展，因此您可以采用您已经为我们想到的模式并加以使用。 如果现在您的基础架构与测试紧密相关并且计划扩展，那么这是一个首先分裂然后扩展的好时机。
最后一点：如果任务是加快测试速度，那么想到的第一件事就是添加更多的模拟器，使其在某种程度上使其速度更快。 实际上，通常不需要添加，而是仔细分析代码并用几行代码来优化所有内容，例如在具有cookie的示例中。 这比并行化要好，因为用两行代码节省了100分钟的时间，而对于并行化，您将必须编写大量代码，然后支持基础架构的关键部分。 为了金钱和资源，它将花费更多。
那些对Heisenbug会议的报告感兴趣的人可能还会对以下Heisenbug感兴趣：它将在12月6日至7日在莫斯科举行，会议网站已经包含了许多报告的描述（顺便说一句，仍接受报告申请 ）。