Время выполнения авто тестов на проектах

gui
api
execution
Теги: #<Tag:0x00007fedb9ee65c0> #<Tag:0x00007fedb9ee6480> #<Tag:0x00007fedb9ee6340>

(Roy Obenon) #1

Всем здравствуйте, хотел бы поинтересоваться у кого на проекте какое среднее (и максимальное) время выполнения авто тестов (гуй и апи)? У меня на проекте время выполнения некоторых тестов (гуй и апи) достигает 8+ч., что меня сильно напрягает в целесообразности такого долгого выполнения (либо вероятность того, что он упадет из-за сторонних факторов (отвалилась сеть, сессия, ПРОСТО упал :wink:) очень велика. Хотелось бы узнать ваше мнение по поводу этого.


(Николай Анатольевич) #2

Среднее время 100+ тестов, запускаемых ежедневно - от 15 до 30 минут. Что можно делать 8+ часов, если не секрет?


(Roy Obenon) #3

копирование виртуалок, бекап - рестор данных


(Yaroslav Pernerovskyy) #4

Из опыта кровавого энтерпрайза, максимально что я видел - 4 недели! Второе место 48 часов.
Так что 8 часов это не серьезно даже )))


(Roy Obenon) #5

и как сторонние факторы не влияли на тесты?


(Alexander) #6

800 юайных функциональных тестов, 12 потоков, две железные машины под ноды, одна железная машина под хаб. Занимает от 45 минут до часа.


(Alexandr Navara) #7

Энтерпрайз, API + GUI, общее количество 9к тестов, весь пайплайн около 8 часов, причем API и GUI бегают параллельно на разных нодах. Основной тормозящий фактор - плохо спроектированные API тесты - не дают возможность параллельного запуска.


(Vladislav Kulasov) #8

8ч это не много. Я меня сделано так:

  1. Тесты на группы, по приоритетам. Важные в самом начале.
  2. Использую репорт портал для результата “сразу”.
    У меня один репорт ранится от 2мин до 10. И таких не один десяток. Пока 2 ноды, но чем больше нод тем больше нужно поддерживать :frowning:

(Roy Obenon) #9

приоритет запуска и так понятен, просто считаю, что долгие тесты ни к чему хорошему не приведут.


(Vladislav Kulasov) #10

Ну смотря что вы подразумеваете под “долгими тестами”.
время занимаемое тестами можно разделить на части:

  1. подготовка окружения
  2. подготовка данных
  3. тесты

Например 1 и 2 это не тесты + если у вас в тестах долго отрабатывает само тестируемое приложение, и вы ни как не можете на это влиять, то это тоже не проблема тестов.
Плохо когда тесты долгие - это когда тест можно поделить на части. Если вы не можете это сделать, то это не проблема тестов.


(Roy Obenon) #11

pre, post условия я не подразумевал включать в оценку времени выполнения, я имелось виду сам ТЕСТ


(Михаил Братухин) #12

И чем меряете этот «сам тест»?
Предусловия и пост-условия часто занимают большую часть времени прогона и мерить без них не совсем понятно для чего. Если только для поиска «узких» мест в тестах и методике для дальнейшей оптимизации своей модели.


(Юрий Аксютин) #13

Вопрос не содержит достаточно информации для получения четкого ответа.
По моему проекту:
350 тестов UI(Specflow, Selenium, database, azure blob, media service…) в 15 потоках, проходят 50-60 минут
в 5 потоках соответственно 3 часа
В идеале, при наличии достаточного количества вычислительных ресурсов, время прохождения тестов должно соответствовать времени прохождения самого долгого теста(в моем случае 15 минут)
Абсолютно верно, что чем дольше идет тест, тем больше вероятность влияния на результат побочных факторов(особенно если приложение и тесты запускаются в облаке)


(Mykhailo Poliarush) #14