Как ускорить автотесты

Подбираем эффективную конфигурацию под ваши нужды

Disclaimer. В статье рассмотрим конфигурацию, которую вы можете внедрить в свои проекты. При этом помните про несколько факторов:

• Результат может варьироваться, если используются разные серверные машины.
• Избыток ресурсов — это не всегда хорошо.
• Оптимизация железа должна идти бок о бок с оптимизацией тестов.

Всем привет! Меня зовут Иван Левиков, я старший инженер по тестированию.

ВКонтакте развиваю и ускоряю автотесты, анализирую и улучшаю инфраструктуру, создаю новые решения.

При проектировании инфраструктуры для автотестов на Android приходится искать ответы на вопросы о том, где можно их запускать и где лучше это делать. 

Рассмотрим самые популярные места для запуска автотестов: 

• облачные решения;

• решения на физических девайсах. 

Облачные решения

В этой категории много предложений от разных компаний, например: 

• Amazon,

• Firebase Test Lab,

• Huawei DigiX Lab,

• Remote Test Lab от Samsung,

• и другие.

Говоря обобщённо, можно выделить такие преимущества и недостатки ферм из облачных решений ↓

В интернете много обзоров, так что не будем останавливаться на этом.

Если не хотите использовать внешние решения, а стремитесь построить что-то своё, можно обратиться к связке из OpenSTF и физического девайса или к эмуляторам андроид-устройств. Остановимся на каждом варианте чуть подробнее. 

OpenSTF + физический девайс

В нашем опыте будет фигурировать Samsung Galaxy S20+ (6 ядер, 8 гигов). По характеристикам это достаточно мощный девайс (см. рейтинг производительности), и его ПО будет обновляться ещё долго. Берём в эксперимент.

Так выглядел один из первых прототипов нашей фермы. Собран из смартфонов Samsung, которые питаются через USB hub и подключены к ноутбуку с локально развёрнутой OpenSTF. Можно поиграть в «Отгадай модель устройства по фото».

Так мы и жили довольно долго, управляя физическими девайсами через OpenSTF. При очевидных преимуществах были и сложности — перечисляю их ниже.

Мы сталкивались с множеством проблем: это, например, очистка данных, закрытие всплывающих окон, падение производительности и непонятные флаки тестов. Если остальные недочёты мы рутинно побеждали, то дебаг и отладка флакующих тестов стали ресурсоёмкими задачами. В одних случаях это было связано с текущим состоянием устройства, а в других — казалось, что с фазой Луны и ретроградным Меркурием. 

Ферма с виртуальными Android-девайсами

Мы решили провести разные эксперименты, чтобы повысить стабильность. В первую очередь — улучшить нашу ферму, но не за счёт покупки новых физических девайсов, как обычно, а создав параллельно ферму эмуляторов.

В итоге мы остановились на конфигурации с виртуальными андроид-девайсами. Начали с построения фермы из связки уже знакомой нам OpenSTF и эмуляторов QEMU. В стандартной комплектации из коробки у наших эмуляторов было по 2 виртуальных ядра и 4 гига оперативной памяти. В целом по производительности и жизнеспособности они нас устраивали. Но для некоторых ситуаций необходимо было создавать собственные решения: например, для превентивного прогнозирования возможной деградации эмулятора и падений тестов из-за этого. Винрейт (соотношение между упавшими и пройденными тестами) в исходном состоянии из коробки в среднем был около 65%, и автотесты при этом находили баги. 

Ищем оптимальную конфигурацию железа для эмуляторов

Но положение дел меня по-прежнему не устраивало, так что я отправился в длинное приключение в поисках стабильности. Цель: найти оптимальную конфигурацию железа для эмуляторов. Обнаружил пару статей и readme в репозитории Google: там рекомендовали использовать конфиг на 4 виртуальных ядра и 12 гигов оперативной памяти. Мне стало интересно, почему так. А что будет, если дать больше или меньше? 

Меня заинтриговали эти вопросы, так что я решил погрузиться в них. Казалось бы, чего здесь долгого — придумать способ для оценки производительности и сравнить между собой несколько конфигураций.

Но всё оказалось не так просто: в процессе работы пришлось делать много анализов производительности, искать причины появления ООМ (Out of memory). Поэтому простым это путешествие было не назвать. Оно стало тем самым «20-minute adventure» — на полгода