Как сократить время прогона авто тестов?

общие вопросы
, ,
#1

Бывает, встречается такой вроде бы простой и банальный вопрос на собеседованиях, либо сам задумываюсь над этим. Первым делом в голову лезет “распараллелить”, но понятно, что этим явно дело не ограничивается, и на собеседовании таким ответом сильно никого не удовлетворишь. Дальше уже появляются мысли типа “провести рефакторинг, избавиться от ненужных тестов, оптимизировать Java код” и более абстрактные фразы. Так вот хотелось бы все таки получить ответ от знающих и понимающих людей: какие действительно важные конкретные шаги помогают ускорить автотесты? Спасибо!

1 лайк
Как ускорить тесты в сложных сценариях с регистрацей и заполнением анкеты
#2

Для начала следует ответить самому себе на вопрос: а каковы истинные причины долгого прогона тестов? Ведь это может быть как банальная нехватка ресурсов, так и слепое стремление автоматизировать все подряд. А может просто технический долг или нестабильное окружение?

На самом деле, не существует универсального ответа. Очень многое зависит от тех условий, в которых вы работаете, а также - ваших скиллов.

Если хотите конкретики, то рассматривайте точечные ситуации. По каждой можно придумать свои пути решения. И на собеседованиях от вас, как правило, ждут толкового анализа и качественных рассуждений для подобного рода вопросов.

8 лайков
#3

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

1 лайк
#5

Оптимизация базы данных может помочь)) Например SET GLOBAL innodb_flush_log_at_trx_commit=2;

innodb_flush_log_at_trx_commit — имеет три допустимых значения: 0, 1, 2. При значении равном 0, лог сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. При значении равном 1, лог сбрасывается на диск при каждой транзакции. При значении равном 2, лог пишется при каждой транзакции, но не сбрасывается на диск никогда, оставляя это на совести ОС. По умолчанию используется 1, что является самой надежной настройкой, но не самой быстрой. В общем случае вы можете смело использовать 2, данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд (зависит от настроек ОС). 0 — самый быстрый режим, но данные могут быть утеряны как при крахе ОС, так и при крахе самого сервера MySQL (впрочем данные лишь за 1-2 секунды).

1 лайк
#6

У меня в практике было несколько причин:

  1. Тормоза при работе с БД
  2. Нужен рефакторинг логики тестов (может алгоритмы какие затратные или много раз инициализируется вебэлемент)
  3. Криво настроены ожидалки
    4)“Сложные” локаторы
#7

Из личного опыта:

  1. Проанализировать тесты -разбить на более мелкие. Убирать дублирующиеся проверки (если функционал проверен в одном тесте, нет смысла делать аналогичную проверку в другом(,если входные параметры не различаются))
  2. Убрать лишние жёсткие ожидания по времени
  3. Локаторы - лучше использовать css-селекторы
  4. Параллельный запуск.
    Мы так сократили время прохождения тестов с 2 часов до 15 минут.
#8

У нас родилась одна идея - по выбрасыванию событий из тестов, с данными которые могут быть использованы в других тестах.

Пример - АПИ тесты, и допустим какой то запрос к поиску - когда поиск прошел - мы бросаем событие с данными которые вернулись из этого поиска, и если есть тесты которые требуют эти данные для старта - мы запускаем тесты с ними. Получается эдакий древовидный запуск тестов и очень тщательное переиспользование данных где возможно - экономим телодвижения в тестах.

Это пока очень все расплывчасто и на бумаге. Если этот пост соберет 5 лайков - напишу статью на медиум с описанием концепции такого запуска.

9 лайков
#9

runtime dependencies?

#10

похоже пора писать статью

2 лайка
#11

Да интересно. Вот допустим поиск не прошёл, что дальше делать? Или какой-то вася пупкин запустил в другом скоупе тесты которые чистят результаты

#12

Всё это решаемо. Вопрос в том насколько это будет прозрачно и насколько легко это будет менеджить.

#13

Режим “Очевидность” включен
Время выполнения = Объем / Скорость выполнения
Т.ч. время можно уменьшать за счет уменьшения объема или повышения скорости.
Режим “Очевидность” выключен

Объем можно понижать статически (выбрасывать избыточные или ресурсо-емкие тесты) или динамически (выбирать только нужные тесты под изменения: change-based testing).

Для повышения скорости для начала требуется профилирование.

В авто-тестах можно выделить 5 основных фаз:

  • подготовка среды для теста
  • выполнение
  • проверка результата
  • фиксация результатов и других артефактов в системе
  • очистка среды

Без ясной картины, какой ресурс и на какой фазе является бутылочным горлышком, не понятно, что оптимизировать.
Скажем, если все упирается в один ресурс, то распараллеливание может только усугубить ситуацию.
Например, уперлись в сеть Ethernet. Параллельная работа нескольких машин увеличит вероятность конфликтов и снизит эффективную пропускную способность сети.

В целом, я не вижу принципиальных отличий с HighLoad - в основном применяются те же приемы.

1 лайк