Перейти к содержимому

Фотография

Как ускорить автотесты, давайте соберем все возможные варианты


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 16

#1 FestiveGrape

FestiveGrape

    Новый участник

  • Members
  • Pip
  • 69 сообщений
  • ФИО:Андреевич


Отправлено 10 июня 2018 - 18:56

Добрый вечер.
 
У нас есть 500 UI-тестов, которые прогоняются в параллельных потоках за 20 минут. Хотим ускорить процесс и каждые 30-60 секунд ускорения будут нам очень кстати
 
Уже сделали следующее:
  • прошлись по самым времязатратным тестам и улучшили их
  • поправили все вызовы, чтобы не было никаких лишних ожиданий
  • убрали все sleep'ы
  • там, где возможно, сделали генерацию данных через API, чтобы не создавать объекты на UI
  • запускаем тесты в headless режиме
 
Как еще вы ускоряете тесты? Может используете какие-то фичи или знаете еще какие-то шаги для ускорения тестов? Называйте даже самые банальные и очевидные - вдруг мы что-то забыли или не знали
 

Буду очень благодарен! 

  • 0

#2 Noksa

Noksa

    Активный участник

  • Members
  • PipPip
  • 117 сообщений
  • ФИО:Александр

Отправлено 10 июня 2018 - 20:05

Самое банальное и очевидное - улучшить железо, а как следствие количество потоков.
  • 0

#3 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 11 июня 2018 - 05:09

Отсортировать по критичности и выкинуть половину
  • 5

#4 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 11 июня 2018 - 09:07

затагить только самые критичные тесты как Smoke, и при нормальном билде запускать только их

 

а все тесты запускать например ночью


  • 1

#5 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 12 июня 2018 - 09:48

Отсортировать по критичности и выкинуть половину

+1

 

Истинное искусство тестировщика - уменьшение числа тестов.

 

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

 

PS. Перед тем как приступить к автоматизации процесса поиска ошибок нужно сделать ОЧЕНЬ много изменений в другмх процессах. Почему то все пытаются сделать наоборот. С известным заранее печальным результатом.

  •  
  • там, где возможно, сделали генерацию данных через API, чтобы не создавать объекты на UI

 

 

 

Зря. Сделайте БД со всеми необходимыми для тестов данными. Балее бэкап/ресторе и наслаждайтесь жизнью. Еще лучше - виртуалка. Перед прогонами поднимаете слепок и вуаля!

 

 

Самое банальное и очевидное - улучшить железо, а как следствие количество потоков. 

 

 

Это прошлый век. Сейчас выгоднее на время прогона тестов арендовать вычислительные мощности в облаке.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#6 Noksa

Noksa

    Активный участник

  • Members
  • PipPip
  • 117 сообщений
  • ФИО:Александр

Отправлено 12 июня 2018 - 09:57

У ТС нет цели уменьшить количество авто-тестов.

У него совсем другая цель.

 

 

 

Истинное искусство тестировщика - уменьшение числа тестов.

Предлагаете уменьшать покрытие? 

 

При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.

 

 

 

Это прошлый век. Сейчас выгоднее на время прогона тестов арендовать вычислительные мощности в облаке.

 

Кому как. Я за стабильную мощную физическую машину.

 

И ещё учитывайте, что не все компании, а если быть точнее - их политика безопасности, разрешает использовать какое-либо облако.


  • 0

#7 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 12 июня 2018 - 13:58

 

Предлагаете уменьшать покрытие? 

 

При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.

можно наверное многие тесты перенести на уровни ниже, на РЕСТ уровень и на юнит тесты, поэтому можно и увеличить покрытие уменьшая число е2е автотестов


  • 0

#8 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 12 июня 2018 - 16:16

У ТС нет цели уменьшить количество авто-тестов.

У него совсем другая цель.

 

 

 

Истинное искусство тестировщика - уменьшение числа тестов.

Предлагаете уменьшать покрытие? 

 

При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.

 

Покрытие, это ложная метрика. Настоящая метрика это уровень бездефектности. 

"Гонять при релизах все тесты" это очень плохо. Очень. Очень, очень, очень. Если вы вынуждены это делать, то вам уже... Слово из 6 букв, вторая "И". 

 

 

 

Это "Фиаско". Впрочем, то что вы подумали тоже хорошо отражает реальность.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#9 Noksa

Noksa

    Активный участник

  • Members
  • PipPip
  • 117 сообщений
  • ФИО:Александр

Отправлено 12 июня 2018 - 18:47

И чем же это плохо, если это занимает при хорошей параллельности 10 минут?
Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого.
  • 0

#10 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 13 июня 2018 - 07:23

Проблема в том, что из "прогнать все автоматизированные UI-тесты" совершенно не следует "ноль дефектов на проде".


  • 0

#11 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 13 июня 2018 - 08:52

И все таки какие люди счастливые... Всего жалких "500 UI-тестов". Вот было бы немного, ну хотя бы тысяч 5-10. Хотя бы. Я уж не говорю про нормальное количество.

 

Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого. 

 

 

Если это так, то у вас "сильно связанный код". Что в свою очередь означает, что вам уже Слово из 6 букв, вторая "И". Не надо смотреть на разработку с точки зрения тестирования. Смотрите с точки зрения разработки в целом. Если вы просели по группе атрибутов качества "модифицируемость" (ГОСТ 25010), то... У вас все очень, очень плохо.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#12 Noksa

Noksa

    Активный участник

  • Members
  • PipPip
  • 117 сообщений
  • ФИО:Александр

Отправлено 13 июня 2018 - 09:18

Проблема в том, что из "прогнать все автоматизированные UI-тесты" совершенно не следует "ноль дефектов на проде".

 

Безусловно. Я об этом и не писал :)

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

 

Да и вообще, все клиенты разные. Кому-то не нравится что в тексте допущены ошибки, кому-то ещё что-то. 

 

И все таки какие люди счастливые... Всего жалких "500 UI-тестов". Вот было бы немного, ну хотя бы тысяч 5-10. Хотя бы. Я уж не говорю про нормальное количество.

 

Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого. 

 

 

Если это так, то у вас "сильно связанный код". Что в свою очередь означает, что вам уже Слово из 6 букв, вторая "И". Не надо смотреть на разработку с точки зрения тестирования. Смотрите с точки зрения разработки в целом. Если вы просели по группе атрибутов качества "модифицируемость" (ГОСТ 25010), то... У вас все очень, очень плохо.

 

Да хоть 50000. Если ресурсы компании позволяют это так же прогонять за 10 минут (или смотря сколько у вас time2market), не вижу никакой проблемы.

А если вы ограничены в ресурсах, то конечно - выкидывайте тесты и пишите, что так надо делать и это вообще best practice.

 

 

PS: Даже если у вас не "сильно связанный код", никто никогда не даст гарантию, что его изменение обязательно не заденет что-то другое.

 

Большинство дефектов, в общем-то, обычно отсюда и вытекает, что "ой, а тут не должно было ничего измениться".

 

 

За сим откланиваюсь, дальнейшая дискуссия не имеет смысла.


  • 0

#13 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 13 июня 2018 - 12:20

За сим откланиваюсь, дальнейшая дискуссия не имеет смысла.

Слив защитан.
  • 1

#14 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 13 июня 2018 - 15:55

вот бы Гугл так делал: "а давайте все тесты прогонять каждый раз, вдруг что-то где-то сломалось?", интересно что бы получилось


  • 0

#15 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 13 июня 2018 - 18:48

Ключевое слово "ПОЛЕЗНЫХ" тестов.
Пользу теста измерить просто:
Количество найденых тестом дефектов / количество прогонов теста.
Как-то смотрел доклад товарища, который так сделал. У них было ЕМНИП >5млн тестов и время прогона ~12 часов. Полный сьют периодически запускают, а прогон тестов по PR сократили минут до 15.


  • 0

#16 BabyRoot

BabyRoot

    Специалист

  • Members
  • PipPipPipPipPip
  • 833 сообщений


Отправлено 14 июня 2018 - 12:14

https://habr.com/post/358178/

4 и 6 антипатерн для вас.


  • 0

#17 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 14 июня 2018 - 20:44

Да хоть 50000. Если ресурсы компании позволяют это так же прогонять за 10 минут (или смотря сколько у вас time2market), не вижу никакой проблемы.
А если вы ограничены в ресурсах, то конечно - выкидывайте тесты и пишите, что так надо делать и это вообще best practice.

Во-первых не за 10, а за 20 минут. А во-вторых, если бы ресурсы компании позволяли это сделать, то топикстартер не гнался бы за ускорением в 30 секунду.

Вы рассуждаете, как будто ресурсы компании бесконечны... Бизнесу такой подход не нравится.

Продолжать предлагаю здесь: http://software-test...-uskorit-testy/

 

Открыл новую тему.


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных