- прошлись по самым времязатратным тестам и улучшили их
- поправили все вызовы, чтобы не было никаких лишних ожиданий
- убрали все sleep'ы
- там, где возможно, сделали генерацию данных через API, чтобы не создавать объекты на UI
- запускаем тесты в headless режиме
Как ускорить автотесты, давайте соберем все возможные варианты
#1
Отправлено 10 июня 2018 - 18:56
#2
Отправлено 10 июня 2018 - 20:05
#3
Отправлено 11 июня 2018 - 05:09
#4
Отправлено 11 июня 2018 - 09:07
затагить только самые критичные тесты как Smoke, и при нормальном билде запускать только их
а все тесты запускать например ночью
#5
Отправлено 12 июня 2018 - 09:48
Отсортировать по критичности и выкинуть половину
+1
Истинное искусство тестировщика - уменьшение числа тестов.
Вам не нужно гонять все тесты. До того, как программист напишет код фичи, автотесты на эту фичу должны быть написаны. Программист делает резолв, идет за чаем. В это время скрипт разворачивает тестовую среду на основе бранча и прогоняет только те тесты, которые привязаны к этой задаче.
PS. Перед тем как приступить к автоматизации процесса поиска ошибок нужно сделать ОЧЕНЬ много изменений в другмх процессах. Почему то все пытаются сделать наоборот. С известным заранее печальным результатом.
- там, где возможно, сделали генерацию данных через API, чтобы не создавать объекты на UI
Зря. Сделайте БД со всеми необходимыми для тестов данными. Балее бэкап/ресторе и наслаждайтесь жизнью. Еще лучше - виртуалка. Перед прогонами поднимаете слепок и вуаля!
Самое банальное и очевидное - улучшить железо, а как следствие количество потоков.
Это прошлый век. Сейчас выгоднее на время прогона тестов арендовать вычислительные мощности в облаке.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 12 июня 2018 - 09:57
У ТС нет цели уменьшить количество авто-тестов.
У него совсем другая цель.
Истинное искусство тестировщика - уменьшение числа тестов.
Предлагаете уменьшать покрытие?
При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.
Это прошлый век. Сейчас выгоднее на время прогона тестов арендовать вычислительные мощности в облаке.
Кому как. Я за стабильную мощную физическую машину.
И ещё учитывайте, что не все компании, а если быть точнее - их политика безопасности, разрешает использовать какое-либо облако.
#7
Отправлено 12 июня 2018 - 13:58
Предлагаете уменьшать покрытие?
При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.
можно наверное многие тесты перенести на уровни ниже, на РЕСТ уровень и на юнит тесты, поэтому можно и увеличить покрытие уменьшая число е2е автотестов
#8
Отправлено 12 июня 2018 - 16:16
У ТС нет цели уменьшить количество авто-тестов.
У него совсем другая цель.
Истинное искусство тестировщика - уменьшение числа тестов.
Предлагаете уменьшать покрытие?
При релизах всё равно надо гонять все тесты. И чем их больше (т.е. больше покрытие) - тем лучше.
Покрытие, это ложная метрика. Настоящая метрика это уровень бездефектности.
"Гонять при релизах все тесты" это очень плохо. Очень. Очень, очень, очень. Если вы вынуждены это делать, то вам уже... Слово из 6 букв, вторая "И".
Это "Фиаско". Впрочем, то что вы подумали тоже хорошо отражает реальность.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
Отправлено 12 июня 2018 - 18:47
Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого.
#10
Отправлено 13 июня 2018 - 07:23
Проблема в том, что из "прогнать все автоматизированные UI-тесты" совершенно не следует "ноль дефектов на проде".
#11
Отправлено 13 июня 2018 - 08:52
И все таки какие люди счастливые... Всего жалких "500 UI-тестов". Вот было бы немного, ну хотя бы тысяч 5-10. Хотя бы. Я уж не говорю про нормальное количество.
Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого.
Если это так, то у вас "сильно связанный код". Что в свою очередь означает, что вам уже Слово из 6 букв, вторая "И". Не надо смотреть на разработку с точки зрения тестирования. Смотрите с точки зрения разработки в целом. Если вы просели по группе атрибутов качества "модифицируемость" (ГОСТ 25010), то... У вас все очень, очень плохо.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12
Отправлено 13 июня 2018 - 09:18
Проблема в том, что из "прогнать все автоматизированные UI-тесты" совершенно не следует "ноль дефектов на проде".
Безусловно. Я об этом и не писал :)
Но чем больше полезных тестов вы прогоните, тем меньше потенциальных дефектов там окажется.
Да и вообще, все клиенты разные. Кому-то не нравится что в тексте допущены ошибки, кому-то ещё что-то.
И все таки какие люди счастливые... Всего жалких "500 UI-тестов". Вот было бы немного, ну хотя бы тысяч 5-10. Хотя бы. Я уж не говорю про нормальное количество.
Нет, конечно можно забить и прогнать только явно «задетые» фичи за пару минут, а потом наблюдать за дефектами на проде и за метрикой бездефектности - выбор каждого.
Если это так, то у вас "сильно связанный код". Что в свою очередь означает, что вам уже Слово из 6 букв, вторая "И". Не надо смотреть на разработку с точки зрения тестирования. Смотрите с точки зрения разработки в целом. Если вы просели по группе атрибутов качества "модифицируемость" (ГОСТ 25010), то... У вас все очень, очень плохо.
Да хоть 50000. Если ресурсы компании позволяют это так же прогонять за 10 минут (или смотря сколько у вас time2market), не вижу никакой проблемы.
А если вы ограничены в ресурсах, то конечно - выкидывайте тесты и пишите, что так надо делать и это вообще best practice.
PS: Даже если у вас не "сильно связанный код", никто никогда не даст гарантию, что его изменение обязательно не заденет что-то другое.
Большинство дефектов, в общем-то, обычно отсюда и вытекает, что "ой, а тут не должно было ничего измениться".
За сим откланиваюсь, дальнейшая дискуссия не имеет смысла.
#13
Отправлено 13 июня 2018 - 12:20
Слив защитан.За сим откланиваюсь, дальнейшая дискуссия не имеет смысла.
#14
Отправлено 13 июня 2018 - 15:55
вот бы Гугл так делал: "а давайте все тесты прогонять каждый раз, вдруг что-то где-то сломалось?", интересно что бы получилось
#15
Отправлено 13 июня 2018 - 18:48
Ключевое слово "ПОЛЕЗНЫХ" тестов.
Пользу теста измерить просто:
Количество найденых тестом дефектов / количество прогонов теста.
Как-то смотрел доклад товарища, который так сделал. У них было ЕМНИП >5млн тестов и время прогона ~12 часов. Полный сьют периодически запускают, а прогон тестов по PR сократили минут до 15.
#17
Отправлено 14 июня 2018 - 20:44
Да хоть 50000. Если ресурсы компании позволяют это так же прогонять за 10 минут (или смотря сколько у вас time2market), не вижу никакой проблемы.
А если вы ограничены в ресурсах, то конечно - выкидывайте тесты и пишите, что так надо делать и это вообще best practice.
Во-первых не за 10, а за 20 минут. А во-вторых, если бы ресурсы компании позволяли это сделать, то топикстартер не гнался бы за ускорением в 30 секунду.
Вы рассуждаете, как будто ресурсы компании бесконечны... Бизнесу такой подход не нравится.
Продолжать предлагаю здесь: http://software-test...-uskorit-testy/
Открыл новую тему.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных