Запускать тесты оказалось не таким уж и хитрым делом. Но как мы можем подготовиться к росту их количества?
Существует 2 типа масштабирования: вертикальное и горизонтальное.
Вертикальное масштабирование подразумевает увеличение количества ресурсов на машине, горизонтальное, увеличение количества машин с сохранением текущего ресурса, либо его уменьшением.
В случае, если мы решим использовать самый мощный мак про на сегодняшний день, с 28 CPU, у нас будет возможность эффективного запуска порядка 14-18 симуляторов одновременно, в расчёте 1-2 ядер на симулятор.
В теории, такая доработка позволит заметно ускорить выполнение тестовых сценариев. На практике, при задании параллельного выполнения, встроенный координатор стандартного раннера распределяет тесты по их количеству, что создает дисбаланс во времени выполнения между симуляторами.
Второй минус такого подхода заключается в том, что предел масштабирования достигается давольно быстро, и этот предел – жесткий.
Горизонтальное масштабирование имеет более мягкий предел – бюджет вашей компании, потому, такой способ больше подходит при стремительном росте количества тестов. Минус горизонтального масштабирования заключается в том, что он требует гораздо больше трудозатрат.
Представим, что нашей целью является равномерное распределение тестовых сценариев на N машин с мощностью в 2 CPU каждая. При этом, N может быть от 1, до бесконечно большого числа машин в вашем флоте.
Разберемся с требованием равномерного распределения. Равномерное распределение тестовых сценариев – это такое распределение сценариев между машинами, при котором время старта и завершения выполнения всех операций будет равным, в пределах погрешности.
Другими словами, мы хотим, чтобы при параллельном выполнении тестов на разных машинах, время завершения для всех машин было примерно одинаковым.
Реализовать такое распределение не представляет сложности. Вся информация, которую нам необходимо знать, это идентификатор тестового сценария и среднее время его выполнения.
Имея эти 2 параметра для каждого теста, мы можем написать алгоритм балансировки нагрузки при помощи “кучи” (Heap). В реализации этого алгоритма, мы будем складывать наши тесты в очереди (Queue), находящиеся внутри MinHeap. Количество очередей в куче будет равно нашему N.
Таким образом, мы добьемся примерно-равного распределения тестов в очередях по суммарному времени выполнения. Каждая очередь будет отправлена на соответствующую машину для выполнения. В результате, время выполнения всех тестов среди всех машин должно быть примерно-одинаковым.
“Откуда мы узнаем время выполнения тестов”, – думаете вы? Для этого, мы будем собирать аналитику по каждому выполненному тесту и отправлять ее в базу данных.
Для этих целей, нам подойдет TimeSeries база данных (например InfluxDB), из которой мы сможем запрашивать среднее время выполнения тестов за определенный период времени. Допустим, за вчера.
При таком подходе, вы сможете значительно уменьшит время выполнения ваших UI тестов и быть готовыми к их последующему росту. Все что нужно будет сделать – изменить значение нашего N.
Последним, но не по значению аспектом вашей инфраструктуры, является аналитика. Как понять что с выполнением тестов нет проблем? Как узнать время выполнения каждого теста? И на многие подобные вопросы, вам поможет ответить аналитика вашей системы.
Продолжение:
twitter.com/mobileunderhoo…