t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

Теги: #<Tag:0x00007f9b03673478> #<Tag:0x00007f9b03673220> #<Tag:0x00007f9b03672dc0>

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

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

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

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

3 Симпатий

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

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

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

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

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

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

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

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

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

2 Симпатий

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

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

1 Симпатия

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