Вообще, это от английского tool, инструмент. Не тулзы, потому, что речь в единственном числе. В разных уголках мира говорят по разному. Но вообще статья не про название, с удовольствием отвечу на комментарии к сути
Интересный кейс, job scheduler так настроены? Или реально 20 минут процессинга? Видимо у меня просто личный опыт наложился, где я видел сценарии которые 20-25 минут кликают по экрану. Там были крайне сложные сценарии, где настраивались визарды, дублировались сложные логики, чтобы сделать тест атомарным, было очень большое количество проверяемых действий. Я даже не подумал, что у вас сценарий просто 20 минут ждет
На самом деле наши длительные кейсы не просто 20 минут ждут. В наших приложениях люди проводят длительное время. И например, через какое то время использования некоторых функций нашего приложения - появляются различные события. Вот эти события мы и проверяем.
Что вы называете автотестом? Такое ощущение, что говоря "автотест" вы подразумеваете "все 2000 автотестов".
Автотест - это автоматизированный тестовый сценарий. Абстрактный пример такого сценария
Регистрируем пользователей А и B
Заходим в приложением пользователем А
Отправляем заявку от пользователя А к пользователю В
Заходим в систему пользователем В и проверяем, что он получил заявку от А
Что значит "в среднем у нас происходит 8 запусков автотестов на одну публикацию"? Это 8 запусков одних и тех же тестов? Зачем?
Процесс тестирования у нас проходит несколько этапов. Условно, это может быть Stage1, Stage2, Stage3. На каждом из этих этапов мы запускаем наши автотесты. По различным причинам, отсутствие багов при тестировании на stage1 является необходимым, но не достаточным условием для отсутствия багов на stage2 и так далее. Каждое из окружение имеет свои особенности, поэтому для гарантирования качества мы не можем пропускать эти этапы.
Что такое "публикация"? Это релиз новой версии? Как часто происходят "публикации"?
Публикация это появление какого то изменения на продакшене. Новая функциональность, например. Мы не готовим релиз(большое количество новых фич) в течении нескольких месяцев. Мы делаем частые публикации(которые, необязательно маленькие). Количество публикаций - переменная величина, но в среднем их больше 10 в неделю
Вам не кажется, что наличие автотеста, который проходит более 25 минут является маркером плохого тест-дизайна.
Как я уже писал в самой статье мы сознательно отказались от использования моков и костылей в автотестах, и решили тестировать только пользовательские сценарии. В наших приложениях есть пользовательские сценарии, которые занимают столько времени. Другими словами - событие "B" происходит через 20 минут после события "А". Мы не пробрасываем сообщение в шину, не используем бэкдоры, а проверяем саму систему. Сама система это делает. Поэтому вопрос о плохом тестдизайне не стоит.
Соответственно привести систему к любому состоянию - дело десятка секунд.
К сожалению, нет. Система очень сложная, с кучей микросервисов (речь уже о тысячах). Подсунуть побыстрому что-то в базу не получается по многим причинам, в том числе и потому, что система живая и поддерживать такие костыли очень сложно. Запросы к базе у нас, по большей части, это SELECT, для каких-то очень важных точечных проверок.
Я правильно понимаю, что придумали довольно хитрую систему с A, B ..., чтобы сэкономить максимум 25 минут из 8 часов?
В среднем у нас происходит 8 запусков автотестов на одну публикацию. До всех преобразований 1 запуск длился около 2-х часов. Мы обратили внимание на эту проблему, когда заметили, что последний тест завершается через 15-20 минут после всех остальных. Сейчас в каждом запуске у нас не остаются длинные автотесты в конце, а значит тестировщик раньше увидит результат. Под поднятием приоритета, вы, наверное, имеете ввиду [Order()]. К сожалению, он действует только в рамках одного неймспейса. Организовать 2к+ тестов в одном неймспейсе чисто семантически не очень правильно.
Понятно, что магии нет и все равно где то приходим к использования Thread.Sleep, но речь про совсем грязный код вида thread.sleep(TimeSpan.FromSeconds(30)), вместо явного ожидания появления элемента.
Я же правильно понимаю, что в системе с тестами только api и ui шаги.
В наших тестах есть все виды взаимодействия: api, ui, запросы к базе через драйверы и т.д. Атомарность кейсов соблюдена настолько, насколько это возможно. Но, как я писал ранее, мы решили придерживаться парадигмы автоматизации пользовательских кейсов, а не проверки кнопок и менюшек в вакууме. Мы пишем приемочные тесты, а они, по своему определению, не могут состоять из одного шага и проверки. Да, какие то шаги пересекаются, но они максимально упрощены. Еще раз отмечу, что при высоком уровне паралеллизации - большое число ложных срабатываний связано с максимальной загрузкой железа виртуалок из-за огромного количества запросов. Думаю, вам не нужно объяснять, что если cpu и диск под 100%, то о стабильности автотестов можно не мечтать.
Зачем вводить категории по продолжительности? По бизнес value - логично, по продолжительности не очень вижу логику. Они же все равно все должны пройти.
Идея была реорганизовать все кейсы таким образом, чтобы они запускались от наиболее долгого к наиболее быстрому. Когда речь про 1 поток, то разницы нет. А когда речь про многопоточность - появляются нюансы. Представьте ситуацию, когда у вас 10 тестов и 5 потоков. Из этих 10 тестов есть 3 теста, которые выполняются 15 минут каждый, остальные 7 тестов выполняются по 2 минуты. И в нашем случае получалось, что 2 из 3 долгих тестов попадали в один поток, что делало минимальное время прохождения запуска: 15+15 = 30 минут. Как бы быстро остальные тесты не бежали - все равно запуск будет ждать этот долгий поток с двумя тестами по 15 минут. После наших преобразований у нас в каждый поток попадает только 1 долгий тест, и получается что минимальная продолжительность тестового запуска уже 15+2=17 минут.
Мы пробовали перейти на selenoid/zalenium еще в 2017 году. Я тогда услышал про них на одной из конференций и вдохновился идеей.
Проблема заключалась в том, что не закрывались конейтейнеры с сессией. Наши администраторы выдали мне CentOs, в ней был такой баг. Плюс, мы не получили какого-то прироста в скорости или в количестве, а главным преимуществом я вижу возможность использования разных версий браузеров. Что для нас тоже не совсем актуально, так это то, как большинство наших пользователей используют последнюю версию браузера.
Так что selenoid добавлял новые проблемы, но при этом не решал существующих задач. Хотя я думаю, что мы скоро на него перейдем, судя по отзывам его уже хорошо допилили.
Вот я про удобство и говорю — у меня совершенно нет проблем ездить на большом автомобиле, чем на самокате. А по поводу стабильности: чаще всего просто обновлять библиотеки надо не сразу а недельки через три, когда коммьюнити уже протестит. Вообщем для меня это очень похоже на биткоин — сами придумали проблему, которой раньше не существовало и сами ее решили
Вот честно — не вижу проблем поставить java и селениум сервер. Все работает в таком режиме довольно стабильно, до 80 браузеров на 16 виртуалках. Сколько можно селеноидом сэкономить — 200 метров на винте и 100 метров в оперативке?
Нет, вы не правильно поняли. Я к тому, что главная задача — сократить время на тестирование. и в вашем случае — вы фиксите баги последовательно(так как находятся они последовательно во время запуска автотестов). А в моем случае — все тестируется паралелельно и соответственно фиксятся они тоже паралелльно.
Простите, но вы или новичек в автоматизации или не серьезно ей занимаетесь. Тут есть сразу две проблемы(может больше): 1. При вашем подходе вы не сможете параллелить тесты. 2. При вашем подходе вы вообще ничего не протестируете(упал вход, чинят вход). Вот реальный кейс: разработчики выкатывают патч, в котором кроме изменений в логине(которые и сломали) есть так же изменения в других частях приложения. И вот при вашем подходе, когда тесты зависимы — все будут сидеть и ждать пока пофиксят логин(ну или переключаться на другие таски). А если делать независимы — то при сломанном логине, тесты по документообороту, обмену сообщениями, чем угодно еще, что входило в патч — будут идти и давать результат. В итоге уже после первого прогона станет более менее ясно — сломали логин или вообще все сломали и не выкатываемся
Он и сейчас не дешевле у нас в Варшаве
Вообще, это от английского tool, инструмент. Не тулзы, потому, что речь в единственном числе. В разных уголках мира говорят по разному. Но вообще статья не про название, с удовольствием отвечу на комментарии к сути
На самом деле наши длительные кейсы не просто 20 минут ждут. В наших приложениях люди проводят длительное время. И например, через какое то время использования некоторых функций нашего приложения - появляются различные события. Вот эти события мы и проверяем.
Автотест - это автоматизированный тестовый сценарий. Абстрактный пример такого сценария
Регистрируем пользователей А и B
Заходим в приложением пользователем А
Отправляем заявку от пользователя А к пользователю В
Заходим в систему пользователем В и проверяем, что он получил заявку от А
Процесс тестирования у нас проходит несколько этапов. Условно, это может быть Stage1, Stage2, Stage3. На каждом из этих этапов мы запускаем наши автотесты. По различным причинам, отсутствие багов при тестировании на stage1 является необходимым, но не достаточным условием для отсутствия багов на stage2 и так далее. Каждое из окружение имеет свои особенности, поэтому для гарантирования качества мы не можем пропускать эти этапы.
Публикация это появление какого то изменения на продакшене. Новая функциональность, например. Мы не готовим релиз(большое количество новых фич) в течении нескольких месяцев. Мы делаем частые публикации(которые, необязательно маленькие). Количество публикаций - переменная величина, но в среднем их больше 10 в неделю
Как я уже писал в самой статье мы сознательно отказались от использования моков и костылей в автотестах, и решили тестировать только пользовательские сценарии. В наших приложениях есть пользовательские сценарии, которые занимают столько времени. Другими словами - событие "B" происходит через 20 минут после события "А". Мы не пробрасываем сообщение в шину, не используем бэкдоры, а проверяем саму систему. Сама система это делает. Поэтому вопрос о плохом тестдизайне не стоит.
К сожалению, нет. Система очень сложная, с кучей микросервисов (речь уже о тысячах). Подсунуть побыстрому что-то в базу не получается по многим причинам, в том числе и потому, что система живая и поддерживать такие костыли очень сложно. Запросы к базе у нас, по большей части, это SELECT, для каких-то очень важных точечных проверок.
В среднем у нас происходит 8 запусков автотестов на одну публикацию. До всех преобразований 1 запуск длился около 2-х часов. Мы обратили внимание на эту проблему, когда заметили, что последний тест завершается через 15-20 минут после всех остальных. Сейчас в каждом запуске у нас не остаются длинные автотесты в конце, а значит тестировщик раньше увидит результат.
Под поднятием приоритета, вы, наверное, имеете ввиду [Order()]. К сожалению, он действует только в рамках одного неймспейса. Организовать 2к+ тестов в одном неймспейсе чисто семантически не очень правильно.
Понятно, что магии нет и все равно где то приходим к использования Thread.Sleep, но речь про совсем грязный код вида thread.sleep(TimeSpan.FromSeconds(30)), вместо явного ожидания появления элемента.
В наших тестах есть все виды взаимодействия: api, ui, запросы к базе через драйверы и т.д. Атомарность кейсов соблюдена настолько, насколько это возможно. Но, как я писал ранее, мы решили придерживаться парадигмы автоматизации пользовательских кейсов, а не проверки кнопок и менюшек в вакууме. Мы пишем приемочные тесты, а они, по своему определению, не могут состоять из одного шага и проверки. Да, какие то шаги пересекаются, но они максимально упрощены.
Еще раз отмечу, что при высоком уровне паралеллизации - большое число ложных срабатываний связано с максимальной загрузкой железа виртуалок из-за огромного количества запросов. Думаю, вам не нужно объяснять, что если cpu и диск под 100%, то о стабильности автотестов можно не мечтать.
Идея была реорганизовать все кейсы таким образом, чтобы они запускались от наиболее долгого к наиболее быстрому. Когда речь про 1 поток, то разницы нет. А когда речь про многопоточность - появляются нюансы.
Представьте ситуацию, когда у вас 10 тестов и 5 потоков. Из этих 10 тестов есть 3 теста, которые выполняются 15 минут каждый, остальные 7 тестов выполняются по 2 минуты.
И в нашем случае получалось, что 2 из 3 долгих тестов попадали в один поток, что делало минимальное время прохождения запуска: 15+15 = 30 минут. Как бы быстро остальные тесты не бежали - все равно запуск будет ждать этот долгий поток с двумя тестами по 15 минут.
После наших преобразований у нас в каждый поток попадает только 1 долгий тест, и получается что минимальная продолжительность тестового запуска уже 15+2=17 минут.
Мы пробовали перейти на selenoid/zalenium еще в 2017 году. Я тогда услышал про них на одной из конференций и вдохновился идеей.
Проблема заключалась в том, что не закрывались конейтейнеры с сессией. Наши администраторы выдали мне CentOs, в ней был такой баг. Плюс, мы не получили какого-то прироста в скорости или в количестве, а главным преимуществом я вижу возможность использования разных версий браузеров. Что для нас тоже не совсем актуально, так это то, как большинство наших пользователей используют последнюю версию браузера.
Так что selenoid добавлял новые проблемы, но при этом не решал существующих задач. Хотя я думаю, что мы скоро на него перейдем, судя по отзывам его уже хорошо допилили.
Вот я про удобство и говорю — у меня совершенно нет проблем ездить на большом автомобиле, чем на самокате. А по поводу стабильности: чаще всего просто обновлять библиотеки надо не сразу а недельки через три, когда коммьюнити уже протестит. Вообщем для меня это очень похоже на биткоин — сами придумали проблему, которой раньше не существовало и сами ее решили
Вот честно — не вижу проблем поставить java и селениум сервер. Все работает в таком режиме довольно стабильно, до 80 браузеров на 16 виртуалках. Сколько можно селеноидом сэкономить — 200 метров на винте и 100 метров в оперативке?
Простите, но вы или новичек в автоматизации или не серьезно ей занимаетесь. Тут есть сразу две проблемы(может больше): 1. При вашем подходе вы не сможете параллелить тесты. 2. При вашем подходе вы вообще ничего не протестируете(упал вход, чинят вход). Вот реальный кейс: разработчики выкатывают патч, в котором кроме изменений в логине(которые и сломали) есть так же изменения в других частях приложения. И вот при вашем подходе, когда тесты зависимы — все будут сидеть и ждать пока пофиксят логин(ну или переключаться на другие таски). А если делать независимы — то при сломанном логине, тесты по документообороту, обмену сообщениями, чем угодно еще, что входило в патч — будут идти и давать результат. В итоге уже после первого прогона станет более менее ясно — сломали логин или вообще все сломали и не выкатываемся