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

Тестирование производительности (JMeter)
онлайн, начало 22 июня
Управление требованиями
онлайн, начало 22 июня
Автоматизация функционального тестирования
онлайн, начало 29 июня
Программирование на C# для тестировщиков
онлайн, начало 29 июня
Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 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
  • Pip
  • 21 сообщений
  • ФИО:Александр

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

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

#3 Freiman

Freiman

    Гуру

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

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

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

#4 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 866 сообщений
  • ФИО:Роман

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

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

 

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


  • 1

#5 SALar

SALar

    Гуру

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


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

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

+1

 

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

 

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

 

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

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

 

 

 

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

 

 

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

 

 

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


  • 0

-- 

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

Блог 255 ступеней

 


#6 Noksa

Noksa

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

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

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

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

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

 

 

 

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

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

 

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

 

 

 

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

 

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

 

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


  • 0

#7 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 866 сообщений
  • ФИО:Роман

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

 

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

 

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

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


  • 0

#8 SALar

SALar

    Гуру

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


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

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

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

 

 

 

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

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

 

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

 

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

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

 

 

 

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


  • 0

-- 

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

Блог 255 ступеней

 


#9 Noksa

Noksa

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

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

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

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

#10 Freiman

Freiman

    Гуру

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

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

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


  • 0

#11 SALar

SALar

    Гуру

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


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

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

 

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

 

 

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


  • 0

-- 

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

Блог 255 ступеней

 


#12 Noksa

Noksa

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

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

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

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

 

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

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

 

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

 

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

 

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

 

 

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

 

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

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

 

 

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

 

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

 

 

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


  • 0

#13 Freiman

Freiman

    Гуру

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

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

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

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

#14 Spock

Spock

    Специалист

  • Members
  • PipPipPipPipPip
  • 866 сообщений
  • ФИО:Роман

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

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


  • 0

#15 Little_CJIOH

Little_CJIOH

    Гуру

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


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

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


  • 0

#16 BabyRoot

BabyRoot

    Специалист

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


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

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

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


  • 0

#17 Vasiliy

Vasiliy

    Гуру

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

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

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

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

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

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

 

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


  • 0


Selenium 2.0: стартовый уровень
онлайн, начало 7 сентября
Программирование на Java для тестировщиков
онлайн, начало 6 июля
Автоматизация функционального тестирования
онлайн, начало 29 июня
Selenium WebDriver: полное руководство
онлайн, начало 13 июля



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

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

Яндекс.Метрика
Реклама на портале